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. 

A couple of things about autosaves:

- I noticed they don't show up in the load-a-saved-game GUI menu. Is this intentional?

- The first time you play in a particular gamedir, "load a" will not autocomplete any autosave names even if enough time has elapsed to create one or more autosaves. It looks like the autosave names are not recognized, at least for autocomplete purposes, until you after do a manual savegame. 

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

You'll need to do a diff with the original wrapper engine code for this too, because there are some subtle changes required engine-side relating to Alt-Tab handling.

I dropped your "ResizeWindow" and rewrote "ResetMode" to handle switching from Windowed to Windowed without other changes.

There's a changelog included so you can see what's different/fixed/broken/etc since the last release. 

Cool! I'm kind of sporadic during the holidays.

Look forward to checking out the code!

@johhny

I noticed they don't show up in the load-a-saved-game GUI menu. Is this intentional?

Yes, at least for now. FrightNight and I didn't like non-user based save games in the menu. Doesn't mean that is a "final answer" or that couldn't change, but unwanted "randomish" save games in the menu seemed wrong.

The first time you play in a particular gamedir, "load a" will not autocomplete any autosave names even if enough time has elapsed to create one or more autosaves.

I'm rather certain that is perception only. While I haven't checked, one thing I do know is that any save game forces an autocomplete update.

The first save has a bit of different interval because who really cares about a save game when you've played less than 2 minutes, if you see my point.

An autosave is a "Help! I forgot to save and played for 45 minutes!" feature as a safety net for the player.

The "I died 100 seconds into the map" isn't really what autosave is there for, you know ;-) 

Also, you have hit on a fine-tuning weakness.

I usually start coding something "too conservatively" and then gravitate it towards what the user would expect.

Which is fine and the right way to do things.

You make it work efficiently first, then you relax it to conform to user expectations and figure out how it fits into the user interface correctly.

It is ok for something to be over-efficient at first, but not user-tuned. If something is written over-efficiently, that is the right kind of problem to have as a starting-point.