"Then you should be using: " = "Then you should NOT be using:" obviously ...

/Pays the price of not previewing post for 567th time. 

Seems like I managed to leave out a 0, it should indeed say 128000.

Seems like I paid the price even after proofreading! 

 

Will give you a nice round 128 MB heap. 

The laptop I used when I was working on Fitz Mark V has virtually the same specs as your machine (graphics, Intel, Win 7 64, etc.)

I don't have any ideas on why you would have this issue, I will say that Fitz 0.85 should run on your machine if you do the "set affinity trick".

Go to Task Manager running Fitz 0.85 and select fitzquake085.exe and do Select Affinity and select "cpu 0" only. Then Fitz 0.85 will run ok without the clock issue.

http://i.techrepublic.com.com/gallery/6327615-577-460.jpg

The "clock fix" is just the standard deal that is used by engines like JoeQuake, ezQuake, etc. There isn't anything supernatural about it, it just uses a different Windows API call to get the time. I might have even used the code from DirectQ.

In fact, you might try DirectQ. Considering the quirky nature of the problem you have, it could be an OpenGL drivers kind of thing and DirectQ uses Direct3D:

http://mhquake.blogspot.com/ (Downloads on the right side of page) 

Was about to post that after changing my heapsize to 131072 I had played through several maps without crashing... and then everything froze as I quit the program. Joy.

I guess I could just use Quakespasm of course, but after having been away from singleplayer Quake for far too long, instead having played coop using EzQuake, I have become accustomed to how that engine looks and feels. I think Mark V captures this feel well with the widescreen fov and viewmodel corrections.

For comparison, here's how my screen looks using fov 130 with FitzQuake 0.85 and Mark V, and also r_viewmodelfov 130 for the latter.

Incredibly minor detail, and maybe I'm just imagining it, but movement feels much smoother with the corrections. 

Make that Quakespasm. Still, exactly the same as it would be with Fitz0.85.

Is Quakespasm your engine as well, Baker? 

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.