News | Forum | People | FAQ | Links | Search | Register | Log in
Mark V - Release 1.00
http://quakeone.com/markv/

* Nehahra support -- better and deeper link
* Mirror support, "mirror_" textures. video
* Quaddicted install via console (i.e. "install travail")
* Full external texture support DP naming convention
* Enhanced dev tools texturepointer video inspector video
* IPv6 support, enhanced server capabilities
* Enhance co-operative play (excels at this!)
* Software renderer version (WinQuake)
* "Find" information command (ex. type "find sky")

Thanks to the beta testers! NightFright, fifth, spy, gunter, pulsar, johnny law, dwere, qmaster, mfx, icaro, kinn, adib, onetruepurple, railmccoy

And thanks to the other developers who actively provided advice or assistance: Spike (!), mh, ericw, metlslime and the sw guys: mankrip and qbism.

/Mac version is not current yet ...; Linux will happen sometime in 2017
First | Previous | Next | Last
 
Well, I've got about a dozen Quake soundtracks (id1, hipnotic, rogue, shrak, malice, impel, xmen, n64 etc), all of them in 256 kbps VBR OGG, de-emphasized where necessary. I'm pretty happy with this collection as it stands and don't feel like repeating the process for MP3. I've read about Baker's reasoning on how MP3 is faster to access, but I'd still like an option for OGG support. And who knows, we might all switch to FLAC at some point.

Yeah, I get the reasoning behind avoiding opengl32.dll, in the old vanilla installations of Quake (and other games from that era) it's a 3dfx wrapper, which causes problems on modern systems. But I feel like the current solution of removing the option of using any wrapper at all is a bit too heavy handed. 
 
In theory MarkV already has .ogg support provided you have a DirectShow-compatible codec installed. As a rule of thumb, if you can play it in Windows Media Player, you can play it in MarkV. I know that for a fact because I'm the original author of that code.

In practice MarkV is hard-coded to only search for files with a .mp3 extension. Supporting .ogg as well should be just a matter of adding support for the other extension, but I didn't originate that part of the code (or at least I don't recall doing so) so I can't say what kind of work would be involved in this change. 
Ogg Vorbis Is History, Use Opus Like QS 
 
 
Ah, ogg files.

Supported on Windows, the Mac, the iPhone. Widely used in the commercial games industry and in the music industry. Supported by the Unreal engine and the Source engine.

Oh wait. That's mp3. None of the above support ogg.

My Android phone can play ogg. If you open an ogg file in Google Music, it will convert it to mp3 and then play it ;-) That's Google's idea of ogg support.

Ogg fits in nicely in the category containing 8-Track, BetaMax, Laserdisc, Zip drives, the Zune, PlaysForSure, HD DVD, Windows Mobile, Windows Phone.

Short version: Oggs? Fuck, no! Plus you don't even know why you are using ogg, Quakespasm supports mp3 -- so what was it that made you think "ogg" to begin with? Answer: You don't know, because no one using ogg ever knows why they are using ogg, especially because in the real world, no one is ever doing oggs because nothing supports them.

/Against my better judgment, I click submit! 
 
@mh
In practice MarkV is hard-coded to only search for files with a .mp3 extension. Supporting .ogg as well should be just a matter of adding support for the other extension

Thank a lot for this tip, turns out Mark V DOES play OGG if you just open the .exe in a hex editor and search and replace all instances of .mp3 ASCII text with .ogg. Really makes you wonder, why not just add literally 3 extra characters to the source code to enable OGG support? It really seems like Baker's got some personal agenda against it, since literally every other modern Quake engine supports OGG, because why not. Oh well, I suppose there's no need to discuss this further. 
The Smell Of Napalm On The Forum 
There's something wonderful about reading Baker raging against ogg, and then immediately afterwards reading about how despite Baker's strong desire to prevent it by explicitly coding it out, someone has hacked it to work with a find+replace.

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!" 
Doesn't Sound Complicated At All? 
Implement a generic audio library and comment out ogg from the list of supported formats. 
 
why not just add literally 3 extra characters to the source code to enable OGG support

I obviously can't speak for Baker but this wouldn't be just 3 extra characters. It's only 3 characters if you directly replace the existing .mp3 support with .ogg support, but of course you then lose .mp3 support.

