Crash on SDL_SetVideoMode when called more than once (1.3)

SDL Development
1

I’ve found out that the following code crashes for me with the latest HG revision of SDL1.3 in linux, mac and iOS:

Code:
#include <stdio.h>
#include <unistd.h>
#include <SDL/SDL.h>

int main(int argc, char *argv[]) {
if (SDL_Init(SDL_INIT_EVERYTHING) != 0) {
fprintf(stderr, “\nUnable to initialize SDL: %s\n”, SDL_GetError());
return 1;
}
// Just set the video mode twice using the compat functions
SDL_SetVideoMode(320, 240, 16, 0);
sleep(2);
SDL_SetVideoMode(640, 480, 16, 0);
sleep(2);
SDL_Quit();
return 0;
}

The crash happens when SDL tries to make the second SDL_SetVideoMode, and can be avoided if lines 471 to 473 (call to SDL_ResizeVideoMode()) are commented out in src/SDL_compat.c.

Running the program with gdb gives the following info on linux:

Code:
josebage at joseba-AAO:~/cvs/bennugd/monolithic/3rdparty/SDL-1.3/linux$ LANG=C gdb main
GNU gdb (GDB) 7.2-ubuntu
Copyright © 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and “show warranty” for details.
This GDB was configured as “i686-linux-gnu”.
Para las instrucciones de informe de errores, vea:
http://www.gnu.org/software/gdb/bugs/…
Leyendo s?mbolos desde /home/josebage/cvs/bennugd/monolithic/3rdparty/SDL-1.3/linux/main…hecho.
(gdb) run
Starting program: /home/josebage/cvs/bennugd/monolithic/3rdparty/SDL-1.3/linux/main
[Depuraci?n de hilo usando libthread_db enabled]
[Nuevo Thread 0xb7fdeb70 (LWP 10994)]

