Multisample in Open GL, at least for Windows, has been disabled for ... actually it's been quite a while ... You are the first one to notice ;-)

mh is down on the idea on adding to the Direct3D build. There's a post somewhere in this thread where he discusses why.

I could re-enable it in the Windows Open GL build with some effort of rewriting some things slightly, but in the age of 3800 x 2600 monitors, multisample is going to be hella hard to notice.

Looming as a larger factor -- the Direct 3D build has ...

1) superior frames-per-second performance
2) superior compatibility on older hardware

Direct3D 9 is going to become the main build hardware accelerated build for Windows eventually. 

Thanks!

If you want to join in the fun, grab the current source code and try to compile the Linux version in CodeBlocks on your CentOS and see if it runs ok. Requires SDL 2.0.4 dev.

I haven't had time to raid Requiem for the goodness in the Linux build like video capture and such. 

I'll check the latest builds tonight to see if the flickering has gone away on my system. Should I also check autosave behavior? Anything else?

Lots of irons in the fire lately, I still have more on my todo list --- and I need tackle MH shadow volumes. I don't even have the Mac version quite up-to-date.

/And pesky little issues like ones reported by dwere, yourself (config read order, built-in Quaddicted installer unpack with certain file names like your dll example) and nuisance gremlins remain -- hence it's beta.

Autosave should be fixed. And any information on whether or not the flickering is gone for your machine (and pulsars) would be great! 

The shadow volumes aren't robust, by the way. You're going to find places where they leak through geometry or fly around at odd angles. In terms of shadow volumes they're probably as good as you can get without going towards a realtime light/shadow setup.

So I'd advise them as an additional option rather than an outright replacement for planar shadows. That means the choice comes down to one of two imperfect shadow types, or no shadows. Not ideal, I know, but different imperfections drive different people nuts in different ways, so hopefully it covers enough angles. 

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

This one resolves one of the problems when running a windowed mode the same height as your desktop, and where the mode gets clamped. That being viewport/rendertarget size mismatch. Extra code is in GL_BeginRendering and the #define name should come with a smiley - it's meant to be humourous, not insulting. ;)

This one also resolves a second minor issue where a rendertarget used as a texture needs to be unbound before it can be set as a rendertarget again. Not such a big deal because D3D will detect this and unbind it for you, but still nice to have it done properly.

The wrapper now gets a totally clean run on the Direct3D debug runtimes. 

Hm, I am finding that since version 1.26, activating id1 mirrors will completely freeze me up. r_mirroralpha 1 prevents it from happening.

That's in addition to the weird extra-long delay when loading external textures, which also showed up in 1.26

Might it have to do with these new warnings I get as of 1.26?

Warning: texture_env_combine not supported
Warning: texture_env_add not supported

I also get this one, but it was always there in DX9:

Warning: texture_non_power_of_two not supported

And it looks like the env_combine warning is also present in DX8. But there are no mirrors in DX8, and it loads external textures without an extra delay. 

/me imagines a function name,

#define MAYBE_THIS_WILL_MAKE_GUNTER_SHUT_UP 

the directx version runs uber sluggish for me 

The file in revision B link is named 1027_mark_v_dx9_revision_a.zip. 

Yeah change the revision_a to revision_b to download. 

Also, as of DX9 version 1.26, the fog got uglier again when gl_overbright 1 is set....

It's an issue I reported on the old page (#1217 of old page, if you wanna see the screenshot), but it was improved in DX9 1.25, and now it's back to the previous, a bit uglier, behavior (fewer fog bands on lit wall areas, making a rougher gradient).... 

Played thru ad_mire using mark_v.exe from the 1025 beta zip; no flicker. 

@johhny - awesome.

@gunter - So DX9 1.25 was good, DX9 1.26 fog less good. Right?

@railmccoy - r_oldwater = no issues now, right? 

I'm sure mh is gonna want to know more about the specifics.

I get 700 peak frames per second with basic FitzQuake settings in some areas of the start map just wandering around.

And my machine is rather average. 

@gunter - As the DX9 had more capabilities enabled, I disabled DX8 limitations that I had imposed on DX9.

In the case of external textures, I have Mark V using glMatrixMode (GL_TEXTURE) to perform scaling for texture coordinates to align it with the original texture, a feature which DX8 did not have.

I'll wait for mh comments before delving into it, I noticed changes to the mip-mapping process, etc. 

The AD quake.rc sets max_edicts 8192 for Fitz/QS/Mark V but apparently dx9_mark_v doesn't recognize the command.

Also, textures are still blurred while I have GL_NEAREST_MIPMAP_LINEAR specified in both quake.rc and autoexec.cfg. 

Combine/Add/Fog/Performance

So I don't have to do a new release for Baker to get this fix.

Bug in d3d9_glcontext.cpp, line 409, in "if (D3DSHADER_VERSION_MAJOR (d3d_Globals.DeviceCaps.PixelShaderVersion) > 2)" change ">" to ">=". Oops.

That will fix the engine reporting combine and add not available, and I believe that it will also fix the whole ugly fog business.

