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. 

Or the inter-quake model format is already supported by a handful of Quake engines.

http://lee.fov120.com/iqm/

And yeah, works in exactly the same way as external texture support. 

That sounds like a good compromise. And +1 for IQM. 

I'm only suggesting this because it looks like that capnbubs guy is making some absolutely nop-notch and faithful remakes of the character models, which even an old fuddy-duddy such as myself thinks are cool.

So it got me thinking that it's a shame to have to be stuck with 8-bit vertex accuracy on those models if it's easy for capnbubs to export versions of those models in a better format...

Just tentatively dipping my toes into the water here really... 

There used to be an "extended-BSP" format which allowed you to bundle high-res textures etc with a bsp file - the extra data was zipped in a lump attached to the end of the file. Because existing quake engines were happy to ignore any junk appended to the end of a file, they would load in any engine.

You could do something similar with an extended .mdl format. It would be a bit fiddly to add the extended coordinates there. The way to do it with no duplicated data would be to split the 16 bit coordinates into a high and low byte, store the high byte in the regular mdl coordinate data and the low bit (offering the extra precision) in the extended data lump.

Care might have to be taken that this method didn't parse models which already have a lump of extra data on the end. Which models have that? Any saved by QME 3.0 - the extra data is things like skinnames and model groupw which the editor wants to preserve (3.1 has its own file format instead) 

Spike basically said "already doing this in FTEQW, if you run sound in separate thread is not problem".

I have the next 2 versions of Mark V planned out, but don't expect to be working on those until late summer.

There is a chance that the "ogg instead of wav" could be in the 2nd future revision.

Meanwhile, in two separate projects goldenboy and Dr. Shadowborg are targeting FTEQW which does Fitz 666 protocol and bsp2. DarkPlaces does bsp2 and IQM.

There is ample opportunity to play around with those features even now in other engines. 

I just wanted to know why decompressing oggs or mp3s is such a problem for quake. 

24 hours ago I had only considered "what might go wrong" or how someone might abuse the feature (turn every .wav into an 11 MB .ogg or .mp3 and then blame the engine and demand "you must fix").

Then it occurred to me that you can make a laggy map with bad r_speeds in a map editor. I had already changed my mind prior to Spike's post, but I had the idea of pre-emptively decompressing to .wav on gamedir change.

Spike's method is far better than that.

Not the first time someone thought "this feature would be bad" and later changing mind.

I actually look forward to playing around with this. 

How to get rid of mouse acceleration completely? It's switched off in the system and I use -dinput and m_filter 0
, couldn't find anything else in readme.
But still get inaccurate mouse input like with a bit of acceleration - depending on the speed I move my mouse with, not just distance.

It is specific fitzQuake problem, I don't have this in DP or FTE or other quake games. 

-noforcemparms
-noforcemaccel
-noforcemspd

or all 3.

http://www.quakewiki.net/archives/console/commands/quake.html#p--noforcemaccel

Both WinQuake and GLQuake have this issue, FitzQuake isn't unique. And the code causing the issue you refer to is "not well liked" by hardly anyone. But it is in WinQuake/GLQuake so like +mlook, the behavior is destined to remain in this engine so that keeps with the original Quake behavior [whatever they could have been thinking ... ??? ]. 

it seems more and more that fitzquake gets called out for behaving in some ways the same as glquake.

At the time i thought it made sense because the target user is someone who is switching from glquake to fitzquake, so their configs should continue to work (i.e. i didn't change the defaults of any pre-existing cvars.)

Many years later i guess people install fitzquake before any other engine, or they are switching from more radically different engines like darkplaces, which have very different default behaviors.

So i should probably change all the default settings in the next version to "good settings." 

There are plenty of settings that should be default without having to change the config; mlook on, mouse wheel up/down changes weapon, console speed higher (terrible with large screens) and console/sbar text changes size to match screen resolution. 

There is sadly annoying stuff in default.cfg hiding in pak0.pak too:

* F11 key zoom alias that changes sensitivity and default.cfg
* Keys could be improved to default to WASD with Q and E for swim up/down
* "Reset to defaults" in the engine has unpredictable behavior because Quake didn't reset cvars, so re-running default.cfg does not fully default.
* The +/- sizeup and sizedown keys confuse if accidentally pressed and these are in default.cfg living in pak0.pak

Also the original QuakeC source didn't support both impulse 10/impulse 12 weapon switching, some single player mods like Castle of Koohoo or Duke of Ontranto (and far more) impulse 12 does not do anything.

[Avoiding mentioning too much how in original Quake (or Travail or Marcher or ...) in coop if one player grabs silver key and dies, key is gone and map is effectively broke as no further progress is possible ... relevant to exact topic ... I suppose not]. 

In coop, the keys always stay just like the weapons (but unlike them, they fire their targets correctly).