[SDL] Transparency problems with certain textures

Scott Percival moralrecordings at gmail.com
Thu Mar 7 14:59:21 PST 2013

And of course by "myapp.dump" I mean "myapp.trace". Oops.

On 8 March 2013 06:58, Scott Percival <moralrecordings at gmail.com> 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 <masonwheeler at yahoo.com> 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 <moralrecordings at gmail.com>
>> To: Mason Wheeler <masonwheeler at yahoo.com>; SDL Development List
>> <sdl at lists.libsdl.org>
>> 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 <masonwheeler at yahoo.com> 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);
>>>    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

More information about the SDL mailing list