@NightFright

For me the big deal is that Mark V has a really hard time loading MP3 files on my WinXP netbook. I've heard another person say something similar.

When loading a decent-quality MP3 track inside Mark V, the entire game literally freezes up for over 20 seconds while a glitched menu sound (if I just activated external music in the menu) replays over and over until it unfreezes, and then the music starts playing.... I manged to find some re-encoding settings that reduced the quality of the MP3 a lot and got that freeze delay down to 5 seconds....

However, when I use OGG files (by renaming things or hacking Mark V with a hex editor to replace "MP3" with "OGG") then the song loads almost instantly, with only a 1 second delay or less.

So yeah, it's a real issue for me, and not just some weird irrational preference for certain formats! ;) 

Add: I'm not sure, but since you can reliably identified and recreated the circumstances in multiple engines, it gives me something to think about. 

Gunter, I just want to point out that it is impossible to play ogg on Android or an iPhone (without unacceptably chewing up metric shit tons of CPU -- hence the frames per second would be absolute trash --- because it is an obscure format and hence does not have hardware decoding in the processor) while because mp3 uses hardly any cpu at all because it has hardware decoding built into every phone/PC/device on the planet.

Plus the Mac version of Mark V plays mp3 via Apple API via hardware decoding using nearly 0% cpu. ogg being an obscure format that no companies ever use, there is no Apple API for that.

I care that your Quake works right, but you already found a solution that works for your computer issue with mp3 by cheating around with something that happens to work on Windows.

So your personal issue is solved.

My issue is I want things to work the same on all 5 platforms that Mark V supports.

Why the hell would I want to support an obscure music format that can never work on the 2 mobile platforms that I like with Mark V.

Why would I also want to recode the Mac version to support a shittier music format that uses more CPU? Oh -- and since I couldn't use Apple API I would have to rewrite the music code.

And the Quake .mp3 sound tracks are available everywhere, like on the Steam page. Case in point, this guy is links to it. Also Travail's soundtrack is mp3.

Also why the hell support more than 1 music format?

Shall we figure out new graphics formats like .bmp or hey let's do .gif!

The only engine that can't play mp3 is DarkPlaces, and to be blunt --- DarkPlaces is an extremely shitty engine for playing Quake because it made itself so damn incompatible with a lot of Quake mods.

I'm just communicating my point of view.

I don't care if people discuss it or what not, discussion is always a great thing -- environments where you don't find discussion or arguing are sterile and mindless. You might consider listening to my point of view, though --- I have one too! Haha 

mh, yeah, I was being overly-dramatic because you were doing the same. But you've remained clam and respectful in your recent post, so I will do the same (funny how that works).

Sure, I would normally take your word for it, in areas of engine programming, but not when you are making statements that are clearly exaggerated and misleading.

