@gunter - DX9 1029 build is current one. MH did a lot of fixes based on your comments. 

"The one thing that always annoyed me about QMB -- which has effects for many things --- the Enforcers had no laser effect.
"
Ya I added an effect to the enforcers and those laser, though I like the little lines around the effect of AMFQuake...

btw speaking on QMB effects Ralf and I added the lightning effect which JoeQuake added later, just the image/splash not the cl_true_lightning.
(i cant remember Ralf's Quake name hmm).. 

Mark V - 1030 Beta Build

- QMB Enforcer Laser when QMB is enabled Lasers video
- Bloom option in only Open GL build (r_bloom 1) Bloom Video
- DX9 alpha masked textures temp workaround until mh patch

r_bloom 1 doesn't save to config. I view bloom as a bit of novelty.

It is also a performance killer and I think the code is probably inefficient -- but since its a toy around feature that's ok.

Tonight, might see if I can resolve some of the issues others have noted and maybe get out a 1031 build. And if mh has a patch tomorrow, do that.

Then comes an extended break with the hopes that will be able to do more updates in the spring some time. 

Ah, I had no idea you did that in Qrack.

Do you have a link to your current source code? I'd like to compare notes.

The lack of a laser effect always ticked me off about QMB, haha.

But until very recently, didn't have an engine with QMB available, so never thought about it. 

Re-reading ... I didn't know you created the lightning gun sparks in JoeQuake either. But it doesn't surprise me at all considering effects ideas is "your thing" and you like experimenting with those ideas, like how fast rendering is "MH's thing". 

http://www.quaketastic.com/files/tools/windows/engines/Direct3D9-Wrapper-2017-01-17.zip

Then comes an extended break with the hopes that will be able to do more updates in the spring some time.

I guess a code drop is in order then.

This one includes:

* Alpha mask texture fix.
* Sky polygon batcher.
* Guards against 0-dimension video modes. 

http://quakeone.com/qrack/ 

if you compare jq0.13dev to any qrack you'll see what's diff, that was the base i started on; and the first file I focused on was gl_rpart.c ;) 

1) MH's revised sky draw is a pretty decent speed boost for the scrolling sky.

2) I needed to know whether or not MH was right about color 255 not supposed to be fullbright.

Original WinQuake color 255

In the above screenshot, notice I took care to stand next to a wall with lighting.

The brownish color on the walls is color 255, which is surrounded by fullbright white (color 254) and the black area is non-fullbright red (color 79).

Color 255 isn't generally a very useful color. It is rarely used.

But in WinQuake it is acting as a fullbright color. 

I haven't checked but I have a good degree of confidence that the colormap has it as a column of 255. So from the perspective of the colormap it is fullbright and I'm probably wrong.

Where things get tricky is how you interpret index 255 because '{' textures should be able to have fullbrights on them too, and 255 cannot be both fullbright and alpha in a '{' texture.

It's also the case that in all of ID1 no BSP texture uses index 255 (I checked).

There's also this in the colormap generation code in qlumpy (https://github.com/id-Software/Quake-Tools/blob/master/qutils/QLUMPY/QUAKEGRB.C#L233):

note: 254 instead of 255 because 255 is the transparent color, and we don't want anything remapping to that

So I can say with a good degree of confidence that even though 255 is represented as fullbright in the colormap, it is not intended to be actually used for anything other than transparent. 

Where things get tricky is how you interpret index 255 because '{' textures should be able to have fullbrights on them too, and 255 cannot be both fullbright and alpha in a '{' texture.

I think it has to be transparent, otherwise fence textures would cease to exist as a feature. Since it's transparent, it should not be added to the fullbright mask. And alphaedgefix should be used to fill it in with neighboring colors.

On non-fence textures, it should be fullbright since that is how it works in all versions of the game (software and accelerated) that support fullbrights. 

@mh - It disturbed me that such a behavior difference occured.

I wanted to know exactly why Windows + D caused a problem. Here is the reason.

Dumping system messages:

