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

I expect that you'll have some feedback and I'll have some work. 

Direct3D 9 SDK June 2010 is correct SDK?

https://www.microsoft.com/en-us/download/details.aspx?id=6812 

June 2010 should do, yes, although I wrote it to work with any version (so long as it includes D3Dcompiler.h) 

Incidentally, I did all of this work using Visual C++ 2008 Express, and I do recommend that you build the initial DirectFitz project before trying any integration to Mark V. 

Finished compiling ... For anyone who wants to try the initial Direct X 9 build, here is a .exe

MH Direct X 9 - FitzQuake 0.85

----

@mh ...

5 minute mark comments

1) Wow! That's a nice framerate!
2) Adjusting the brightness moves the pixels on-screen by 1 pixel up and by pixel 1 left. Presumably gamma != 1.
3) vid_vsync sure works. I had to turn it off to check it out
4) I see you took a different and more organized approach, implementing several C++ instead of the single file approach. Not that this makes any difference at all.
5) Didn't see any .lib files in the project, nor #pragma comment(lib, mylib.lib) so I am guessing d3d9 has pragma comments in the headers somewhere.
6) Haha, it resizes!
7) Surprised no contrast cvar, you used to be very insistent that any decent engine must have contrast ;-) /I agree with that, obv.
8) Haven't checked the contrast/gamma ranges.

Initial comments. May be a few hours or possibly even tomorrow before I have more comments or a may change my mind and investigate it a lot more before then ....

Main reason: I was coding something which is 85% of a complex change and if I don't strike while the iron is hot, I may forget the subtle details.

But needless to say, I'm liking this Direct3D 9 wrapper quite much! 

Underwater warp screenshot - Direct X 9 

There should still be one #pragma comment (lib), for d3d9.lib, but since that only exports a single function I could very easily dynamically link instead. Everything else is dynamically linked at runtime, primarily to resolve problems caused by different versions of the d3dx9 and d3dcompiler DLLs.

I didn't implement a contrast cvar because I wanted to keep intrusive changes to the original engine code at a minimum. Of course I then went and made a lot of intrusive changes elsewhere! Anyway, the brightness/contrast setup does support contrast, but the engine just hard-codes it to 1; I took the calculations from Mark V's gamma tables (used for applying brightness/contrasdt to screenshots) so they'll be consistent with those.

I understand what's happening with the "adjust brightness/shift by 1" thing but I'm not sure I understand why. Need to look into that more.

Yes, I found the single-file approach quite difficult to work with when making wide ranging changes. I switched to C++ quite late and mostly on account of a comment you had on wglMakeCurrent in the old wrapper - so that part is your fault! After fixing that up, I found that I wanted a "context" struct to keep things better-organized than using a lot of standalone globals, then found that I was passing this struct as the first param to a lot of functions. That's the point at which one needs to consider switching to C++, for code-cleanliness and robustness if nothing else.

On the other hand I do see a huge appeal to the single-file approach. I love stuff like stb_image where you just drop in a single header and you've got everything - so easy! But at this stage I don't think I'm going to switch back.

I'm going to let you chew over things for a short while before I pick it up again; currently debating what the best way to deliver new versions of this is going to be. Obviously you'll need to change some of the public API stuff "from "gl*" to "d3dmhgl*" or whatever) and I seem to remember that you're comfortable using WinMerge so I think I can just bash ahead with the internal stuff and leave it up to you to work out the diffs? 

took the calculations from Mark V's gamma tables

Cool, now I don't have to look into that. I was messing with the contrast just 30 seconds ago to play with it.

Quakespasm uses Mark V's gamma/contrast system and Mark V's gamma/contrast system is backwards compatible to WinQuake.

I put a lot of thought and planning into Mark V's gamma/contrast system and I was, for instance, very pleased when ericw implemented it same in Quakespasm.

Also noticed some other things, like colored lights "option" for scrag/wizard attacks and such. And a possible dynamic light calculation correction in r_lightpoint not related to the concept of getting the light from inline models (*5 or *10 models, etc.) 

R_LightPoint was actually the last thing I worked on, earlier on today. I'm really pleased with how that turned out, but still annoyed about shadows.

I just really love adding those extra dynamic lights. I can understand that they might have been slow in 1996, but in 2016 they're so cool to have and add so much to the game.

Reminds me that I haven't corrected the stock Fitz support for > 32 dynamic lights; that's very badly broken. 

