CopyRect and alpha values
Archives Forums/Blitz3D Bug Reports/CopyRect and alpha values
| ||
| When I perform a CopyRect from ImageBuffer to TextureBuffer, or from BackBuffer to TextureBuffer, I always loose my alpha values. I assume that Blitz3D should also copy the 8 bits of alpha values as it's an integral part of the image. |
| ||
| It's not IMHO. Images and back/frontbuffer are 24 bit. Only textures may be 32 Bit. Not sure if you can copy the alphachannel using copyrect from tex buffer to texbuffer. Although I agree, it would be much smarter to use 32 bit for everything, or 64bit. So you could handle transparency fx or hi recision RGB editing on a OS near level. But the real world is imperfect. I think 2D will become marginal soon anyway. (Tho, they use emulations in 3D for retro fx) |
| ||
| jfk EO-11110: I won't try to argue with you. But your concept of 2D graphics is missing some crucial knowledge if you think there are no alpha channel definition in a 2 mode, or with sprites, what not. |
| ||
| Indeed! Professional video mixers use 3D acceleration to perform tasks such as video cross alpha-fading and such. 2D is ok to load and render the video, even if blitzcommands are just too weak to make a proper video player. Open, Close and IsPlaying is not sufficent for me. I'd leek to seek the stream forward at least, and knowing the total length and so forth... Bye, |
| ||
| To copy alpha from texture to texture, use Toms DX7Test.dll that offers a CopySurface command that copies pixels between 2 textures and offers this capability. |
| ||
| After reading this, I have the feeling that this is a no issue, but verry annoying!!! I think it,s related to the *bug* as this behaviour seems to be pre-meditated in the first place. ***** V1.53 ***** Replace$ bug with same strings fixed. ReadLine$() returns all chars except chr$(13)/chr$(10). ImagesCollided fixed. READPIXEL AND READPIXELFAST USERS PLEASE READ: ---------------------------------------------- Some issues with ReadPixel and ReadPixelFast have arisen. While working on the 3D, it has been necessary to make ReadPixel and ReadPixelFast "alpha-aware". This means that the high 8 bits of the color returned ReadPixel/ReadPixelFast now contain valid alpha information. However, in the case of Blitz2D apps, there is no alpha information in images! I have decided that in the abscence of any alpha information, a pixel is assumed to have 'full' alpha. Therefore, values returned by ReadPixel/ReadPixelFast will now (usually) have their high 8 bits sets. The exception will be when reading pixels from Blitz3D textures created with an alpha channel. To get the old behaviour of ReadPixel/ReadPixelFast, use the following: rgb=ReadPixel( x,y ) And $FFFFFF This will 'mask out' the 8 high bits of alpha and return just the red, green and blue components of the pixel. I apologize for any inconvenience this change may have caused/be causing, but I believe that, long term, this approach is the right way to go... |
| ||
| Fast Extend lib allows you to copy alpha information. |
   |