Transparency problems with certain textures

SDL Development
1

I’ve got a window with an OpenGL renderer, and a routine that goes like this:

Use SDL_Image to load an image to a surface.
Create a texture from the surface.
Render the texture to the window.
Render a rectangle of color with a partially transparent alpha value over the top of the texture.

When the image I’m loading is an 8-bit image, this works fine.? But when it’s a 32-bit image, the alpha doesn’t work; instead of a translucent rectangle drawn over the image, I get a solid rectangle.

I talked with Sam about this off-list, and he said that this looks really straightforward and there’s no good reason why it should be behaving this way, and to ask you guys on here.? So, does anyone have any reason why it should work this way?? Here’s the routine to draw the overlay; it gets called after the image is rendered, which is a simple call to SDL_RenderCopy.

procedure DrawShadedImage(const size: TPoint);
var
?? dst: TRect;
begin
?? glEnable(GL_ALPHA_TEST);
?? glEnable(GL_BLEND);
?? glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

?? SDL_SetRenderDrawColor(imgDisplay.Renderer, 255, 64, 64, 130); //translucent light red
?? dst := rect(0, 0, size.x, size.y);
?? SDL_RenderFillRect(imgDisplay.Renderer, @dst);

?? SDL_SetRenderDrawColor(imgDisplay.renderer, 255, 255, 255, 255)
end;

Sam and I suspect that the problem is in the image loading or converting code somewhere, that when given a 32-bit image it ends up creating a texture that doesn’t like alpha blending somehow, but neither of us knows the graphics code well enough to be sure.

Any ideas?

Mason

2

I would have a go at running it through apitrace -
http://apitrace.github.com . This way you get a full dump of just the
OpenGL calls made by the application, and you can do things like
replay it back, or check the internal GL state at any point of
execution (to ensure that some unrelated function doesn’t clobber the
GL state you just painstakingly set up). Almost any obscure OpenGL
problem can be solved by staring at the apitrace dump for long enough.On 8 March 2013 06:10, Mason Wheeler wrote:

I’ve got a window with an OpenGL renderer, and a routine that goes like
this:

Use SDL_Image to load an image to a surface.
Create a texture from the surface.
Render the texture to the window.
Render a rectangle of color with a partially transparent alpha value over
the top of the texture.

When the image I’m loading is an 8-bit image, this works fine. But when
it’s a 32-bit image, the alpha doesn’t work; instead of a translucent
rectangle drawn over the image, I get a solid rectangle.

I talked with Sam about this off-list, and he said that this looks really
straightforward and there’s no good reason why it should be behaving this
way, and to ask you guys on here. So, does anyone have any reason why it
should work this way? Here’s the routine to draw the overlay; it gets
called after the image is rendered, which is a simple call to
SDL_RenderCopy.

procedure DrawShadedImage(const size: TPoint);
var
dst: TRect;
begin
glEnable(GL_ALPHA_TEST);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

SDL_SetRenderDrawColor(imgDisplay.Renderer, 255, 64, 64, 130);
//translucent light red
dst := rect(0, 0, size.x, size.y);
SDL_RenderFillRect(imgDisplay.Renderer, @dst);

SDL_SetRenderDrawColor(imgDisplay.renderer, 255, 255, 255, 255)
end;

Sam and I suspect that the problem is in the image loading or converting
code somewhere, that when given a 32-bit image it ends up creating a texture
that doesn’t like alpha blending somehow, but neither of us knows the
graphics code well enough to be sure.

Any ideas?

Mason

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

3

…well that was interesting.

I downloaded it, tried to run it,
and apparently it is nothing like “as advertised”.? The webpage gives a
bunch of screenshots of useful features that make it look like an actual
debugger, which is what I need.? Instead, it appears to be nothing but a
command-line-driven logging tool with no user interface.? Where do I
download the product in the screenshots?

Mason________________________________
From: Scott Percival
To: Mason Wheeler <@Mason_Wheeler>; SDL Development List
Sent: Thursday, March 7, 2013 2:31 PM
Subject: Re: [SDL] Transparency problems with certain textures

I would have a go at running it through apitrace -
http://apitrace.github.com . This way you get a full dump of just the
OpenGL calls made by the application, and you can do things like
replay it back, or check the internal GL state at any point of
execution (to ensure that some unrelated function doesn’t clobber the
GL state you just painstakingly set up). Almost any obscure OpenGL
problem can be solved by staring at the apitrace dump for long enough.

