|
a bug RLE sprites |
Milan Mimica
Member #3,877
September 2003
|
There is a bug somewhere in RLE sprite code because draw_trans_sprite() and draw_trans_rle_sprite() do not display the same image, when the RLE sprite and the plain sprite are of the same contens. Attached is a test program that shows the difference: the magenta color is not displayed but it should.
-- |
X-G
Member #856
December 2000
|
Actually, attached is a TGA, which is (believe it or not) an even worse web format than BMP. Try again. -- |
Evert
Member #794
November 2000
|
Show code. I'm willing to bet there's a colour conversion happening somewhere. |
Milan Mimica
Member #3,877
September 2003
|
I attached a wrong file, sorry. Corrected now. edit:
-- |
GullRaDriel
Member #3,861
September 2003
|
Milan Mimica's test code:
Screenshot of the program: Source Image: "Code is like shit - it only smells if it is not yours" |
Evert
Member #794
November 2000
|
Quote: So is it a bug? It can't literally be , since I know from my own code that using a BITMAP or an RLE sprite created from that bitmap do actually produce the same result when normally drawn. You should have mentioned you were using alpha channels though (or maybe I should have read your original post a bit more carefully and inferred it from there)! When you construct the RLE sprite, it throws away the magic pink parts irrespective of the alpha value there (the docs are actually outdated in this respect because they say that "repeated zero pixels are replaced by a single length count"). When you then activate the alpha blender and draw the sprite, it will only look at the alpha value for the parts that it has retained - it cannot draw parts of the image it has thrown away. In other words, the image shows the expected behavior for the RLE sprite. Quote: As draw_sprite() this function skips transparent pixels. For the alpha-blending mode, however, "transparency" is only determined by the alpha value (as per http://www.allegro.cc/manual/set_alpha_blender), so this is probably actually the intended behavior for alpha blending. If anything, this is a bug in draw_trans_sprite(), not in the RLE sprite code. However, I think this more reflects a difference between RLE sprites and "normal" sprites than a bug in the code. You may argue that RLE sprites created after enabling the alpha blending mode should skip pixels that are invisible according to the alpha value rather than the mask colour (maybe it actually does this, but I don't think so), but I personally feel this makes things much more complicated for little gain. I don't think you have a case for RLE sprites created before enabling the alpha blender. I think the current behavior is actually consistent with the documentation, but the documentation doesn't make this clear enough. In other words, I think the documentation should be clarified rather than the code changed. Feel free to argue this point though. One other thing: I vaguely recall something like this being discussed on AD at some point in the past few years. You may want to see if anything like that turns up in the archive (I can probably do that more easily from my local mailbox at home than through the SF archive, but I won't be able to do that for a couple of days at least). |
|