That's all working now.

One point to note in Mark V:

32, // 32-bit z-buffer
8, // 8-bit stencil buffer

This is actually bumping your hardware requirements to D3D10 or higher class hardware.

Hardware typically doesn't actually have separate depth and stencil buffers, but rather a single interleaved depth/stencil buffer. The common options are:

* 16-bit depth.
* 24-bit depth, 8 bit unused.
* 24-bit depth, 4-bit stencil, 4-bit unused.
* 24-bit depth, 8-bit stencil.
* 32-bit depth.

I'm not sure how prevalent 24-depth/4-stencil/4-unused is in the wild, and I think 32-depth had issues on older hardware (I recall some Intels actually giving you 16-bit depth if you requested 32), but the other formats are robust and compatible.

So if you require a stencil buffer you should always request an 8-bit stencil buffer and always drop depth bits to 24.

Because they're interleaved, you should always try to clear both depth and stencil at the same time too. You'll get a faster clear that way.

Anyway, in it's current state the wrapper just sniffs for the presence of stencil bits in the PIXELFORMATDESCRIPTOR and if present it gives you a 24-depth/8-stencil format, irrespective of how many bits of either you request. Otherwise you get 24-depth/8-unused (which I might change to 32-depth sometime).

This behaviour may change in future versions to better reflect what you actually ask for, so I don't advise relying on it. 

I know about the stencil, at least on a subconscious level, switching areas of the engine quite often (IPv6 --> input --> system messages --> etc.) I lose sharpness.

mh: Back when I quit working on DirectQ, part of the reason why I killed the engine was because it was being pulled in too many different directions.

I don't want to beat this to death, but you always have to tell someone "no" to "help me with my engine coding" 3 or 4 times because are in above their heads in something.

And if you help them, you have created a cycle of dependency, like giving a homeless person some food.

They'll be back on your doorstep tomorrow if you help them.

I already said explicitly I am not an engine help forum, but I knew I would need to say "no" more times because I have been in that situation dozens of times.

Someone who exhibited the capability to truly engine code would be able to take what is in JoeQuake (the MD3 code in that engine is quite easy to understand) and do it themselves. Plus they would not be using CodeBlocks on Windows, they would be using the vastly superior Visual Studio.

Anyways ... I can empathize with the situation, but if you can't take the md3 code from JoeQuake and use that as a tutorial, you have no business engine coding at all and need to immediately stop doing it.

/Enough said. Much to do! 

Plus also, if you don't have Visual Studio that means you never tried to compile JoeQuake which is in Visual Studio.

Therefore, by definition, you aren't trying very hard to begin with. And engine coding is hard as hell and such laziness disqualifies you from having what it takes to engine code.

/Ok, I lied a little last post. Enough said. Like this time I really, really mean it. Unless I change my mind. ;-) Much to do ... 

@baker: There is no reason to get rude.. 

Dude --- you've told me
1) My source code was broken.
2) 5-6 instances of "engine coding help" type questions, with 2-3 of "other model format" after a politely, but clearly worded "no".

Did you not eventually expect get the "Are you hard of hearing?" version?

I sure would have ;-)

You probably have a great project, but by all appearances you simply don't have what it takes to do engine coding.

Whether or not that is "rude" or fair or even not fair, it just is what it is.

It is important for someone in your situation --- the "I'm in over my head situation" --- to get a reality check.

As someone who has been the beneficiary of "reality checks" by other engine coders (mh and Spike have given me "reality checks" in the past, especially when I was very new. Bet you didn't know that! They were very helpful reality checks. It wasn't what I wanted to hear, it was what I **needed** to hear) ...

In low-level coding this is someone doing you a favor. 

Direct X 9 Version | Source Code

If started with -nostencil .. is mostly solid.

And no switching between full-screen and windowed mode, and no alt-tab in full-screen mode, should work ok.

Doesn't have r_waterwater integrated yet, not shader based gamma/contrast isn't available yet either.

More work to be done in the mode changing and ALT-TAB department. ALT-TAB in some instances has issue with gl_oldwater 0, seems to be full-screen mode only).