On 8 March 2013 06:10, Mason Wheeler <@Mason_Wheeler> wrote:

I’ve got a window with an OpenGL renderer, and a routine that goes like
this:

Use SDL_Image to load an image to a surface.
Create a texture from the surface.
Render the texture to the window.
Render a rectangle of color with a partially transparent alpha value over
the top of the texture.

When the image I’m loading is an 8-bit image, this works fine.? But when
it’s a 32-bit image, the alpha doesn’t work; instead of a translucent
rectangle drawn over the image, I get a solid rectangle.

I talked with Sam about this off-list, and he said that this looks really
straightforward and there’s no good reason why it should be behaving this
way, and to ask you guys on here.? So, does anyone have any reason why it
should work this way?? Here’s the routine to draw the overlay; it gets
called after the image is rendered, which is a simple call to
SDL_RenderCopy.

procedure DrawShadedImage(const size: TPoint);
var
? ? dst: TRect;
begin
? ? glEnable(GL_ALPHA_TEST);
? ? glEnable(GL_BLEND);
? ? glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

? ? SDL_SetRenderDrawColor(imgDisplay.Renderer, 255, 64, 64, 130);
//translucent light red
? ? dst := rect(0, 0, size.x, size.y);
? ? SDL_RenderFillRect(imgDisplay.Renderer, @dst);

? ? SDL_SetRenderDrawColor(imgDisplay.renderer, 255, 255, 255, 255)
end;

Sam and I suspect that the problem is in the image loading or converting
code somewhere, that when given a 32-bit image it ends up creating a texture
that doesn’t like alpha blending somehow, but neither of us knows the
graphics code well enough to be sure.

Any ideas?

Mason

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

4

2013/3/7 Mason Wheeler

I’ve got a window with an OpenGL renderer, and a routine that goes like
this:

Use SDL_Image to load an image to a surface.
Create a texture from the surface.
Render the texture to the window.
Render a rectangle of color with a partially transparent alpha value over
the top of the texture.

When the image I’m loading is an 8-bit image, this works fine. But when
it’s a 32-bit image, the alpha doesn’t work; instead of a translucent
rectangle drawn over the image, I get a solid rectangle.

I talked with Sam about this off-list, and he said that this looks really
straightforward and there’s no good reason why it should be behaving this
way, and to ask you guys on here. So, does anyone have any reason why it
should work this way? Here’s the routine to draw the overlay; it gets
called after the image is rendered, which is a simple call to
SDL_RenderCopy.

procedure DrawShadedImage(const size: TPoint);
var
dst: TRect;
begin
glEnable(GL_ALPHA_TEST);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

SDL_SetRenderDrawColor(imgDisplay.Renderer, 255, 64, 64, 130);
//translucent light red
dst := rect(0, 0, size.x, size.y);
SDL_RenderFillRect(imgDisplay.Renderer, @dst);

SDL_SetRenderDrawColor(imgDisplay.renderer, 255, 255, 255, 255)
end;

Sam and I suspect that the problem is in the image loading or converting
code somewhere, that when given a 32-bit image it ends up creating a
texture that doesn’t like alpha blending somehow, but neither of us knows
the graphics code well enough to be sure.

Any ideas?

Mason

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

Calling “glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)” is potentially
useless because afterwards, when you call the SDL drawing functions, on
OpenGL the first thing they do is call GL_SetDrawingState, which
calls GL_SetBlendMode, which in turn may (and probably is) revert your
setting…

What I used to do before doing the SDL_RenderGeometry function, was to draw
a point at -1,-1 thus forcing SDL to a known internal state, then I changed
the blend function as you do. Then, when you call the draw function you
actually want, SDL won’t touch the blend mode.

So, it may be worth a try to see what happens,after rendering the image,
call SDL_RenderDrawPoint, then call DrawShadedImage.–
Gabriel.

5

It’s a two-parter. You run your application through the apitrace tool,
which makes the dump:

$ ~/Development/apitrace/apitrace trace ./myapp

Run through the problem on screen then quit; this’ll make a file
called myapp.dump, which you then pass to the GUI:

$ ~/Development/apitrace/qapitrace ./myapp.dumpOn 8 March 2013 06:50, Mason Wheeler wrote:

