FWIW I just played through Amphitheater Of Abaddon using build 1080 and didn't notice any problems. 

(and that was me) 

Defaults to gamma .75 I can confirm this as I've installed it into new directories 3x this week. I usually reset my config by hand BTW so it's defaulting for sure. 

Heads up that uwjam is performing pretty badly with this mod. Seems the sprites are causing significant framerate issues. I will test some more this evening but wanted to check with anyone else and see if they were experiencing issues.

I just played in QSS and did not experience the showdown. 

I haven't tested uwjam with Mark V but I've played a few other maps that have some frame rate issues despite running perfectly fine in other ports. Not really sure how to troubleshoot something like this though. 

The MarkV D3D9 sprite drawing code is particularly sensitive to high numbers of sprites and will suffer performance problems in those situations.

Basically it looks something like this:

for (int i = 0; i < numsprites; i++)
{
SetState ();
DrawSprite ();
UnSetState ();
}

In order to deal with D3D9's well-known draw call overhead problems, the D3D9 wrapper code attempts to concatenate multiple draw calls with the same state into a single draw call, so that the whole thing can run with fewer draw calls.

The MarkV code (inherited from FitzQuake, in turn inherited from GLQuake) prevents it from being able to do that, because making any state change will break a batch.

Changing it to something like this will help a lot:

SetState ();

for (int i = 0; i < numsprites; i++)
DrawSprite ();

UnSetState ();

By SetState and UnSetState I specifically mean the alpha test state here; the polygon offset state only happens with Hipnotic bullet-hole decals and should be rare enough, whereas texture changes are something that has to happen so that's a state change that you'll just swallow. But this change on it's own should go a long way towards fixing things up. 

Added to the list. 

Recursion is hated in lowest-level coding -- when you look at what is going on at the stack level.

Recursion causes tons of unnecessary stack push/pop slowing down what would be faster loop mechanics inside a single function.

Elegance hates "goto". Yet "goto" dominates the world and well-written low-level code is code that the compiler can reduce to "goto" form avoiding the use of recursion.

/The D3D9 sprite handling is making me think about how to best optimize sprites next round to fit how D3D9 wants the data fed. 

This is just similar to the technique for making dynamic lights go fast - if you have a bunch of work to do, dividing it into fewer large batches will always outperform many smaller batches. Beyond that it's just a matter of understanding what patterns can prevent fewer large batches, and in any 3D API (including native OpenGL) that's going to be things like unnecessary state changes. Typically brought on by things that seem "right", such as unbinding textures/buffers, or putting state back the way it was after drawing an object.

The Quake code is riddled with small inefficiencies and it's death by 1000 cuts. None of this mattered in 1996 when GLQuake only ran on high end workstations, and everybody else had a 3DFX which routed it's drawing through a layer which tried to make something sensible out of it.

Ever bought a new GPU and found that Quake ran no faster on it?

Recursion is going to be down in the noise in any Q1 performance graph. Any decent compiler will automatically generate the right optimized tail-recursion code for you, without you needing to resort to tricksy or cutesy obfuscation. Don't waste time on the small beans.

In an ideal world that D3D9 code would not be needed; you could rip it out tomorrow and start investing time in making your OpenGL go fast, which IMO would be preferable to trying to make the 2 APIs coexist peacefully. The big secret is that Intel graphics are no longer crap, and haven't been for a long time. It's not Intel graphics, it's Quake's use of OpenGL that's crap.

As a general rule, bad OpenGL code will go faster than bad D3D code. But good D3D code will go faster than good OpenGL code. But in order to get good D3D code you need to go native and start writing code that's tailored to D3D's strengths; trying to translate bad GL code into something that tries to do the right thing in D3D can only get so far and will always throw up unexpected glitches and bottlenecks - like the sprites case. 

I was thinking of qmb and to some extent Nehahra extra effects that are in the engine (above and beyond stock Quake sprites). qmb is highly recursed. 

Ah, I'm not familiar with the QMB code although I've been aware of the effects since almost the very beginning. That's something I must rectify. 

I took a look at the real-time lighting prototype you made a few hours ago.

Looking at the source, I thought the dates were funny because you wrote it at the same time as the DX9 wrapper. 

How do I enable vsync and set color depth in Mark V? And for a Quakespasmer just coming around to Mark V, what are some of the notable differences between Mark V and QS, ie. what's the reason behind developing two separate engines that do a lot of the same things? 

vid_vsync 1 (I think away from PC)

Mark V in DirectX 9, has mouse driven menus (if you get used to it and go to QS - you'll miss it), levels menu item, demos menu item, you can fast forward demos, some developer tools and a "find" function in the console - which is handy.

Quakespasm has excellent performance and compatibility with mods etc is very good. But I prefer Mark V overall for the reasons above. 

Mark V does nehahra, whereas QS doesn't, correct me if I'm wrong 

Many of the MarkV features you speak of are not solely markV, but a culmination of other open source software.
Use what you like. But when you get down to brass tacks, gameplay, it's pretty much just Quake. 

MarkV Direct3D 9 doesn't allow changing of colour depth; it's hard-coded to the colour depth of your desktop. 

Thanks. Mark V looks nicer on my machine (better colour depth, smoother gradients than QS) but as dumptruck_ds alluded to I have issues with performance. As a total package QS is tough to beat. 

how could the color depth be better than QS? Is it HDR? 

It should be identical unless the driver is doing some performance/quality tradeoffs behind the scenes. 

Black is a deeper black and fog gradates better in a map like honey for example. I thought it was my shitty monitor until I ran Mark V for the first time to play Nehahra. Performance was slower than QS (laggy mouselook) but it looked great. Too bad I can't show the difference. Could very well be my system which is getting up there in age but the two certainly don't look identical. 

Fog being different would make some sense, because the two different APIs can potentially have different fog calculations, with OpenGL's hint mechanism in particular being quite weakly specified: it's perfectly legal for GL_NICEST fog to give you per-vertex fog, for example.

In general however I would attribute this to your driver just giving a different image, as I said, likely via a performance/quality tradeoff. There's certainly no magic voodoo going on here. 

Ah yes, that pesky driver update that failed on three different occasions is fucking me in the ass, thanks for the insight... 

Hm. Baker... I found something you did and I don't like it :D

I was re-assigning some buttons so now I can use ALT to +attack (I was using the button on my trackpad with my thumb to +attack, but I've found it's less of a stretch -- physically -- to just hit the ALT key with my thumb instead).

So then I hit ALT + M to do a certain key combo that I occasionally use, and the console starts spitting this out at me:

Mute: ON --- ALT-M to Toggle
Mute: OFF --- ALT-M to Toggle

Sure enough, ALT + M puts Quake on Mute....

But I don't want that!

If you want a Mute feature, just make it a console command: "mute" and we can assign it to whatever key we choose.

As it is now, it's interfering with a key combo that I want to do something else....


Ya know, while I'm talking about ALT key combos, I remember suggesting in the past to allow key combos to be bound, so if I actually wanted ALT + M to do MUTE (if MUTE were a console command) I could do it like:

Bind @m mute

(if you made @ designate the ALT key combination)

Ah, on the Old Page #1352 I was thinking about "shift" keys for gamepad binding, but it could also work for keyboards. I suggested allowing any key to be designated at the "shifting" key for combinations....

Do any other Quake engines allow fancy binding of key combos?


Anyway, key combo binding is a "possible wishlist" kind of thing.

Whereas ALT+M = MUTE is a "NOOOOOOOOOOOO!!!" kind of thing :D

And probably a "Only Gunter would discover that undocumented feature and take issue with it" kind of thing ;)