GP2X Hw Accelerated Sdl

[Mudi]

Hmm... paeryn, you wouldn't have any idea why a call to SDL_FreeRW on a perfectly OK SDL_RWops would be Segfaulting, would you? I checked the sources, and it's just a call to free(), and it also segfaulted when I just did a free myself... is the free overrunning the amount of memory the RWops is using perhaps?

*grumbles and goes off to check the source for initialization of RWops.*

Oh, it works perfectly fine compiled for PC btw.

 

[theoddbot]

Mudi: The best tool for memory debugging is valgrind on Linux, she is magic, but x86 only for now.

 

[Mudi]

Yup, x86 only is a definite problem, since the code in question works 100% on PC and only segfaults on Gp2X

 

[luteijn]

Bruce Perens' efence library compiled for arm (I hope, didn't test it properly)

 

[paeryn]

Hmm... paeryn, you wouldn't have any idea why a call to SDL_FreeRW on a perfectly OK SDL_RWops would be Segfaulting, would you? I checked the sources, and it's just a call to free(), and it also segfaulted when I just did a free myself... is the free overrunning the amount of memory the RWops is using perhaps?

​

Not sure... You have called SDL_RWclose() before trying to free it haven't you?
Does SDL_FreeRW always segfault even in a simple progam?

 

[theoddbot]

Mudi: Just because it runs doesn't mean it's correct. Run it in valgrind.

 

[synkro]

Mudi: The best tool for memory debugging is valgrind on Linux, she is magic, but x86 only for now.

​

valgrind is my bitch! I use it everyday!

 

[Epicenter]

I'm experiencing some weird behavior with even a very simple test program I run with this. If I do not enable Double Buffering, my sprites all flicker like mad, everything, even things that are Software surfaces. If I do use Double Buffering, nothing draws at all. There isn't an error of any sort in the console, but absolutely jack draws on the screen.

In addition, all my surfaces that have a solid green (R:0, G:255, B:0) as their transparent color and are set to be transparent with SDL_SetColorKey -- ONLY gain proper color keying (The green becomes transparent) when they are HARDWARE surfaces! Why would this be?

Thanks for the help, and great work so far on the libraries, Paeryn-- even if everything's not working just right the performance gains are astounding!

 

[paeryn]

I'm experiencing some weird behavior with even a very simple test program I run with this. If I do not enable Double Buffering, my sprites all flicker like mad, everything, even things that are Software surfaces. If I do use Double Buffering, nothing draws at all. There isn't an error of any sort in the console, but absolutely jack draws on the screen.

Without double-buffering you're drawing onto the visible surface. If you draw a sprite say halfway down the screen, the display might have already gotten to a point part-way down your sprite by the time you start drawing. What you'll see for that frame is the top part of your sprite missing.
With double-buffering you're drawing to a different surface to the one being displayed. It's not until you call SDL_Flip() that the hardware shows the surface on the screen.
Are you calling SDL_Flip() when using double-buffering? You need to, in place of SDL_UpdateRects(), when you've finished drawing a frame.

In addition, all my surfaces that have a solid green (R:0, G:255, B:0) as their transparent color and are set to be transparent with SDL_SetColorKey -- ONLY gain proper color keying (The green becomes transparent) when they are HARDWARE surfaces! Why would this be?

Hmm, not sure about that. I'll add that to the top of my list of things in need of checking... It'll probably be Tuesday before I get a chance to look into it though.

 

[Epicenter]

Don't sweat it, I didn't actually have the lib installed correctly! Thanks anyway man, and great job.

 

[deadlychicken22]

Don't sweat it, I didn't actually have the lib installed correctly! Thanks anyway man, and great job.

​

I am having a similar problem, maybe your solution could help me..... I downloaded the latest pre-compiled libs on this thread and i copied them into their corresponding folder in my devkitGP2X folder, and then I tried to compile my game with them.

When I compile it with SDL_SWSURFACE, it works, but the music is messed up (fw 1.4), it has some speed issues, and there are slight graphical problems.

When I compile it with SDL_HWSURFACE but no |SDL_DOUBLEBUF it works, but the music is messed up (fw 1.4, again) and it flickers like crazy (yes, i know why this is).

When I compile it with SDL_HWSURFACE and |SDL_DOUBLEBUF and I try to run it on my gp2x, all I get is a black screen and then i'm kicked back to the gp2xmenu. I think that it is crashing and that theoddbots firmware is catching that and returning me to the menu.

I want to be able to compile my game with SDL_HWSURFACE and |SDL_DOUBLEBUF (as I was before) and also get the music working normally on fw 1.4.... do you have any idea what I'm doing wrong?

thanks,
-ben

 

[Epicenter]

Supposedly there are just sound issues with this SDL implementation and FW 1.4. I'd just go back to 1.2.1. As for the crashing, I'd run it with USB serial and see if that's true and if you can diagnose WHY it is crashing with printf's in the program.

 

[Voyageur]

Well, as for sound issues, I have "fixed" my toolchain by swapping my libmikmod.a with one from Guyfawkes' precompiled libs. Changing just this file and wav,ogg,mp3 and friends play fine again (just don't ask me why, I did not touch my other libs). Hope this helps

Note: the link is the one I used when I solved the problem, there may be a newer version but this one works for sure!)

 

[deadlychicken22]

Supposedly there are just sound issues with this SDL implementation and FW 1.4. I'd just go back to 1.2.1. As for the crashing, I'd run it with USB serial and see if that's true and if you can diagnose WHY it is crashing with printf's in the program.

