SDL 1.3 API change

slouken · January 21, 2010, 4:20pm

The latest SDL 1.3 snapshot has converted SDL_TextureID and
SDL_WindowID to structure pointers. This allows easier debugging and
faster and simpler internal code. Windows are still referenced by ID
in events, and there are new functions SDL_GetWindowID() and
SDL_GetWindowFromID() to handle this.

I included #defines of SDL_TextureID and SDL_WindowID in SDL_compat.h
so hopefully all code won’t immediately break, but they are considered
deprecated and will go away in a future snapshot. All the test code
has been converted to use the new types.

Please let me know ASAP if you have any problems related to this change!

See ya!–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Adam_Strzelecki · January 21, 2010, 6:02pm

Sam Lantinga wrote:

The latest SDL 1.3 snapshot has converted SDL_TextureID and
SDL_WindowID to structure pointers. This allows easier debugging and
faster and simpler internal code.

Great. Thank you.

Windows are still referenced by ID
in events, and there are new functions SDL_GetWindowID() and
SDL_GetWindowFromID() to handle this.

This may cause little trouble with previous 1.3 API as statements such: if(my_window == event.key.windowID) won’t work anymore.
But I understand this is to protect from events from destroyed window.

I included #defines of SDL_TextureID and SDL_WindowID in SDL_compat.h
so hopefully all code won’t immediately break, but they are considered
deprecated and will go away in a future snapshot. All the test code
has been converted to use the new types.

I advise to better use:
typedef SDL_Texture *SDL_TextureID;

Unless you want problems when declaring variables in some function this way:
SDL_TextureID t1, t2, t3;

With define only t1 is declared as SDL_Texture *, others are SDL_Texture and you get:
error: storage size of ?t2? isn?t known

Regards,–
Adam

hardcoder · January 21, 2010, 6:11pm

Sam Lantinga wrote:

The latest SDL 1.3 snapshot has converted SDL_TextureID and
SDL_WindowID to structure pointers. This allows easier debugging and
faster and simpler internal code. Windows are still referenced by ID
in events, and there are new functions SDL_GetWindowID() and
SDL_GetWindowFromID() to handle this.

I included #defines of SDL_TextureID and SDL_WindowID in SDL_compat.h
so hopefully all code won’t immediately break, but they are considered
deprecated and will go away in a future snapshot. All the test code
has been converted to use the new types.

Please let me know ASAP if you have any problems related to this change!

After tiny mods to make my application work with new API, everything seems to work nicely except one thing: SDL_Quit() seems to do some infinite looping maybe as it never returns now which makes application freeze.

Adam_Strzelecki · January 21, 2010, 6:46pm

After tiny mods to make my application work with new API, everything seems to work nicely except one thing: SDL_Quit() seems to do some infinite looping maybe as it never returns now which makes application freeze.

Same here, my app works like a charm until I try to quit.

I get infinite loop at:

2732 /* Free existing textures for this renderer */
2733 while (renderer->textures) {
2734 SDL_DestroyTexture(renderer->textures);
2735 }

SDL_DestroyTexture fails all the time because renderer->textures->renderer is 0x0! So we loop infinitely.

(gdb) p *renderer->textures
$3 = {
format = 2251694084,
access = 0,
w = 56,
h = 22,
modMode = 0,
blendMode = 2,
scaleMode = 0,
r = 255 ‘?’,
g = 255 ‘?’,
b = 255 ‘?’,
a = 255 ‘?’,
renderer = 0x0,
driverdata = 0x0,
prev = 0x0,
next = 0xa2000101974600
}

Here’s a backtrace:

#0 0x0000000100ab931c in SDL_SetError (fmt=0x100ba43e8 “id texture”) at /Users/ono/Code/Libraries/SDL/Xcode/SDL/…/…/src/SDL_error.c:66
#1 0x0000000100b8d7da in SDL_DestroyTexture (texture=0x101973ab0) at /Users/ono/Code/Libraries/SDL/Xcode/SDL/…/…/src/video/SDL_video.c:2703
#2 0x0000000100b8d88a in SDL_DestroyRenderer (window=0x10194ef00) at /Users/ono/Code/Libraries/SDL/Xcode/SDL/…/…/src/video/SDL_video.c:2734
#3 0x0000000100b8b177 in SDL_DestroyWindow (window=0x10194ef00) at /Users/ono/Code/Libraries/SDL/Xcode/SDL/…/…/src/video/SDL_video.c:1440
#4 0x0000000100b8da90 in SDL_VideoQuit () at /Users/ono/Code/Libraries/SDL/Xcode/SDL/…/…/src/video/SDL_video.c:2802
#5 0x0000000100aba054 in SDL_QuitSubSystem (flags=65535) at /Users/ono/Code/Libraries/SDL/Xcode/SDL/…/…/src/SDL.c:217
#6 0x0000000100aba092 in SDL_Quit () at /Users/ono/Code/Libraries/SDL/Xcode/SDL/…/…/src/SDL.c:244
#7 0x000000010000bb6c in main (argc=1, argv=0x7fff5fbff700) at source/main.c:1086

