Just done some stepping through a debug build of the latest Mark V and I think I know what's wrong with stencil.

In OpenGL glClear is affected by the various write masks (glColorMask, glDepthMask, glStencilMask).

In Direct3D the equivalent is not.

However, in Direct3D clears are clipped to the viewport rectangle, whereas in OpenGL they are not.

Therefore, if you make a glClear call through the wrapper, and if the previous glViewport was to create a partial viewport, the full window won't be cleared.

This was a very real problem caused by FitzQuake's render-to-framebuffer water where it updates the warp images before calling glClear. The GL_SetCanvas stuff (which IMO needlessly complicates the 2D renderer) sets a partial viewport, then we come along and call glClear and only that partial viewport is cleared.

Result is that only a small square in bottom-left (or top-left, can't remember) of the window gets anything drawn in it during the main 3D render.

To work around this I added code to my implementation of glClear which reset the viewport to the full window before clearing. This was done in the expectation that there would only be one glClear call per frame which would clear all required buffers.

That's obviously not the case in Mark V which clears the stencil buffer before drawing it's mirror sky stuff.

Added complication: in D3D viewport rectangle and depth range are combined in a single state. In GL they're separate states. So resetting the viewport also messes with the depth range.

End result is that both the viewport rect and the depth range are messed-up as soon as you make that glClear (GL_STENCIL_BUFFER_BIT) call.

I'm going to fix this by putting the viewport back to the way it was after making the clear call. With hindsight I should have done this from the outset, but you know what they say about hindsight. 

I haven't had time to load up Windows 8 or Windows 10, but I did testing on Win 7 with and without Aero and so far everything looks ok --- at least in Windows 7 with whatever Direct X drivers came with Win 7 -- I know they aren't the same as, say, XP which may behave radically different.

You may have noticed I added on-the-fly resizable window to WinQuake to make the "let engine decide window borders" into irrelevant issue. The DX9 build was my main reason for wiring up WinQuake to resize-on-the-fly. 

The GL_SetCanvas stuff (which IMO needlessly complicates the 2D renderer)

Don't have much of an opinion on that ...

But I can say it was hard as hell to make WinQuake 2D render identical to FitzQuake.

So when Gunter was saying "original Quake centerprint" it somewhat follows I wasn't that big on the idea initially.

@Stencil clear -- Open GL should have done it that way, which is the better behavior ... and they would have in hindsight ;-) 

This is a case where I think no API gets it right.

Clears being affected by the write masks and the viewport rect are both IMO undesirable behaviours. GL adds the scissor rect to bound the clear, D3D9 lets you specify an array of RECTs but they're clipped to the viewport too, D3D11 has none of this crap so it gets partially there but in the end it fails because it doesn't let you specify a subrect to clear at all.

The ideal API would look something like:

Buffer->Clear (RECT clearRect, int clearMask, int ClearValue);

In other words, you explicitly specify what you want cleared, how much of it you want cleared, and what you want it cleared to. No side-effects from previous state.

I'm dubious about having a clearMask but one feature it does give you is the ability to clear RGB without clearing A (or vice-versa) in the color buffer. I don't personally have a use case for that but others might. 

Man, that %appdata config saving shiz is annoying.

I was trying out the new DX9 build but still had the skybox error as with previous version... took some time to find that and delete it so I could get a fresh start. Which solved it.

Is this by design, cause it takes such a simple concept and fucks it up, imo.

I mean, I just want a config file, saved in my id1/mod directory.

I know other games/apps do this but I don't try out 35 different flavors of those games/apps like we do with Quake ;) 

Damage, this is beta at the moment.

When it works properly, you wouldn't even know it was there because it was meticulously planned.

It was there for 2+ years, not even super-picky Gunter noticed.

Until I slightly broke it recently.

I'm very against advanced-enginitis disease.

/Keep in mind that only in this last week was anyone even aware of convenience that made life easy street for 2+ years in Mark V. ;-) 

I just read 2 pages back what was going on behind the scenes! 