Program received signal SIGSEGV, Segmentation fault.
0x080a14fc in BlitNtoN (info=0x8111440) at src/video/SDL_blit_N.c:2098
2098 DUFFS_LOOP(
(gdb)

If you need more info, please let me know and I’ll provide it.

2

I just tried this and it worked fine. Can you grab the latest snapshot (as
of a couple of hours ago) and see if it still happens?

Thanks!On Fri, Feb 11, 2011 at 3:18 PM, josebagar <joseba.gar at gmail.com> wrote:

I’ve found out that the following code crashes for me with the latest HG
revision of SDL1.3 in linux, mac and iOS:

Code:

#include
#include
#include

int main(int argc, char *argv[]) {
if (SDL_Init(SDL_INIT_EVERYTHING) != 0) {
fprintf(stderr, “\nUnable to initialize SDL: %s\n”,
SDL_GetError());
return 1;
}
// Just set the video mode twice using the compat functions
SDL_SetVideoMode(320, 240, 16, 0);
sleep(2);
SDL_SetVideoMode(640, 480, 16, 0);
sleep(2);
SDL_Quit();
return 0;
}

The crash happens when SDL tries to make the second SDL_SetVideoMode, and
can be avoided if lines 471 to 473 (call to SDL_ResizeVideoMode()) are
commented out in src/SDL_compat.c.

Running the program with gdb gives the following info on linux:

Code:

josebage at joseba-AAO:~/cvs/bennugd/monolithic/3rdparty/SDL-1.3/linux$
LANG=C gdb main
GNU gdb (GDB) 7.2-ubuntu
Copyright © 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and “show warranty” for details.
This GDB was configured as “i686-linux-gnu”.
Para las instrucciones de informe de errores, vea:
…
Leyendo s?mbolos desde
/home/josebage/cvs/bennugd/monolithic/3rdparty/SDL-1.3/linux/main…hecho.
(gdb) run
Starting program:
/home/josebage/cvs/bennugd/monolithic/3rdparty/SDL-1.3/linux/main
[Depuraci?n de hilo usando libthread_db enabled]
[Nuevo Thread 0xb7fdeb70 (LWP 10994)]

Program received signal SIGSEGV, Segmentation fault.
0x080a14fc in BlitNtoN (info=0x8111440) at src/video/SDL_blit_N.c:2098
2098 DUFFS_LOOP(
(gdb)

If you need more info, please let me know and I’ll provide it.

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

–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

3

I just tried this and it worked fine. Can you grab the latest snapshot (as of a couple of hours ago) and see if it still happens?

I had the same problem on OSX. It segfaults … sometimes. I displays the right graphics … sometimes.
It never gets the textures right (but they work if you revert to the original size).On 12/02/2011, at 5:24 PM, Sam Lantinga wrote:

–
john skaller
@john_skaller

4

I just tried this and it worked fine. Can you grab the latest snapshot (as of a couple of hours ago) and see if it still happens?

I had the same problem on OSX. It segfaults … sometimes. I displays the right graphics … sometimes.
It never gets the textures right (but they work if you revert to the original size).

I recently switched to SDL 1.3 and I have this problem too.

I’m working on TuxCap and I’m developing on MacOS. Lately I decided
to try and port some TuxCap game to iOS, and that’s why I switched to SDL 1.3
I’ve checked out the latest HG (as of three days ago).

For some reason (which I have to solve some day) my program starts in
windowed mode and then switches to full screen. And it crashes somewhere
in SDL_SetVideoMode. I still don’t have a good way to debug this because
when SDL switches to full screen I can’t debug anymore. I have to kill
gdb remotely.

With a small test program I can’t get it to crash.

So does anyone have some tips how to debug full screen SDL from a remote
machine?

BTW. I’ve used valgrind, and I have to repeat this once more. Perhaps that
might give a hint.

– KeesOn 12 Feb, 2011, at 08:44 , john skaller wrote:

On 12/02/2011, at 5:24 PM, Sam Lantinga wrote:

5

I just tried this and it worked fine. Can you grab the latest snapshot (as of a couple of hours ago) and see if it still happens?

I had the same problem on OSX. It segfaults … sometimes. I displays the right graphics … sometimes.
It never gets the textures right (but they work if you revert to the original size).

I recently switched to SDL 1.3 and I have this problem too.

Are you static linking?

I have both static and dynamic linking happening now, but the dynamic linking
is screwing something up very badly.

I do not believe this is SDL as such, It’s probably something to do with Obj-C
bindings to Cocoa or whatever Applish stuff is doing the window management.

BTW: according to someone on StackOverflow the loss of textures when switching
to full screen is a known bug: they have to be reloaded manually. It seems this
doesn’t work on a resize either.On 14/02/2011, at 2:10 AM, Kees Bakker wrote:

On 12 Feb, 2011, at 08:44 , john skaller wrote:

On 12/02/2011, at 5:24 PM, Sam Lantinga wrote:

–
john skaller
@john_skaller

6

I just tried this and it worked fine. Can you grab the latest snapshot (as of a couple of hours ago) and see if it still happens?

I had the same problem on OSX. It segfaults … sometimes. I displays the right graphics … sometimes.
It never gets the textures right (but they work if you revert to the original size).

I recently switched to SDL 1.3 and I have this problem too.

Are you static linking?

No, but I doubt that this would matter.

I have both static and dynamic linking happening now, but the dynamic linking
is screwing something up very badly.

I do not believe this is SDL as such, It’s probably something to do with Obj-C
bindings to Cocoa or whatever Applish stuff is doing the window management.

BTW: according to someone on StackOverflow the loss of textures when switching
to full screen is a known bug: they have to be reloaded manually. It seems this
doesn’t work on a resize either.

Hard to say.

Here are some valgrind errors that analysing right now:
Maybe I shouldn’t be doing a SDL_FreeSurface myself. At least not for the one returned
by SDL_SetVideoMode.

==6964== 1 errors in context 7 of 35:
==6964== Invalid free() / delete / delete[]
==6964== at 0x264BC8: free (vg_replace_malloc.c:366)
==6964== by 0x30D86E: SDL_FreeSurface (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/SDL.framework/Versions/1.3/SDL)
==6964== by 0x5375E2: Sexy::DDImage::~DDImage() (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/tuxcap.framework/Versions/4.0/tuxcap)
==6964== by 0x538217: Sexy::DDInterface::Cleanup() (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/tuxcap.framework/Versions/4.0/tuxcap)
==6964== by 0x5384CA: Sexy::DDInterface::Init(void*, bool) (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/tuxcap.framework/Versions/4.0/tuxcap)
==6964== by 0x3F1A11: Sexy::SexyAppBase::InitDDInterface() (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/tuxcap.framework/Versions/4.0/tuxcap)
==6964== by 0x3F28ED: Sexy::SexyAppBase::MakeWindow() (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/tuxcap.framework/Versions/4.0/tuxcap)
==6964== by 0x3F1C26: Sexy::SexyAppBase::SwitchScreenMode(bool, bool, bool) (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/tuxcap.framework/Versions/4.0/tuxcap)
==6964== by 0x3245C: GameApp::SwitchScreenMode(bool, bool, bool) (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== by 0x98DC0: WP_Options::switch_screen_mode() (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== by 0x9902A: WP_Options::set_user(std::string const&) (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== by 0x9BAA8: WP_Options::get_language() (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== Address 0x149f7e70 is 0 bytes inside a block of size 64 free’d
==6964== at 0x264BC8: free (vg_replace_malloc.c:366)
==6964== by 0x30D86E: SDL_FreeSurface (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/SDL.framework/Versions/1.3/SDL)
==6964== by 0x3F1DEB: Sexy::SexyAppBase::MakeWindow() (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/tuxcap.framework/Versions/4.0/tuxcap)
==6964== by 0x3F1C26: Sexy::SexyAppBase::SwitchScreenMode(bool, bool, bool) (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/tuxcap.framework/Versions/4.0/tuxcap)
==6964== by 0x3245C: GameApp::SwitchScreenMode(bool, bool, bool) (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== by 0x98DC0: WP_Options::switch_screen_mode() (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== by 0x9902A: WP_Options::set_user(std::string const&) (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== by 0x9BAA8: WP_Options::get_language() (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== by 0x32098: GameApp::Init() (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== by 0x6931: main (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964==
==6964== 1 errors in context 8 of 35:
==6964== Invalid read of size 4
==6964== at 0x30D843: SDL_FreeSurface (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/SDL.framework/Versions/1.3/SDL)
==6964== by 0x5375E2: Sexy::DDImage::~DDImage() (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/tuxcap.framework/Versions/4.0/tuxcap)
==6964== by 0x538217: Sexy::DDInterface::Cleanup() (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/tuxcap.framework/Versions/4.0/tuxcap)
==6964== by 0x5384CA: Sexy::DDInterface::Init(void*, bool) (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/tuxcap.framework/Versions/4.0/tuxcap)
==6964== by 0x3F1A11: Sexy::SexyAppBase::InitDDInterface() (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/tuxcap.framework/Versions/4.0/tuxcap)
==6964== by 0x3F28ED: Sexy::SexyAppBase::MakeWindow() (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/tuxcap.framework/Versions/4.0/tuxcap)
==6964== by 0x3F1C26: Sexy::SexyAppBase::SwitchScreenMode(bool, bool, bool) (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/tuxcap.framework/Versions/4.0/tuxcap)
==6964== by 0x3245C: GameApp::SwitchScreenMode(bool, bool, bool) (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== by 0x98DC0: WP_Options::switch_screen_mode() (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== by 0x9902A: WP_Options::set_user(std::string const&) (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== by 0x9BAA8: WP_Options::get_language() (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== by 0x32098: GameApp::Init() (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== Address 0x149f7e84 is 20 bytes inside a block of size 64 free’d
==6964== at 0x264BC8: free (vg_replace_malloc.c:366)
==6964== by 0x30D86E: SDL_FreeSurface (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/SDL.framework/Versions/1.3/SDL)
==6964== by 0x3F1DEB: Sexy::SexyAppBase::MakeWindow() (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/tuxcap.framework/Versions/4.0/tuxcap)
==6964== by 0x3F1C26: Sexy::SexyAppBase::SwitchScreenMode(bool, bool, bool) (in /Users/kees/src/lokokiboko/build-debug/src/LokoKiboko.app/Contents/Frameworks/tuxcap.framework/Versions/4.0/tuxcap)
==6964== by 0x3245C: GameApp::SwitchScreenMode(bool, bool, bool) (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== by 0x98DC0: WP_Options::switch_screen_mode() (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== by 0x9902A: WP_Options::set_user(std::string const&) (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== by 0x9BAA8: WP_Options::get_language() (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== by 0x32098: GameApp::Init() (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)
==6964== by 0x6931: main (in ./build-debug/src/LokoKiboko.app/Contents/MacOS/LokoKiboko)

– KeesOn 13 Feb, 2011, at 16:24 , john skaller wrote:

On 14/02/2011, at 2:10 AM, Kees Bakker wrote:

On 12 Feb, 2011, at 08:44 , john skaller wrote:

On 12/02/2011, at 5:24 PM, Sam Lantinga wrote:

7

I just tried this and it worked fine. Can you grab the latest snapshot (as of a couple of hours ago) and see if it still happens?

I had the same problem on OSX. It segfaults … sometimes. I displays the right graphics … sometimes.
It never gets the textures right (but they work if you revert to the original size).

I recently switched to SDL 1.3 and I have this problem too.

Are you static linking?

No, but I doubt that this would matter.

I have both static and dynamic linking happening now, but the dynamic linking
is screwing something up very badly.

I do not believe this is SDL as such, It’s probably something to do with Obj-C
bindings to Cocoa or whatever Applish stuff is doing the window management.

BTW: according to someone on StackOverflow the loss of textures when switching
to full screen is a known bug: they have to be reloaded manually. It seems this
doesn’t work on a resize either.

Hard to say.

Here are some valgrind errors that analysing right now:
Maybe I shouldn’t be doing a SDL_FreeSurface myself. At least not for the one returned
by SDL_SetVideoMode.

That’s probably it.

Here is a little test program to make it crash consistently. So we either have to make
SDL_FreeSurface be aware of SDL_compat.c or we have to set some rules to not free the surface
that you get from SDL_SetVideoMode.

-------------- next part --------------
A non-text attachment was scrubbed…
Name: main.c
Type: application/octet-stream
Size: 2143 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110213/b82c8f11/attachment.objOn 13 Feb, 2011, at 17:29 , Kees Bakker wrote:

On 13 Feb, 2011, at 16:24 , john skaller wrote:

On 14/02/2011, at 2:10 AM, Kees Bakker wrote:

On 12 Feb, 2011, at 08:44 , john skaller wrote:

On 12/02/2011, at 5:24 PM, Sam Lantinga wrote:

8

SDL_FreeSurface used to have condition that prevented it from freeing
the display surface if I remember right… It wouldn’t have worked
with multiple display surfaces though.On 13 February 2011 11:38, Kees Bakker <kees.bakker at xs4all.nl> wrote:

Here is a little test program to make it crash consistently. So we either have to make
SDL_FreeSurface be aware of SDL_compat.c or we have to set some rules to not free the surface
that you get from SDL_SetVideoMode.

9

Has anybody tried the small sample code I posted?

10

Has anybody tried the small sample code I posted?

No, but Sam did, and he didn’t see the crash.

I can’t say if your problem with SDL_SetVideoMode is the
same as mine, but I just tried a workaround which seems
to help: skip SDL_FreeSurface.

If you look into video/SDL_surface.c then you’ll notice
that SDL_FreeSurface can delete a surface, but the code
in SDL_compat.c never notices. If you do a new
SDL_SetVideoMode then it will possibly free some surfaces
that we’re already freed.

To repeat myself: We either have to make SDL_FreeSurface
be aware of SDL_compat.c or we have to set some rules to not
free the surface that you get from SDL_SetVideoMode.

– KeesOn 13 Feb, 2011, at 18:19 , josebagar wrote:

11

Ok, thanks for the info.
I’ll try to switch the code that calls to SDL_SetVideoMode to SDL1.3 ASAP.

Just in case it helps, I’m statically linking. If I can get some more detail, I’ll let you know.

Thanks for the info.

12

Are you static linking?

No, but I doubt that this would matter.

It might. It does for me. I have a function which outputs to a C++ ostringstream then grabs
a string out of that, which is then part of an output to cout… it works fine statically linked,
it doesn’t output when dynamically linked (but literal strings in the same output
statement work).

The same technology works fine in EVERY other dylib I generate there are 100
or so regression tests that all work fine, the SDL demos don’t work properly
but I’ve never seen a simple integer to string conversion function fail in dynamic
linkage but work in static linkage … but only when linking to SDL …

SDL may not be causing this problem directly, but its doing something nasty!
It happens this is the only code I have with Objective-C component.

Here are some valgrind errors that analysing right now:
Maybe I shouldn’t be doing a SDL_FreeSurface myself. At least not for the one returned
by SDL_SetVideoMode.

It’s possible, since the surface is probably allocated by Objective-C, and there’s some kind
of NSFreePool thing you’re supposed to use to release Obj-C heap values … but this
would have to be done right inside SDL. EVen statically linked, Obj-C itself tells me
in one of the demos that there’s no pool and it is going to leak the memory.

So clearly the SDL bindings to the OSX windowing/graphics system aren’t right yet.On 14/02/2011, at 3:29 AM, Kees Bakker wrote:

–
john skaller
@john_skaller

13

I’m making this change now, thanks!On Sun, Feb 13, 2011 at 9:30 AM, Kees Bakker <kees.bakker at xs4all.nl> wrote:

On 13 Feb, 2011, at 18:19 , josebagar wrote:

Has anybody tried the small sample code I posted?

No, but Sam did, and he didn’t see the crash.

I can’t say if your problem with SDL_SetVideoMode is the
same as mine, but I just tried a workaround which seems
to help: skip SDL_FreeSurface.

If you look into video/SDL_surface.c then you’ll notice
that SDL_FreeSurface can delete a surface, but the code
in SDL_compat.c never notices. If you do a new
SDL_SetVideoMode then it will possibly free some surfaces
that we’re already freed.

To repeat myself: We either have to make SDL_FreeSurface
be aware of SDL_compat.c or we have to set some rules to not
free the surface that you get from SDL_SetVideoMode.

– Kees

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

–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

14

I fixed a leak in the mode change code recently, so if you’re not using the
latest SDL 1.3 snapshot you should upgrade.

You can also set a breakpoint in the function listed in the error message to
catch the stack trace of where it’s happening. If you do, can you please
let me know where it is?

Thanks!On Sun, Feb 13, 2011 at 10:27 AM, john skaller < skaller at users.sourceforge.net> wrote:

On 14/02/2011, at 3:29 AM, Kees Bakker wrote:

Are you static linking?

No, but I doubt that this would matter.

It might. It does for me. I have a function which outputs to a C++
ostringstream then grabs
a string out of that, which is then part of an output to cout… it works
fine statically linked,
it doesn’t output when dynamically linked (but literal strings in the same
output
statement work).

The same technology works fine in EVERY other dylib I generate there are
100
or so regression tests that all work fine, the SDL demos don’t work
properly
but I’ve never seen a simple integer to string conversion function fail in
dynamic
linkage but work in static linkage … but only when linking to SDL …

SDL may not be causing this problem directly, but its doing something
nasty!
It happens this is the only code I have with Objective-C component.

Here are some valgrind errors that analysing right now:
Maybe I shouldn’t be doing a SDL_FreeSurface myself. At least not for the
one returned
by SDL_SetVideoMode.

It’s possible, since the surface is probably allocated by Objective-C, and
there’s some kind
of NSFreePool thing you’re supposed to use to release Obj-C heap values …
but this
would have to be done right inside SDL. EVen statically linked, Obj-C
itself tells me
in one of the demos that there’s no pool and it is going to leak the
memory.

So clearly the SDL bindings to the OSX windowing/graphics system aren’t
right yet.

–
john skaller
skaller at users.sourceforge.net

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

–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

15

I fixed a leak in the mode change code recently, so if you’re not using the latest SDL 1.3 snapshot you should upgrade.

I am using mercurial for the bleeding edge now.

Static linkage on my demo # 3 is now working with resize, and also full screen.
[this is a Felix recode of one of the NeHe demos, with nice coloured rotating
cube and pyramid]

Output looks like this:

~/felix> demos/sdl/sdl-1.01.03-0
98 frames in 5.001 seconds = 19.5961 FPS
23 frames in 5.001 seconds = 4.59908 FPS
Resize w=784, h=608
Set video mode
Resized now
73 frames in 5.03 seconds = 14.5129 FPS
Resize w=934, h=772
Set video mode
Resized now
75 frames in 5.015 seconds = 14.9551 FPS
99 frames in 5.002 seconds = 19.7921 FPS
Resize w=1080, h=776
Set video mode
Resized now
Resize w=893, h=771
Set video mode
Resized now
55 frames in 5.024 seconds = 10.9475 FPS
44 frames in 5.05 seconds = 8.71287 FPS
55 frames in 6.608 seconds = 8.32324 FPS
Resize w=1280, h=800
Set video mode
Resized now
71 frames in 5.031 seconds = 14.1125 FPS
87 frames in 5.027 seconds = 17.3065 FPS

The same code running in a dylib (exactly the same C++ except for minor change to the call
to the top level to use dlopen() instead of a static link) also now works but here’s the output:

frames in seconds = FPS
frames in seconds = FPS
frames in seconds = FPS
frames in seconds = FPS
frames in seconds = FPS
Resize w=, h=
Set video mode
Resized now
Resize w=, h=
Set video mode
Resized now
frames in seconds = FPS
frames in seconds = FPS
Resize w=, h=
Set video mode
Resized now
frames in seconds = FPSOn 14/02/2011, at 5:30 AM, Sam Lantinga wrote:

–
john skaller
@john_skaller

16

I fixed a leak in the mode change code recently, so if you’re not using the latest SDL 1.3 snapshot you should upgrade.

I am using mercurial for the bleeding edge now.

Static linkage on my demo # 3 is now working with resize, and also full screen.
[this is a Felix recode of one of the NeHe demos, with nice coloured rotating
cube and pyramid]

Demo # 4 works, resizing happens BUT the textures are lost on resize.
This is a rotating cube with NeHe written on it, using a texture.

Same problem with dynamic linkage: textures lost, and in addition,
frames in seconds = FPS
frames in seconds = FPS

numeric data lost (works with static linkage and the same routine works
in 100 other dylibs).On 14/02/2011, at 6:14 AM, john skaller wrote:

On 14/02/2011, at 5:30 AM, Sam Lantinga wrote:

–
john skaller
@john_skaller

17

Well, demo #5 works and textures on this one are NOT lost on
resize… its the same rotating cube, as #4 but this time the rotation
is controlled by the Keyboard.

Interesting. Wonder why the textures aren’t lost with this version…On 14/02/2011, at 6:44 AM, john skaller wrote:

–
john skaller
@john_skaller

18

Okay, now trying to free the video surface won’t do anything, as was the
case in 1.2.On Sun, Feb 13, 2011 at 10:28 AM, Sam Lantinga <@slouken> wrote:

I’m making this change now, thanks!

On Sun, Feb 13, 2011 at 9:30 AM, Kees Bakker <kees.bakker at xs4all.nl>wrote:

On 13 Feb, 2011, at 18:19 , josebagar wrote:

Has anybody tried the small sample code I posted?

No, but Sam did, and he didn’t see the crash.

I can’t say if your problem with SDL_SetVideoMode is the
same as mine, but I just tried a workaround which seems
to help: skip SDL_FreeSurface.

If you look into video/SDL_surface.c then you’ll notice
that SDL_FreeSurface can delete a surface, but the code
in SDL_compat.c never notices. If you do a new
SDL_SetVideoMode then it will possibly free some surfaces
that we’re already freed.

To repeat myself: We either have to make SDL_FreeSurface
be aware of SDL_compat.c or we have to set some rules to not
free the surface that you get from SDL_SetVideoMode.

– Kees

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

–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

19

The code I posted now works great for me, without crashing and resizing the window just fine. Thanks a lot.

20

Great, you’re welcome! :)On Sun, Feb 13, 2011 at 2:56 PM, josebagar <joseba.gar at gmail.com> wrote:

The code I posted now works great for me, without crashing and resizing
the window just fine. Thanks a lot.

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

–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks