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

I may be tripping, but everything seems taller.

Thinner ogre legs are weirding me out. 

Old issue has popped up. Well, it was an old issue in DX8, but it was fixed in that. It exists as of DX9 1.25:

gl_fullbright 1 = most weapons opaque when using ring + transparent weapon models (but not axe) unless using custom textures (must be as metlslime said, and the custom textures don't contain fullbright pixels). Illusionary ent guy is also opaque.

gl_fullbrighs 0 = everything transparent, including illusionary guy.


Interestingly, I can see my shadow through the otherwise opaque illusonary ent guy IF I set r_shadows 3.


r_shadows 3 looks cool, and works fine when I'm running around a map by myself, but my little netbook cannot handle it when there are lots of other things casting shadows! Yikes, kills my FPS hard....

And it can make some weird effect, heh, like this:

http://imgur.com/a/8zbT5

But as the 2nd screenshot shows with standard shadows, weird shadows were always a thing in Quake! 

@fifth - If you have a chance, could you let us know if the 1028 build DX9 works ok now?

@jimbob - thanks for info. Awesome. "Thinner ogre legs are weirding me out" ... I'm assuminng you are talking ogre shadows with r_shadows 3, but if not could you post a screenshot?

@rail - nice to see r_oldwater issue is put to rest.

@gunter - I'm getting this too.

I type map "dm3" with r_viewmodel_ring 1 (it's in the menu by setting "Invisibility: Draw Weapon")

I grab the ring and the weapon is fully visible, instead of translucent.

Also in some cases, transparent entities are more transparent than in Open GL. Putting this e1m1 external .ent file in quakeid1maps, which turns the starting elevator into a transparent func_illusionary, it is close to fully invisible in DX9 but rather visible in Open GL.

That elevator example wasn't of enough interest by itself, but since Gunter pointed out the invisibility weapon draw, I thought now was a good time to mention it.

However, I didn't want to point it out until I had time to verify that the state of all the gl capabilities is correct --- i.e. I cannot be 100% that it couldn't be a Mark V mistake that shows no symptoms in Open GL. 

Shader gamma - stretch looking

What I think could be going on there relates to how 2D matrix calculations often need a 0.5 nudge for even numbers.

The menu canvas in that scenario should be 320 x 200. I don't see the "stretch effect" in the console at 640x480 in Mark V, but the stretch impact might be too minimal.

If I were to type vid_hardwaregamma 1, instead using display brightness adjustment and not the shader, the menu text appears normal. 

Comment you made elsewhere was insightful -- "It suits me as well to work on the rendering layer and let other people deal with the other stuff."

Since the inverse has been helpful for me, since I've been able to focus on an entirely different set of objectives, like concentrating on get some extra builds ironed out (linux, trying to address killpixel's now deceased issues with WinQuake, etc.)

The fact that waterwarp and shadows work on these other platforms like linux is awesome, clearly.

/Time for me to attack outstanding issues, Mac build and see if firewalled .bsp rotation support can be implemented for damage_inc/sock. 

Although I have no need to use it. Is there a reason why gl_texturemode is always linear? 

Baker and MH, you two are just incredibly passionate workers.

DX9 version is of interest to me because ShadowPlay(Nvidia recorder) can hook with it. Water warp is a great effect and I get smooth gameplay with the latest beta release. r_shadow 2 looks great, with 3 having strange issues like the shadows being cast on the geometry below.

Is there a reason why gl_texturemode is always linear?

From my brief test, I also noticed this!