Like when you tried to quit of Quake? Is this correct? I'm just trying to understand and get whatever info I can.

Quakespasm is a multiplatform FitzQuake: http://quakespasm.sourceforge.net/ by szo, stevenaus and Sleepwalkr. 

Those 2 features you like (view model correction + widescreen correction). Those are both in DirectQ. 

Yes, froze up my entire system just as I quit the game. I've updated my graphics card drivers, hopefully that helps. 

There's a fundamental bug in FitzQuake and derivitaves (even the latest QS in the SVN has it) where the list of GL extensions and capabilities is retrieved once only, at startup, and then reused throughout mode changes. That can cause crashes as this list actually belongs to the current GL context; it's not global.

A potential crash case would be if you have a switchable graphics laptop and you're switched to the Intel GPU before the context goes down, but subsequent drawing uses an extension that the Intel doesn't have. Not certain how relevant that one is here, but it should be fixed.

A further bug is that it doesn't check extension names with a space at the end. This violates GL spec as the extensions string is specified to be space-delimited; it could falsely detect support for GL_ARB_do_something when the extension actually supported is GL_ARB_do_something_else (sidenote: Doom 3 has this bug too). I don't know of any extensions that this would trip up on though, but it is a potential crasher and correctness dictates that it should be fixed.

One other crasher that I'm aware of and that may be relevant here is that Quake Con_Printfs a "player left the map" message during shutdown if you exit while a map is running; if the context is down when this happens it can cause a crash.

The final one is during Host_ClearMemory; if you free this memory you can crash as the progs.dat code is still accessed until a disconnect fully completes. So if that's what's happening, just zero it instead (which is safe) and let the OS automatically reclaim it when the process terminates. 

See I never implemented string safety stuffs in Mark V because it would have torn a tornado-like path across the source code.

And my plan was to implement a ton of easy-to-understand upgrades like the QIP engine source code did to explain to whoever was interested how to do stuff.

[And changing all the sprintfs and strcpys would maul the source beyond recognition. Yeah techy enginey stuffs to the casuals ...]

One or more of the later part of your list could be culprits in this. 

Thanks for the bug pointers.

Regarding extensions being not per-context: see new commit:
http://quakespasm.svn.sourceforge.net/viewvc/quakespasm?view=revision&revision=781

Regarding Host_ClearMemory(): I think qs should be safe about it (same for "player left the map" like messages during shutdown), but I applied the following nonetheless:
http://quakespasm.svn.sourceforge.net/viewvc/quakespasm?view=revision&revision=782 

The extensions thing is not actually a matter of string-safety; it's a case of if you're using 'if (strstr (gl_extensions, "GL_ARB_do_domething"))' then you will also get a positive on "GL_ARB_do_domething_else". If your GL implementation supports the latter but not the former, then you've got a false positive.

There are already some extensions that follow this pattern, with GL_ARB_occlusion_query and GL_ARB_occlusion_query2 being one example that springs to mind. In practice and of this example any implementation that supports the second will always support the first anyway, but the pattern is there and it's not guaranteed that future extensions will get lucky like that.