Regards,–
Adam

slouken · January 21, 2010, 9:16pm

Thanks for the report. Do you have a test case? I haven’t been able
to reproduce it, and I haven’t found the problem by code inspection…On Thu, Jan 21, 2010 at 10:46 AM, Adam Strzelecki wrote:

After tiny mods to make my application work with new API, everything seems to work nicely except one thing: SDL_Quit() seems to do some infinite looping maybe as it never returns now which makes application freeze.

Same here, my app works like a charm until I try to quit.

I get infinite loop at:

2732 ? ? ? ?/* Free existing textures for this renderer */
2733 ? ? ? ?while (renderer->textures) {
2734 ? ? ? ? ? ?SDL_DestroyTexture(renderer->textures);
2735 ? ? ? ?}

SDL_DestroyTexture fails all the time because renderer->textures->renderer is 0x0! So we loop infinitely.

(gdb) p *renderer->textures
$3 = {
?format = 2251694084,
?access = 0,
?w = 56,
?h = 22,
?modMode = 0,
?blendMode = 2,
?scaleMode = 0,
?r = 255 ‘?’,
?g = 255 ‘?’,
?b = 255 ‘?’,
?a = 255 ‘?’,
?renderer = 0x0,
?driverdata = 0x0,
?prev = 0x0,
?next = 0xa2000101974600
}

Here’s a backtrace:

#0 ?0x0000000100ab931c in SDL_SetError (fmt=0x100ba43e8 “id texture”) at /Users/ono/Code/Libraries/SDL/Xcode/SDL/…/…/src/SDL_error.c:66
#1 ?0x0000000100b8d7da in SDL_DestroyTexture (texture=0x101973ab0) at /Users/ono/Code/Libraries/SDL/Xcode/SDL/…/…/src/video/SDL_video.c:2703
#2 ?0x0000000100b8d88a in SDL_DestroyRenderer (window=0x10194ef00) at /Users/ono/Code/Libraries/SDL/Xcode/SDL/…/…/src/video/SDL_video.c:2734
#3 ?0x0000000100b8b177 in SDL_DestroyWindow (window=0x10194ef00) at /Users/ono/Code/Libraries/SDL/Xcode/SDL/…/…/src/video/SDL_video.c:1440
#4 ?0x0000000100b8da90 in SDL_VideoQuit () at /Users/ono/Code/Libraries/SDL/Xcode/SDL/…/…/src/video/SDL_video.c:2802
#5 ?0x0000000100aba054 in SDL_QuitSubSystem (flags=65535) at /Users/ono/Code/Libraries/SDL/Xcode/SDL/…/…/src/SDL.c:217
#6 ?0x0000000100aba092 in SDL_Quit () at /Users/ono/Code/Libraries/SDL/Xcode/SDL/…/…/src/SDL.c:244
#7 ?0x000000010000bb6c in main (argc=1, argv=0x7fff5fbff700) at source/main.c:1086

Regards,

Adam

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

–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Nathaniel_J_Fries · January 22, 2010, 12:43am

Well, the issue must be that the renderer is destroyed before the textures.
Switch the order of destruction. (order of destruction sounds cool >:-) )

Adam_Strzelecki · January 22, 2010, 12:48pm

Sam,

I nailed down the problem. With all respect SDL_Renderer’s textures double linked list is all wrong.

(1) SDL_CreateTexture don’t set created texture->next->prev at all… IMHO should be:

SDL_Texture *
SDL_CreateTexture(Uint32 format, int access, int w, int h)
{
(…)
texture->renderer = renderer;
texture->next = renderer->textures;

if (renderer->textures) {
```
   renderer->textures->prev = texture;
```
}
renderer->textures = texture;

if (renderer->CreateTexture(renderer, texture) < 0) {
SDL_DestroyTexture(texture);
return 0;
}
return texture;
}

