I've once used allegro for djgpp a long time ago and there's a function there that would display a bitmap with it's parts colored magenta as transparent parts... I've seen similar techniques with VC++, how do you do it in win32asm?
In DirectX (which I'm assuming you want to use), there are two ways. The first is to do it by hand. Write a blit routine which locks a specific part of a screen and skips over pixels of a specific color. The second is an automated approach. You use the function IDirectDrawSurface->SetColorKey, and set it to the exact color you want to omit. Then, use IDirectDrawSurface-> BltFast (or whatever you use) and viola. The color is omitted. You will have to include a specific flag called DDBLT(FAST)_SRCCOLORKEY on the surface in order for the second process to work correctly, and you may need to tweak the system in order to get perfect results, but nonetheless, it should work fine. :)
thanks racso, but I'm just on to the simpler way to do it without directx, Ive seen a program made from masm do it, the winplane game included with masm32 v6 service pack 1, it used only the basic GDI functions, unfortunately it didn't have a source included... thanks again...
Hi There are basically 2 or 3 ways to do it, c++ or ASM it doese not matter: 1. keycolour testing ====================== its a test you do when you read the source pixel from the source image and check it for keycolour (usually black as magenta is again usually reserved for the player colour) if your pixel==key colour just dont place it on the destination (variouse optimizations like MMX 4/8 pixels in a single ops or hardware acceleration can be used here) 2.Masking =================== usually its used in GDI have 2 bitmaps for the sprite a normal one with black as colour key and a secondo one=the mask with black where the pixels of the sprite are and white elsewhere AND the mask to the destination and then OR the sprite on top of it thats all...its faster because you DONT have to test at EVERY pixel...but uses 2xpictures...so not so fast after all you can use BitBlt with ROPs to do that 3. Compiled sprites ====================== Just make a program out of your sprite: like: mov ,56 mov ,65 ...etc ITS THE FASTEST EVER METHOD...because you have no reads from the source and no key colour testing at all...However its harder to grasp...and a sprite compiler is reqired... Also Clipping is tricky this way... (a border is required) using any of this method in MASM or any other ASM or VB or C++ or Pascal or "whatever you like" is no problem ... i think :D...but IMHO ASM deliveres the best speed ever :D This message was edited by BogdanOntanu, on 2/19/2001 11:38:15 PM
There's a way I've heard of to 'automate' transparent blits without using a mask bitmap, basically it creates the mask on the fly. Create a monochrome bitmap and select it into the dc. Set the dc's backcolor to the desired transparent color. Then blit the orgional bitmap onto this dc. The resultant bitmap in the dc will be black for the background color, white for the rest. Select an appropiate raster op and you can puch holes with this to drop your desired bitmap transparently.
I first learned of Compiled sprites in Allegro and back then they were fast. But Paul Hsieh has an article that explains why they are now bad. Basically, they make the instruction cache of newer processors useless. bitRAKE
thanks for your suggestions.
In my transparent flat button example, I used the following technique: 1) Load bitmap 2) Create a compatible dc and bitmap 3) For each pixel (you must know the width & height - besides, how can we find it out?) do GetPixel - compare with RGB transparent, then SetPixel with transparent color. Also you can use this to create a mask for MaskBlt on-the-fly: change transparent color to mask blank color, all others - to masked color. I am sure it will work. You have to do this conversion only once, at bitmap load time, and it is not very slow :) Hope it will help...
im not much of a game programmer at all, i really dont even know how to use DirectX properly. But, im guessing, you wouldn't need to have a preset color which is transperant in an image, but rather because a bitmap isn't likly to use all 24bits of colours (assuming its 24bit), for an extra 24bits, you can have a bitmap independant transperancy colour.
IGosha, could I take a look at your source?
bitrake: well compiled sprites use code L1 cache as a separate (read only) L1 data cache and leave the whole L1 data cahe as a write only cache...this improves speed a lot also...(because of Hardward architecture of L1 cache) ALSO a compiled sprite will not do the test for "zero" or color key pixels (this test CAN NOT be predicted by MicroP) so again will gain speed ALSO will only transfer/read the "right pixels" like a RLE compressed sprite will also do...so again will gain speed ALSO the new MicroP are SuperScallar .. so many MOV operations will be executed in the same time...keeping the pipeline at its best use :) ... bottom line compiled sprites still rocks... has other problems...(not speed) This message was edited by BogdanOntanu, on 2/23/2001 6:43:52 PM
The flat transparent source you asked is here: http://www.trojan.ru/download/BitBtn.zip It's my first GDI code, but it seems to work pretty good :)