[SDL] Transparency problems with certain textures

Mason Wheeler masonwheeler at yahoo.com
Thu Mar 7 16:29:06 PST 2013


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 <moralrecordings at gmail.com>
To: Mason Wheeler <masonwheeler at yahoo.com>; SDL Development List <sdl at lists.libsdl.org> 
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 :(

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 <masonwheeler at yahoo.com> 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!) :(
>
> 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 <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: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 <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);
>>>>    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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130307/d9436e9e/attachment-0009.htm>


More information about the SDL mailing list