GP2X Hw Accelerated Sdl

[Drag]

How do I acquire a lib####.a style library from this? Is there already one precompiled in the posted archive? I have no idea how to compile the source code on my own.

 

[Mudi]

You could use ooPo's toolchain, it has a script that compiles everything for you.

 

[paeryn]

I'm now working on CaPriCe for Gp2x and have some "trouble" trying to speed up the emulator... It uses 2 surfaces instead of doublebuffer, but the CPC's are clocked to 50hz so 50 frames is the max. I have recoded to use double buffer and the emu gets 30FPS because the VBL at 60hz...

60Hz is what the LCD wants (or should be thereabouts - it's seems to sit around 58 on mine) I'll check in a bit if the LCD can cope with 50Hz, I know it doesn't like it if you try freezing the display...
If you put the GP2X in TVout mode first, NTSC will always give you 60, and PAL will always give you 50.
Edit: Yes - I've got it running down at 30Hz - quite flickery, 50Hz flickers too. Just incase anyone cares - I've just had it up as far as 310Hz! Seriously washed out colour. 110Hz seems to be about as far as it can go and still give a decent picture.

Declaring both surfaces as HWSURFACE may work at similar speed to one double buffer but without the 60FPS lock? Then, maybe I don't need to recode the doublebuffer...

A double-buffered screen is slightly different than having 2 surfaces. If you're using two surfaces to emulate it and are blitting them to a single-buffered screen then yes you will avoid the forced vsync but you will get some tearing, although with luck it won't be too noticable / more preferable than forcing 30 / 60 fps.
Physically it's slower because double-buffering doesn't require a full-screen blit each frame, but then again if you can process one frame & do the blit in less time than it takes the vsync you'll end up being faster.
Don't forget that directly writing to a HWSURFACE (not counting SDL's BlitSurface & FillRect) is slower than to a SWSURFACE. I'll do some tests to get rough speeds of various surface types at some point.

If I want to remove the 60FPS lock, is just remove the "do {} while VBL "'s from the source?
If just the use of two surfaces declared in hardware is enought...
Anyway, thank you very much for the hardware SDL!!!

​

If you're not double-buffering then (at the moment) you don't need to use SDL_Flip(). Removing the vsync more or less negates any benefit of double-buffering, but yes, removing the vsync's will remove the fps lock.

Drag:
configure & make. The configure options that I use are in the README.GP2X, you should (may) just need to alter the directory for where it puts them. There are pre-compiled libs too - see the first post for download location.

 

[Epicenter]

Dumb question, but proving difficult to find. How does one allocate a hardware surface rather than a software one? And is there really any decent way to tell when the 5MB of VRAM allocated is full besides looking for crashes?

 

[paeryn]

Dumb question, but proving difficult to find. How does one allocate a hardware surface rather than a software one? And is there really any decent way to tell when the 5MB of VRAM allocated is full besides looking for crashes?

​

In the flags for SDL_CreateRGBSurface(), e.g.

surface = SDL_CreateRGBSurface(SDL_HWSURFACE, 32, 32, 16, 0, 0, 0, 0);

Aslo, if you've got a surface from IMG_Load() or such then :-

hw_surface = SDL_DisplayFormat(sw_surface);

will create one and copy the contents over (don't forget to free the SW one if you don't need it after).
If a surface won't fit in HW then whatever function (either CreateRGBSurface or DisplayFormat usually) will fail and return NULL. You can see how much memory is left by... erm... ahh... oh, it's private - I'll add it to the list of functions I'm adding. Even when I add it, it won't be definitave as video memory might be too fragmented to hold big surfaces.

 

[Drag]

D'oh! I didn't know those were the newest libs. My mistake.

Anyway, thanks for precompiling the libs, and keep up the good work on them!

 

[BradN]

Just an idea on the FPS range - if you have a program that wants 50hz, it might be possible to run it at 100 and then use some system timer trickery (or whatever) to figure out which 'half' of the frame a current vblank is for.

 

[paeryn]

Just an idea on the FPS range - if you have a program that wants 50hz, it might be possible to run it at 100 and then use some system timer trickery (or whatever) to figure out which 'half' of the frame a current vblank is for.

​

Hmm.. Could be tricky. Something to look into sometime I suppose...

Unrelated, Spent ages trying to figure out why my SW->HW blitting code's not working - only to find SDL's not even calling my routines. Strange since if it isn't calling mine it should be calling its own

Edit:
<Picks up dunce hat and sits in corner>
I should've read how SDL handles palettized surfaces...

 

[Mudi]

Hmm.. Could be tricky. Something to look into sometime I suppose...

Unrelated, Spent ages trying to figure out why my SW->HW blitting code's not working - only to find SDL's not even calling my routines. Strange since if it isn't calling mine it should be calling its own

​

Eww, hate it when that happens.

"Hey, why isn't it logging that it's going through here!"
"Hey, why isn't it stopping! I have a breakpoint set!"

A while later...
"Ooooooooh. Grrrr."

 

[pepone]

You are aware that the upper memory is slow to access aren't you? If you're using it to hold often-used data then you'll be taking quite a performance hit. I think squidge clocked it at 65% the speed of normal malloc'ed memory.

​

Yes, I did know. But some neogeo roms are so big that i have to use it for sound data. I'm sure that if the upper mem is correctly configured with cache enabled, performance will be improved.

 

[synkro]

