-
Notifications
You must be signed in to change notification settings - Fork 5
Alpha transparency in textures doesn't work correctly #149
Comments
Yeah, I can see something similar when running your example. The large texture (6000 pixels wide) returns -3 from CompositeTags on RadeonHD driver but this seems to be a separate issue from alpha blending as I tried to skip this for experiment. For which parts render target textures are involved? IIRC there were something in SDL debug logs. For example, is the main hero blended directly or using some target texture? Is it possible to see the rendering code? I probably need to construct something simpler with a smaller amount of textures. |
The problem is that this is all programmed in Hollywood so that probably doesn't help you that much. You can find the source code for the Beast demo in the RebelSDL archive available from here: https://www.hollywood-mal.com/download.html Hollywood passes the pixel data to RebelSDL as 32-bit ARGB. RebelSDL will then create a texture from this pixel data like so:
Later the script scales each texture by 200% which is done by taking the texture created like above and creating a new texture from it like so:
And then the texture is just drawn using |
Are you also blitting to a target texture with blending? I noticed that if I do something like
Then your demo seems to work. But I don't understand why this helps, why rendering to a target texture which is a similar bitmap than the "default target" should be dealt somehow differently... |
No, I'm not blitting to a target texture with blending. When blitting to a texture, blend mode is always set to |
Btw, here's what
So you can see that the code above doesn't blit with blending to the target texture... |
Thanks for confirming. Bug is mine, problem is related to the batching mechanism. I was using the "current" blend mode of texture, instead of the one that was placed into the command queue. That's why NONE could turn into BLEND. Renderer target blending is still quite messed up, I need to test it more. |
@capehill: This fixes the alpha issue but it breaks normal, non-blended drawing. Check out this example: |
@softwarefailure Can you say, does newtest.zip have anything in alpha channel (non-zero values)? Also, does it work in SW rendering for you? When I hacked it into SW mode, I got a white screen. RC4: https://github.com/AmigaPorts/SDL/releases/tag/v2.0.12-rc4-amigaos4 Now, both your tests seem to work on Radeon R200 and RadeonHD. |
A quick test shows that it works now (although there is now a white line at the bottom and a white line at the right, but these are minor issues, see here: https://github.com/AmigaPorts/SDL/issues/150 ) I'll do some more extensive tests tomorrow and let you know. From the top of my head I think if blending is off it's pretty much undefined what is in the alpha byte but I'll check that too tomorrow. |
I did some more tests and it seems to work nicely. Both in hardware and in software mode. In RebelSDL you can force software mode by using
instead of
But I discovered a new issue, see here: https://github.com/AmigaPorts/SDL/issues/154 |
Fixes merged into master. |
Check out the attached example. It uses
SDL_BLENDMODE_BLEND
to draw textures with transparent pixels. However, this works neither on my Pegasos2 nor on my X1000.This is what it should look like:
This is what it looks like on the Pegasos2: (you can see that the trees are missing entirely and there is a box visible around the player sprite and the fence; also, some lines are visible in the sky)
This is what it looks like on the X1000:
As you can see, on the X1000 it's even worse.
Note that the trees might be missing because the texture is too large but the rest should really be drawn correctly.
Here is the test binary:
temp.zip
The text was updated successfully, but these errors were encountered: