InsideQC Forums

blubswillrule wrote: I try to spell correctly, especially when you meet someone new, grammar can say a lot about people.

I disagree! Bad grammar usually only say 1 thing about people, that it's a 99% chance english isn't their native language.

It was probably done the way it was to save memory since the PSP only got 22 or was it 24Mb of ram...

QU to Metre would make more sense

Also I agree about the floor with a small addition, need to add 0.999 to the higher

1-8 makes it rand between 1.000 t0 8.999 with a floor making it pretty much equal chance to get any of the numbers 1-8

http://tomaz.snowcold.net/news.php

Still has my TomazQuake stuff on it

reckless wrote:i guess older msvc was a bit more lenient than newer versions about pointer errors (shame on you ms)

No it has always errored about using . and -> wrong.

Is it the old 'bragabouthowhardcoreourcardisbyspammingthestringsfullofsupportedglextensions' bug?
:idea: :idea: :idea:

Open gl_vidnt.c, look for this line in GL_Init (line number 609 or thereabouts): Con_Printf ("GL_EXTENSIONS: %s\n", gl_extensions);
And comment it out. :D

Another way to fix ...

Of course it's not from the original code, it's a code change. It seems a little unreasonable to me to expect code changes to be identical to the original code, unless I'm missing a point here.

Yes, I know that Z_Malloc calls Z_TagMalloc, but where else is Z_TagMalloc used in the engine? Nowhere ...

What codebase is this based on?
Like the comment about Z_TagMalloc not being used? and the code you pasted there? Thats NOT from the original quake code, in fact, all the Z alloc code does happen in Z_TagMalloc, since Z_Malloc pretty much does nothing but call Z_TagMalloc.

Nice job Nvidia. 191.xx drivers blow up alot of Quake engines.

The fix is to replace vsprintf with _vsnprintf. Ugg.

Kirk Barnes gets credit for finding this...

That "bug" happened years ago. It's been fixed in just about any engine that has been run on anything newer than a GeForce 2 card.

A ...

tbh im not sure

this is the one from fitz

#define CLAMP(min, x, max) ((x) < (min) ? (min) : (x) > (max) ? (max) : (x)) //johnfitz

looks a bit more clean ill have to try it out and see if theres any difference.

Yeah that one makes the assumption that min is always smaller than max, the one i ...

well the function aint from me its part of fuhquake source later joequake.

actually looking at one of the values it seems b is the value to clamp while a = min and c = max ?

code snippet below

// clamp center of light to corner and check brightness
l = DotProduct(impact, surf->texinfo->vecs[0 ...

thought it was pretty straight forward hmm :/

if the value a is less than the value b then a is used as min else b is min

say if 1"a" is less than 2"b" then min is 1"a" else min"a" is 2"b"

can use it instead of doing if ( a < 0 ) { a = 0; }
like min (a, 0); a will newer get below 0 but it can go ...

#define bound(a, b, c) ((a) >= (c) ? (a) : (b) < (a) ? (a) : (b) > (c) ? (c) : (b))

clamps the stuff to its min/max values Wink very handy.

Would be alot more handy if you specified which of a b and c is min, max, and the value to clamp. I tried to decypher it but failed.

No I dont use Cygwin to do real PSP work, you can but you dont need to.

And no its not the same hardware or the same SdK when doing the real thing.

I use the swedish link ftp.sunet.se, never fails and I got 100mbit connection towards it. Regarding binaries, no idea.

To get it to compile, well, I just use my 2 year old Cygwin install, but I ran the Cygwin setup earlier today and updated everything to latest, thats it, I'm not sure how old my PSPSDK is tho but as far as I can tell from the SVN for it nothing important have changed. It does after all take 5 hours ...