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. :( 

bleh. '2' is referring to the disappearing bmodel.
This is due to the bmodel's bbox being linked to too many visiblility 'areas'. the problem is that the engine has a limited number of links to visible areas and when that list fills up, it just starts removing other links and replacing them. 

Ah, hopefully won't be a problem with a full vis then? :/ 

I noticed that dropout in the beta but didn't think anything of it specifically because lots of the bmodels in my map did that and yes it got better after fullvis. 

In my experience, it tends to get worse with a full vis, but you won't know for sure until it's done. 

As well as the problem with it's size (which would affect any brush model type) try this:

gl_flashblend 0
Fire a rocket at it.

Ugly, isn't it? 

Does Mark V support luma on skin textures?