…well that was interesting.

I downloaded it, tried to run it, and apparently it is nothing like “as
advertised”. The webpage gives a bunch of screenshots of useful features
that make it look like an actual debugger, which is what I need. Instead,
it appears to be nothing but a command-line-driven logging tool with no user
interface. Where do I download the product in the screenshots?

Mason

From: Scott Percival <@Scott_Percival>
To: Mason Wheeler ; SDL Development List

Sent: Thursday, March 7, 2013 2:31 PM
Subject: Re: [SDL] Transparency problems with certain textures

I would have a go at running it through apitrace -
http://apitrace.github.com . This way you get a full dump of just the
OpenGL calls made by the application, and you can do things like
replay it back, or check the internal GL state at any point of
execution (to ensure that some unrelated function doesn’t clobber the
GL state you just painstakingly set up). Almost any obscure OpenGL
problem can be solved by staring at the apitrace dump for long enough.

On 8 March 2013 06:10, Mason Wheeler wrote:

I’ve got a window with an OpenGL renderer, and a routine that goes like
this:

Use SDL_Image to load an image to a surface.
Create a texture from the surface.
Render the texture to the window.
Render a rectangle of color with a partially transparent alpha value over
the top of the texture.

When the image I’m loading is an 8-bit image, this works fine. But when
it’s a 32-bit image, the alpha doesn’t work; instead of a translucent
rectangle drawn over the image, I get a solid rectangle.

I talked with Sam about this off-list, and he said that this looks really
straightforward and there’s no good reason why it should be behaving this
way, and to ask you guys on here. So, does anyone have any reason why it
should work this way? Here’s the routine to draw the overlay; it gets
called after the image is rendered, which is a simple call to
SDL_RenderCopy.

procedure DrawShadedImage(const size: TPoint);
var
dst: TRect;
begin
glEnable(GL_ALPHA_TEST);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

SDL_SetRenderDrawColor(imgDisplay.Renderer, 255, 64, 64, 130);
//translucent light red
dst := rect(0, 0, size.x, size.y);
SDL_RenderFillRect(imgDisplay.Renderer, @dst);

SDL_SetRenderDrawColor(imgDisplay.renderer, 255, 255, 255, 255)
end;

Sam and I suspect that the problem is in the image loading or converting
code somewhere, that when given a 32-bit image it ends up creating a
texture
that doesn’t like alpha blending somehow, but neither of us knows the
graphics code well enough to be sure.

Any ideas?

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

6

And of course by “myapp.dump” I mean “myapp.trace”. Oops.On 8 March 2013 06:58, Scott Percival <@Scott_Percival> wrote:

It’s a two-parter. You run your application through the apitrace tool,
which makes the dump:

$ ~/Development/apitrace/apitrace trace ./myapp

Run through the problem on screen then quit; this’ll make a file
called myapp.dump, which you then pass to the GUI:

$ ~/Development/apitrace/qapitrace ./myapp.dump

On 8 March 2013 06:50, Mason Wheeler wrote:

…well that was interesting.

I downloaded it, tried to run it, and apparently it is nothing like “as
advertised”. The webpage gives a bunch of screenshots of useful features
that make it look like an actual debugger, which is what I need. Instead,
it appears to be nothing but a command-line-driven logging tool with no user
interface. Where do I download the product in the screenshots?

Mason

From: Scott Percival <@Scott_Percival>
To: Mason Wheeler ; SDL Development List

Sent: Thursday, March 7, 2013 2:31 PM
Subject: Re: [SDL] Transparency problems with certain textures

I would have a go at running it through apitrace -
http://apitrace.github.com . This way you get a full dump of just the
OpenGL calls made by the application, and you can do things like
replay it back, or check the internal GL state at any point of
execution (to ensure that some unrelated function doesn’t clobber the
GL state you just painstakingly set up). Almost any obscure OpenGL
problem can be solved by staring at the apitrace dump for long enough.

On 8 March 2013 06:10, Mason Wheeler wrote:

I’ve got a window with an OpenGL renderer, and a routine that goes like
this:

Use SDL_Image to load an image to a surface.
Create a texture from the surface.
Render the texture to the window.
Render a rectangle of color with a partially transparent alpha value over
the top of the texture.

