A roundabout way.

Or, possibly, if we chased up the link to I3d we'd find some hidden ITS release... :) 

 

This MOD by SOC is not an ARG, FYI 

Moody arc figs modify cargos. Crag modify so cigars my food. 

I have a tiny issue with mark v. My soundtrack mp3 files won't play. I'm sure I have installed the files in the right place, since this is logged:

Current music track: music/track04.mp3

But I'm not hearing it. Either there's another volume adjuster I'm not finding (I tried the CD music volume slider), or perhaps this has something to do with it:

CDAudio_Init: MCI_OPEN failed (266)

I don't have a physical CD player present on this machine, perhaps some virtual ones though. Or is this codec related? 

DirectQ used to work but now it's giving the same error message. Has to be something with my system. Never mind. 

@Mandel: A sincere thanks. Makes me think the world is a better place when seeing high investigations like that.

Anyways, I told Sock I'd do an update for Mark V and once is coming shortly (24 hours or less is the estimate. Maybe with something of interest to Mandel.) 

1. tool_menu command. A conceptual experiment.
2. follow/chase/race your ghost player (type "ghostdemo demo1" in console to follow John Romero around e1m3). A ghost will not pass out-of-sight and will wait for you.
3. community.lmp support (sock wanted this and is a quality solution).
4. Sound limit reverted to GLQuake/WinQuake/FitzQuake 0.85 level instead of the "DOS Quake level" per comments above.

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

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

For reference: community.lmp http://www.simonoc.com/files/misc/community.lmp (This is an alternative to pop.lmp registered Quake check for a total conversion to indicate that Quake should act as if the registered version is being run). 

@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