Thread: Are these possible - transparency and colors

I'm just wondering if this is possible with AlphaBlend or whatever other Windows functions there are.

1. The color of an object remains the same but the alpha varies as determined by a grayscale image. Would it be possible to have this image be drawn with a static color and variable alpha (alpha is a grayscale map), and use 8 bits per pixel instead of 32? If it can be, how could it be done?
2. An image has areas that are fully transparent but others fully opaque, but nothing inbetween. It's like GIF images - transparency is set to one particular color. That is, one of the chosen colors (even for 24-bit images) is to be rendered as fully transparent. Could this be done and if so, how?

The second is possible using blit masks. I think the call is MaskBlt. Petzold's book contains the technique.

The first is not possible.

Well, the first would actually be possible by writing your own function, but it's horribly slow (I don't get why something like DrawDibDraw, AlphaBlend, or BitBlt can draw dozens of objects so quickly whereas merely writing 255 to 3/4 million pixels (2 1/4 million bytes) uses 50% CPU). It's supposedly for the clouds in case you're wondering.

As to the second one, MaskBlt does seem to be one option. It's supposedly mainly for the terrain or landscape the character runs around on.

The reason is that the calls you mention use hardware acceleration or at least a lock-work-unlock cycle.

SetPixel, on the other hand, must lock and unlock graphics memory for every call. This means that for setting 10000 pixels (100x100 - that's actually very small) you have to lock and unlock 10000 times.

Hmm. How would I use hardware acceleration for modifying special effects on the fly? In my game, for example, there's the flare effect where "copies" of the player character expand outward in the direction opposite of travel and they constantly change colors. Modifying the colors is the easy part, but doing so is rather CPU demanding because of not using hardware acceleration.

I would suggest not using GDI, but instead an API that gives you more direct access to the hardware.

I'm not using either GDI or API for this, just basic C stuff. It's basically like this:

Code:

unsigned char ImageData[1440000]; // 800x600 image at 24-bit color

...
void FillColor(unsigned char red, unsigned char green, unsigned char blue)
{
	unsigned int ArrayIndex = 0;
	
	while (ArrayIndex < 1440000)
	{
		ImageData[ArrayIndex] = blue;
		ImageData[ArrayIndex+1] = green;
		ImageData[ArrayIndex+2] = red;
		ArrayIndex += 3;
	}
}

int main()
{
	unsigned int FrameCount = 0;
	
	while (FrameCount < 1200) // 20 seconds
	{
		FillColor(255, 160, 64); // a bright orange
		WaitFrames(1); // wait a frame, 1/60 second
		FrameCount++;
	}
	
	return 0;
}

This just fills a block of pixels 800x600 at true color and it uses 30% of the CPU alone if done at 60 fps. There's no Windows-related functions at all here (except Sleep and timer-related things in the WaitFrames function, but that's completely irrelevant), just basic C stuff and my own functions. This is just an example of such a case.

I only posted that to give an example. What Win32API functions would I then use to create/modify images in real time? For example, take the flare effect. This animation, from early 2005, shows what the flare effect looks like and behaves (This is a still frame preview of it). Programming the effect is quite easy, but it requires modifying the colors in real time (the transparency is constant though - AlphaBlend works for that). Short of using a loop like in my sample code in my previous message to modify the RGB values (of which is CPU demanding), I don't know how else it can be done. That's just one example. There's also the speed blast's distortions, the pound stomp's shockwave, and a few other special effects.

Also don't waste CPU cycles, Limiting the frames by hogging the cycles until the FPS matches is silly.