When the image I’m loading is an 8-bit image, this works fine. But when
it’s a 32-bit image, the alpha doesn’t work; instead of a translucent
rectangle drawn over the image, I get a solid rectangle.

I talked with Sam about this off-list, and he said that this looks really
straightforward and there’s no good reason why it should be behaving this
way, and to ask you guys on here. So, does anyone have any reason why it
should work this way? Here’s the routine to draw the overlay; it gets
called after the image is rendered, which is a simple call to
SDL_RenderCopy.

procedure DrawShadedImage(const size: TPoint);
var
dst: TRect;
begin
glEnable(GL_ALPHA_TEST);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

SDL_SetRenderDrawColor(imgDisplay.Renderer, 255, 64, 64, 130);
//translucent light red
dst := rect(0, 0, size.x, size.y);
SDL_RenderFillRect(imgDisplay.Renderer, @dst);

SDL_SetRenderDrawColor(imgDisplay.renderer, 255, 255, 255, 255)
end;

Sam and I suspect that the problem is in the image loading or converting
code somewhere, that when given a 32-bit image it ends up creating a
texture
that doesn’t like alpha blending somehow, but neither of us knows the
graphics code well enough to be sure.

Any ideas?

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

7

Wow.? Qapitrace has got to be the worst debugging tool I have ever
used, and that’s saying a lot!? (Why oh why does gDebugger not like my
graphics card?!?? That’s what a GL debugging tool should behave like!)
:frowning:

But it did display the contents of each frame, and from that I
was able to determine that something was calling glDisable(GL_BLEND),
and it wasn’t my code.? Turns out that the SDL window’s renderer had its
blend mode set to NONE instead of BLEND.? Fixing that fixed the
problem.

Mason________________________________
From: Scott Percival
To: Mason Wheeler <@Mason_Wheeler>; SDL Development List
Sent: Thursday, March 7, 2013 2:59 PM
Subject: Re: [SDL] Transparency problems with certain textures

And of course by “myapp.dump” I mean “myapp.trace”. Oops.

On 8 March 2013 06:58, Scott Percival wrote:

It’s a two-parter. You run your application through the apitrace tool,
which makes the dump:

$ ~/Development/apitrace/apitrace trace ./myapp

Run through the problem on screen then quit; this’ll make a file
called myapp.dump, which you then pass to the GUI:

$ ~/Development/apitrace/qapitrace ./myapp.dump

On 8 March 2013 06:50, Mason Wheeler <@Mason_Wheeler> wrote:

…well that was interesting.

I downloaded it, tried to run it, and apparently it is nothing like “as
advertised”.? The webpage gives a bunch of screenshots of useful features
that make it look like an actual debugger, which is what I need.? Instead,
it appears to be nothing but a command-line-driven logging tool with no user
interface.? Where do I download the product in the screenshots?

Mason

From: Scott Percival
To: Mason Wheeler <@Mason_Wheeler>; SDL Development List

Sent: Thursday, March 7, 2013 2:31 PM
Subject: Re: [SDL] Transparency problems with certain textures

I would have a go at running it through apitrace -
http://apitrace.github.com . This way you get a full dump of just the
OpenGL calls made by the application, and you can do things like
replay it back, or check the internal GL state at any point of
execution (to ensure that some unrelated function doesn’t clobber the
GL state you just painstakingly set up). Almost any obscure OpenGL
problem can be solved by staring at the apitrace dump for long enough.

On 8 March 2013 06:10, Mason Wheeler <@Mason_Wheeler> wrote:

I’ve got a window with an OpenGL renderer, and a routine that goes like
this:

Use SDL_Image to load an image to a surface.
Create a texture from the surface.
Render the texture to the window.
Render a rectangle of color with a partially transparent alpha value over
the top of the texture.

When the image I’m loading is an 8-bit image, this works fine.? But when
it’s a 32-bit image, the alpha doesn’t work; instead of a translucent
rectangle drawn over the image, I get a solid rectangle.

I talked with Sam about this off-list, and he said that this looks really
straightforward and there’s no good reason why it should be behaving this
way, and to ask you guys on here.? So, does anyone have any reason why it
should work this way?? Here’s the routine to draw the overlay; it gets
called after the image is rendered, which is a simple call to
SDL_RenderCopy.

procedure DrawShadedImage(const size: TPoint);
var
? ? dst: TRect;
begin
? ? glEnable(GL_ALPHA_TEST);
? ? glEnable(GL_BLEND);
? ? glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

