glquake and previous fitzquake versions have the max surf extents set to 512, while winquake and fitzquake .75 set it at 256.

I don't fully understand the 256 limit either, but i figured that since compilers default to 240, and winquake can't take above 256, that i'd be safer with 256. Nobody would intentionally break winquake support by using a higher subdivide value, i thought.

So maybe i should revert or remove the surface extents check, in order to support broken maps like q1tm2_pushplay. 

The easy solution would be for me to recompile my q1tm2. Too bad I'm not going to do that. 

what about the edict limit? 

the current version does not have a bumped edict limit.

I hadn't actually planned on doing this in the future, but i'm not really opposed to it either. 

it just makes some maps able to run like nesp09 that's all. 

Why not restore the previous capacity so the map can load in FitzQuake, but issue a warning so the mapper is informed of exceeding this capacity? 

well, i think i'll actually investigate whether there's a problem loading or running a map with polygons of ANY large size. Maybe the test doesn't make sense in a GLQuake-based engine. 

i have to say, the overbright lighting adds a hell of a lot to the visuals, and gives the engine a real authentic software quake feel. What an excellent release!

I do find the lack of model interpolation a strong enough negative factor to stop me using Fitzquake as my default engine, however; add me to the list of people politely requesting the option in a future version :)

The only 'bug' i encountered was the shells box had a white line at its lower rim (as it touches the floor), quite noticable in some places. But all in all, gg! 

Yes I noticed that as well. 

The only 'bug' i encountered was the shells box had a white line at its lower rim (as it touches the floor), quite noticable in some places. But all in all, gg!

That is actually a bug in the texture on the model, and is visible in all gl engines. If you set gl_texturemode to one of the gl_nearest_* modes, it goes away. Actually, it ALMOST goes away, becuase you can still see individual white pixels now and then.

Anyway, maybe i should edit the texture and put the fixed model up for download. I've been meaning to do that; just never got around to it. 

It doesn't appear on the shell box (20), but does on the shell box (40). I checked it out in the engine I use, nglquake, and it took me a while to find one, I thought you must have been smokin' some wild gear there for a while ;) Then I found one, and found that it only happens with the 40 box. Don't know why I never noticed it before, unless it is more pronounced in fitzquake for some reason ? 

freezes computer on any map load 

and i couldnt find any (is it a gl engine?), ive got screenshots of the same shells box in both engines too 

I just checked and it is present in GLQuake, and Darkplaces, but not tomazquake. Tomazquake is a gl engine, so i'm going to check the source to see what cheap hack he employed to eliminate that problem. 

do you mapper people light maps with software or gl in mind? Just interested to know. 

i looked in the TQ source, and he does indeed have a special hack where he replaces that row of white pixels with a row of more sensible green pixels. I wonder if this would be better or worse than a "fixed assets pack," from a user standpoint. 

that sucks. Can you tell me which OS, video card, etc? Not that i have a clue how to fix it when windows locks up, becuase i don't know (even in theoretical terms) what causes it. 

I light maps primarily for GL, but I also try to make sure software is good or at least playable. 

I light only for GL. i can't be arsed to light for software. i hate lighting enough as it is. 

The way I lit could.bsp was to light the first 1/3 of the map and check it in both GL and software. After that, I just copied the light ents from that section into the rest of the map and then only tested the lighting in GL. In fact, I even forgot to test the final map in software until metlslime mentioned the square spotlights (which I couldn't be bothered to fix). 

if you bind a key to "toggle gl_overbright" in fitzquake, you can run around the map seeing both winquake and glquake lighting at the touch of a button! 

i light for gl, software can suck it 

if you light for software, its more likely to look washed out in GL, but if you light for GL it usually has nice contrast in software i find. Binding a key to "toggle gl_overbright" in Fitzquake as metl suggested would be a good way of testing it out though... 

why light for the bad lighting model nyyyyyyargh 

"if you light for software, its more likely to look washed out in GL, but if you light for GL it usually has nice contrast in software.."

true