Hey, when do you plan to release the version with mlook + windowed fixes? 

Boring engine technicality: MH explained a superior way of handling mouse input in the last day or two that is streamlined and efficient and very reliable and easy to manage.

So at the moment, I'm on a side quest since I don't want to put out two separate revisions that change the input code heavily back to back. Giving me something extra to do before I get this newest revision out and slowing me down a bit at the moment. 

I have to respectfully disagree with the rationale just given for not fixing up FOV. The reality is that hardware has moved on since 1996, and widescreen is now the norm. My own experience is that fixed-up FOV is a basic player expectation and not a fancy engine feature that's only of technical interest - I have a fairly large amount of positive feedback from people who specifically mention fixed-up FOV as a feature that they welcome.

Fixed-up FOV can be implemented without changing the defaults or other behaviour of the FOV cvar. FOV 90 will still give you the correct horizontal and vertical FOV for your chosen resolution and aspect, so everything can still work as expected.

320x200 resolution was not an aesthetic choice, it was a technical one. 320x200 was the old standard VGA mode 13h, meaning that it was the one display mode that was just guaranteed to work on everything. If that mode had been any other resolution, then that hypothetical other resolution would have been Quake's default. 

If widescreen really is the norm, just set FOV to default to 105 instead of 90. This gives correct behavior on a clean install, and doesn't override existing users configs that already have ~105 in their config.cfg or autoexec.cfg 

note that this probably means putting in a hack to ignore the default.cfg value for FOV, if there is one. But messiness under the hood may be worth it if the user experience is your highest goal. 

Why not just add a cvar to toggle between using absolute and aspect corrected fov, having absolute set as the default. 

the question is whether new users will have to change their configs, or whether existing users will have to change their configs. Any cvar like that would require one set of people to change their configs. 

A large percentage of players aren't even aware that the FOV setting exists, or - even if they are - that it can be used to correct for widescreen (the same applies to +mlook). Those that are aware of it can always re-adjust. I suggest doing some research around the usual suspects such as the Steam forums, etc, for info on the specific problems that people have with Quake; these make great targets for fixing in any engine that aims at being accessible to players. Find what prevents people from getting into the game, fix it, and problems go away. This is the same philosophy behind removing the necessity for (but not the existence of) command-line options. Identify the barriers to entry, remove them, otherwise you're just developing for a captive audience who already know everything inside-out and are therefore not bothered by this stuff (and nor are they appropriate people to pass comment on how these things should be handled).

Regarding configs, the obvious solution is engine-specific configs. The old QuakeDev forums raised this as a point that was widely addressed in Q2 ports but all but ignored in Q1. It enables more peaceful engine cohabitation by ensuring that settings specific to one engine don't wreck another.

Again, it depends on who you're developing for. The same old group of people who will always use your engine no matter what, or are you trying to reach out to new players? 

engine-specific configs
oh my god, yes! or use /documents/mygames/engineName/modName/config.cfg 

documents / mygames / engineName / modName / config.cfg 

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.