? ? SDL_SetRenderDrawColor(imgDisplay.Renderer, 255, 64, 64, 130);
//translucent light red
? ? dst := rect(0, 0, size.x, size.y);
? ? SDL_RenderFillRect(imgDisplay.Renderer, @dst);

? ? SDL_SetRenderDrawColor(imgDisplay.renderer, 255, 255, 255, 255)
end;

Sam and I suspect that the problem is in the image loading or converting
code somewhere, that when given a 32-bit image it ends up creating a
texture
that doesn’t like alpha blending somehow, but neither of us knows the
graphics code well enough to be sure.

Any ideas?

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

8

That’s a bit harsh, there are plenty of piss-poor debugging tools out
there vying for the “worst ever” crown. I agree gDEBugger is a lot
nicer in many aspects, but similar to yourself I’ve managed to make it
work on exactly 1 computer out of the 7 or so I tried. And that was
with crashes every 30 minutes or so. glslDevil was even better because
it had step-through shader debugging, but for some reason I can’t get
that working anywhere now :frowning:

At the very least, apitrace is stable and displays things in a way
which lets you quickly reproduce and digest results. I actually prefer
looking at just the seperate GL call stack instead of the weird gdb
mashup interface thing that gDEBugger has going on. Once you know what
the problem is in GL space, then you can run gdb seperately and know
what you want to intercept.

I agree that for profiling, or shader debugging, or anything remotely
complex involving buffers, you’re probably SOL. But half the time
OpenGL problems are caused by dodgy state changes, and apitrace does
an okay job for diagnosing that.On 8 March 2013 07:54, Mason Wheeler wrote:

Wow. Qapitrace has got to be the worst debugging tool I have ever used,
and that’s saying a lot! (Why oh why does gDebugger not like my graphics
card?!? That’s what a GL debugging tool should behave like!) :frowning:

But it did display the contents of each frame, and from that I was able to
determine that something was calling glDisable(GL_BLEND), and it wasn’t my
code. Turns out that the SDL window’s renderer had its blend mode set to
NONE instead of BLEND. Fixing that fixed the problem.

Mason

From: Scott Percival <@Scott_Percival>
To: Mason Wheeler ; SDL Development List

Sent: Thursday, March 7, 2013 2:59 PM

Subject: Re: [SDL] Transparency problems with certain textures

And of course by “myapp.dump” I mean “myapp.trace”. Oops.

On 8 March 2013 06:58, Scott Percival <@Scott_Percival> wrote:

It’s a two-parter. You run your application through the apitrace tool,
which makes the dump:

$ ~/Development/apitrace/apitrace trace ./myapp

Run through the problem on screen then quit; this’ll make a file
called myapp.dump, which you then pass to the GUI:

$ ~/Development/apitrace/qapitrace ./myapp.dump

On 8 March 2013 06:50, Mason Wheeler wrote:

…well that was interesting.

I downloaded it, tried to run it, and apparently it is nothing like “as
advertised”. The webpage gives a bunch of screenshots of useful features
that make it look like an actual debugger, which is what I need.
Instead,
it appears to be nothing but a command-line-driven logging tool with no
user
interface. Where do I download the product in the screenshots?

Mason

From: Scott Percival <@Scott_Percival>
To: Mason Wheeler ; SDL Development List

Sent: Thursday, March 7, 2013 2:31 PM
Subject: Re: [SDL] Transparency problems with certain textures

I would have a go at running it through apitrace -
http://apitrace.github.com . This way you get a full dump of just the
OpenGL calls made by the application, and you can do things like
replay it back, or check the internal GL state at any point of
execution (to ensure that some unrelated function doesn’t clobber the
GL state you just painstakingly set up). Almost any obscure OpenGL
problem can be solved by staring at the apitrace dump for long enough.

On 8 March 2013 06:10, Mason Wheeler wrote:

I’ve got a window with an OpenGL renderer, and a routine that goes like
this:

Use SDL_Image to load an image to a surface.
Create a texture from the surface.
Render the texture to the window.
Render a rectangle of color with a partially transparent alpha value
over
the top of the texture.

When the image I’m loading is an 8-bit image, this works fine. But when
it’s a 32-bit image, the alpha doesn’t work; instead of a translucent
rectangle drawn over the image, I get a solid rectangle.