With gl_overbright 1 and without combine the engine will do multiple passes blending in coloured fog with black fog. Where combine is available it will do it all in a single pass.

I now believe that the multiple pasees are the cause, rather than per-vertex vs per-pixel or API differences.

This should be reproducable with original FitzQuake or with QuakeSpasm by running -nocombine.

I'd encourage further performance testing after that. D3D9 being sluggish should go away: it would explain why Baker and I get good perf but some others don't - because you're being incorrectly dropped from single-pass to multi-pass the renderer is obviously doing at least twice as much work.

I've a hunch this may also fix Gunter's reported issue with mirrors.

It's the Quake equivalent of NASA's minus sign.

Changes to mipmapping/Textures

I decided that default glTexImage behaviour was insane. You can specify miplevels in any order, with different formats, textures can be incomplete and the whole thing can't be validated until draw time.

So what I did was ignore every miplevel but 0, using that to build the texture. A full mipmap chain is always built and sampler states are used to control level selection. I have to take over mipmap level building myself here too as a result of all this.

So what this means is that the engine is building mipmap levels twice. Once in the regular code, which the wrappper just discards, and once again in the wrapper.

I suggest just calling glTexImage for level 0 in the D3D9 build and everything else will just work.

textures are still blurred while I have GL_NEAREST_MIPMAP_LINEAR specified

Because you have anisotropic filtering set to higher than 1. Nothing I can do about that; D3D defines 3 texture filter modes: point, linear and anisotropic. If anisotropic filtering is higher than 1 then point filtering (the equivalent of GL_NEAREST) is ignored.

A workaround might be to ignore anisotropic filtering for GL_NEAREST modes but I suspect other people would complain about that. 

Both Mark V and Quakespasm use max_edicts 8192, although in Quakespasm you can change it and in Mark V you can't.

GL_NEAREST_MIPMAP_LINEAR specified in both quake.rc and autoexec.cfg

Sounds like a bug in Mark V related the currently slightly borked config execution.

When the beta gets closer to being a stable, I'll make sure your example is ok. 

Mark V uses the stencil buffer for sky draw and the stencil sky draw is in the middle ...

So stencil sky draw is going to wipe it and it looks like you draw shadow volumes at the tail end.

I'm rather stencil rusty at the moment and you're in the thick of it, if you have a quick thought on how to adjust the stencil calls to only use maybe a certain bit, would be greatly appreciated.

I've always read that at least in Open GL, I should be wary of trying to do anything other than 0 or ~0 (-1).

But there's 4-8 bits of stencil available.

Meanwhile, I'll just come up with a workaround because I want to get the next release out.

Then the other school of thought is just firing off the shadows before drawing sky and we'll just say alpha entities don't have them ;-) And shadows on water is just tough luck.

R_DrawShadows (); //johnfitz -- render entity shadows

R_DrawEntitiesOnList (false); //johnfitz -- false means this is the pass for nonalpha entities

Sky_Stencil_Draw (); // Baker: This will draw the sky if there is stencil.

R_DrawTextureChains_Water (false); //Baker -- solid warp surfaces here

R_DrawEntitiesOnList (true); //johnfitz -- true means this is the pass for alpha entities

R_DrawTextureChains_Water (true); //johnfitz -- drawn here since they might have transparency

Yeah, I have to say I like the shadows quite a bit. They may not be completely perfect, but they're still a mighty nice upgrade. 

Unfortunately the shadow volumes need all 8 bits because they increment/decrement rather than just marking specific bits.

What I'd do is split the R_DrawEntitiesOnList (false) call into two.

First call before sky and only draws bmodel entities.

Second call after sky and draws alias model entities.

You then need another clear of the stencil buffer after drawing sky too, but I think that's the simplest and cleanest way to do it. 

Makes sense. Thanks! 

Mark V Build 1028 - Direct X 9, Open GL, DX8

The Direct X 9 build should be fully up-to-date with everything including the latest tweak suggestions from MH and all the revisions.

I often get triple or higher the fps with DX9 vs. the Open GL build.

Fifth and gunter had issues with some sluggishness in DX9, but the latest version should make those problems go away.

Volumetric Shadows

Most easily experienced typing in the console:

chase_active 1; r_shadows 3 // 3 = volume

Volumetric shadows are in the DX9 and Open GL builds, as is MH waterwarp. There is a DX8 build in the zip, mostly for beta testing use as DX9 gets hammered and molded.

Linux Build - Although I didn't include binaries, the CodeBlocks project should be up-to-date for building and would have all the above features. Source code is in the same folder as the download in this post. 

The new shadows look really cool, especially on rotating items.

Anyway, it doesn't look that cool in certain situations such as this (regarding the casting location of the shadows).

However, I think that problem already existed with the old shadow system, so I guess we have to file it under visual glitch. 

Heh, yeah that's what I said above about where they leak through geometry.

In order to solve that you'd need to start casting shadows from all brush and world geometry, and next thing you know you've got a full-blown real-time lighting engine.

Personally I always run Quake without shadows anyway, on the basis that no shadows are better than bad shadows. This just offers shadows that are bad in a different way. 

A blob like in quake 3