WM_WINDOWPOSCHANGING wparam: 0 lparam 18fab0
WM_GETMINMAXINFO wparam: 0 lparam 18f7b0
WM_NCCALCSIZE wparam: 1 lparam 18fa88
---------
(Windows + D show desktop, Quake will run a frame here because the message queue is empty -- we have not received a WM_SIZE message yet so we don't know we are minimized.)
---------
WM_NCPAINT wparam: 1 lparam 0
WM_GETTEXT wparam: 1fe lparam 18e580
WM_ERASEBKGND wparam: 5011197 lparam 0
WM_WINDOWPOSCHANGED wparam: 0 lparam 18f890
WM_MOVE wparam: 0 lparam 99016b
WM_SIZE wparam: 0 lparam 1e00280

(Minimized runs frame here, we received WM_SIZE already so we are ok!) 

Beta Build 1031

1- Correct alpha masked texture support in DX9

2- MH faster scrolling sky rendering (DX9, DX8 and Open GL)

2- Resolves a DX9 + "Windows key + D (show desktop)" issue.

Should have one more build later. 

Just been doing some testing comparing texture gamma ("txgamma") to shader gamma (which will have the same result, if not the same perf, as full-screen desktop gamma, which I didn't test).

Visually they're not identical. This should have been obvious, but wasn't, at least to me.

With texture gamma the calculation is pow (texture, gamma) * lightmap

With shader gamma the calculation is pow (texture * lightmap, gamma)

Shader gamma feels more "right" because it applies gamma as a post-process after the entire scene is composited.

You can't deny the performance of texture gamma, and it does give a richer look which can be more visually appealing.

To make texture gamma give the same result as shader gamma, you should also gamma-adjust the lightmaps. pow (texture, gamma) * pow (lightmap, gamma) because exponents are distributive over multiplication. 

Thanks for the calculation comparison analysis.

Yeah, texture gamma and shader gamma have differences. You'll notice Gunter perspective that the polyblends look better with texture gamma. Meanwhile, I wonder about transparent brushes/models which is a "double application" scenario with texture gamma.

Ironically, with texture gamma, I had to modify the FitzQuake texture manager to be aware of textures intended for blending and exclude them from texture gamma (example: the optional QMB particles are blended) to avoid "double application" (although I doubt the final color is technically "gamma-correct" according to the calc). 

I'm not all that caught up in this topic.

I think frames per second is important, but I also think fps above 72 in single player is a bit superfluous. Because Quake physics acts up around 250 or 300 fps (killer lifts, missed triggers on maps like E3M2. 144 fps ... which matters because some monitors, hopefully isn't too bad.

Anyway, like I said, I'm not caught up in this ...

Here is Mark V DX9 and Quakespasm (Mark V Open GL would lose substantially). Quakespasm is set to gamma 1 and contrast 1 to keep shader gamma out of the equation.

But we'll have mirrors on in DX9 just too give DX9 some extra work to do ...

http://quakeone.com/markv/media/dx9_and_quakespasm.jpg

For fun, here is Mark V DX9 and FTE. DX9 Mark V is using external textures.

Spike's FTE is probably the fps champion of all Open GL engines.

http://quakeone.com/markv/media/dx9_and_fte.jpg

MH's DirectQ? Yeah, DirectQ smokes all of the above in a curb stomp which not even close.

http://quakeone.com/markv/media/directq.jpg

My Win 7 laptop has rather modest specs, anyone with an actual "good" graphics card is going to see way higher fps than above.

Anyway, anything above 72 or arguably 144 fps in single player Quake isn't too useful anyway. 

Has anyone ever tried to disconnect the rendering from game logic in Quake? I feel like that'd be a nice thing to have, then we'd be able to run at any FPS we liked and avoid the bugs mentioned above.

I also feel like it would be a giant pain in the ass to figure out and actually implement... 

DarkPlaces has it.

DirectQ had it with a tiny inconsistency that someone picky like me or Gunter would notice, otherwise I almost acquired it from DirectQ and inside Mark V is a partial implementation of retaining some of the improvements from the attempt (more consistent clock timers).

All modern Quakeworld engines have it.

FTE has it on steroids.

At some point will happen in Mark V. 

I know that unborked physics at higher fps in on the wishlist for a bunch of speedrunners. 

Mark V 1032 Beta - Windows, Linux, DX9, DX8, Open GL, WinQuake

Source Code

Features Vs. Mark V 1.2

- Very fast "triple the fps" DirectX 9 build courtesy of MH
- WinQuake looking water warp in Open GL/DX9 (MH again)
- Volumetric shadows - r_shadows 3 (MH again)
- Sky speed up in Open GL/DX8/DX9 (Yeah, MH)

- Linux Open GL build (thanks to JimBob for testing, Spike for debug tips)
- Linux WinQuake build

- Resize on-the-fly windowed mode in all builds (except DX8). Yes, even Linux. Tried to make the Linux build fancy. May have succeeded.

- QMB enforcer lasers available video

- Improved performance on NVidia cards
- 2 Extra options in video menu for convenience.

- Other things, no doubt. But what were they? Scroll back in the thread ;-)

Hopefully resolved the remaining significant issues, like dwere's context creation failure message. Attempted to add texture gamma to DX9 and then ended up with a blank screen and plenty of wasted time, killing the opportunity to add true rotation and even get the Mac build running. :(

Engine coding sucks like that sometimes, but I won't pretend to not be irritated about missing a few items I very much wanted to get done.

/All feedback and any issues reported do get read.

Next update is likely in the spring. 

In DX9 only, models with fullbright pixels still can't handle transparency (like an illusionary player model, or the gun view models except axe). gl_fullbrights 0 makes them transparent again.


Hm, there is still a big difference in the water warp effect in the Winquake version as compared to DX & GL. The Windows one just doesn't warp as much, and is less noticeable. 

Software Quake waterwarp is resolution-dependent. Run it at 320x200 and you'll see a very different effect to if you run it at higher res.

The waterwarp code I wrote is resolution-independent.

IMO the software Quake behaviour is undesirable.

More discussion, test cases, etc here: http://forums.insideqc.com/viewtopic.php?f=3&t=5827

You'll notice that my warp code reverses the X-axis direction but is otherwise good. That's something I intend to fix some day (the X-axis bit, not the otherwise good bit). 

Ah, I see. I agree about the undesirable part. 

Binaries still work on KDE without need for re-compilation.

The laser effect is neato -- kinda like they're being squeezed out of the gun. Would make for a decent "shooting star" effect. Might be nice if they could be toggled off for the player (like the FVF Laser Android class), while still being enabled for the enforcer. But not a big deal *shrug*

Winquake crashes (seg. fault) when I try to drag-expand the window too much. Appears it may be trying to snap to fullscreen (like a snap-to-edge behavior). That doesn't bother me, though, cos I likely won't be using Winquake, and that's an easy situation to avoid anyhow. Otherwise runs fine.

Anyhow, please ignore that until the spring. And thanks again for bringing Mark V to Linux. I will enjoy playing Quake with it in the meantime :) 

I had the same reaction as Gunter that the GL waterwarp effect has a surprisingly strong distortion. I guess I was used to running WinQuake at a non-minimum resolution back in the day.

It's not a big deal, but out of curiosity: how feasible is it to expose "warp amount" as a console variable?