I talked with Sam about this off-list, and he said that this looks
really
straightforward and there’s no good reason why it should be behaving
this
way, and to ask you guys on here. So, does anyone have any reason why
it
should work this way? Here’s the routine to draw the overlay; it gets
called after the image is rendered, which is a simple call to
SDL_RenderCopy.

procedure DrawShadedImage(const size: TPoint);
var
dst: TRect;
begin
glEnable(GL_ALPHA_TEST);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

SDL_SetRenderDrawColor(imgDisplay.Renderer, 255, 64, 64, 130);
//translucent light red
dst := rect(0, 0, size.x, size.y);
SDL_RenderFillRect(imgDisplay.Renderer, @dst);

SDL_SetRenderDrawColor(imgDisplay.renderer, 255, 255, 255, 255)
end;

Sam and I suspect that the problem is in the image loading or converting
code somewhere, that when given a 32-bit image it ends up creating a
texture
that doesn’t like alpha blending somehow, but neither of us knows the
graphics code well enough to be sure.

Any ideas?

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

9

I didn’t say it was the worst debugging tool ever–I don’t doubt that there are
worse products out there–just that it’s the worst that I have ever used.
Which is true, as it lacks even the most rudimentary debugging features,
most noticeably an actual debugger (aka the ability to connect to a running
process), and, even looking past that and judging it solely on the features it,
does have, it’s missing the ability to pause execution.? I tell it to play a
replay, and it just zips through the whole thing as fast as it possibly can.? No
pause, no advance-one-frame-at-a-time… nothing that could assist you with

the process of narrowing down your bug.? Literally theonly useful thing in
there–that I could find, at least–is the dump itself and the Search feature.

Mason________________________________
From: Scott Percival
To: Mason Wheeler <@Mason_Wheeler>; SDL Development List
Sent: Thursday, March 7, 2013 4:15 PM
Subject: Re: [SDL] Transparency problems with certain textures

That’s a bit harsh, there are plenty of piss-poor debugging tools out
there vying for the “worst ever” crown. I agree gDEBugger is a lot
nicer in many aspects, but similar to yourself I’ve managed to make it
work on exactly 1 computer out of the 7 or so I tried. And that was
with crashes every 30 minutes or so. glslDevil was even better because
it had step-through shader debugging, but for some reason I can’t get
that working anywhere now :frowning:

At the very least, apitrace is stable and displays things in a way
which lets you quickly reproduce and digest results. I actually prefer
looking at just the seperate GL call stack instead of the weird gdb
mashup interface thing that gDEBugger has going on. Once you know what
the problem is in GL space, then you can run gdb seperately and know
what you want to intercept.

I agree that for profiling, or shader debugging, or anything remotely
complex involving buffers, you’re probably SOL. But half the time
OpenGL problems are caused by dodgy state changes, and apitrace does
an okay job for diagnosing that.

On 8 March 2013 07:54, Mason Wheeler <@Mason_Wheeler> wrote:

Wow.? Qapitrace has got to be the worst debugging tool I have ever used,
and that’s saying a lot!? (Why oh why does gDebugger not like my graphics
card?!?? That’s what a GL debugging tool should behave like!) :frowning:

But it did display the contents of each frame, and from that I was able to
determine that something was calling glDisable(GL_BLEND), and it wasn’t my
code.? Turns out that the SDL window’s renderer had its blend mode set to
NONE instead of BLEND.? Fixing that fixed the problem.

Mason

From: Scott Percival
To: Mason Wheeler <@Mason_Wheeler>; SDL Development List

Sent: Thursday, March 7, 2013 2:59 PM

Subject: Re: [SDL] Transparency problems with certain textures

And of course by “myapp.dump” I mean “myapp.trace”. Oops.

On 8 March 2013 06:58, Scott Percival wrote:

It’s a two-parter. You run your application through the apitrace tool,
which makes the dump:

$ ~/Development/apitrace/apitrace trace ./myapp

Run through the problem on screen then quit; this’ll make a file
called myapp.dump, which you then pass to the GUI:

$ ~/Development/apitrace/qapitrace ./myapp.dump

On 8 March 2013 06:50, Mason Wheeler <@Mason_Wheeler> wrote:

…well that was interesting.