I do hate when control is taken away from me without my consent, even in an attempt to "protect me." As I mentioned, a feature like this NEEDS a prompt for user control. It's not necessarily a bad thing... except that it takes away (easy) user control of the cfg file. It would be better with just printing something like, "Your config.cfg file has been altered by outside sources. type 'exec backup.cfg' to load last Mark V cfg settings." But apparently this feature is not currently working as intended or something.... How exactly is is supposed to work?



Ok, looks like we're moving in the right direction. My window no longer gets sent to limbo in any of the previous situations.

But I still have the issue I reported above, where the window gets clamped to 800x578 but it thinks its at 800x600, resulting in some ugly stuff happening.

(seen in the 1st & 3rd screenshot I had posted:
http://imgur.com/a/3NLCg

However, if I press alt-enter, then alt-enter again, that issue goes away and then DX9MV knows it's actually in a 800x578 window again (just like if I start it up in that res to begin with). Then the window looks all correct, like in a previous screenshot I posted: http://imgur.com/a/URhKC

Ok, it looks like the issue is only occurring in the (admittedly unusual) situation where my window has been set to 800x578 (due to the automatic clamping) and then I reset it to 800x600 windowed mode in the Options menu again.

It does not appear to happen if I am making any change from a completely different resolution, whether windowed or not.

And it looks like the "full screen borderless window" mode of 1024x600 no longer works the same. Now it does have a border.... which is causing the clamping of the height to 578 as well, which means I can reproduce the same issue (when already in window 1024x578 then trying to set to windowed 1024x600).

And it seems the full screen modes are... um... not correct. They are displaying the same chopped text as when it THINKS it's in a 800 height window but it's actually in a 578 height window....

So it seems like the full-screen modes are accounting for there being borders or something.... I get this effect even when I first start up DX9MV at the fullscreen res of 1024x600 without any weird res changing

Here's a screenshot: http://imgur.com/a/v5i5h

My scr_conscale is at the weird 1.5 but that alone previously didn't cause the issue, as the 2nd screenshot from DX8MV shows. Oh, it appears the previous DX9 version had this issue as well, so I guess it's not new to today's release.


But with this new version, I am getting a long delay when starting a game -- about 13 seconds. I don't have MP3s enabled. It only takes about 5 seconds to start a game in DX8MV.

This delay happens regardless of my resolution settings. Ah, it seems to be taking extra long for HQ textures to load.... If I disable them, then it loads a new game in about 4 seconds. This delay did not happen in the previous DX9 version.



About r_waterwarp:

Console variable: Toggle the use of the screen warping effect when the player is submerged in liquids. Set to below zero for water warp in GL version, but not in WinQuake version. r_waterwarp 2 in Open GL is FitzQuake style waterwarp.

I find that information confusing, and it doesn't seem to work.

In GL or DX9, you can ONLY get the new effect no matter the setting (though "0" is "off").

In DX8 there is only the old GL warp effect (I understand the new effect isn't in this version).

And in the Winquake version, the water warp is so subtle/slow you can BARELY notice it. 

Addendum:

If I start up DX9MV with 1024x600 windowed having been previously set, it correctly appears to be the borderless window that takes up my full screen, but the distorted text is still occurring.

If I change to 1024x600 windowed mode from any other mode (including just hitting alt-enter twice after starting as above), then the window borders appear and the window gets clamped to 1024x578, but then the text is no longer distorted.... 

... when can we expect the Vulkan version, baaaahahahahha

Why should modern day Quake be relegated to such archaic API's!!! 

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

Stencil is fixed, tested & confirmed working in latest Mark V release too.

THIS DOESN'T INCLUDE ANY FIXES FOR ISSUES REPORTED BY GUNTER

I'm still in "investigate mode" for those. I considered the stencil issue sufficiently important to release a new version fixing that, since it affects everyone and currently has ugly special-case code in MarkV.

@Gunter

I asked you above if you had any suggestions for an acceptable fallback if it does turn out that the 800x600 behaviour is something that we don't have control over in software.

I'd really appreciate an answer to that, because I really cannot change the way Direct3D works.

I am willing to put significant work into tuning this to meet your requirements, but I do need to be seeing something coming from you too, and right now I'm not. 

Really good to see things like true lightning in, and I could mention a whole series of other features I like about the engine, but I can sum up by praising the user convenience it provides. That manifests itself mainly in the console, where all the features like text editing shortcuts, find, help and shift-tab to reverse cycle are incredibly handy for anyone who uses the console frequently. Also good to see mh helping out, since DirectQuake was always my favourite engine prior to Mark V.

While fiddling around with it I've found a few issues you may be interested in. I hope these haven't all been covered already (I did ctrl+f a bit through this thread, but it's coming up on 1000 comments now and tricky to track everything said). My system is an up-to-date Windows 10 64 bit; i7 870; Nvidia 970 with driver 376.33.

1. Just confirming 2 things mentioned above - the r_oldwater crash mentioned by Baker in comment 761 is still present. The vid_hardwaregamma 0 alt-tab issue mentioned by Gunter in comment 335 seems to no longer be present in v1026.

Some other points about alt-tab/alt-enter/fullscreen stuff which I think Gunter has discussed, but I may as well give my own experience of it since I made some notes. I use a 1920x1080 display. In v1025 + v1026 the game always seems to start in what appears to be fullscreen borderless mode even when vid_width 1920; vid_height 1080; vid_fullscreen 1; vid_restart are in autoexec.cfg in that order. In the dx9 builds, an alt+enter at this point gives you fullscreen exclusive. OpenGL works as might be expected with this cfg - ie providing fullscreen exclusive behaviour immediately. On v1025, continuing to toggle alt+enter results in switching between 1920x1080 fullscreen borderless and 1920x1080 fullscreen exclusive. On v1026, toggling results in 1920x1080 bordered window and 1920x1080 fullscreen exclusive.

2. It seems vid_multisample has no effect in dx8, dx9 and OpenGL. I also noticed vid_fsaa doesn't work for me in Quakespasm, though DirectQuake's vid_multisample does.

Mark V - https://i.imgur.com/DYPxBwE.jpg
DirectQuake - https://i.imgur.com/OHQcKnh.jpg

3. It seems r_showtris 1+2 both do the same thing. The description indicates that one shows triangles visible to the engine, whereas the other shows those only the human eye can see, yet they both seem to only draw the engine's view.

4. Mirrors don't function correctly in dx9 when reflecting the sky.

dx8 - https://i.imgur.com/B9ZtwLp.jpg
dx9 - https://i.imgur.com/UpBVC0b.jpg

5. Noticeable input latency in dx8. When testing the dx8 build I had the sense that the game was feeling much less smooth generally than the other builds, almost juddery and with what felt like a significant difference in input latency. I borrowed a 120fps camera and did the following test - record the mouse and the screen simultaneously -> press mouse1 to fire -> count the number of frames from mouse button depression to response on screen. Not perfect, obviously ideally you want an LED attached to the mouse, but I think the test gives a good enough indication.

On dx8, on a mouse with a polling rate of 500, host_maxfps 500, a screen refreshing at 60hz and vid_vsync 0, the average number of video frames from button press to screen response was 4.7

On dx9 under the same conditions, it was 1

No idea if this is simply a limitation of dx8, but thought it might be worth knowing. The point I mentioned earlier about the game always starting windowed in dx9 is also relevant to this, since subjectively I noticed windowed has greater input latency, which is usually (always?) the case when playing any game windowed. 

I'm not really sure what you're asking, mh.

Acceptable fallback? Just make it work correctly like it did in the DX8 version, heh.

I'm pretty sure I've provided enough detailed feedback for Baker to start hammering away the problems. And I'm pretty sure this IS something controllable by software, because, as I noted:

I've found the problem (Mark V thinking it's at 800x600 when it's really clamped to 800x578 window) only occurs when I try to change to 800x600 windowed via the menu when it's currently at 800x578 windowed (I know, there's never actually any reason to do this, other than testing).

New bit of info: at that point if I do vid_restart I get: "Video mode request is same as current mode."

So again, it THINKS it's in 800x600 but it's actually in a clamped window of 800x578, and that is causing rendering issues.

But the problem fixes itself upon mode change by hitting alt-enter twice (going to fullscreen then back to windowed mode). So when it knows it's changing modes, it sets things up correctly.

The problem also doesn't happen when starting with -width 800 -height 600 by the command line (I get a correctly clamped and rendered window).


So it just seems that it needs to go through the proper steps after each mode change *even if it thinks a mode change is not occurring*

So, it needs to do something like:

-set new mode
-check for window clamping altering that request
-adjust video stuff to correctly reflect clamped size

Instead, when I am currently in the 800x578 previously-correctly-clamped window (when DX9MV has correctly detected it, it shows that in the Options menu, even though vid_height reports 600) and then I tell it by the menu to change to 800x600 (for texsing...), it does something like:

-set new mode
-don't notice the window was clamped back to the previous setting (meaning no window size change actually occurred)
-draw things at the non-clamped setting (800x600), causing issues, and report that the video mode is 800x600, which doesn't match the window size.


Perhaps the glitch is occurring because the actual clamped new window size is the same as the old window size, so it does not think anything was adjusted... so it doesn't realize the window is not the size it was requested to be.


I'm not sure what more info I can give as a bug tester, heh. I think Baker should be able to address this with the info provided.

But if you can be more specific in what you're asking, mh, I will, of course, try to provide any help I can. Assuming you're not just asking me for something you know is impossible for me to provide? ;) 

Coming up very shortly ... 

Further info:

The reason my little glitch can never occur in DX8MV is that it reports I am at 800x600 in the menu even when the window is correctly clamped to 800x578, so it won't let me try to change to 800x600 since it thinks I am at 800x600 already.

Whereas DX9MV correctly reports 800x578 in the menu, so it WILL let me try to change to 800x600... which confuses it, apparently.


This glitch has become pretty minor though, now that Baker fixed the window positioning thing (I previously thought they were related). 

Another new wrapper version probably coming up soon, depending how many fixes I can get in over the next hour or two.

Alt-tab from fullscreen modes loses the warp images and occasional device reset fails - fixed. Again, it's just a single fix but it is important enough to warrant an update. 

Perfect mirrors + stencil shadows.

Direct X 9 - Build 1027 A

Once I saw the source code, I knew this will be followed by Revision B with ...

the "2017 HOLEEFUK feature of the Year" ... as some may describe it. I want to see this myself.

The source will appear in the folder http://quakeone.com/markv/older here just a min, in case MH needs sooner rather than later. 

With 1027a, r_oldwater 0 + alt-tab when in fullscreen no longer causes a crash, but does produce the following strangeness - https://i.imgur.com/ywSXIWm.jpg

Can confirm skies now reflect correctly in mirrors. 

I think at this stage I'm more confused about what's happening than anything else.

Anyway... now that I have an XP VM I have Pix and the DirectX control panel back - WOO-HOO! - I never realised how much I missed them.

I already have a fix for one issue coming in... 

With 1027a, r_oldwater 0 + alt-tab when in fullscreen no longer causes a crash, but does produce the following strangeness

Fix in next version. 

Welcome back! And thanks!

/Gotta get this Revision B going ... 

Question: Where is my shadow?

MH's answer: in visual form 

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

Fixes "With 1027a, r_oldwater 0 + alt-tab when in fullscreen no longer causes a crash, but does produce the following strangeness "

I didn't get Gunter's stuff in although I now have one solid lead for what's going on.

Thanks to the DirectX control panel and the debug runtimes I can see that I'm getting a lot of "viewport is outside the render target" errors when running at the same height as the desktop mode.

That needs to be fixed as a first priority, and the reason why it happens is that the display mode clamps.

I can't right now see a good way of handling this without adding more code that's going to percolate back up to the engine.

So rather than take the time to work it through and delay the required alt-tab fix, I'm releasing now so that Baker can get that fix. 

Direct X 9 - Build 1027 B

Latest mh revisions addressing issues. Source will soon be in the same place as last time.

/MH shadow volumes awaits in revision C. 

You guys are crazy productive sometimes. I really appreciate all the work that various Quake-dudes put into this little hobby.

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?