Reminds me that I haven't corrected the stock Fitz support for > 32 dynamic lights; that's very badly broken.

I have 128 dynamic light support that was based on a tutorial you wrote, but whether or not you'd like tutorialize within DirectFitz 9 for, say, Quakespasm or other engine without feature is obviously up to you ;-)

For reference the easiest map to see where the change matters is the Warpspasm secret map, but I suspect you had to have a test map in mind yourself, otherwise how would you know if it works? Hehe

still annoyed about shadows

This 2007 build of DarkPlaces has correct shadows ...

https://icculus.org/twilight/darkplaces/files/darkplacesengine20071120.zip

Just pointing this out. Obviously, the source is in that .zip since that is how LH has always done it.

Shadows, a pestilence that annoys engine developers ;-) 

What's annoying is because "lightspot" (or my equivalent of it) is calculated in R_LightPoint, and because that's what used for positioning the shadow, it should just automagically work - no extra code needed.

That tells me that the likelihood is I'm doing something else wrong, but right now damned if I can think of what. It'll come.

Thanks for the reminder that I had written a tutorial about the lights. No, I didn't have a map in mind, it was just obviously broken (trying to fit 64 light bits into a 32-bit int isn't going to happen). 

If you ever get a chance, this block of code has me somewhat confused:

(Water warp area ...)
....// bottom-left-is-origin crap
#ifdef DIRECT3D9_WRAPPER
....glOrtho (0, 1, 1, 0, -1, 1);
#else
....glOrtho (0, 1, 0, 1, -1, 1);
#endif

I know Direct3D uses a different 3D matrix than the "mathematically correct, but somewhat inconvenient and annoying OpenGL 3D matrix especially when you want to do 2D".

But none of the other glOrtho calls are treated in that manner? Something I'm not seeing here, I'm sure ... 

The other glOrtho calls are set up in a way that they cancel out. This one isn't, because I'm using normalized device coords and identity matrices (those glOrtho calls are really the equivalent of identity with D3D being vertically flipped) so I need to correct for it.

Ummm - did that make sense? 

Mentioning something, even though it doesn't really matter.

With dx8 Mark V in windowed mode, if someone alt-tabs out of it, I do something sneaky and minimize the window -- to obfuscate the fact that the window must stay on top of all others.

May be an unchangeable characteristic of Direct3D.

I hadn't thought about this in quite some time. But since DirectFitz 9 doesn't employ a trick like that, for a moment I wasn't quite understanding why it was staying topmost when it lost focus.

/This behavior does not much matter, but I'm just pointing it out. 

Actually my suspicion was correct - that was nonsense. NDC goes -1..1 but I'm going 0..1 for starters. What's relevant here is glCopyTex(Sub)Image copying from bottom-left, but D3D StretchRect copying from top-left. 

Yes that makes sense. It's an optimization, not a behavioral difference ;-) 

Look for WS_TOPMOST in the window styles and kill it. 

Unless I am somehow doing something wrong searching the source code, WS_TOPMOST returns 0 results.

Although I know far less about Direct3D, I have always been under the impression that a non-topmost window in D3D is impossible.

/Also, this isn't something important. 

Sweet, new goodies to play with. And I can ruin it all by injecting something to give Quake all those features it was always missing, like hacky SSAO, awful Vignette effects and dumb colour grading.

Honestly though, even though I don't have anything technically useful to say, I feel like both Baker and mh need to be thanked and congratulated for making cool things for Quake like new engines and renderers. So thanks and congratulations for being cool! 

if autosave feature is disabled by default in the latest build? 

I'm just not able to reproduce it: http://www.quaketastic.com/files/screen_shots/Topmost_window.png

I suspect something localized on your PC. 

@baker: any chance that you could post a tutorial to implement md3 support to fitzquake?
I saw you started one at insideqc, but never finished it. 

I'll look into it. 

It could be my Direct 3D drivers. I notice that DirectQ does the same (minimizes it). So apparently the behavior of Direct3D 9 is subject to some sort of variance, since clearly yours is different (and more likely up-to-date). I may end trying to grab the Window style flags -- is it GetWindowsLong --- and see if I can detect the behavior. 

I did end up trying Mark V on a GeForce high-end gaming laptop -- I think the driver version was (372.70). Did not experience flickering, but the driver wasn't (372.75) and didn't have time to do an update.

However, the display was high DPI and Mark V likely needs the DPI awareness attrbrite because even the experience in the WinQuake version was rather "unpleasant" on a high DPI display.