Alpha problems when creating programmatic textures

[Mason_Wheeler]

I’m having some problems with transparency.

I’m trying to do the following:

Create a SDL_Surface.
Fill it with blankness so that it’s completely transparent
Draw several pixels on it
Create a texture from the surface
Render the texture

The problem is, when I render the texture, instead of only seeing the pixels I drew, I see the entire thing, with a black background.

I’ve made sure that the texture’s blend mode is set properly, and that the surface’s blend mode was set before calling SDL_CreateTextureFromSurface, but I’m still getting black backgrounds.

Here’s my code:

function CreateSurface(r, g, b: byte): PSdlSurface;
begin
?? result := TSdlSurface.Create(8, 20, 32);
?? if result.MustLock then
??? result.LockSurface;
?? result.Fill(nil, SDL_MapRGBA(result.Format, 0, 0, 0, 0)); //calls SDL_FillRect to fill the entire area
?? // drawing code here
?? if result.MustLock then
??? result.UnlockSurface;
end;

The output of this gets passed to a routine that sets the surface’s blend mode to SDL_BLENDMODE_BLEND, then calls SDL_CreateTextureFromSurface and sets the resulting texture’s blend mode to SDL_BLENDMODE_BLEND.? Not including it here because there are several layers involved to account for various special cases that don’t apply here, but at the core that’s what it does.

Anyone have any idea as to why the surface transparency isn’t being converted?

Mason

[Mason_Wheeler]

After a bit of debugging, I found something. It might not be exactly the problem I’m looking for, but it’s related.

SDL_CreateTextureFromSurface was not using alpha because the surface’s A mask was 0.

When I create the texture, I passed in default values of 0 for the R, G, B and A masks, which means SDL should set them up properly.? This ends up in SDL_MasksToPixelFormatEnum, where it hits the following code:

??? switch (bpp) {
??? …
??? …
??? …
??? case 32:
??? if (Rmask == 0) {
??? return SDL_PIXELFORMAT_RGB888;
??? }

This is obviously incorrect; RGB888 is a 24-bit pixel format with no alpha component.? Seems to me it should be returning SDL_PIXELFORMAT_RGBA8888.

Can anyone with more experience in SDL internals verify this?? Seems to me it’s an obvious bug, but is there some justification for it?

Mason________________________________
From: Mason Wheeler <@Mason_Wheeler>
To: sdl
Sent: Saturday, August 10, 2013 8:55 AM
Subject: [SDL] Alpha problems when creating programmatic textures

I’m having some problems with transparency.

I’m trying to do the following:

Create a SDL_Surface.
Fill it with blankness so that it’s completely transparent
Draw several pixels on it
Create a texture from the surface
Render the texture

The problem is, when I render the texture, instead of only seeing the pixels I drew, I see the entire thing, with a black background.

I’ve made sure that the texture’s blend mode is set properly, and that the surface’s blend mode was set before calling SDL_CreateTextureFromSurface, but I’m still getting black backgrounds.

Here’s my code:

function CreateSurface(r, g, b: byte): PSdlSurface;
begin
?? result := TSdlSurface.Create(8, 20, 32);
?? if result.MustLock then
???
result.LockSurface;
?? result.Fill(nil, SDL_MapRGBA(result.Format, 0, 0, 0, 0)); //calls SDL_FillRect to fill the entire area
?? // drawing code here
?? if result.MustLock then
??? result.UnlockSurface;
end;

The output of this gets passed to a routine that sets the surface’s blend mode to SDL_BLENDMODE_BLEND, then calls SDL_CreateTextureFromSurface and sets the resulting texture’s blend mode to SDL_BLENDMODE_BLEND.? Not including it here because there are several layers involved to account for various special cases that don’t apply here, but at the core that’s what it does.

Anyone have any idea as to why the surface transparency isn’t being converted?

Mason

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[slouken]

This sounds like it should work. Have you tried with the latest snapshot?

If you’re still having problems, please report a bug to bugzilla with a
simple C test case and I’ll take a look.

Thanks!On Sat, Aug 10, 2013 at 8:55 AM, Mason Wheeler wrote:

I’m having some problems with transparency.

I’m trying to do the following:

Create a SDL_Surface.
Fill it with blankness so that it’s completely transparent
Draw several pixels on it
Create a texture from the surface
Render the texture

The problem is, when I render the texture, instead of only seeing the
pixels I drew, I see the entire thing, with a black background.

I’ve made sure that the texture’s blend mode is set properly, and that the
surface’s blend mode was set before calling SDL_CreateTextureFromSurface,
but I’m still getting black backgrounds.

Here’s my code:

function CreateSurface(r, g, b: byte): PSdlSurface;
begin
result := TSdlSurface.Create(8, 20, 32);
if result.MustLock then
result.LockSurface;
result.Fill(nil, SDL_MapRGBA(result.Format, 0, 0, 0, 0)); //calls
SDL_FillRect to fill the entire area
// drawing code here
if result.MustLock then
result.UnlockSurface;
end;

The output of this gets passed to a routine that sets the surface’s blend
mode to SDL_BLENDMODE_BLEND, then calls SDL_CreateTextureFromSurface and
sets the resulting texture’s blend mode to SDL_BLENDMODE_BLEND. Not
including it here because there are several layers involved to account for
various special cases that don’t apply here, but at the core that’s what it
does.

Anyone have any idea as to why the surface transparency isn’t being
converted?

Mason

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Mason_Wheeler]