Of course, in your original post on the matter ( #1757 ) you pointed out that Mark V already supports OGG through DirectShow, which you knew because you were the original author of that code, but Mark V is hard-coded to only look for MP3, and supporting OGG should just be a matter of adding support for other extensions, but, you said, "I can't say what kind of work would be involved in this change."

After that tip, irlyap and I found we could hack Mark V to allow OGG files, and PRITCHARD made the amusing comment: "It makes you wonder what ogg did to Baker - murdered/kidnapped family I guess - in the past to make him think 'I have this perfectly good DirectShow support in my engine. I should ruin it and only use it for mp3 format music to ensure that my users have to work harder than with other engines!' "

irlyap made the comment that it would be like "adding 3 characters" which is when you pointed out it would not be THAT simple, which I'm sure is true, but the paragraph of reasons you gave (which you recently re-quoted) is the problem.

I'll just take one part of it as the crux (though I believe the entire quote is trying to make it sound more complicated than it actually is):

"making decisions such as which format has priority over others (not so clear-cut - how do you decide between a high bitrate inferior format vs a low bitrate superior format?)"

So, since you have coded multiple-file-format support before in DirectQ, did you actually DO that comparing of bitrates?

I already know the answer: No, of course you didn't. Comparing bitrates of various file formats would be a completely ridiculous thing to do. There are several Quake engines that support multiple formats, and I bet not a single one of them would dream of doing something like that. The only decision you have to make as to what takes priority is, "do I want MP3 or OGG to have priority?" and the answer to that is already quite obvious for Baker! Heck, I'm thinking that decision would happen automatically if the coder didn't want to specify a specific order -- the engine would just play the first format it came across according to it's internal list of formats to look for....

In #1764 irlyap pointed out that OGG was already " listed in Mark V's file extension look up table" and he guessed that there must be some code that explicitly ignores of forbids it. Then just a couple posts after that, both he and I pointed out that you don't need to do any of that overly-complicated stuff -- just add support for OGG with preference for MP3, and that's it. Sure, that's likely more than adding 3 characters, but I know it's nowhere near as complicated as the quote you brought back up, after we had previously "patiently explained" that none of that was necessary....

Now, maybe your original intent wasn't to make it sound overly-complicated and you were just considering options.... You did also say in that same old post, "I absolutely do think that people should make the effort to do all this, of course. But it would need some guidance as to what the end-user expected behaviour is. ... it would be nice to see players striking up a discussion among themselves about how they'd like to see these kind of decisions work out."

The expected behavior is just as I said (and maybe irlyap explained a bit more thoroughly in #1768 though he spoke of 3 example formats when all you need are 2). Allow support for MP3 and OGG in that order of preference. Or, stated more simply: just allow the engine to look for OGG files if it doesn't find MP3 files! How hard could that be?

Baker's objection to OGG has never been that it would be difficult -- he just wants Mark V to be The Engine of the Future, and OGG doesn't exist in his Perfect Future! (or something like that!).


Now, before there are any slippery-slope arguments like "Where do you stop? If you add one format, you have to add hundreds more..." -- Nope, all anyone is seriously asking for is a second format, OGG. So you have a mere two formats, and that's all you need. Nobody uses any other formats for Quake music (not that I've heard of -- someone said something about Opus and QS? Is that really a thing? What the hell's an Opus?? Isn't that the penguin from a comic strip??). 

I explained my point of view. I want the engine to work the same on all 5 platforms.

Tomorrow, you might get a new computer and you will no longer care about any of this. 

Ok, I'll address your points.

I accept that Android won't play OGG. No problems with that. But I don't see that as a good reason to say, "Since mobile platforms don't support OGG then I also want to prevent the desktop versions from using OGG when they otherwise could."

You say you want things to work the same on all 5 platforms, but that's never going to be quite true. For example, my WinXP netbook does not have a touch screen, and my Android device doesn't have a mouse.... Yet there are touchscreen and mouse things coded into the engine.... So what happens if I enable touchscreen or mouse on a device which doesn't support touchscreen or mouse? Nothing. Nothing happens. And that's fine. That's how it should be.

So if you allow Mark V to simply look for OGG files if it doesn't find MP3 files (simplest way of stating it), what would happen on an Android device, even if I had OGG files installed? Nothing? Would just nothing happen because Android won't play OGG files? So it would be no different whatsoever from now? That's what should happen: Nothing.

So there would be no harm done if a WinXP computer, which can easily play OGG through DirectShow, were allowed to do so, but a Mac or Android would simply do Nothing because it can't play OGG. For the user's benefit it would just be as simple as stating, "Mark V supports MP3 as the primary format, with OGG as an alternate format if you have a Windows computer with DirectShow which is capable of playing OGG" (and face it, Windows users are likely the majority, so it's not a trivial number of users we're talking about).

"Why support two formats?" For convenience of the users. I'm not the only person who has asked for OGG support in the past -- I only started asking when I found OGG magically fixed my freezing problem with MP3s (and I suspect Dutch had the same problem). Yeah, I can hack a workaround, but then I have to offer my hacks to other users who may prefer OGG for various reasons, and I find that "solution" to be ... ugly.

Nobody is asking for more graphic formats, and nobody is asking for a multitude of music formats. But yeah, apparently OGG was a fairly common format for the Quake soundtrack... otherwise there wouldn't have been multiple people asking for it.

And what would be the harm if just *Nothing* happened on platforms that don't support OGG? While at the same time allowing OGG to be used on supported platforms by simply allowing Mark V to check for an OGG file IF it doesn't find an MP3?

The benefit is that it helps users who either have MP3 problems in Mark V (like me), or users who already have the soundtrack in OGG format installed....

Pros: Benefits/is more convenient for some users.
Cons: None?

Is that accurate?

I mean, this isn't a case where you have to specifically tell android to NOT play OGG because it will be slow and crappy, is it?
Isn't it the case where Android (or Mac, or whatever) will simply do Nothing if an OGG is present? Because that's exactly what Mark V does now when an OGG is present! 

"Tomorrow, you might get a new computer and you will no longer care about any of this."

You keeeeep wishing that, don't you? XD



(And I still don't know how to make quoted text appear grey.... How do people do that?) 

And then I found THE FAQ thread.... Which told me the codes, which are very similar to BBCode but not exactly the same.... 

Baker, download this model and drop it into a map using Quoth custom_mapobject or AD misc_model and set the skins to 0 and 1.

I tested with an isolated clean install of Quake and MarkV Dx9 and your newest build. Only the new build displays these models correctly.

http://www.quaketastic.com/files/models/redfield_model.zip

Thing was a bitch to make, so its nice that newest builds of all the engines (DP untested as yet) can display it properly. 

I think everything is going to work ok for DX9 with the masked models.

screenshot: red tree masked model now renders leafy style in DX9

I'm not actually modify the DX9 rendering, but in this case was able to determine what the DX9 hated and do it a bit differently to get it pretty close to what it should look like. 

Just curious, what was different between the two mdl's that caused one to work and the other not? 

This is great Baker, thnx.

Yeah would be interesting to know. Its the same model only skin difference. 

The red skin has fullbright pixels in it.

If you do "imagedump" and look at the fullbright skin generated ...

http://quakeone.com/markv/media/autumntree_fullbright_pixels.png

You can see dark red that would technically show up in pitch black with no lightning.

(Really the texture probably shouldn't -- like it might have glow in the dark pixels to the extent that dark red is , but it happens in map textures all the time too, haha.).

So it was using a combination of OpenGL capabilities at the same time that doesn't normally happen in Quake with alias models (.mdl), so the Direct3D wrapper wasn't prepared for that situation or at least never tested in that situation.

/Short version: Was a DirectX wrapper thing 

I gotta fix this POS tree asap. I'm gonna kill this fu*king thing! 

I had the palette set to no brights, goddmanit! 

This should be a meme or something 

I'm drafting court papers against mtPaint right now. No brights was loaded in the palette. FRAUD. 

Ok, the tree has been DEALT with. The evil brights are gone and the tree now displays in Dx9 Mark V as intended:

Directx9 Alice Quake Map
https://i.imgur.com/mnSnXW1.jpg

There is also a womans shoe model in an bubble with alpha applied and it seems to display as well. There is still a visible transparent layer across the models that does appear in the 1.99 release however.

Thank you @Baker and everyone.
I'm going to celebrate now with the mixing of chocolate and milk... 

^Does NOT appear in 1.99 I should say^ 

Just say "there is small rendering glitch in Mark V DX9 in one area and I'm told that it will be looked into and fixed in the engine if it can be".

If I can fix it, it'll get addressed. I wouldn't stop the show because of that. 

http://quakeone.com/markv

Download: Windows - DirectX | WinQuake
Download: Linux GL | Linux WinQuake

Changes:

* Sky entity support (redfield)
* Alpha masked models w/fullbrights fixed in DX9 (redfield)
* Ctrl/Shift bind firing/console if on server (gunter)
* Linux "Cache LRU link_active" fix (Dr. Dumb*uck)

Also available are a couple of alternative/requested builds: extra builds 

Just related a note, (as I've reported before) my func_illusionary guy with his fullbright pixels still isn't transparent unless I set gl_fullbrights 0. The same goes for weapon models except the axe when I have a ring (unless custom weapon textures are used, which contain no fullbright pixels). 

Now, a fun story!

Oh my gosh.... I just went on a very frustrating adventure to try and make one point... and ended up with several points to make.

So to do this, I decided to try out Mark V's "install" command for map pack from Quaddicted. I've never messed with this feature before.

I tried "install qump" then I went to Single Player, New Game (because Mark V's "map guessing" feature is supposed to make that work)... but... it didn't start Qump.

So I looked at how it was installed, and I see that everything was put directly into the id1 folder....

So I checked the Qump readme, which explained that everything should be installed to a Qump folder.... But I scanned down and saw that the first map was titled "Beginning" (by PRITCHARD!), so I tried "changelevel beginning" -- map not found.

So I looked in the id1/maps folder and saw all the maps were actually named qump_[something], but there was no qump_beginning.... but I saw a "start.bsp" which had been installed.... Ok, that must be it, BUT because of unpacked files not taking preference, doing "changelevel start" will not go to that map!

Ok, so let's start over. I do "uninstall qump" ... NOPE! Mark V tells me the qump folder does not exist.... But.. you just INSTALLED it that way! argh!!!

Ok, I MANUALLY delete all the files that Mark V installed, using the list it told me in console. Handy.

And I notice that it overwrote my id1 start.lit file with qump's start.lit file.... *grumble* So I'll have to replace that with the correct lit file later.

Now, I remember people saying something about specifying a gamedir to install things to with the "install" command, but the HELP info for "install" doesn't tell me how to do that....

Soo.... I just guessed it would be something like "install qump qump".... buuuut that doesn't work, and produces an error message that I find unhelpful:


Need the game to install or the entire URL with
the http:// in it
Example: install travail or install [http://URL]

The version of libcurl used does not support
https:// at this time


So I give up on that and come to the conclusion that I dislike the install feature and will just install everything manually from now on!


I noticed when removing files that the qump.zip file has been downloaded to a id1\_library folder, so I just unzip that and it already contains the Qump folder, making it very simple to install correctly.


Next I switch to the qump game dir and start a New Single Player game, and I'm in the qump start map (because it's correctly named start.bsp, making map guessing completely unnecessary).

So am I happy now? Nope! I finally got to the (only) issue which I started out wanting to illustrate: Mark V does not play the background music for this single-player release from Quaddicted because it's in OGG format!! XD

So I started up DirectQ (mh's engine!) since I knew it supports both MP3 and OGG (with preference for MP3) and did "game qump," and to my surprise it automatically tried to exec an autoexec.cfg file in the qump gamedir!! Which is now the third issue I have previously argued for in Mark V, which mh has strongly argued against, which I have later found to already be incorporated into his own quake engine!


So let me just go through this checklist:

[continued in next post, because I write more than 5000 characters!] 

[continied]

So let me just go through this checklist:

Mark V:

1. Failed at correctly installing with the "install" command (and overwrote one of my lit files), and I couldn't find in-game help info to tell me how to do it correctly. So I had to install manually by just extracting the zip file, as usual.

2. The "map guessing" feature failed to help whatsoever, because in the first situation the start.bsp was installed to the id1 folder, and Mark V gives preference to the pak files (yeah, that's the Quake default, but it shouldn't be, because if someone has copied new files, like this new start.bsp, that should obviously take priority -- I guess that's issue 2.5). Then, once I installed qump correctly, the "map guessing" feature was pointless because the map pack correctly has its own start.bsp... and even if it didnt, I could have used the Levels menu to select a map.

3. Mark V does not play the background track because it's in OGG format, even though (on my system) Mark V can easily play OGG -- it's just hard-coded to only see MP3 files.

4. If I had set up my own cfg files in the Qump directory with any special configurations I want for Qump, Mark V would not run those for me when I switch to the Qump game folder....



Compare this to DirectQ, which is old and no longer being developed:


1. No difference in the first step -- I have to install the qump folder mahually. But since I know I have to do this, I wouldn't have to go through that annoying experience I had trying to use Mark V's install command!

2.5 Even if I had installed incorrectly into the id1 folder, DirectQ would have handled it correctly because it gives preference to unpacked files!

3. DirectQ automatically plays the background music because it hasn't been hard-coded to ignore OGG files.

4. DirectQ automatically runs the autoexec.cfg file in the qump folder when I switch to that gamedir (just the autoexec, not quake.rc), so any settings I want to use for qump will be automatically applied, as they should be.


Now, I'm not actually considering switching to DirectQ, but damn, it did EVERYTHING better in this example!! And each of these issues are things I have strongly argued for in Mark V. And ironically, every one of these things are things that mh has argued with me about, taking the opposite position! Well, not specifically on the "map guessing" feature -- I don't think he's said anything about that, but DirectQ also has a map selecting menu like Mark V does (which is the most correct option for starting custom maps).

mh may suggest that he made mistakes by including those features in DirectQ (he's done that before: #1640 ), but I'm serious here: mh, don't sell yourself short -- these features I've just encountered were great additions to DirectQ, because they "just work" and make things easier for the user without getting in the way or causing problems.




Now, back to the only point I was trying to make when I began this ordeal: some single-player map packs at Quadiccted contain the soundtracks in OGG format (as that was a pretty commonly-used soundtrack format for Quake engines), and Mark V, even though it could easily play them (though not on every platform, I understand), will not do so because you basically won't allow it to look for OGG files.... So... Mark V is (intentionally, in this case) not compatible with maps packs like the following, which contain OGG soundtracks, ranging from 1, 4, up to 11 songs:


https://www.quaddicted.com/reviews/rotcs.html
https://www.quaddicted.com/reviews/quck_demo.html
https://www.quaddicted.com/reviews/func_mapjam9_2.html


These are just the ones I found when specifically looking.... Are there more? I would expect so.

You've said compatibility with single-player releases from Quaddicted if one of the main goals of Mark V, so why deny compatibility to the platforms (like Windows) which are easily capable of playing OGG if you would simply allow it to do so?


And oh yeah, all those other issues which I have argued for in the past, which just happened to come up when I was testing this example:

- No "map guessing" -- it causes me problems in addition to not working or not being needed.

- Unpacked file preference -- if a user installs unpacked files, those are obviously what he wants to use rather than the defaults stored in a pak.

- Exec autoexec.cfg when changing game dir -- if a user has an autoexec in a game dir, he obviously wants it to auto... exec it for that game.


Well, that was fun! XD