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? 

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