I just checked the latest HG version, and the bug in SDL_MasksToPixelFormatEnum is still there.

Manually specifiying R, G, B and A masks when creating the surface works, so I think fixing this would fix the issue.

Mason________________________________
From: Sam Lantinga
To: Mason Wheeler <@Mason_Wheeler>; SDL Development List
Sent: Saturday, August 10, 2013 10:34 AM
Subject: Re: [SDL] Alpha problems when creating programmatic textures

This sounds like it should work. ?Have you tried with the latest snapshot?

If you’re still having problems, please report a bug to bugzilla with a simple C test case and I’ll take a look.

Thanks!

On Sat, Aug 10, 2013 at 8:55 AM, Mason Wheeler <@Mason_Wheeler> wrote:

I’m having some problems with transparency.

I’m trying to do the following:

Create a SDL_Surface.
Fill it with blankness so that it’s completely transparent
Draw several pixels on it
Create a texture from the surface
Render the texture

The problem is, when I render the texture, instead of only seeing the pixels I drew, I see the entire thing, with a black background.

I’ve made sure that the texture’s blend mode is set properly, and that the surface’s blend mode was set before calling SDL_CreateTextureFromSurface, but I’m still getting black backgrounds.

Here’s my code:

function CreateSurface(r, g, b: byte): PSdlSurface;
begin
?? result := TSdlSurface.Create(8, 20, 32);
?? if result.MustLock then
???
result.LockSurface;
?? result.Fill(nil, SDL_MapRGBA(result.Format, 0, 0, 0, 0)); //calls SDL_FillRect to fill the entire area
?? // drawing code here
?? if result.MustLock then
??? result.UnlockSurface;
end;

The output of this gets passed to a routine that sets the surface’s blend mode to SDL_BLENDMODE_BLEND, then calls SDL_CreateTextureFromSurface and sets the resulting texture’s blend mode to SDL_BLENDMODE_BLEND.? Not including it here because there are several layers involved to account for various special cases that don’t apply here, but at the core that’s what it does.

Anyone have any idea as to why the surface transparency isn’t being converted?

Mason

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Mason_Wheeler]

Ugh, did the followup email I sent not go through?

SDL_CreateTextureFromSurface was not using alpha because the surface’s A mask was 0.

When
I create the texture, I passed in default values of 0 for the R, G, B
and A masks, which means SDL should set them up properly.? This ends up
in SDL_MasksToPixelFormatEnum, where it hits the following code:

