@Baker, thanks for the community file, it works a treat. :) There is one more thing I would love to add, the current -heapsize is crazy small, is there a way to make the default 64000 instead?

Would this cause problems with anyone else wanting a lower heapsize? 

Ok what about this idea instead :-
(taken from the source files - common.c)

FIXME:
The file "parms.txt" will be read out of the game directory and appended to the current command line arguments to allow different games to initialize startup parms differently. This could be used to add a "-sspeed 22050" for the high quality sound edition. Because they are added at the end, they will not override an explicit setting on the original command line.

I searched the source files and could not find this implemented but if it was, it would be perfect. I could then create a command line for my MOD. I am trying to make this as easy as possible for new people wanting to play the game and avoid modifying shortcuts.

Also I checked for the map model bug where some were black and everything looks exactly like the original Fitz. 

The default heapsize in Mark V always was 64MB or the equivalent of -heapsize 65536

Do you mean 640MB like 10 times the allocation?
If so, I can understand that because you use a ton of media.

[ #1 - YES really 640 MB -heapsize 640,000]
[ #2 - NO I meant 64 MB. -heapsize 64,000]

If #2, that's in there now. If #1, sure I can do that but I thought you meant 64MB. 

"Also I checked for the map model bug where some were black and everything looks exactly like the original Fitz. "

Glad to hear that.

I spent several hours carefully planning the lighting optimizations back at the time and checked each step many times over, precisely to avoid that kind of issue. Although the lighting code is complex, I've always been disappointed that issue slipped through. 

@Baker, ignore my previous post, the memory is indeed set to 128Mb, I thought it was a memory problem because when I changed resolution I was getting the following error:

SetPixelFormat failed:

I assume this is the fault of my video driver because eventually I can get past this error and the engine works fine. I was trying to set video settings of 1680x1050x32

Thank you for all the help with this release. I know you have been crazy busy lately, thanks for finding the time. :) 

SetPixelFormat: Engine requests to operating system (Windows) "I want 24 bpp and stencil buffer". It wouldn't be the amount of memory allocated to Quake. Your guess about the video card is as good as my guess, seems likely.

I made community.lmp cause sound to default to 22050. ;-)

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

Can mp3 be used to replace .wav files in maps yet? Would love some nice HQ ambiance. 

Another tiny issue, not sure if it is unique to Fitzquake Mark V - I was watching a longer demo when suddenly the screensaver activated (or at least the monitors turned black). I moved the mouse to wake up the monitors (the pause demo playback feature is great btw) but when the picture came back, the gamma and contrast had reset. 

mp3 is just a compressed .wav file [more or less].

mp3 is lossy compression of a sound file like JPEG (.jpg) is lossy compression of a graphics file.

mp3 is to .wav as ...
jpg is to .tga or .bmp or raw.

Use http://media.io/ [or another tool] to convert your mp3 to wav. 

I'm not sure when the next update will be (late summer?) but I'll address that.

I hope you found PGUP/PGDN keys too when you play a demo [fast forward/rewind]. 

I think mechtech meant using mp3 files for single sounds in a map. 

What I was trying to illustrate: why?

FitzQuake doesn't support jpeg [lossy image compression]. You use tga.

Why do you need to use mp3 [lossy sound compression]? Convert the mp3 to wav.

mp3 engine code is super-ugly and you don't really want the engine to do it, you want the operating system to do it. This is more of an Inside3D discussion, but you know how H264 is often supported by hardware? You want hardware doing the mp3 decoding ideally just like you want hardware doing video decoding H264.

Short version: mp3 is messy to support and that's ok for a soundtrack, but the idea of using mp3 instead of .wav is a really bad one for some sort of the same reasons as why png is slow, pk3 is slow and video encoding is slow even with hardware support. 

A compressed sound format. .wav is a huge waste of space. MP3 or ogg even flac. If I was to use say a 15 minute background loop wav is too fat.

if sound file decompression is too much overhead I get it. 

It chews up a ton of CPU (lessen some by hardware support). Quake supports at least 8 simultaneous sounds, 9 if you count sound track.

