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

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!"