Likely an incomplete implementation on my part, it appears something subtle is missing and I'll have to do a deeper examination to see what it is. 

DirectFitz9 video mode changing issue

bind y "toggle vid_fullscreen; vid_restart"

Switch to the largest resolution available.
Then press "y" a couple of times.

The window positioning acts up. I remember with the Direct3D 8 wrapper there may be been an issue with windowed resolutions that overlapped with the window taskbar (the bottom of the screen bar showing applications running).

With the Direct3D 8 wrapper, I believe that since I completely destroyed the window and everything else upon switching between fullscreen and windowed mode, it wasn't a problem.

From all appearances, doesn't look like the Direct3D 9 wrapper supports that. And maybe it shouldn't.

(*) Note: I don't know what version or versions of Windows you run, but at one point Windows 8 was rather displeased with changing Window borders and attributes without DestroyWindow even with Open GL. Since DestroyWindow and ReleaseDC and then recreating the window in Open GL, and then reassigning the context (HGLRC) typically works, not much of an inconvenience. I haven't checked Windows 8 SP 1 or Windows 10 to see if Microsoft "fixed" that behavior that Windows 8 introduced in a later update. 

The "always on top" window issue I experienced works like this:

1) Only if dx9 starts up in fullscreen mode, it seems that Direct3D (not in your code) gives it the topmost attribute.

In d3d9_glcontext.cpp, adding this (trivial) statement before Sleep (10) in ResetMode solves the issue:

if (windowed) SetWindowPos (this->PresentParams.hDeviceWindow, HWND_NOTOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);

The issue is not immediately experienced in DirectFitz 9 because it starts up in windowed mode, then executes config.cfg which contains a vid_restart command.

However, switching to fullscreen and then back to windowed mode, the window will exhibit a permanently topmost behavior. 

Beer for Baker, that's good detective work and useful info for me! Hope to have a new release over the next few days. 

I have not yet ever experienced the "off by 1 pixel" issue with shader gamma in Mark V.

I wonder why it happens in DirectFitz9.

Haven't implemented resize-window-on-the-fly. I'm hoping that the "off by 1 pixel" oddity doesn't surface there either.

More to do. 

Sorry, Pulsar. I should have done a better just communicating the change.

Wanted to make the autosave names more clear and obvious to a newcomer. 

Are you guys making a DirectX engine that can play Arcane Dimensions, right? My low-end netbook can barely play it on Quakespasm sometimes but with the DX9 engine it stays mostly on 60 fps on the few maps that can support it, most still crash.

That would be a miracle. 

I suspect over the course of the week that the answer is mostly likely a "Yes!" 

Direct X 9 Version | Source Code

Requires -nostencil in the command line. Stencil buffer is not yet operational. Does not yet have WinQuake-like r_waterwarp integrated.

c:/quake/DirectMark5.exe -nostencil

Does have fully resizable window capability.

vid_hardwaregamma

Set to 0 = shader gamma (looks nicer in windowed mode)
Set to 1 = hardware gamma [default] (in high resolutions, can be very much faster than shader gamma)

@mh - Some issues exhibited in DirectFitz 9 prototype do not seem to happen in DirectMark5.exe Build 1022. Will do some more testing, but Mark V handles video mode changes differently than FitzQuake and I rewrote small parts of the wrapper. I think the issue list may have gotten smaller, but more testing will tell.

/Source code link will probably work in 10-15 minutes. 

vid_vsync 1 works in windowed mode, but apparently not right away. If I press ALT-ENTER a couple of times, windowed mode doesn't take it.

As a work around for now, I feed it into the command buffer as such ...

Added into end of setmode for now ...

// Vid_SetMode
// Window already created or recreated ...

Vid_Vsync (); // Fullscreen fine, windowed mode no effect though ...

#ifdef DIRECT3D9_WRAPPER
// ensure swap settings right
if (vid.screen.type == MODE_WINDOWED && vid_vsync.value)
... Cbuf_AddText ("vid_vsync 0; wait; vid_vsync 1"); // Works!