One mp3 playing via operating system API (Mark V) = no big deal.

You don't realize the unreasonableness of your idea in regards to performance.

Which is ok, I get that. A few years ago, I would have grilled engine authors with the same thing.

Your idea on the surface seems totally reasonable. mp3 = common = why not lots of them. I know the engine side and I first ran into this with PSPQuake which had both a software version (mad.cpp) and a hardware emulation option.

mp3 playback is resource intensive.

Unfortunately, I don't have an MH/Spike/LordHavoc or Divverent here to better translate this to "layman's terms" of the world of suck that goes on with mp3 decompression.

It's ok for a single "stream".

If I have done a "communication fail" here, I'm to blame. But watch Quakespasm's CPU utilization when playing MP3 or imagine why Quake 3 or DarkPlaces don't support what you propose and realize that my poor attempt to phrase the problem in an easily digestible way is a bad reflection on me but the actual problem is real. 

Are we talking about mp3 music or mp3 sound fxs?
Ogg support would be nice for ambient sound though. 

The above is a discussion about using .mp3 instead .wav files.

(ogg has all the same issues as mp3, as ogg is the lossy compression of a sound file that requires the cpu to continually decompress it adding "stress" and a potential new "lag factor" into the mix [i.e. several mp3 sounds at same time].) 

I understand now your explanation was fine. 9 decompressions happening at once=BAD Idea 

Baker thank you for your dedication to Quake 

so how do modern games do it then? D3 had it, for example, and it's not even that new anymore.

I'm not actually asking for this, but I'm not really understanding what the big deal is. I understand that it takes time to decompress the audio files, but surely it's not so bad as to impact engine performance? 

I think that goes outside the scope of this thread.

But would be good material for another thread to discuss this in further detail (Does Saurbraten do this? Did they think about doing it and rule it in or out and what reasons did they have? What does szo + co. think about this idea? As I understand it, DarkPlaces does not do this ... did LordHavoc rule this out? Did Remake Quake try to talk MH into this? Did MH reject this idea? Etc. etc.)

But these thoughts exceed the scope of FitzQuake Mark V and my knowledge almost entirely ...

[And it is so out-of-scope I'd like to not have it in the Mark V thread, since I can't even be a knowledgeable participant in the discussion ... if you see what I mean ...] 

The time you spend decoding an mp3 is time you don't spend waiting for the disk to read a much larger wav.
If you're worried about decoding time, you can always offload it to another core before initiating playback.
You really won't notice it unless its done in bulk, but that's the same as everything else done during load time.

The real problem with mp3 is that its patented and thus the only way a gpl program can legitimately decode one is to make use of an operating system feature that does the magic for you, resulting in portability issues. ogg vorbis is thus a better choice on account of third-party libraries being legal in the usa and stuff.

In fte, its 200 lines to load+decode mp3 (using the win32-os-based decoder), and 400 lines to load+decode ogg (using libvorbisfile).
Sure, the sound code needs a slight tweak too, of course, but while you're doing that you get bonus points for running the audio mixer on another thread (if your mixer is on a different thread, your on-demand decoding will be too, and yes, I got a not insignificant fps increase from that). 

So, following that quake character re-modelling thread (see General Abuse) - I learned that the QuakeForge engine supports an .mdl format that simply uses 16-bit vertex accuracy, rather than the standard 8-bit vertex accuracy.

What's more, the guy doing the new monster models is using blender, using an .mdl exporter that has the option of writing to this 16-bit .mdl format.

My question is this:

Does support for the 16-bit .mdl format sound like something that's easy enough and worthwhile enough to be worth considering? 

Because then there's another incompatibility between engines. 

if it was implemented in a way so it's only used to replace existing 8-bit models, in the same way that external texture support only works by replacing existing quake textures...

No worse than external texture support then, right? 

if you want to mess with the format, i would highly advocate MD2 format because the grid's granularity is calculated per frame instead of per model. that right there would give a huge boost to fidelity.