​

I had it compiling fine with SDL_HWSURFACE|SDL_DOUBLEBUF before, but the sound was messed up on FW 1.4 and I want to correct that because more and more people will be upgrading in the future. So I downloaded the newest version and tried it and now I can't even get it to work with SDL_DOUBLEBUF, and the sound is still messed up.... I tried to get that usb serial program working, and I get a bash prompt, but for some reason I don't see any of the output from printf's.....

EDIT: when i get some time I plan on starting over from scratch and compiling everything myself, but I'm really busy right now and don't have time...

 

[Flavor]

I tried to get that usb serial program working, and I get a bash prompt, but for some reason I don't see any of the output from printf's.....

​

How do you run your program? Do you type the name of your executable at the bash prompt, or are you running it from the menu? You need to use the prompt to run your program. Sorry if that's not the problem, but I think that one version of the USB gadget that I have seen goes back to the menu (which I don't quite understand).

 

[deadlychicken22]

How do you run your program? Do you type the name of your executable at the bash prompt, or are you running it from the menu? You need to use the prompt to run your program. Sorry if that's not the problem, but I think that one version of the USB gadget that I have seen goes back to the menu (which I don't quite understand).

​

yes, that's probably it, I selected it from the menu. I tried to locate it from the bash prompt but I couldn't figure out how to locate the files.... I don't use command prompts often.... After typing in help, i tried to use a command that would display the files in the current directory (or at least that's what i thought it would do) and all it displayed was a "\".... i'm sure i'm doing something wrong, please tell me what it is.

 

[Flavor]

I tried to locate it from the bash prompt but I couldn't figure out how to locate the files.... I don't use command prompts often.... After typing in help, i tried to use a command that would display the files in the current directory (or at least that's what i thought it would do) and all it displayed was a "\".... i'm sure i'm doing something wrong, please tell me what it is.

​

Try

cd /mnt/sd
ls

That should show you all the files/dirs in the root of your SD. Then, you can "cd" to a subdirectory or whatever. Like, if I wanted to run mygame, I'd do...

cd /mnt/sd/Games/mygame
./mygame.gpe

Also, you probablly don't want the USB gadget to load the menu after setting up the serial link. I have mine set up to just start the serial link and that's all. If you let it go back to the menu, then you can get wierd things like the menu and mygame running at the same time (both trying to update the screen).

If you want my USB serial gadget scripts, PM me your e-mail address.

Also, it's worth knowing that the printf's are nice, but if you can also do source-level debugging with GDB. Personally, I'm just learning to use it, but it will let you step through the source code. Though, I'd recommend just doing the printf stuff at first, and then you can try learning gdb if you need something more.

 

[Wild[Kyo]]

Hi,

First of all sorry for my poor english...

I have a question about de Hw Accelerated SDL...

¿Is it possible that don't resize the screen?

For exemple if I put:

  screen = SDL_SetVideoMode(200, 200,16,SDL_HWSURFACE|SDL_HWPALETTE|SDL_DOUBLEBUF|SDL_FULLSCREEN);

That the SDL don't resize the screen to 320x240 automaticly

I don't know if I explain correctly...

A gretting!

 

[paeryn]

¿Is it possible that don't resize the screen?

For exemple if I put:

  screen = SDL_SetVideoMode(200, 200,16,SDL_HWSURFACE|SDL_HWPALETTE|SDL_DOUBLEBUF|SDL_FULLSCREEN);

That the SDL don't resize the screen to 320x240 automaticly

​

Not initially. My intention was to emulate what a monitor does and fit the requested screen to the full display area.
I'm not sure if your example is the screen size you want (200x200). I don't think it'll cope with displaying a smaller screen than 320x240. If you're requesting a screen that's larger (e.g. 640x480) and want the display to show a part of it, then there's an extra function SDL_GP2X_Display() defined in SDL_gp2x.h that you can call to tell the display which part of the larger bitmap to show.
If you really want the former (a screen size smaller than the display) then at the moment you'll have to make do with creating a screen with 320x240 and only drawing within the area you really want.
I'll look into supporting smaller screen sizes, let me know if this is what you want and I'll move it higher up on my to-do list.

 

[Wild[Kyo]]

,Mar 29 2006, 12:55 AM]¿Is it possible that don't resize the screen?

For exemple if I put:

  screen = SDL_SetVideoMode(200, 200,16,SDL_HWSURFACE|SDL_HWPALETTE|SDL_DOUBLEBUF|SDL_FULLSCREEN);

That the SDL don't resize the screen to 320x240 automaticly

​

Not initially. My intention was to emulate what a monitor does and fit the requested screen to the full display area.
I'm not sure if your example is the screen size you want (200x200). I don't think it'll cope with displaying a smaller screen than 320x240. If you're requesting a screen that's larger (e.g. 640x480) and want the display to show a part of it, then there's an extra function SDL_GP2X_Display() defined in SDL_gp2x.h that you can call to tell the display which part of the larger bitmap to show.
If you really want the former (a screen size smaller than the display) then at the moment you'll have to make do with creating a screen with 320x240 and only drawing within the area you really want.
I'll look into supporting smaller screen sizes, let me know if this is what you want and I'll move it higher up on my to-do list.

​

Again, sorry for my poor english and the explanation of before...

That I wish to say is the last thing you say. Support smaller screen sizes. That is, if I put a screen of 200x200 that the HW Accelerated SDL will don't resize automatically to 320 x 240.

Thanks for all paeryn!!