DisplayIntensitySprite

[THCM]

DisplayIntensitySprite(#Sprite, x , y, Intensity)
This should be a simple version of DisplayTranslucideSprite. Black 0,0,0 should be transparent, but sprite will not be mixed with the background and so it won't need a slow read to the graphicsmemory. It is not only useful for my game, but also to all simple fade-in or out stuff even screenfades should be possible. The good thing is, that's not to hard to implement for you Fred. Just a little bit of cut&paste

[traumatic]

I don't understand. If you have an intensity parameter, isn't "mixing with
the background" mandatory? How else would you be able to determine the
underlying color?

[THCM]

You can also call it brightness. 255 is max (white) and 0 is min (black). I don't want to mix my sprite with the background. I only want to display my sprite with diffrent levels of brightness. It's the same as using DisplayTranslucideSprite with a black background.

[traumatic]

So it's only supposed to work on a black (or other predefined colored)
background then? Hmm... still it has to be mixed!? Is this for 1-bit only?
And no, I don't want to argue, just understand the idea!

[THCM]

It should work on every background. A 16 bit or 32 bit screen is no Problem. It's just the same command as DisplayTransparentSprite with an optional brightness parameter. Black 0,0,0 pixels (or any other color you want) will not be drawn to the screen, because they are transparent. All the other pixels are darkened before they will be plotted to the screen.

[traumatic]

All the other pixels are darkened before they will be plotted to the screen.

And that's what I mean: In order to "darken" a pixel, you need to know
the underlying color, don't you?

Or is it like this: Let's say, you have a one colored image, completely white.
Now displaying this on top of a red background with intensity set to 128
doesn't make it red, but grey?

[THCM]

Here is a simple formula to calculate the brightness. You have to calculate it for every color component (R,G,B). We assume that R,G,B are 8 Bit wide: R=R * Itensity / 256 I think it's possible a simple mmx command to do this for all components at a time.

[traumatic]

So I was right with my last assumption. Ok then, thanks for the explanation.

[THCM]

No, the background has nothing to do with this command. The complete Sprite will be darkened before with my formula above and then it will be drawn like DisplayTransparentSprite. There is no mixing with the existing background. Just a simple fade based on an intensity of 256 levels. I don't know if you can do this in hardware without using Direct3D. But it should be fast enough to draw a sprite from system memory to the screen.

If you want, I can call you and explain on the phone. I'm at work right now.

[traumatic]

Yes so that means that white gets grey!?

[THCM]

If you set the intensity to 0 you'll get a complete black sprite and if you set the intensity to 255 you'll get the original solid (with transparent pixels) sprite and if you set the intensity to 128 you'll get a 50% darker sprite. For example a white (255,255,255) pixel will be grey (127,127,127) and a red (255,0,0) will be dark red afterwards (127,0,0).

With this comannd it's possible to do nice fade in and out effects. Just increment or decrement the intensity every retrace.

[traumatic]

Yes, I got it right then. (5 posts before )

Thx again!


Honestly you just wanted to hear my voice, eh?

[THCM]

Yeah, give this man a cigar! My first thougt was, that you are begging my leg! Just joking!

[dracflamloc]

This is a good idea. Using alphasprite on a whole screen to get a nice fade-in nighttime effect is slow...

[Trond]

How about using Box()?