In response to Ter13
PlgBlt() is used to manage transforms; but that's quite different from masking out the entire display.

Mind you I'm quite comfortable with having some hardware-only features, like the multiplicative blending mode; this being such a big-deal feature, though, might make a difference.

At any rate I still don't know how the concept of a lighting layer would work on DirectX without learning how to use shaders; at least all the sources I've found talk about that. The stencil buffer seems like an option but a poor one, and we'd still have people asking for better choices that they know the hardware can deliver.
I did something like this with my game spies

Here it is in action~
Gonna zombify this post. It's something I'd definitely like to see, mainly because I am recently disgruntled to find out that BLEND_OVERLAY does not work the same as actual Overlay Blending.

One of the main features that I can see for this is to allow creators to implement pseudo-lighting systems without egregious amounts of processing overhead.
I'm willing to look into shaders at any point if someone can point me to a good starting place. I have not yet found a good source online that appears to be compatible with our setup.
I'll see what I can find, would you happen to have a list of the prospects you've already visited? I don't want to end up bringing up old sources that have already been ruled out.
No, not really. The bottom line of it is I need something that will work with our system of using sprites, and drawing the final product with Present(). Most of the stuff I've found anywhere has revolved around Direct3D, which we're not using directly; we're using a sprite blitter.
Hmmm, so we're in C++ using DirectX to display using Present()?

Would a library that works for C++ work so long as it doesn't require any special hooks or is that what DirectX is doing?

Sorry if I seem oblivious, I haven't been here in a few years so I', fairly lost on some aspects.
I'd prefer that any code I use be something simple rather than grafting on another library. It should be plenty easy to do that with DirectX, but I've never had the time to look into shaders in depth there.
It seems that Shaders are primarily implemented through D3D, but I'll look and see if there's method to do it without involving it.

I read something about normal maps... gotta look into it more.
Shaders happen at a high enough level that D3D may not really be an issue. I'm just not sure enough to know.
Which version of Directx are we fiddling with though? 9? Does it matter?
Using 9, yes.
How big is BYOND's rendering code, Lum? Any chance one of us that has C++ chops can take a look under the hood for how it works so we can figure out what specifically needs to be fixed?

I'm pretty handy with OpenGL and GLSL myself. I'm a bit rusty with HLSL and DirectX, but I also have familiarity in the D3D category.
I looked into it and it appears pixel shading with DX is tied into HLSL. Not sure exactly how, but the Microsoft resource pages are very informative to those who know the lingo.

https://msdn.microsoft.com/en-us/library/windows/desktop/ bb944006%28v=vs.85%29.aspx

I think this unfortunately also goes into the issues with textures and the fact that we don't use them in BYOND though, so I'm not sure how helpful that all is, if at all.
The way BYOND is currently rendered, I don't think shaders are at all reasonable to approach. Unfortunately, GDI has been deprecated for quite some time, its successor GDI+ has been deprecated for some time, and its successor Direct2D has been deprecated for a time.

I think it's probably time to move entirely away from fixedfunction DirectX and move toward a polygon-based, shader-enabled rendering approach.
So would this be becoming a suggestion/feature request to overhaul BYOND's display?
In response to Ter13
Our DX rendering code is not very big, actually. I think it'd be feasible to share it with you at some point, although at the moment it's sort of in a state of transition while I mess with the nearest-neighbor thing.

(OpenGL is a bit worse. But it was a nightmare from the beginning.)
(OpenGL is a bit worse. But it was a nightmare from the beginning.)

Have you seen OpenGL 3-4.4? The fixed function crap is dead dead dead. Modern OpenGL's actually a lot more convenient than Modern Direct3D nowadays, and interestingly it's the only way to get things like geometry shaders to work on Windows XP.

OpenGL has really improved quite a lot in the last 20 years. (Ignore that WebGL crap you guys are working with right now, because that's based on ES2.)
I'll have to agree with the OpenGL statement, they've changed a lot in the past years, may be worth looking into.
I'll have to agree with the OpenGL statement, they've changed a lot in the past years.

It's still slightly slower than DirectX on windows, but you get the added ability to natively port to Linux/Mac... Of course, we're still dependent on user32, so it's not like the GL switch is gonna do us a whole lot of good.

Oh, and the fallback shaders are way less complicated in OpenGL than DX.
Page: 1 2 3