However, since the GL_EXTENSIONS string is documented as being space-delimited (see http://msdn.microsoft.com/en-us/library/windows/desktop/dd373553%28v=vs.85%29.aspx - the opengl.org page just describes GL4 where you can no longer glGetString (GL_EXTENSIONS)) the solution is simple.

Just use 'if (strstr (gl_extensions, "GL_ARB_do_domething "))' instead.

That's the bug that both Fitz and Doom 3 have. 

first, thanks for pointing out various bugs that i didn't know about :)

second,

if (strstr (gl_extensions, "GL_ARB_do_domething "))

Won't this fail if the desired extension is the last one in the list? Or is there always a space as the last character of gl_extensions? 

Won't this fail if the desired extension is the last one in the list? Or is there always a space as the last character of gl_extensions?

I've honestly got no idea.

Reading between the lines I'd guess that this might be a reason why the new glGetStringi method was introduced (see http://www.opengl.org/wiki/Get_Context_Info#Extension_list) but I really don't know.

One to check with various drivers I suppose. 

Easy solution, shamelessly stolen from quakeforge:
http://quakespasm.svn.sourceforge.net/viewvc/quakespasm?view=revision&revision=783 

Yeah, that would work.

I'd be more inclined to emulate the glGetStringi method by first parsing into a char** then just iterating through that, but that's academic - so long as it works it's fine.

Incidentally, just remembered to check for space-termination on the entire string, and yes - the string isn't space-terminated, so either of checking with or without a space at the end of the extension name is bugged. 

I think this engine is playing ambient sounds incorrectly.

Example: Run Contract Revoked and load the start map, and then stand in the pentagram in the middle. You can hear the sound cue from the Nightmare selection hall clearly and loudly, which is not the intended behavior at all. 

The hall is right beneath the pentagram, but shouldn't be heard. It's as if Fitz Mark 5 does something to the attenuation... 

DirectQ changes this as well, I think, and DP even more. Sometimes you can even hear the spike shooters from logic gates if they are too close... 

I hate that DP did that, but at least it provides a console command to fix it. 

What is the reasoning in the first place?? 

in DP's case, I believe it was something along the lines of 'I like it better this way'. :\ 

Interesting ...

The sound cut-off distance was brought on par with a couple of other engines. Unaware of the above.

Back in the day, ProQuake raised the sound cut-off distance "to match DOS Quake" to keep fairness against a DOS client in multiplayer (i.e. not fair if DOS client can hear sounds a bit further away) -- although some recent discussion @ Inside3D explores this in more detail. This change found its way into DarkPlaces maybe 5 years when it was noticed DarkPlaces could hear sounds other clients could, and of course found its way into DirectQ (these aren't only clients).

Wasn't looking to alter the intended designs of any single player maps ... and I thought this change was innocent enough but seems not. 

It's easy to just cvar-ize this value (I use "snd_clipdist").

My own use of it dates back to QuakeSrc.org days when it came up originally, and where (as I recall) evidence was presented that this was the original value but had been subsequently changed in a patch. Unfortunately QuakeSrc.org is long dead and it's not possible to provide links, but that's where things stand so far as my recollection is concerned.

It opens an interesting question so far as the topic of "fixing up Quake" is concerned, and I believe that it's similar to the question posed by supporting fullbrights and overbrights - to what extent do you draw the line between "this is the way things are supposed to be" on one hand versus "this is the way mappers/other content creators prefer it" on the other? We're all aware that content exists where using fullbrights and overbrights causes problems with the original design (e.g. using palette entries from the fullbright range for textures which never caused problems in GLQuake), but should this be treated the same or is it something that it's better to keep away from? 

I've been hacking some on the Doom 3 BFG code, and was interested to note that it uses the same method as mine for widescreen FOV: first calculate fov_y based on an ideal aspect (16:9 for D3, 4:3 for mine, although I adjust height for sb_lines too), then calculate fov_x based on the true aspect. 

It opens an interesting question so far as the topic of "fixing up Quake" is concerned

For myself, as far as sound attenuation is concerned, as long as there is a cvar to revert it to default values, then engines can default to whatever they want. Like I said, DP has that option and now I know your engines do so it's a simple matter of including them in config files that run before a mod is loaded.
It's more problematic if you aren't making a mod, but at least the option is there to fix it.

In fact, providing a cvar offers interesting new possibilities for messing with sounds such as fading them out gradually for dramatic effect. 

I'll just use the original sound distance if the single player scoreboard is showing (single player + coop) and if the deathmatch scoreboard is showing I'll use the other value.

Not looking at the source, I'm not 100% sure if the value is client (likely) or server (doesn't seem likely, but I'm not looking @ the source).

I don't like cvars and settings (except for features that help developers tune stuff). 

There's a bug in my map that has a unique component only in Fitzquake. The first room has a pretty large bsp model for some pesky vertex saving. It seems that only RMQ actually allows collision with the model (DP/DirectQ/Fitz don't collide with it at all so I guess this bit is definitely my fault).

However in fitzquake if you move to the far side of the room away from the model it disappears, which no other engine does:

Model rendering properly

Taking a step backward 

fyi the model entity is positioned just to the left of the healthpacks near the middle of the screen, so is definitely inside the room. 

1. ALL engines should handle external bsp collision. Unless you rotated it.

2. You can't fix this unless you can find a way to change the size of the entity's bbox to be smaller. :(