Skip to content
This repository has been archived by the owner on Feb 10, 2024. It is now read-only.

Alpha transparency in textures doesn't work correctly #149

Closed
afalkenhahn opened this issue Jun 16, 2020 · 12 comments
Closed

Alpha transparency in textures doesn't work correctly #149

afalkenhahn opened this issue Jun 16, 2020 · 12 comments
Assignees
Labels
bug Something isn't working OS:amigaos4

Comments

@afalkenhahn
Copy link

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:

expectedresult

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)

peg2

This is what it looks like on the X1000:

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

@capehill
Copy link
Collaborator

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.

@capehill capehill self-assigned this Jun 16, 2020
@capehill capehill added bug Something isn't working OS:amigaos4 labels Jun 16, 2020
@afalkenhahn
Copy link
Author

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:

		if(!(bm->texture = SDL_CreateTexture(sdlw->renderer, SDL_PIXELFORMAT_ARGB8888, SDL_TEXTUREACCESS_STATIC, width, height))) goto error_allocbitmap;
	
		SDL_UpdateTexture(bm->texture, NULL, data, width * 4); 

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:

	if(!(bm->texture = SDL_CreateTexture(sdlw->renderer, SDL_PIXELFORMAT_ARGB8888, SDL_TEXTUREACCESS_TARGET, width, height))) goto error_allocbitmap;
	
	setrendertarget(sdlw, bm->texture);	

	// important: we want to make a raw copy		
	SDL_SetTextureBlendMode(srcbm->texture, SDL_BLENDMODE_NONE);
	
	// this will automatically do the scaling
	SDL_RenderCopy(sdlw->renderer, srcbm->texture, NULL, NULL);		
	
	// restore old setting
	SDL_SetTextureBlendMode(srcbm->texture, (srcbm->blend) ? SDL_BLENDMODE_BLEND : SDL_BLENDMODE_NONE);

And then the texture is just drawn using SDL_RenderCopy(). Everything you see in the demo is drawn like that. It's rather simplistic.

@capehill
Copy link
Collaborator

@softwarefailure

Are you also blitting to a target texture with blending? I noticed that if I do something like

if (blendingPath)
  destAlpha = (targetTexture) ? 0.0f : 1.0f

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...

@afalkenhahn
Copy link
Author

No, I'm not blitting to a target texture with blending. When blitting to a texture, blend mode is always set to SDL_BLENDMODE_NONE. See the code above. That's the only instance of RebelSDL blitting to a target texture.

@afalkenhahn
Copy link
Author

Btw, here's what setrendertarget() from the code above looks like:

static void setrendertarget(struct sdldisplayinfo *sdlw, SDL_Texture *target)
{
	if(sdlw->target != target) {
		SDL_SetRenderTarget(sdlw->renderer, target);
		sdlw->target = target;
	}
}

So you can see that the code above doesn't blit with blending to the target texture...

@capehill
Copy link
Collaborator

@softwarefailure

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
Copy link
Collaborator

@afalkenhahn
Copy link
Author

@capehill: This fixes the alpha issue but it breaks normal, non-blended drawing. Check out this example:
newtest.zip This used to work with your previous build. Now it doesn't work at all. Nothing is drawn. Test system is a Pegasos2.

@capehill
Copy link
Collaborator

@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.

@afalkenhahn
Copy link
Author

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.

@afalkenhahn
Copy link
Author

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

@REQUIRE "RebelSDL", {UseSoftwareRenderer = True, EnableVSync = False}

instead of

@REQUIRE "RebelSDL"

But I discovered a new issue, see here: https://github.com/AmigaPorts/SDL/issues/154

@capehill
Copy link
Collaborator

capehill commented Jul 1, 2020

Fixes merged into master.

@capehill capehill closed this as completed Jul 1, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working OS:amigaos4
Projects
None yet
Development

No branches or pull requests

2 participants