Spy, you know I think you are awesome.

I am email free! And I love it!

If it needs to be done privately, I guess you could send a private message at QuakeOne.com. 

i cannot reach you at QuakeOne.com

btw, fitz08, has the very same issue 

I deleted some private messages over there, you can try again (but really since they upgraded the forum there, I don't know if that was problem or not) or upload to Quaketastic.

My gut instinct is that I think this is a driver issue that will magically disappear at some point once nvidia does an driver update or 2 on your machine.

They probably introduced some sort of stencil bug they introduced since ...

1) It doesn't happen in Quakespasm which doesn't use stencil by default.

2) It doesn't happen in the Direct3D version.

3) Didn't happen on your previous machine, no one else has reported a glitch like that. 

Hello, it's me again. :)
I've tried out a few older versions of Mark V, and the problem is still the same.

Now I'm starting to think that it's definitely up to my hardware. Certainly my GPU, because the drivers are so poor. Yes, the latest ones are from years ago.

In the near future, I might install modded drivers to see if it helps. Intel GMA 965 is a special snowflake among the 9xx series, haha. 

You might try the sdl_mark_v_gl.exe in this beta ...

http://quakeone.com/markv/builds/1025_mark_v_beta.zip

Will it work? Who knows!

Had several beta testers with really, really bad/old computers, some which can't run Open GL but the Direct3D works and getting terrific fps.

Worth a shot anyway. 

Yes, the Intel 965 is pretty damn special - it was Intel's first hardware T&L part, the drivers are absolute cack and the hardware itself is actually slower than the prior (software T&L) generation.

As far as I'm concerned: weirdness, crashing, general bad stuff - that's expected behaviour under OpenGL with this part. 

I've tried out the SDL .exe, and just as I thought...

There's no hope. My GPU is the lottery in terms of incompatibility. :P
I'm not giving up yet, though.

I'll just wait until I build my new PC by the end of this year. Modern hardware will definitely handle it better. :) 

Wonder if anyone else is having issues running it. I'm testing a map so haven't had time to really document things but it seems to stutter quite a bit after running for a few minutes. Can't even finish a play-thru.

Before I dive into reporting wondering if anyone else is experiencing the same behavior?

SO far it's just the main mark_v.exe

dx8, dx9 and winquake are behaving. 

The following bug happens in all current versions of Mark V:
- Quick save and quick load at least once.
- Die and press space to restart the level.
- You respawn with death camera (slanted view).

Also, all versions of Mark V are stuttering for about 3-5 seconds every time I launch the game, sometimes also with cracking sound, usually when loading the first map. It's like it's caching something really bad. My machine is pretty modern, so it shouldn't be related to specs. The game is very smooth after it's done that initial bout of stuttering.

Also please consider adding support for OGG tracks. it's more common than MP3 nowadays and seems to be standard for Quake. Also PNG instead of TGA as well, most HUD/GFX graphics seem to be using PNG.

P.S. And maybe don't try to re-route when an opengl32.dll is put inside the Quake folder. I'm just trying to use a wrapper for some extra graphical effects. This one in particular. It works great with Quakespasm.
https://github.com/crystice-softworks/QeffectsGL 

The death cam respawn was reported (by me :D) a while back.

I don't think that ogg is more common than mp3 now... in fact i'd say it's even less common than it used to be, now that the mp3 patents are starting to expire.

I think the reason to avoid loading opengl32.dll is this. 

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. 

 

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. 

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!" 

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. 

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. 

is there a way to set the fog value via an cfg file or fog depends on qc? 

Just use an external_entity file(yourmapname.ent) Put the fog command in there.