Hmm, seems like the original renderer is pretty limited.

For the record, I've tried Qbism, and it does have HUD scaling and alpha channel support for textures, but I get heavy FPS drops in Arcane Dimensions, when there are any alpha channel textures in my line of sight.

Could we do this another way around and emulate the original paletted 8 bit look in OpenGL? In particular the lighting color map. 

....on trigger_changelevel - is this a known issue or could it be my map?

https://drive.google.com/file/d/0B-xkqcrQhLm7Z3RVeVZZUFdwVlE/view?usp=sharing

It's happened multiple times and on demo playback as well. 

I know exactly how do it. It isn't a question of that at all. The question is, of the things I can do, would I find that interesting enough to want to do before the 25 things that do interest me. If you understand.

Ask Spike or mh or ericw or metlslime or qbism or mankrip, part of an engine coding for a leisure activity is wanting to do the task.

@dumptruck_ds .. don't know. If it progresses to become a released map, I'll make a mental note of it after it is confirmed it doesn't crash any other engine. 

paletted look with gl = fte with r_softwarebanding 1 (or just use the softwarey preset). 

re: the map. tested on Quakespasm-admod last night and it was fine. I will do some further tests with other clients this evening and report back but for now at least that engine behaves as intended.

My trigger change level is made up of some weird shapes as you can sort of see in the screenshot. Not sure if that could be a cause or not. 

it seems the tool_inspector is broken on your latest release v36

also i've got a new video card gtx1070, and noticed a very weird video gliches with the fog enabled

there's no such gliches if i'm using quakespasm engine tho 

here's a captured video
http://quaketastic.com/files/demobug.rar 

 

Yeah, Pritchard reported the tool inspector issue a while back and then a couple of others later on.

I saw the glitching in your video. Could you give me "viewpos" coordinates and map name (or as an alternative the demo which gets me the same information).

I'm guessing since it only happens in certain frame, it occurs when a lavaball pops into view.

Quakespasm and Mark V and Mark V D3D all draw very differently, so the different behavior isn't unsurprising.

I'll make a note to try to recreate the next time I have my hands on a NVidia card machine. Since NVidia updates the drivers all the time, it is a possibility that this is a driver issue that will go away in a future driver update, but I'm not going to make that assumption.

Thanks for the high detail issue report. 

i've updated nvidia driver to the latest version

this glitch is only happens when the fog is enabled, disabling the fog removes the problem
would you mind if i'll send the map
to your mail? 

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.