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 ;) 

Do any other Quake engines allow fancy binding of key combos?
FTE allows you to bind alt+m "echo ALT+M was pressed"
(ctrl+alt+shift modifiers and variations thereof are supported. Note that if you use a key as a modifier then you should probably not bind it to something else at the same time - it'll work, you'll just get unwanted binds.)

A workaround for DP would be to write some csqc that looks for modifier keys and then reconfigures DP's bindmaps, which isn't user friendly for multiple reasons. 

Yes, confirmed that MarkV has Alt-M hard-coded to toggling mute on/off.

Other hard-coded key combos:

Alt-Enter: switch between fullscreen and windows.

Alt-Tab: switch between different applications on the OS.

Ctrl-C: Copy.

Ctrl-V: Paste. 

That FTE functionality wold be something really (really) good to import.


I hadn't thought about those other hard-coded combos, since they are standardized Windows behaviors.... so they behave as most people would already expect.

I suppose you don't need to have CTRL+C and CTRL+V function when the console isn't down though. Those would be the only other combos I would think that might potentially interfere with something someone might bind. Few people are going to mess with the TAB or ENTER key, since they already have commonly-used functions in Quake (scoreboard and entering messages or menu navigation).


On the subject of Mute, if I use my media keys on my keyboard to change system volume or mute, it causes a little display window to pop up on screen notifying me of whatever I changed, and that causes Quake to minimize. I wonder if there's a way for Quake to ... not be forced to minimize in this situation.... 

Huh, well, I'm testing it again today and my media keys aren't forcing Quake to minimize.... Well, not consistently. The first time I tried it, Quake minimized but then it restored itself. After that (even after closing and restarting Quake) it doesn't minimize at all, and the overlay flickers in front or Quake for a moment.

So I don't know. It's inconsistent. Probably a Windows thing. 

On the subject of Copy/Paste, I guess even if the console isn't down, you'd want CTRL+V to function if someone was entering a chat message too.

I have often wanted to Copy test from the console, but you can only select text from the line you are currently typing on (by using shift + left/right), but that's never what I want to do. There should be some way to select text that has already been printed in the console, either with mouse select or by pressing shift+up to select previous console lines.

I end up having to use the "copy" command, which copies the entire console contents. 

Source code only contains project files for building on Windows. No makefile, cmake, etc. 

There's a project file for codeblocks. 

Would there be a way to have more that just three cycling autodemos? I test a lot of maps for newbs and like to use Mark V's cl_autodemo. But much of the time I die a lot! Which obv overwrites the dems.

I know I asked for the map name to be added before, I figured heck why not ask for this too. 

Hey guys!

Animations of Weapons and Super nailgun in particular still look choppy when firing, though these cvars are enabled :

r_lerpmodels "1"
r_lerpmove "1"

How to make 'em smooth like in DirectQ, for instance? 

Animations of Weapons and Super nailgun in particular still look choppy when firing ... How to make 'em smooth like in DirectQ, for instance?

This is a content issue.

FitzQuake (which both Quakespasm and MArkV are derived from) works around it in one way, DirectQ works around it in a different way, and both ways have their pros, cons and trade-offs.

First of all, the issue.

The Quake weapon models have polygons for the muzzle flash animation embedded in them, and when the gun fires the flash polygons are moved into the correct position.

When interpolation is switched on, what this causes is for these polygons to move with interpolation, which causes them to swim into view, and dance back-and-forth across the space between the nailgun barrels.

FitzQuake and derivatives work around this by temporarily switching off interpolation if the gun is in a muzzle flash state.

DirectQ works around it by measuring the delta between vertices in the two frames to be interpolated, and if the delta is sufficiently large (above some arbitrary value that was tweaked until it gave the correct result) assume a muzzle flash motion and don't lerp, on a per-vertex basis.

DirectQ used vertex shaders for everything so it could do this quickly and easily, and it really wasn't much more than an extension of the same kind of thinking as the "assume a teleport and don't lerp" check elsewhere in the engine. It should be obvious that this approach is vulnerable to both false positives and false negatives, however.

The correct way to fix this is new content. A set of weapon models that don't include the flash polygons, a separate generic muzzle-flash model, and the QC code to stitch them together.

Meanwhile, FitzQuake allowed disabling it's behaviour by setting r_lerpmodels to 2 - not sure if MarkV and QS do likewise.