/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 

Still has all the flaws of standard GLQuake shadows. 

Because you have anisotropic filtering set to higher than 1.
OK, I set it to 1. Fixed the blurriness but now my liquids umm... scintillate? (don't know the exact word for it) in the distance, a bit like old TV static. I suppose this is an either/or situation? 

ow my liquids umm... scintillate? (don't know the exact word for it) in the distance

Original FitzQuake doesn't mipmap water textures and this is inherited from that.

On the one hand that replicates the behaviour of software Quake. It also makes the render-to-framebuffer waterwarp easier because you only need to render a single miplevel instead of the full chain.

On the other hand it causes sparklies in the distance. 

'Scintillating water!'

Put it on the back of the box.

No issues with fullscreen alt-tab and r_oldwater 0 now. Gonna play around with the new builds now and see if there's anything else to report. 

Bendy shadows are neato! (and ghost shadows are amusing) 

Mirror freezeup = fixed!
Window clamping resolution glitch = fixed!
New shadows = neat!
Old stencil shadows = now working too.
fugly fog = less fugly!

Fantastic work, mh!


Issues that still exist:

Delay upon first starting a game still happens.

Using external textures and a skybox, no MP3s, all settings the same, upon first starting a new game (starting Quake fresh before each test), time between telling it to start the game in the menu and when the game actually starts:

DX8 = 3.16 seconds
Dx9 1.25 = 3.17 seconds
Dx9 1.26 = 7.17 seconds
Dx9 1.28 = 6.89 seconds

DX9 1.28 with no skybox = 6.45 seconds
DX9 1.28 no external textures = 2.87 seconds
DX9 1.28 no skybox + no textures = 2.42 seconds

DX9 1.25 no sky + no textures = .87 seconds

So the skybox causes a slight delay, but it's the external textures which are really causing the delay, as of version 1.26

The above tests are running id1. The delay gets worse when I'm running FvF, which may be loading other things like monster skins:

DX8 1.28 = 5.96 seconds
DX9 1.28 = 12.59 seconds

So it seems like it is taking very close to twice as long, which may be a clue, like maybe it's loading the textures twice....



Also still happening as of 1.26, when first setting a full-screen windowed mode that matches screen resolution, I'm instead getting a clamped, bordered window (1024x578) instead of the previous 1024x600 borderless window. But the text in the bordered window looks correct....

Upon restarting Quake after making that setting, I get the 1024x600 borderless windowed mode, but I can tell the menu text is distorted (using scr_conwidth 1.5 -- I previously showed screenshots of this effect).

I seem to be getting that distortion in any full-screen mode (this was happening as of 1.25, but not in any of the DX8 builds), which seems to indicate it's still not quite got its rendering resolution just right in full-screen mode.

Ah, I think it's only happening when it's a full-screen mode with height equal to my resolution (so 800x600 or 1024x600 full-screen modes). It seems like it's drawing at a resolution equal to the clamped window's screen height (578), even when that's not needed because it has the full-screen mode height (600 with no borders) to work with....