I downloaded it, tried to run it, and apparently it is nothing like “as
advertised”.? The webpage gives a bunch of screenshots of useful features
that make it look like an actual debugger, which is what I need.
Instead,
it appears to be nothing but a command-line-driven logging tool with no
user
interface.? Where do I download the product in the screenshots?

Mason

From: Scott Percival
To: Mason Wheeler <@Mason_Wheeler>; SDL Development List

Sent: Thursday, March 7, 2013 2:31 PM
Subject: Re: [SDL] Transparency problems with certain textures

I would have a go at running it through apitrace -
http://apitrace.github.com . This way you get a full dump of just the
OpenGL calls made by the application, and you can do things like
replay it back, or check the internal GL state at any point of
execution (to ensure that some unrelated function doesn’t clobber the
GL state you just painstakingly set up). Almost any obscure OpenGL
problem can be solved by staring at the apitrace dump for long enough.

On 8 March 2013 06:10, Mason Wheeler <@Mason_Wheeler> wrote:

I’ve got a window with an OpenGL renderer, and a routine that goes like
this:

Use SDL_Image to load an image to a surface.
Create a texture from the surface.
Render the texture to the window.
Render a rectangle of color with a partially transparent alpha value
over
the top of the texture.

When the image I’m loading is an 8-bit image, this works fine.? But when
it’s a 32-bit image, the alpha doesn’t work; instead of a translucent
rectangle drawn over the image, I get a solid rectangle.

I talked with Sam about this off-list, and he said that this looks
really
straightforward and there’s no good reason why it should be behaving
this
way, and to ask you guys on here.? So, does anyone have any reason why
it
should work this way?? Here’s the routine to draw the overlay; it gets
called after the image is rendered, which is a simple call to
SDL_RenderCopy.

procedure DrawShadedImage(const size: TPoint);
var
? ? dst: TRect;
begin
? ? glEnable(GL_ALPHA_TEST);
? ? glEnable(GL_BLEND);
? ? glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

? ? SDL_SetRenderDrawColor(imgDisplay.Renderer, 255, 64, 64, 130);
//translucent light red
? ? dst := rect(0, 0, size.x, size.y);
? ? SDL_RenderFillRect(imgDisplay.Renderer, @dst);

? ? SDL_SetRenderDrawColor(imgDisplay.renderer, 255, 255, 255, 255)
end;

Sam and I suspect that the problem is in the image loading or converting
code somewhere, that when given a 32-bit image it ends up creating a
texture
that doesn’t like alpha blending somehow, but neither of us knows the
graphics code well enough to be sure.

Any ideas?

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

10

Actually yeah, I completely forgot about glretrace. You’re correct,
that’s utterly useless and needs to be fixed.

For now, right clicking on a suspected draw call in qapitrace and
selecting “replay state” (or whatever it’s named) will show you the
buffer contents and state settings at that point in the draw cycle.
That counts as pausing execution, surely?

As you’ve probably gathered, apitrace was designed as a logging tool,
not an in-process debugger. I think the team were talking about the
best way of grafting on a live debugger, but it hasn’t got anywhere.On 8 March 2013 08:29, Mason Wheeler wrote:

I didn’t say it was the worst debugging tool ever–I don’t doubt that there
are
worse products out there–just that it’s the worst that I have ever used.
Which is true, as it lacks even the most rudimentary debugging features,
most noticeably an actual debugger (aka the ability to connect to a
running
process), and, even looking past that and judging it solely on the features
it,
does have, it’s missing the ability to pause execution. I tell it to play
a
replay, and it just zips through the whole thing as fast as it possibly can.
No
pause, no advance-one-frame-at-a-time… nothing that could assist you with
the process of narrowing down your bug. Literally the only useful thing in
there–that I could find, at least–is the dump itself and the Search
feature.

Mason

From: Scott Percival <@Scott_Percival>
To: Mason Wheeler ; SDL Development List

Sent: Thursday, March 7, 2013 4:15 PM

Subject: Re: [SDL] Transparency problems with certain textures

That’s a bit harsh, there are plenty of piss-poor debugging tools out
there vying for the “worst ever” crown. I agree gDEBugger is a lot
nicer in many aspects, but similar to yourself I’ve managed to make it
work on exactly 1 computer out of the 7 or so I tried. And that was
with crashes every 30 minutes or so. glslDevil was even better because
it had step-through shader debugging, but for some reason I can’t get
that working anywhere now :frowning:

At the very least, apitrace is stable and displays things in a way
which lets you quickly reproduce and digest results. I actually prefer
looking at just the seperate GL call stack instead of the weird gdb
mashup interface thing that gDEBugger has going on. Once you know what
the problem is in GL space, then you can run gdb seperately and know
what you want to intercept.

I agree that for profiling, or shader debugging, or anything remotely
complex involving buffers, you’re probably SOL. But half the time
OpenGL problems are caused by dodgy state changes, and apitrace does
an okay job for diagnosing that.

On 8 March 2013 07:54, Mason Wheeler wrote:

Wow. Qapitrace has got to be the worst debugging tool I have ever used,
and that’s saying a lot! (Why oh why does gDebugger not like my graphics
card?!? That’s what a GL debugging tool should behave like!) :frowning:

But it did display the contents of each frame, and from that I was able to
determine that something was calling glDisable(GL_BLEND), and it wasn’t my
code. Turns out that the SDL window’s renderer had its blend mode set to
NONE instead of BLEND. Fixing that fixed the problem.

Mason

From: Scott Percival <@Scott_Percival>
To: Mason Wheeler ; SDL Development List

Sent: Thursday, March 7, 2013 2:59 PM

Subject: Re: [SDL] Transparency problems with certain textures

And of course by “myapp.dump” I mean “myapp.trace”. Oops.

On 8 March 2013 06:58, Scott Percival <@Scott_Percival> wrote:

It’s a two-parter. You run your application through the apitrace tool,
which makes the dump:

$ ~/Development/apitrace/apitrace trace ./myapp

Run through the problem on screen then quit; this’ll make a file
called myapp.dump, which you then pass to the GUI:

$ ~/Development/apitrace/qapitrace ./myapp.dump

On 8 March 2013 06:50, Mason Wheeler wrote:

…well that was interesting.

I downloaded it, tried to run it, and apparently it is nothing like “as
advertised”. The webpage gives a bunch of screenshots of useful
features
that make it look like an actual debugger, which is what I need.
Instead,
it appears to be nothing but a command-line-driven logging tool with no
user
interface. Where do I download the product in the screenshots?

Mason

From: Scott Percival <@Scott_Percival>
To: Mason Wheeler ; SDL Development List

Sent: Thursday, March 7, 2013 2:31 PM
Subject: Re: [SDL] Transparency problems with certain textures

I would have a go at running it through apitrace -
http://apitrace.github.com . This way you get a full dump of just the
OpenGL calls made by the application, and you can do things like
replay it back, or check the internal GL state at any point of
execution (to ensure that some unrelated function doesn’t clobber the
GL state you just painstakingly set up). Almost any obscure OpenGL
problem can be solved by staring at the apitrace dump for long enough.

On 8 March 2013 06:10, Mason Wheeler wrote:

I’ve got a window with an OpenGL renderer, and a routine that goes like
this:

Use SDL_Image to load an image to a surface.
Create a texture from the surface.
Render the texture to the window.
Render a rectangle of color with a partially transparent alpha value
over
the top of the texture.

When the image I’m loading is an 8-bit image, this works fine. But
when
it’s a 32-bit image, the alpha doesn’t work; instead of a translucent
rectangle drawn over the image, I get a solid rectangle.

I talked with Sam about this off-list, and he said that this looks
really
straightforward and there’s no good reason why it should be behaving
this
way, and to ask you guys on here. So, does anyone have any reason why
it
should work this way? Here’s the routine to draw the overlay; it gets
called after the image is rendered, which is a simple call to
SDL_RenderCopy.

procedure DrawShadedImage(const size: TPoint);
var
dst: TRect;
begin
glEnable(GL_ALPHA_TEST);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

SDL_SetRenderDrawColor(imgDisplay.Renderer, 255, 64, 64, 130);
//translucent light red
dst := rect(0, 0, size.x, size.y);
SDL_RenderFillRect(imgDisplay.Renderer, @dst);

SDL_SetRenderDrawColor(imgDisplay.renderer, 255, 255, 255, 255)
end;

Sam and I suspect that the problem is in the image loading or
converting
code somewhere, that when given a 32-bit image it ends up creating a
texture
that doesn’t like alpha blending somehow, but neither of us knows the
graphics code well enough to be sure.

Any ideas?

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