I've seen his implementation of it, and it looks superior to anything else when it comes to the weapon being in the right place. Methinks. :E 

MH is right as not having widescreen correction eats away at vertical FOV, narrowing the range of what is on-screen vertically. FOV was never intended to penalize vertical visibly, it was just that everyone used 4:3 resolution in the CRT era (640x480, 800x600, 1024x768, etc.)

This is a flaw. 

Download: http://quake-1.com/docs/utils/fitzquake_mark_v.zip

Readme: http://quake-1.com/docs/utils/fitzquake_mark_v.txt

Widescreen FOV correction, dynamic lights properly affect moved/rotated brush models, dynamic light bleed-through fix.

All entities are colormapped (colored dead bodies, etc. - like if in coop and you die or play against bots, etc.)

Demo rewind (PGDN) and fast forward (PGUP) of any demo the user plays via "playdemo"(and pause pressing pause key).

(The startup demo sequence is not user-initiated and that sequence is not meant to be paused or messed with as it is a game preview.

You must use the playdemo command like "playdemo demo1" to have demo pause/rewind/fast forward available.) 

mp3 tracks support. And boring stuff you won't care about, although documented in the readme.

Download: http://quake-1.com/docs/utils/fitzquake_mark_v.zip

Readme: http://quake-1.com/docs/utils/fitzquake_mark_v.txt 

what about that infamous whiteroom bugfix

i assume thats still not fixed 

It's on the to-do list. I haven't worked through the potential solutions. I understand the underlying issue involved as szo and MH explained what causes the problem. 

fitzquake_mark_v_r7.zip please 

I followed the same naming pattern, I kinda of thought you'd know the URL but still ...

http://quake-1.com/docs/utils/fitzquake_mark_v_r7.zip 

Hi, loving the fov/gun/various other fixes in this, especially the clock fix so that the game runs at the proper speed, however as with your "Fitzquake Plus" I keep having an annoying issue - after playing for a while, the game freezes up completely, with the last sounds played looping over and over, then after a few seconds the screen turns a solid color and the sound a single tone. I can't ctrl+alt+del or do anything other than forcing a shutdown by holding down the power button. Previously this has only occured after playing for an hour or so, but today it happened after just a few minutes. I assume it has something to do with my computer having multiple cores, but I can't really pinpoint the problem. It's an ASUS G73JH laptop which I've had for two years, and I think it has only frozen up/crashed two-three times if I'm not taking these Fitzquake issues into account.

Here are my system specs:

Windows 7 Home Premium 64-bit
Intel Core i7 Q 720 @ 1.60GHz, 1600 Mhz, quad-core
6GB Installed RAM
ATI Radeon HD5870, 1GB VRAM

And my Fitzquake command-line parameters:

-width 1920 -height 1080 -bpp 32 -zonesize 2048 -heapsize 12800

I haven't played using Fitzquake 0.85 for long enough to see if it'll happen there as well, as I have the clock bug with it running too fast - that's why I've used Fitzquake Plus in the past, and now Mark V. Any input/advice on this is much appreciated. 

It's probably worth while to test using another engine (eg Quakespasm or FitzQuake0.85) to check that the problem is not one of bad hardware/overheating. 

Then you should be using:

-heapsize 12800

That means 12800 KB. Which is about 12 MB.

Although not a sure thing, this is likely why you are crashing. 

"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.