Sprite blend_type Subtraction

[regi]

Hey guys,

I'm working on some edits for a certain lighting script and would really appreciate some assistance with sprites. To create lights, I've been thinking of showing sprites with blend_type 2 (subtraction) over a black rectangular bitmap (darkness); this doesn't seem to have any effect, though. It'd be helpful if someone could point out how exactly the built-in blend_type/subtraction works, and if it would work in this case.

 

[Glitchfinder]

Hey guys,

I'm working on some edits for a certain lighting script and would really appreciate some assistance with sprites. To create lights, I've been thinking of showing sprites with blend_type 2 (subtraction) over a black rectangular bitmap (darkness); this doesn't seem to have any effect, though. It'd be helpful if someone could point out how exactly the built-in blend_type/subtraction works, and if it would work in this case.

If you check out the picture files in this old project of mine, you will have a pretty good example of how it works. Specifically, the lighter a part of an image set to subtract is, the darker it makes whatever is behind it. In fact, this project is actually a pretty good example of how to make lighting in general, since it provides both light and shadow.

 

[regi]

Well, it seems to have the opposite effect of what I originally thought. If I'm understanding correctly, it doesn't actually subtract away darkness, but adds the inverse of each pixel, right?

If that's the case, I guess it's back to square one figuring out an efficient way for getting rid of darkness. I know it probably has something to do with masks, but using pictures gets messy whenever light areas overlap. Any advice on how to achieve something like this?

Spoiler: Example image

 

[Glitchfinder]

Well, it seems to have the opposite effect of what I originally thought. If I'm understanding correctly, it doesn't actually subtract away darkness, but adds the inverse of each pixel, right?

If that's the case, I guess it's back to square one figuring out an efficient way for getting rid of darkness. I know it probably has something to do with masks, but using pictures gets messy whenever light areas overlap. Any advice on how to achieve something like this?

Spoiler: Example image

Unfortunately, that would, to the best of my knowledge, require a dynamic alpha mask for most uses. Which rpg maker does not support natively. The only real way to add alpha masking to an RM Game would be to create a .dll file that dynamically modifies the image data in memory. The problem with that is, the original image data is NOT preserved. At all. I've worked with this in the past (I even created code that almost perfectly mimics the default RM* transition system, including the blending option), and if you need the original image back at some point, you have to clone it before you do any work on it. Which would mean you would have to recalculate the entire image every time a light turned off. Which isn't particularly effective, but, seeing as it's in C or C++, at least it's faster than doing it in Ruby.

If you're interested in a basic .dll file that can modify the image stored in RM* memory, I'm pretty sure a properly targeted search through my posts will turn up at least a couple posts of mine with such code, as well as several posts of mine where I link to said posts with code. Though, I never did post the final code for that transition.dll, now that I think about it. I'll have to see if I still have it somewhere.

Edit: I figured I should also clarify exactly what that blend type does. In the case of subtraction, it will take an image and, if the inverse of the image's color would make a pixel darker, it will essentially merge the two. If it would make it lighter, or if it's transparent, or if the overall value (essentially brightness) remains the same, then it makes no difference and doesn't change it. This is in opposition to the addition blend mode, where if the pixel is brighter, then it will change it, but if it's the same or darker, it won't. Colors do play a role in both of these, as you would see if you did something like setting a sprite to subtract mode. It actually looks kinda neat, and can be used to make a nice kind of evil ghost effect. Addition can make a nice good ghost effect, too.

 

[Brewmeister]

If I'm understanding correctly, it doesn't actually subtract away darkness,

Yes, that is backwards. Since absolute dark is (0, 0, 0), you can't subtract anything from it. (very simplified example to illustrate concept)

What we need is something like a "subtract alpha" mode that reduces the alpha # based on another image.
Then your light 'mask' would be the inverse of the subraction you want (opaque in the middle, fading to transparent around the edges)
Not a true 'mask', but acting like a dynamic mask.

Although, as Glitch highlighted, calculating a dynamic mask could be pretty detrimental to performance.

Be Well

 

[regi]

Hrm, sounds a lot more complicated than I'd hoped. I've worked with Flash before so I know that alpha masks are possible, but it seems like RM isn't suitable for the task.

Just to be clear, my original idea was overlaying the screen with a 640*480 black rectangle, and lowering the opacity of circular areas of light (so that the bottom layer showed through). Would that still have the same problem as described?

 

[Glitchfinder]

Hrm, sounds a lot more complicated than I'd hoped. I've worked with Flash before so I know that alpha masks are possible, but it seems like RM isn't suitable for the task.

Just to be clear, my original idea was overlaying the screen with a 640*480 black rectangle, and lowering the opacity of circular areas of light (so that the bottom layer showed through). Would that still have the same problem as described?

That's exactly what I was describing earlier. The performance hit could be pretty much eliminated by programming and linking to a .dll file, but that requires a bit more work than you were anticipating, especially since the alpha mask needs to be completely recalculated entirely every time a "light" (i.e. one of the portions that is subtracting opacity) is removed.

 

[regi]

Thanks for the info, then. I'll look into your past projects and see if I can pull anything up. (Haven't had much experience with .dll's, but there's always a first time!)

EDIT: sorry, would you mind linking me to said .dll you made? The forum search does not seem to like file extensions/periods.

 

[Glitchfinder]

Thanks for the info, then. I'll look into your past projects and see if I can pull anything up. (Haven't had much experience with .dll's, but there's always a first time!)

EDIT: sorry, would you mind linking me to said .dll you made? The forum search does not seem to like file extensions/periods.

You can find one of the original posts here. I believe I compiled that in Microsoft Visual Studio, but Code::Blocks or some other compiler that can use both C and C++ should work fine as well. The first function that modifies a bitmap is AlienTwo, along with several others after that. Just keep in mind, while you can modify as little of the bitmap as you want, if you try to change a single value outside the bitmap, the game will crash, and won't give you an understandable reason for it.