somehow D3D isn't honoring the GL_ALPHA_TEST on first texture in the combine

This is what I suspect, yes.

The combine mode should be passing through the alpha channel from the diffuse texture to output, ignoring the alpha channel of everything else. It looks as though it's configured to not do so. Perhaps passing through alpha from the lightmap texture instead, although without a closer examination of the code it's only speculation. 

tmustate_t doesn't look like its initialising the combine_alpha.
which means that tmu0 == disabled, instead of selectarg1(texture)

you can probably fix it by overwriting its non-defaults with the following in the engine:
glActiveTextureARB(GL_TEXTURE0_ARB);
glTexEnvi(GL_TEXTURE_ENV, GL_SOURCE0_ALPHA_ARB, GL_PRIMARY_COLOR_ARB);
glTexEnvi(GL_TEXTURE_ENV, GL_SOURCE1_ALPHA_ARB, GL_TEXTURE);
qglTexEnvi(GL_TEXTURE_ENV, GL_COMBINE_ALPHA_ARB, GL_MODULATE);

the proper fix is of course in the wrapper. 

After doing what Spike said about setting GL_SOURCE0_ALPHA_ARB and GL_SOURCE1_ALPHA_ARB 

I built the Open GL build on accident. Yeah, the wrapper isn't aware of those constants. 

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?

Specs: Underclocked Celeron N2806 with Bay-Trail iGPU. Aero disabled in W7.

Maybe I should whine in QS related threads instead. 

Will this solve such problems?
Download dx9 build 1029 and find out.

Only way to know. 

I suspect that QuakeSpasm will run faster for a number of reasons.

Story from ancient history.

One of the reasons why I moved to D3D9 originally was that I was fed up of poor Intel driver quality (the other reason was to stop people behaving as though they had a god-given right to demand Linux builds but that's another story).

The thing I found however was that, if you write your OpenGL code in a similar style, you'll actually get the same end result. Faster, more stable prformance.

The trouble with Intel drivers was actually programs doing horrible things that NV and AMD were more robust with. But the things that programs did were still horrible: writing to the front buffer, GL_RGB texture formats, lots of tiny lightmap updates.

QuakeSpasm has picked up lots of my old code (or code similar to it) that actually resolves many Intel problems. Example: QuakeSpasm draws directly from vertex buffers whereas MarkV via the D3D9 wrapper needs to shuffle data around in memory and mangle it from glBegin/glEnd calls to something D3D9 can use. That's a lot of extra overhead that QuakeSpasm just doesn't have.

Intel Bay-Trail is a DX11-class iGPU and QuakeSpasm is capable of taking advantage of newer API features to run faster and more stable (it's a complete fallacy that older API features are more low-end friendly). MarkV doesn't even try.

For sure download it and try it though. 

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