I'll have to dig into this one, but if I press the Windows key + D (show desktop), DX9 does an error ResetDevice::failed.

A bit odd since minimizing the window by clicking minimize doesn't have a similar issue. 

I'll have to dig into this one, but if I press the Windows key + D (show desktop), DX9 does an error ResetDevice::failed

Windows-D seems to have different behaviour to minimizing. Specifically, Windows-D sets the window client rect to 0/0/0/0 so it looks as though device reset is failing by trying to create a 0-dimension back buffer.

You can add code to check for attempted mode changes to 0 width or 0 height and just not change the mode if detected; that should do it. 

Just stepping through a frame in PIX to determine states/etc when drawing a '{' texture, and came across something fairly astonishing.

About 80% of the Direct3D calls in a frame are spent on sky.

It's clear what's happening here: the FitzQuake code is changeing state after each quad used in the sky render, so D3D is unable to batch.

I'm going to rewrite this a little to be significantly more efficient and it should hopefully be easy enough to pick up in MarkV.

Meantime back to PIX traces for '{' textures.... 

You may already have this fixed, but I'm finding it useful to step through the calls made and textures used and get a full picture of exactly what's going on.

It's also good to have a record of problems hit and bugs fixed along the way.

FitzQuake is incorrectly identifying palette index 255 as fullbright.

This needs fixing in two places: first in the check for fullbright texels (add a continue if we find index 255), second in the actual palette building (revert index 255 to being alpha rather than solid black in both the fullbright and nobrights palettes).

The first fix will get the general case of most '{' textures. The second fix is needed for '{' textures with fullbright texels. 

Quakespasm in AD 1.5 randomly changes my average fps between 10 and 30 when doing nothing at ad_start. Will this solve such problems?

This must be lightmap uploads. If I turn on "r_speeds 1", every 5-10 frames there are 5 lightmaps updated from the flickering torches. However, when a lava ball pops up, that causes 5-10 lightmap uploads every frame.

QS is using GL_RGBA / GL_UNSIGNED_BYTE for lightmap uploads, iirc MH reported that BGRA and/or the unsigned int 8888 format are needed for faster uploads on some GL drivers. (our batching of uploads is also slightly weird... QS does all uploads for the world, then draws it, then for each bmodel it does the lightmap uploads, then draws the surfaces)

let's continue in the QS thread, if you don't mind trying a test build or two we can probably improve it.

Btw how does MarkV GL perform for you? 

Alpha mask textures are now fixed.

It turns out that D3D texture stage state defaults (which I was setting) are slightly different to GL combine mode defaults (which I wasn't). A bunch of glGetTexEnv calls in a GL engine and I had the correct defaults, then set them up, and everything works.

I'm going to wait a day or so before doing a code-drop in case anything else comes up. 

Yeah, the sky is slow. ;-) I know. I know that you wrote several sky speed up tutorials in the past (Z-fail skys, etc, etc.) . ;-)

Also frames per second is funny topic.

Quakespasm gets a large speed boost from using vertex arrays. In highly complex scenes, it gets a lot more frames per second. With gamma 1 and contrast 1.

Then cashes in much of the gains via shader gamma (33% fps loss sometimes) that gets more expensive the higher the screen resolution

Somewhere in a thread, ericw and I once discussed this topic and I raised the theoretical idea of real-time changeable texture gamma.

Which of course is now a Mark V feature, one that gunter thinks looks better than hardware gamma or shader gamma.

So what on the surfaces looks like apples and apples, is more like apples and oranges ;-)

It's not a straight road, but more of a curvy road.

And engine coding is mostly about pioneering new ideas and having fun.

Any code that I write, I hope someone takes that and uses it --- qbism added automatic underwater transparency from Mark V last year, for instance, I told him how it worked and where to look.

I coded the texture gamma system in Mark V to see what it would look like, after the insideqc discussion ericw started and also see if it could be done. 

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