someone (I'd like to say me, but atm impossible) should write down everything related to this SDL version and put it in the wiki.... please.

 

[slygamer]

60Hz is what the LCD wants (or should be thereabouts - it's seems to sit around 58 on mine) I'll check in a bit if the LCD can cope with 50Hz, I know it doesn't like it if you try freezing the display...

​

I was always wondering why I've always got a rock-solid 58fps in my apps that are locked to the vsync. I thought I'd done something dodgy in my fps code.

 

[mongolito404]

someone (I'd like to say me, but atm impossible) should write down everything related to this SDL version and put it in the wiki.... please.

​

You mean adding content to the Paeryn's_SDL page

 

[paeryn]

someone (I'd like to say me, but atm impossible) should write down everything related to this SDL version and put it in the wiki.... please.

​

You mean adding content to the Paeryn's_SDL page

​

Wow! Cheers... And I'll swap the X / Y buttons in the next release - forgot all about that (not my code)

 

[Flavor]

Wow! Cheers... And I'll swap the X / Y buttons in the next release - forgot all about that (not my code)

​

Please be sure to mention when you release a version with these swapped. I am sure that several developers (myself included) have already worked around this problem and will have to undo the workaround when the new lib is released.

Thanks!

 

[KaosOverride]

Don't forget that directly writing to a HWSURFACE (not counting SDL's BlitSurface & FillRect) is slower than to a SWSURFACE.

The Caprice CPC emu writes the whoole screen directly to the back_surface->pixels + CPCscreen_offset in groups of 4 pixels per access, and then blits to the screen_surface once the frame is complete. back_surface is a hardware surface created by SDL_CreateRGBSurface with SDL_HWSURFACE flag, and screen_surface with the SDL_Setvideomode (SDL_HWSURFACE flag, no double buffer)

So if writing to a hardware surface is slower than software surface... Do you mean it's better to declare the back_surface as SWSURFACE rather than HWSURFACE and then blit?

Well, now I'm at work, so this night I'll try some tests... I have both codes (With separate surfaces and with double buffer) in separate diretories, so no problem in recoding the back surface
Thanks a lot!!

EDIT: looks like there is no difference between HWSURFACE and SWSURFACE for the back_surface... Maybe SDL_CreateRGBSurface gives me same type of surface??

 

[paeryn]

The Caprice CPC emu writes the whoole screen directly to the back_surface->pixels + CPCscreen_offset in groups of 4 pixels per access, and then blits to the screen_surface once the frame is complete. back_surface is a hardware surface created by SDL_CreateRGBSurface with SDL_HWSURFACE flag, and screen_surface with the SDL_Setvideomode (SDL_HWSURFACE flag, no double buffer)

So if writing to a hardware surface is slower than software surface... Do you mean it's better to declare the back_surface as SWSURFACE rather than HWSURFACE and then blit?

EDIT: looks like there is no difference between HWSURFACE and SWSURFACE for the back_surface... Maybe SDL_CreateRGBSurface gives me same type of surface??

​

CreateRGBSurface should honour the surface type (you need to explicitly ask for HW). SetVideoMode always creates a HWSURFACE.
The speed decrease isn't definitive, it varies on how you access the memory. It's caused by the fact that HWSURFACEs are in memory that isn't cached, so the decrease will be more obvious in cases where the CPU would otherwise be benefiting from caching.
Basically, using HWSURFACE is baseline speed, using SWSURFACE _could_ give you a speed increase - how much is down to how cache friendly the compiled code is.

 

[boeseronkel2k]

I grabbed the binary version, and it here's how my game worked.

1)  Selected the game from the menu.
2)  Got black screen.
3)  Goto 2.

i have a question, how do you fixed the problem, i have build the lib from the source but i have the same problem

i have this problem with all sdl programs linked with this library

also a simple test programm

int main(int argc, char* argv[])
{
    SDL_Surface *screen;
	SDL_Init(SDL_INIT_AUDIO|SDL_INIT_VIDEO|SDL_INIT_JOYSTICK);
	screen = SDL_SetVideoMode(320,240,16,SDL_HWSURFACE|SDL_DOUBLEBUF);
..

SDL_Init(SDL_INIT_AUDIO|SDL_INIT_VIDEO|SDL_INIT_JOYSTICK);
works nice
screen = SDL_SetVideoMode(320,240,16,SDL_HWSURFACE|SDL_DOUBLEBUF);
-> black screen and hangs

 

[chimpoid]

I think audio requires video initialised. Perhaps transpose video & audio in your init line?
Weak, I know but worth a stab. My init stuff is

if ( SDL_Init(SDL_INIT_VIDEO | SDL_INIT_JOYSTICK | SDL_INIT_AUDIO) < 0 ) {
    ComplainAndExit(); // If it wont start, kill it
  }
screen = SDL_SetVideoMode(320, 240, 0, SDL_HWSURFACE|SDL_DOUBLEBUF);
  if ( screen == NULL ) {
    ComplainAndExit(); // if it fails kill it
  }

That works just fine for me using the precompiled libraries.

Chimpoid

 

[TKF15H]

The order of the parameters being ORed doesn't make any difference. It's all one long int being passed to SDL_Init anyway. The difference may be that boeseronkel2k is trying to create a surface with 16 bpp, which the GP2X may not like (no idea, I haven't started coding for it yet) while you're using 0 which leaves SDL free to pick whatever depth it feels like.