Adding multiple file format support would involve enumerating files of multiple extensions, sorting them into lists, 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?), and how to handle the inevitable crazy-assed situation where someone has multiple formats in the same folder (some of which may even be multiple versions of the same file in different formats).

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. Multiple end users pulling an engine in different directions is something I can personally vouch for as never ending well, and 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. 
 
Funny thing is, OGG is actually already listed in Mark V's file extension look up table:
https://i.imgur.com/txwPXjA.png

But there must be some code that explicitly ignores or forbids it. Seriously though, just why. It's a relatively popular file format for video game audio.

To enable OGG support find the above bit in a hex editor and replace mp3 with ogg. Simply renaming your OGG tracks to MP3 should work as well, I guess. 
OGGre 
I'm confused... Isn't engine inter-compatibility something to strive for? Considering that all other engines support the format AND the fact that most soundtracks available online are in .ogg, it strikes me as odd that Baker would want to force the user to convert the files in order to use them with his engine. Plug'n'play, man, plug'n'play... 
 
Probably doesn't want bloat. 
 
D:

Ok Baker, I NEED ogg support!

I tried the hacks mentioned above (either renaming my ogg to mp3, or hex-editing mark_v), then, after installing the ogg directshow filter ( http://www.vorbis.com/setup_windows/ ), Mark_V does play ogg.... and it loads in a FRACTION OF THE TIME as an mp3 file of the same file size!

Do you remember a while back, me going through a LOT of testing because I have an issue where loading an mp3 file causes Mark V to freeze up while the file loads? (mentioned in #651 above)

After some encoding gymnastics I managed to get that loading time (during which everything freezes up) down to only like 4.2 seconds for track04.mp3.... Well, I converted it to an ogg of the same bit rate and file size, and it loads in only 1.23 seconds!

So... yeah. That would be the reason to allow ogg files to be found by Mark V (since it is already capable of playing them).

You really don't have to do all the complicated stuff mh mentioned. Just state, "Mark V supports the following formats, in the following order of preference: mp3, ogg."

And let the users sort their own files and formats and bitrates. 
 
Indeed, there's no need to compare bitrates or anything, just let it read formats A|B|C in the priority of A, B, C. And the game folder should take priority over id1, e.g. say you have OGGs in id1 but e.g. Travail comes with an MP3 soundtrack, disregard the OGGs in id1 then, unless there's not enough tracks in the game folder, in which case read the missing ones from id1. I think that's how Quakespasm handles it anyway, correct me if I'm wrong. 
Baker 
is there a way to set the fog value via an cfg file or fog depends on qc? 
@ Spy 
Just use an external_entity file(yourmapname.ent) Put the fog command in there. 
I Don't Quite Sure What You Talking About 
why would i put the fog command in the external ent file? and where exactly should i put it?

i'm using the fog value via the worldspawn. AD mod supports this and shows fog correctly, but it seems kinn's old mod (bastion/marcher) doesn't support fog from the worldspawn, as there's no fog after loading map.

i'm just wondering :) 
 
The worldspawn "fog" key is handled by the engine, it should work in id1 with MarkV (and most engines). Maybe bastion/marcher is resetting it via QC. 
@ Spy 
My answer was for the simple question of setting fog values via an external(.cfg) file, now I see your problem! 
Eric 
i have a map with a worldspawn settings something like
fog_density x
fog_colour x y z

and after loading this map in AD the fog appears correctly, then i put the very same map in the id1/maps folder and run it from the vanilla game
there's no fog at all
until i manually set the fog numbers in the console, what gives? 
@spy 
those are AD-specific fog keys.
Try: "fog" "density r g b" 
Have You Just Tried... 
"fog" "Density R G B"

All on one line for stock id? 
 
Try: "fog" "density r g b"

i put this line fog 0.015 0.35 0 0
into an *cfg file without the quotes, but no avail. 
 
Sorry, put it in worldspawn, not a cfg file :) i.e. the worldpawn key is "fog" and the value is "0.015 0.35 0 0" 
Miracle 
yay, it's working this way. silly me. Thank you Eric and damage_inc 
Permission 
Hey, I require help
Whenever I try to launch any of those 2 executables using:
./mark_v_linux or ./mark_v_winquake_linux
I get following error:
bash: ./mark_v_winquake_linux: Permission denied
Double-clicking doesn't work either

On manjaro, hope anyone can help 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.