Pre-1029 it seems to smooth text regardless of the value scr_scaleauto is set to - 0, 1 or 2.

scr_scaleauto 0 - https://i.imgur.com/GpbB9P6.jpg
scr_scaleauto 1 - https://i.imgur.com/ei9oAMk.jpg

All my scr_ settings are included in the above images. Also, yes, I've only seen this in dx9, it never appeared in dx8 or OpenGL. It did sort of feel like a feature, yeh, in fact I think I've seen cvars in other Quake engines for controlling the smoothness of console text.

Gunter - I can't reproduce alt-tab issues in the scenario you describe. 

@rail - yeah, I get that and I've had smooth text in other engine projects. But wasn't intended here as I hope to at some point in the future have integral scaling in the WinQuake build (but it's rather low priority, especially since Mark V WinQuake's stretch mode in video options to some extent provides a similar flexibility).

mh closed the book on that with the latest DX9 fixes in 1029. 

The other flavors of Mark V are good, hope I'm not reporting something that is known or ongoing ;) 

Arcane Dimensions start.bsp - alpha masked vines screenshot
DX8 screenshot start.bsp, which has no combine
DX9 screenshot start.bsp

Arcane Dimensions 1.50 download link:
https://www.quaddicted.com/filebase/ad_v1_50final.zip

1) c:/quake/dx9_mark_v.exe -nocombine (perfect!)
2) c:/quake/dx9_mark_v.exe -nomtex (perfect!)

3) c:/quake/dx9_mark_v.exe (doesn't look right ...)

If I type r_fullbright 1 in the console they become proper masked textures.

Typing fog 0 or gl_overbright 0 or gl_fullbrights 0 appears to have no impact.
-----

So it looks related to combine + multi-texture + lightmaps.

It's a very complicated case. 

Just an alphamasked test image:

http://imgur.com/a/XmcXl 

Yeah -nocombine/-nomtex fixed it. 

The one thing that always annoyed me about QMB -- which has effects for many things --- the Enforcers had no laser effect.

YouTube - Laser Effect in upcoming build

Modelled a bit after AMFQuake, which is a forgotten engine. 

Alpha masked textures must have always been there in prior versions. Or at least I don't understand how the latest wrapper changes could affect it. It sounds like a combine alpha mode is not set up correctly. Combine RGB is, that would be immediately obvious.

Sharp text actually goes back to original GLQuake, and was retained in Quake II. I believe the reason is technical rather than aesthetic: adjacent characters would bleed into each other with bilerping. Nonetheless, it was a very deliberate feature of the original code. 

My gut instinct on this is that it is probably not a wrapper issue.

I'd make the assumption that it isn't a wrapper issue until there is evidence that it is a wrapper issue.

I couldn't say with any level of confidence that the engine is hitting those draw functions in the same state every time, because there is no state manager.

Nor could I say for sure that everything that should be set, is being set.

Remember in prior time when the DX8 wrapper was new and you tested it on TyrQuake and discovered there was glPopMatrix with no push in the code (or something to that effect)?

Is something like that happening here? It is possible. I always assume something "not known to be under quality control" should be assumed to not be under quality control. 

It's possible that the bug is outside the wrapper although I'm not 100% clear on that owing to the following:

* I only see comparison screnshots with DX8 which didn't have combine.

* I only fixed the wrapper bug where combine wasn't reported for PS2.0 hardware quite recently.

So I consider there being some likelihood that it is in the wrapper. If -nocombine fixes it and if it's related to alpha masking, then alpha combine modes seem a possible first port of call to me.

Does anybody have a good test map for these? Preferably something that doesn't require BSP2 or a custom progs? 

Here is a bsp that'll load in Fitz 0.85 without a progs.

http://quakeone.com/markv/media/start_ad.zip

You'll have to noclip up the vines.

I played around with the function in Mark V's gl_world.c:R_DrawBrushModel_DrawSequentialPoly ... if (gl_overbright.value)
if (renderer.gl_texture_env_combine && renderer.gl_mtexable) section ...

And made a number of attempts to explicitly set everything and it looks like somehow D3D isn't honoring the GL_ALPHA_TEST on first texture in the combine. 

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.