??? switch (bpp) {
??? …
??? …
??? …
??? case 32:
??? if (Rmask == 0) {
??? return SDL_PIXELFORMAT_RGB888;
??? }

This is obviously incorrect; RGB888 is a 24-bit pixel format with no alpha component.? Seems to me it should be returning SDL_PIXELFORMAT_RGBA8888.

Mason________________________________
From: Mason Wheeler <@Mason_Wheeler>
To: Mason Wheeler <@Mason_Wheeler>; SDL Development List
Sent: Saturday, August 10, 2013 9:47 AM
Subject: Re: [SDL] Alpha problems when creating programmatic textures

After a bit of debugging, I found something. It might not be exactly the problem I’m looking for, but it’s related.

SDL_CreateTextureFromSurface was not using alpha because the surface’s A mask was 0.

When I create the texture, I passed in default values of 0 for the R, G, B and A masks, which means SDL should set them up properly.? This ends up in SDL_MasksToPixelFormatEnum, where it hits the following code:

??? switch (bpp) {
??? …
??? …
??? …
??? case 32:
??? if (Rmask == 0) {
??? return SDL_PIXELFORMAT_RGB888;
??? }

This is obviously incorrect; RGB888 is a 24-bit pixel format with no alpha component.? Seems to me it should be returning SDL_PIXELFORMAT_RGBA8888.

Can anyone with more experience in SDL internals verify this?? Seems to me it’s an obvious bug, but is there some justification for it?

Mason

---

From: Mason Wheeler <@Mason_Wheeler>
To: sdl
Sent: Saturday, August 10, 2013 8:55 AM
Subject: [SDL] Alpha problems when creating programmatic textures

I’m having some problems with transparency.

I’m trying to do the following:

Create a SDL_Surface.
Fill it with blankness so that it’s completely
transparent
Draw several pixels on it
Create a texture from the surface
Render the texture

The problem is, when I render the texture, instead of only seeing the pixels I drew, I see the entire thing, with a black background.

I’ve made sure that the texture’s blend mode is set properly, and that the surface’s blend mode was set before calling SDL_CreateTextureFromSurface, but I’m still getting black backgrounds.

Here’s my code:

function CreateSurface(r, g, b: byte): PSdlSurface;
begin
?? result := TSdlSurface.Create(8, 20, 32);
?? if result.MustLock then
???
result.LockSurface;
?? result.Fill(nil, SDL_MapRGBA(result.Format, 0, 0, 0, 0)); //calls SDL_FillRect to fill the entire area
?? // drawing code here
?? if result.MustLock then
??? result.UnlockSurface;
end;

The output of this gets passed to a routine that sets the surface’s blend mode to SDL_BLENDMODE_BLEND, then calls SDL_CreateTextureFromSurface and sets the resulting texture’s blend mode to SDL_BLENDMODE_BLEND.? Not including it here because there are several layers involved to account for various special cases that don’t apply here, but at the core that’s what it does.

Anyone have any idea as to why the surface transparency isn’t being converted?

Mason

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[slouken]

The default for 32-bit formats has always been XRGB, since specifying a
24-bit format gives you an inefficient 3-byte format. If you want an alpha
channel you do need to specify the masks.

Cheers!On Sat, Aug 10, 2013 at 11:36 AM, Mason Wheeler wrote:

Ugh, did the followup email I sent not go through?

SDL_CreateTextureFromSurface was not using alpha because the surface’s A
mask was 0.

When I create the texture, I passed in default values of 0 for the R, G, B
and A masks, which means SDL should set them up properly. This ends up in
SDL_MasksToPixelFormatEnum, where it hits the following code:

switch (bpp) {
...
...
...
case 32:
    if (Rmask == 0) {
        return SDL_PIXELFORMAT_RGB888;
    }

This is obviously incorrect; RGB888 is a 24-bit pixel format with no alpha
component. Seems to me it should be returning SDL_PIXELFORMAT_RGBA8888.

Mason

---

From: Mason Wheeler

To: Mason Wheeler ; SDL Development List <
sdl at lists.libsdl.org>
Sent: Saturday, August 10, 2013 9:47 AM

Subject: Re: [SDL] Alpha problems when creating programmatic textures

After a bit of debugging, I found something. It might not be exactly the
problem I’m looking for, but it’s related.

SDL_CreateTextureFromSurface was not using alpha because the surface’s A
mask was 0.

When I create the texture, I passed in default values of 0 for the R, G, B
and A masks, which means SDL should set them up properly. This ends up in
SDL_MasksToPixelFormatEnum, where it hits the following code:

switch (bpp) {
...
...
...
case 32:
    if (Rmask == 0) {
        return SDL_PIXELFORMAT_RGB888;
    }

This is obviously incorrect; RGB888 is a 24-bit pixel format with no alpha
component. Seems to me it should be returning SDL_PIXELFORMAT_RGBA8888.

Can anyone with more experience in SDL internals verify this? Seems to me
it’s an obvious bug, but is there some justification for it?

Mason

---

From: Mason Wheeler
To: sdl
Sent: Saturday, August 10, 2013 8:55 AM
Subject: [SDL] Alpha problems when creating programmatic textures

I’m having some problems with transparency.

I’m trying to do the following:

Create a SDL_Surface.
Fill it with blankness so that it’s completely transparent
Draw several pixels on it
Create a texture from the surface
Render the texture

The problem is, when I render the texture, instead of only seeing the
pixels I drew, I see the entire thing, with a black background.

I’ve made sure that the texture’s blend mode is set properly, and that the
surface’s blend mode was set before calling SDL_CreateTextureFromSurface,
but I’m still getting black backgrounds.

Here’s my code:

function CreateSurface(r, g, b: byte): PSdlSurface;
begin
result := TSdlSurface.Create(8, 20, 32);
if result.MustLock then
result.LockSurface;
result.Fill(nil, SDL_MapRGBA(result.Format, 0, 0, 0, 0)); //calls
SDL_FillRect to fill the entire area
// drawing code here
if result.MustLock then
result.UnlockSurface;
end;

The output of this gets passed to a routine that sets the surface’s blend
mode to SDL_BLENDMODE_BLEND, then calls SDL_CreateTextureFromSurface and
sets the resulting texture’s blend mode to SDL_BLENDMODE_BLEND. Not
including it here because there are several layers involved to account for
various special cases that don’t apply here, but at the core that’s what it
does.

Anyone have any idea as to why the surface transparency isn’t being
converted?

Mason

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[john_skaller]

The default for 32-bit formats has always been XRGB, since specifying a 24-bit format gives you an inefficient 3-byte format. If you want an alpha channel you do need to specify the masks.

So can you say what happens when I create a window (on OSX for me at present),
and then get a surface from it?

Also what happens in TTF when it returns a surface containing the bitmap
for a glyph?

I have had some issues with alpha not working in plain SDL (no OGL).
Software rendering only.On 11/08/2013, at 4:49 AM, Sam Lantinga wrote:

–
john skaller
@john_skaller
http://felix-lang.org

[slouken]

If you get a window surface, that should have opaque alpha.

When get a surface from SDL_ttf it depends on which function you used.

Make sure you have the latest RC candidate, and if you’re having issues
please submit a bug report with a minimal test case. There are lots and
lots of code paths through the blit code so tracking down bugs is a matter
of stepping through the code.

On my TODO list is a comprehensive automated test covering all combinations
of pixel formats and blit flags, but it’ll happen post 2.0.On Sat, Aug 10, 2013 at 3:24 PM, john skaller <skaller at users.sourceforge.net wrote:

On 11/08/2013, at 4:49 AM, Sam Lantinga wrote:

The default for 32-bit formats has always been XRGB, since specifying a
24-bit format gives you an inefficient 3-byte format. If you want an alpha
channel you do need to specify the masks.

So can you say what happens when I create a window (on OSX for me at
present),
and then get a surface from it?

Also what happens in TTF when it returns a surface containing the bitmap
for a glyph?

I have had some issues with alpha not working in plain SDL (no OGL).
Software rendering only.

–
john skaller
skaller at users.sourceforge.net
http://felix-lang.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[john_skaller]

If you get a window surface, that should have opaque alpha.

I see.

On OSX, this is sometimes not what you want. OSX windows often have transparency
so you can see through them to the desktop.

So I guess specifying that would have to be an option of the CreateWindow function,
and if specified then the surface would have the appropriate transparency.

Not sure how useful that would be. My Vim does not do it. However
the iTerminal program does.

However there’s another way if we can just fill the surface with
a transparent colour.

and if you’re having issues please submit a bug report with a minimal test case. There are lots and lots of code paths through the blit code so tracking down bugs is a matter of stepping through the code.

Yeah, there are. Must have been a LOT of work over a long time
to get that stuff working. Low level graphics and abstraction don’t mix (at least not
if you want performance).

On my TODO list is a comprehensive automated test covering all combinations of pixel formats and blit flags, but it’ll happen post 2.0.

Just curious how you can automate verification of the output (without visual inspection).
To do that you have to calculate what the output should be.

How would you do that? Using SDL of course. Err … but that’s what you’re
trying to test :)On 11/08/2013, at 8:44 AM, Sam Lantinga wrote:

–
john skaller
@john_skaller
http://felix-lang.org

[Sik_the_hedgehog]

This has been discussed some days ago on GDNet, turns out that
hardware doesn’t support 24-bit textures at all anymore, and instead
drivers will convert them to 32-bit. Unless one is desperate to keep
the data in RAM and reduce memory usage as much as possible, don’t
bother with 24-bit.

2013/8/10, Sam Lantinga :> The default for 32-bit formats has always been XRGB, since specifying a

24-bit format gives you an inefficient 3-byte format. If you want an alpha
channel you do need to specify the masks.

Cheers!

On Sat, Aug 10, 2013 at 11:36 AM, Mason Wheeler wrote:

Ugh, did the followup email I sent not go through?

SDL_CreateTextureFromSurface was not using alpha because the surface’s A
mask was 0.

When I create the texture, I passed in default values of 0 for the R, G,
B
and A masks, which means SDL should set them up properly. This ends up
in
SDL_MasksToPixelFormatEnum, where it hits the following code:

switch (bpp) {
...
...
...
case 32:
    if (Rmask == 0) {
        return SDL_PIXELFORMAT_RGB888;
    }

This is obviously incorrect; RGB888 is a 24-bit pixel format with no
alpha
component. Seems to me it should be returning SDL_PIXELFORMAT_RGBA8888.

Mason

---

From: Mason Wheeler

To: Mason Wheeler ; SDL Development List <
sdl at lists.libsdl.org>
Sent: Saturday, August 10, 2013 9:47 AM

Subject: Re: [SDL] Alpha problems when creating programmatic textures

After a bit of debugging, I found something. It might not be exactly the
problem I’m looking for, but it’s related.

SDL_CreateTextureFromSurface was not using alpha because the surface’s A
mask was 0.

When I create the texture, I passed in default values of 0 for the R, G,
B
and A masks, which means SDL should set them up properly. This ends up
in
SDL_MasksToPixelFormatEnum, where it hits the following code:

switch (bpp) {
...
...
...
case 32:
    if (Rmask == 0) {
        return SDL_PIXELFORMAT_RGB888;
    }

This is obviously incorrect; RGB888 is a 24-bit pixel format with no
alpha
component. Seems to me it should be returning SDL_PIXELFORMAT_RGBA8888.

Can anyone with more experience in SDL internals verify this? Seems to
me
it’s an obvious bug, but is there some justification for it?

Mason

---

From: Mason Wheeler
To: sdl
Sent: Saturday, August 10, 2013 8:55 AM
Subject: [SDL] Alpha problems when creating programmatic textures

I’m having some problems with transparency.

I’m trying to do the following:

Create a SDL_Surface.
Fill it with blankness so that it’s completely transparent
Draw several pixels on it
Create a texture from the surface
Render the texture

The problem is, when I render the texture, instead of only seeing the
pixels I drew, I see the entire thing, with a black background.

I’ve made sure that the texture’s blend mode is set properly, and that
the
surface’s blend mode was set before calling SDL_CreateTextureFromSurface,
but I’m still getting black backgrounds.

Here’s my code:

function CreateSurface(r, g, b: byte): PSdlSurface;
begin
result := TSdlSurface.Create(8, 20, 32);
if result.MustLock then
result.LockSurface;
result.Fill(nil, SDL_MapRGBA(result.Format, 0, 0, 0, 0)); //calls
SDL_FillRect to fill the entire area
// drawing code here
if result.MustLock then
result.UnlockSurface;
end;

The output of this gets passed to a routine that sets the surface’s blend
mode to SDL_BLENDMODE_BLEND, then calls SDL_CreateTextureFromSurface and
sets the resulting texture’s blend mode to SDL_BLENDMODE_BLEND. Not
including it here because there are several layers involved to account
for
various special cases that don’t apply here, but at the core that’s what
it
does.

Anyone have any idea as to why the surface transparency isn’t being
converted?

Mason

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Mason_Wheeler]

Right.? And explicitly asking for a 32-bit surface, (which can really only mean one thing: 3 colors and an alpha channel,) and then getting a surface without an alpha channel, is a heck of a POLS violation!

Mason________________________________
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Sent: Saturday, August 10, 2013 5:28 PM
Subject: Re: [SDL] Alpha problems when creating programmatic textures

This has been discussed some days ago on GDNet, turns out that
hardware doesn’t support 24-bit textures at all anymore, and instead
drivers will convert them to 32-bit. Unless one is desperate to keep
the data in RAM and reduce memory usage as much as possible, don’t
bother with 24-bit.

2013/8/10, Sam Lantinga :

The default for 32-bit formats has always been XRGB, since specifying a
24-bit format gives you an inefficient 3-byte format.? If you want an alpha
channel you do need to specify the masks.

Cheers!

On Sat, Aug 10, 2013 at 11:36 AM, Mason Wheeler <@Mason_Wheeler>wrote:

Ugh, did the followup email I sent not go through?

SDL_CreateTextureFromSurface was not using alpha because the surface’s A
mask was 0.

When I create the texture, I passed in default values of 0 for the R, G,
B
and A masks, which means SDL should set them up properly.? This ends up
in
SDL_MasksToPixelFormatEnum, where it hits the following code:

? ? switch (bpp) {
? ? …
? ? …
? ? …
? ? case 32:
? ? ? ? if (Rmask == 0) {
? ? ? ? ? ? return SDL_PIXELFORMAT_RGB888;
? ? ? ? }

This is obviously incorrect; RGB888 is a 24-bit pixel format with no
alpha
component.? Seems to me it should be returning SDL_PIXELFORMAT_RGBA8888.

Mason

? ------------------------------
? From: Mason Wheeler <@Mason_Wheeler>

To: Mason Wheeler <@Mason_Wheeler>; SDL Development List <
sdl at lists.libsdl.org>
Sent: Saturday, August 10, 2013 9:47 AM

Subject: Re: [SDL] Alpha problems when creating programmatic textures

After a bit of debugging, I found something. It might not be exactly the
problem I’m looking for, but it’s related.

SDL_CreateTextureFromSurface was not using alpha because the surface’s A
mask was 0.

When I create the texture, I passed in default values of 0 for the R, G,
B
and A masks, which means SDL should set them up properly.? This ends up
in
SDL_MasksToPixelFormatEnum, where it hits the following code:

? ? switch (bpp) {
? ? …
? ? …
? ? …
? ? case 32:
? ? ? ? if (Rmask == 0) {
? ? ? ? ? ? return SDL_PIXELFORMAT_RGB888;
? ? ? ? }

This is obviously incorrect; RGB888 is a 24-bit pixel format with no
alpha
component.? Seems to me it should be returning SDL_PIXELFORMAT_RGBA8888.

Can anyone with more experience in SDL internals verify this?? Seems to
me
it’s an obvious bug, but is there some justification for it?

Mason

? ------------------------------
? From: Mason Wheeler <@Mason_Wheeler>
To: sdl
Sent: Saturday, August 10, 2013 8:55 AM
Subject: [SDL] Alpha problems when creating programmatic textures

I’m having some problems with transparency.

I’m trying to do the following:

Create a SDL_Surface.
Fill it with blankness so that it’s completely transparent
Draw several pixels on it
Create a texture from the surface
Render the texture

The problem is, when I render the texture, instead of only seeing the
pixels I drew, I see the entire thing, with a black background.

I’ve made sure that the texture’s blend mode is set properly, and that
the
surface’s blend mode was set before calling SDL_CreateTextureFromSurface,
but I’m still getting black backgrounds.

Here’s my code:

function CreateSurface(r, g, b: byte): PSdlSurface;
begin
? ? result := TSdlSurface.Create(8, 20, 32);
? ? if result.MustLock then
? ? ? result.LockSurface;
? ? result.Fill(nil, SDL_MapRGBA(result.Format, 0, 0, 0, 0)); //calls
SDL_FillRect to fill the entire area
? ? // drawing code here
? ? if result.MustLock then
? ? ? result.UnlockSurface;
end;

The output of this gets passed to a routine that sets the surface’s blend
mode to SDL_BLENDMODE_BLEND, then calls SDL_CreateTextureFromSurface and
sets the resulting texture’s blend mode to SDL_BLENDMODE_BLEND.? Not
including it here because there are several layers involved to account
for
various special cases that don’t apply here, but at the core that’s what
it
does.

Anyone have any idea as to why the surface transparency isn’t being
converted?

Mason

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org