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. 

I made a quick and unknowledgable run at making glEnable for GL_STENCIL_TEST work. But was unsuccessful.

Mirrors work though -- this means that glDepthRange is working quite nicely! (The current implementation of mirrors doesn't need stencil very much. I use glColorMask (0,0,0,0) /*don't write color*/ mostly to do a depth write where the mirror surface lives instead. ) 

Spirit and a few others (mostly of the engine development variety) may remember this.

Baker's Visual Concept of a Built-In "Quake Injector"


Take that and then consider the Undergate and becomes possible to see the vague direction it is ultimately heading. And explains some of Mark V feature set very well.

/Note: I actually made something like the Quake Injector before the Quake Injector existed screenshot. Only a few people were interested in it, was harder to get people interested in single player at the time. Plus engine coding was more interesting to me. Was happy when the Quake Injector came out, promoted it quite a bit. 

OK, I've pretty much fixed all of those items.

I currently don't have a test case for stencil because the stock Fitz code doesn't use it. What I'll probably do is add stencil buffer support to r_shadows 1, because it's quick and easy to do and was in a well-known QuakeSrc.org tutorial too, so it's well-known to the community.

Adding the enable/disable for stencil should have been easy and more or less self-explanatory: just follow the pattern of the others, using GL_STENCIL_TEST and D3DRS_STENCILENABLE. There are a number of reasons why this might not work though, including if a pixel format was selected without a stencil buffer.

I'll fix all that up and make it nice and robust. 

Hah, nice screenies there Baker.

It's kind of hard to get a handle on all the Quake content out there and how to use, but at least partially that's a "nice problem to have" sort of situation. 

The fun thing about MD3 loading is: where do you stop?

You see, MD3 is more than just a model format. Once you have that done, you're going to want textures too. And because content creators always want maximum flexibility, you're going to want the full Q3A shader system. And you're going to want to draw it from vertex arrays because that's the way the format is designed. But by that point you've more-or-less reimplemented the full Q3A renderer in the Quake engine.

This is a design goal of engines like DarkPlaces and FTE. It's not a design goal of other engines, and because time isn't an infinite resource, time spent doing this is time not spent doing other stuff.

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. The SP guys wanted one set of things, the MP guys another, content replacement people wanted something else, modders, mappers, QC people, low-end people, high-end people - all different and sometimes overlapping but sometimes conflicting requirements. Meantime there was only one of me.

You absoluetly do need a laser-sharp focus and you absolutely do need to say "no" and be non-negotiable about it. DirectQ is a cautionary tale of what can happen when you don't.

If I had 5 $/�/�/� for each time somebody asked me "can you just implement $PET_FEATURE, I'm sure it will only take you 5 minutes and it would be so cool" - I wouldn't need to work for a living and would actually have time to do this kind of stuff!

As it stands I don't have that kind of luxury, so I have to cherry-pick what I spend my time doing, and also mix it in with beer/friends/other hobbies/eating/sleeping/entertainment/etc.

While the very same specifics may or may not apply to Baker, it should be obvious from his prior posts that he is similarly time-constrained.

So, options. If Baker has 1 week between now and June, is it better spent writing an MD3 tutorial or is it better spent doing other Mark V work? 

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