However, when a lava ball pops up, that causes 5-10 lightmap uploads every frame.

I love you how you worded that ;-)

Lavaball shows up, ruins the day. 

FitzQuake is incorrectly identifying palette index 255 as fullbright

Keep in mind that color 255 is standard Quake is, in fact, a fullbright color.

The Kurok engine that I once used to enjoy playing around with forced 255 to transparent full-time.

And when playing standard Quake with that Kurok engine --- would notice maps and mods that actually used color 255 in textures.

Particular if you hit up conversions ...

http://www.quaketerminus.com/addon.shtml

At the time, that discovery was a real kill-joy for me. Because I loved alpha masked textures and the Kurok's simple treatment of all 255 is transparent was easy as newbie engine developer to work with ...

So let's just say I was disappointed when I found actual maps and mods using color 255 on purpose. 

Hm, I was just comparing FPS in various builds....

I found I am getting significantly better FPS in DX8MV than in DX9MV, which I think is mainly because my FPS drops significantly when I use gamma or contrast, and this affects DX9MV much worse than DX8MV.

And it looks like DX8 1.28 really improved my FPS by like 15-20 points over the previous DX8 1.25 release (and earlier builds)... although the txgamma looks darker/uglier/washed-out starting at 1.28

Just standing in the start map facing forward, 800x600 window, and vid_hardwaregamma 0, mirrors off (and freezeall to prevent lava balls from affecting it):

DX8 1.25
no contrast adjustment = 74 FPS
with contrast adjustment = 70 FPS
turn and face wall, no contrast = 125 FPS
facing wall, contrast applied = 114 FPS

DX8 1.28
no contrast adjustment = 91 FPS
with contrast adjustment = 86 FPS
turn and face wall, no contrast = 142 FPS
facing wall, contrast applied = 130 FPS


DX9 1.28
no contrast adjustment = 90 FPS
with contrast or gamma adjustment = 55 FPS
turn & face wall, no contrast/gamma = 150 FPS
facing wall, contrast/gamma applied = 100 FPS



So, yeah.... With the previous DX8 build I could just use txgamma and even a little contrast and the FPS would be decent.

In the new DX8 1.28, the txgamma just doesn't look good, but darn, the FPS is better! What did you do, Baker?

In DX9, I must use gamma so I get the bad FPS hit.



Oh, I guess I do have another option: I can use vid_hardwaregamma 1 and then my FPS is no longer affected by adjustments..... But my desktop is.

In that case I get pretty much the same performance with DX8 and DX9, though DX9 does 8-10 FPS better when I'm facing a wall, heh. 

Eventually DX9 will have texture gamma.

I would conduct the DX8 vs. DX9 speed comparisons using vid_hardwaregamma 1.

Otherwise, you are throwing an unfair speed penalty on the DX9, because shader gamma isn't free. 

Also, the start map isn't a good choice of maps.

DX9 supports mirrors. DX8 doesn't.

The mirror draw is expensive, haha ;-) 

I also have a lot of I's to dot and T's to cross.

I'll check out whatever I did in DX8 1.28 that affected txgamma appearance. 

@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.