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. 

I'm not doing an MD3 tutorial. 

d3d9_glcontext.cpp - line 206

if (mode.Format != d3d_Formats[i]);

Note trailing semi-colon. 

Ouch! Good catch. 

Good catch.

I was like, "Uh, that doesn't look like intentional code. MH wouldn't do it like that, I don't think. He'd probably have empty brackets"

integration

glEnable (GL_STENCIL_TEST) ... EnableDisable ... unknown param. Haha ... I was hoping I'd be looking at myself in the mirror on the start map when I just compiled.

GL_ARB_texture_non_power_of_two not found. Since I think you actually wrote this, I'll probably just improvise.

Have some plenty more integration to do, but it's going pretty smoothly ;-)

It runs and plays at the DX8 functionality level, but of course that isn't the goal here and I have about 45 instances of slightly different treatment that I did for DX8 which I have to recode/tune/etc. 

I did change the name of the autosaves to auto_save_0.sav, auto_save_1.sav, auto_save_2.sav (they used to be named a0, a1, a2)

Type: load auto_save_0

... for most recent autosave. It does default on. And should auto-complete.

Example:

Type: load (press ALT+Space .. autocomplete from nothing capability)
Type: load a (press TAB)

Let me know if everything is ok.

btw -- Better than even chance "shadows on platforms, lifts, etc." will be available as an option to put in worldspawn at some point. At one time you expressed interest in "true lightpoint" and is something being discussed as an mapping opt-in. 

I did everything for stencil test except the enable...!

I could easily add NPO2.