(2) SDL_DestroyTexture don’t handle siblings->prev at all too, here’s a fix:

void
SDL_DestroyTexture(SDL_Texture * texture)
{
(…)
renderer = texture->renderer;
if (texture->prev) {

   texture->prev->next = texture->next;

   if ( (texture->prev->next = texture->next) ) {

       texture->next->prev = texture->prev;

```
   }
```
} else {

```
   renderer->textures = texture->next;
```

   if ( (renderer->textures = texture->next) ) {

       renderer->textures->prev = NULL;

```
   }
```
texture->renderer = NULL;

renderer->DestroyTexture(renderer, texture);
SDL_free(texture);
}

With that fixes everything seems to work for me fine,

Regards,–
Adam

slouken · January 22, 2010, 3:55pm

Good catch. I put a very similar fix into subversion, can you double check it?

Thanks!On Fri, Jan 22, 2010 at 4:48 AM, Adam Strzelecki wrote:

Sam,

I nailed down the problem. With all respect SDL_Renderer’s textures double linked list is all wrong.

(1) SDL_CreateTexture don’t set created texture->next->prev at all… IMHO should be:

?SDL_Texture *
?SDL_CreateTexture(Uint32 format, int access, int w, int h)
?{
? ? (…)
? ? texture->renderer = renderer;
? ? texture->next = renderer->textures;

? ?if (renderer->textures) {

? ? ? ?renderer->textures->prev = texture;

? ?}
? ? renderer->textures = texture;

? ? if (renderer->CreateTexture(renderer, texture) < 0) {
? ? ? ? SDL_DestroyTexture(texture);
? ? ? ? return 0;
? ? }
? ? return texture;
?}

(2) SDL_DestroyTexture don’t handle siblings->prev at all too, here’s a fix:

?void
?SDL_DestroyTexture(SDL_Texture * texture)
?{
? ?(…)
? ?renderer = texture->renderer;
? ?if (texture->prev) {

? ? ? ?texture->prev->next = texture->next;

? ? ? ?if ( (texture->prev->next = texture->next) ) {

? ? ? ? ? ?texture->next->prev = texture->prev;

? ? ? ?}
? ? } else {

? ? ? ?renderer->textures = texture->next;

? ? ? ?if ( (renderer->textures = texture->next) ) {

? ? ? ? ? ?renderer->textures->prev = NULL;

? ? ? ?}

? ? texture->renderer = NULL;

? ? renderer->DestroyTexture(renderer, texture);
? ? SDL_free(texture);
?}

With that fixes everything seems to work for me fine,

Regards,

Adam

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

–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Adam_Strzelecki · January 22, 2010, 4:15pm

Good catch. I put a very similar fix into subversion, can you double check it?

I in DestroyTexture it is enough to have either:

if (texture->prev) {
    if ( (texture->prev->next = texture->next) ) {
        texture->next->prev = texture->prev;
    }
} else {
    if ( (renderer->textures = texture->next) ) {
        renderer->textures->prev = NULL;
    }
}

or:

if (texture->next) {
    texture->next->prev = texture->prev;
}
if (texture->prev) {
    texture->prev->next = texture->next;
} else {
    renderer->textures = texture->next;
}

Maybe 2nd option is more clear.

Regards,–
Adam

Marty_Leisner · January 24, 2010, 1:53am

Sam Lantinga writes on Thu, 21 Jan 2010 08:20:59 PST
> The latest SDL 1.3 snapshot has converted SDL_TextureID and
> SDL_WindowID to structure pointers. This allows easier debugging and
> faster and simpler internal code. Windows are still referenced by ID
> in events, and there are new functions SDL_GetWindowID() and
> SDL_GetWindowFromID() to handle this.
>
> I included #defines of SDL_TextureID and SDL_WindowID in SDL_compat.h
> so hopefully all code won’t immediately break, but they are considered
> deprecated and will go away in a future snapshot. All the test code
> has been converted to use the new types.
>
> Please let me know ASAP if you have any problems related to this
change!
>
> See ya!
> –
> -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Great…this makes it easier to debug…

When app code uses libraries with pointers the librries produced, I find it
very useful to have a debug path to “test” the validity of the structure the
pointer refers to, instead of blindly derefencing and doing weird things (when
the application is busted)

Something like:

struct foo {
#ifdef MAGIC
struct foo *magic;
#endif
…
}

and creating the structure
MAKE_MAGIC§ p->magic = p
and
TEST_MAGIC assert(p == p->magic)

marty