32-bit images *using* the alpha byte
BlitzPlus Forums/BlitzPlus Programming/32-bit images *using* the alpha byte
| ||
| When a readpixelfast call is made you get a 32-bit integer but with an alpha that is always 255, and when you write to the screen it is if the alpha byte of the write value had been 255, whatever it actually was. Now - could someone write functions that saves, loads and draws bitmaps with the alpha byte in taken into effect? Or should I use PNG-images, how then, and do they contain frames for animation? |
| ||
| alpha has no effect in Blitzplus, no matter what value you set it at. |
| ||
| Yes, i know.. unless you read the alpha byte from a bank and then calculate color of pixel as a blend between imagepixel (in bank) and screen-pixel, where the image is as solid as the alpha byte is great. |
| ||
| I don't see any reason why you couldn't, but I suppose it would be pretty CPU-intensive, since you're doing the work of the GPU in software. |
| ||
| Alphasource# = alphaintvalue / 255 this converts a 0 to 255 alpha value toa 0 to 1 floating point value. alphadest# = 1 - alphasource# red = (redsource * alphasource#) + (reddest * alphadest#) green = (greensource * alphasource#) + (greendest * alphadest#) blue = (bluesource * alphasource#) + (bluedest * alphadest#) then just change the destination color to the above red/green/blue color... Note, however that this isn't fast enough for most real time use... |
| ||
| The reason why it's too slow for realtime use is that readpixelfast and writepixelfast are slow simply because they have to transverse the videocard bandwidth bottleneck to return/set anything... If you are wanting to do this in realtime then forget about the backbuffer() as it won't do you any good...instead create a image in system memory for this, and store your sprites in banks or arrays...writepixelfast is very fast when used within system memory...and you can then use the built in Blitz draw image routines (NOT writepixelfast) to put your system memory image "buffer" onto the frontbuffer() for the user to see... When you writepixelfast you are not only sending a 16/32 bit color across to the video card but you are also sending out a message telling the video card you are sending a single pixel and screen cords for it's location...so in effect you are trying to transfer around 4 times the data just to write one pixel to the screen...but when useing the Blitz image drawing commands this can be done faster because the system tells the videocard how much is being transfered at once, so each pixel doesn't need the added "header" memory transfer overhead that writepixelfast does... |
| ||
| MSW: Hrm.. good to know.. but to create a new blitz-image with regard taken to alpha and the background makes the image be in need of re-generation when the background changes. Would it still be faster though, to, for each "DrawImageAlpha", to generate a new image through a readpixelfast / poking in bank loop, and then draw it using DrawImage, perhaps? You mean that a bank is perfectly drawable as an image if it consists of the same 32-bit integers (although alpha byte is not effective)? Any extra bytes telling width/height/mask/frames to take into account when manually generating a blitz image? I was trying to do very much that same thing you suggested in your 2nd post but f*cked up somehow and made the whole thing more complicted than necessary.. Now I'll try a DrawImageAlpha func using WritePixelFast for a start... |
| ||
| <crappy code removed> |
| ||
| What's wrong anyone? Your Azul image is a .JPG which doesn't support alpha channels... when you load an image Blitz converts it into the same color depth as your program is useing...this means a 8-bit paletted 256 color .BMP is converted into full 32-bit color when you use the Blitz loadimage function...and as BlitzPlus doesn't have support for alpha channels...it won't do anything with them. |
   |