#endif // DIRECT3D9_WRAPPER 

Wanted to make the autosave names more clear and obvious to a newcomer.
Any particular reason you inserted an extra underscore in auto_save, then? autosave_0, autosave_1 etc seem more obvious to me since I've always read it as a single word and not two words separated by a space. Or even autosave0, autosave1...: the underscore is more of a programmer thing that isn't intuitively used by n00bz. Plus, the less characters to type the better IMHO. 

There are some single player releases with autosaves built into them. So I don't want to use a name like "autosave", for instance.

In Mark V, someone who used it any length of time would just type "load a" and press TAB.

1) So no one would be typing more stuff ;-)
2) You just need to remember the "a", you don't need to know the name.

Mark V auto-completes even ..
1) skybox names (!!!)
2) key names
3) demo names
4) save names
5) map names
6) game folders
7) Several other things.

Mark V can auto-complete in the middle of line! If you have a long line, you can backspace in the middle of it and press TAB or ALT-SPACE and it won't mess anything up.

In fact, Mark V even has undo and re-do! You can press CTRL-Z or CTRL-SHIFT-Z (redo) in the console.

That's in addition to being able to hold down shift and select text in the console and copy it or paste it.

And in addition to being able to press CTRL+PGDN and CTRL+PGUP to resize the console.

Mark V is user-convenience engine ;-) 

Direct X 9 Version | Source Code

Requires -nostencil in command line, as stencil buffer isn't ironed out.

1) r_waterwarp 2 is WinQuake style waterwarp
2) Resizable window at any time
3) Shader based gamma available (vid_hardwaregamma 0), look nicer in windowed mode. Hardware gamma is faster, especially in high resolutions.
4) The renderer is faster. Startup and Alt-Enter are astonishingly fast. Haven't been able to get a complete handle on the speed increase, but certain highly complex maps seem to render at least twice as fast.

@mh - I've taken it about as far I can go ;-) Aside from some outstanding testing situations I've thought of and some polishing up ideas I've charted out.

Stuff:
1) stencil
2) non-power of 2 texture sizes
3) Technically, vid_vsync 1 + windowed mode doesn't immediately work at video mode change time, but I did a workaround putting some commands in the command buffer.
4) Without thinking too hard, I do not believe there are any other outstanding issues. I don't have any known mode switching issues ever nor the off by 1 pixel shader gamma issue either.

I have the engine use the provided Direct 3D screenshot method when the buffer already has gamma/contrast applied to it (if shader gamma is on, for instance), since it seems to be at least 3 times faster when writing PNG (PNG is a notoriously slow format to write). 

So there is a valid reason, then. OK thanks. 

 

I have no time for testing with a house full of visiting mini-ogres. And it looks like there's still work to be done before exhaustive testing really begins. 

Been sick the past few days so I'm a little behind schedule, but all of the items mentioned by Baker above are now fixed. I haven't yet integrated the changes Baker made to the wrapper.

There's some weird interactions I want to shake out between video startup, mode switching and window resizing, but if it takes me too long I'll just do another upload of the current version with window resizing flagged as "potentially unstable". 

Current vsync behaviour is a bug in my code.

What's happening is that the vsync setting is not holding across a device reset. Now, sometimes (e.g. if creating a new context or doing anything else which reverts all state back to defaults) that's the behaviour you want, but other times (mode change, alt tab, etc) it's not.

The quick and dirty fix is to find the line "this->PresentParams.PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE;" in context_t::SetupPresentParams, remove it from there and put it into context_t::context_t *above* the call to this->SetupPresentParams instead.

That should be enough to get you going and you can remove your workaround. :) 

A bit more about the flickering:

I played through DOPA using mark_v_winquake.exe and didn't notice any flickering.

I switched over to using mark_v.exe for playing ad_mire, and I noticed flickering pretty regularly (played up to the point of turning the first valve). Switched to quakespasm_sdl2.exe and played through the same part of the map, no flickering.

I'm using a GTX 1070 with latest drivers. Let me know if you ever want some additional system info, or for me to try anything out.