GP2X Hw Accelerated Sdl

[paeryn]

Trenki, I've finally managed to get the toolchain up and running. I ended up having to get my SDL code back from sourceforge and on there the GP2X_DEBUG is already commented out and works perfectly for me. There are a few writes to sdterr in the mouse and joystick routines (and one in the video memory allocation) which aren't #ifdef'd out but will be in the next update.
What version of the compiler are you using? I'm using gcc-4.1.1

 

[Trenki]

Thats weird. I used the gcc that comes with the devkitGP2X. Don't know the exact version number though.
If I don't compile with the GP2X_DEBUG flag set my demo crashed when I hit Ctrl-C. Maybe i will give the GDB a try when I find the time.

Edit: Did you compile gcc-4.1.1 yourself? Is there an easy way to do this myself for the devkitGP2X or is there an already precompiled version out there?

 

[Mr.Jabberwocky]

So all this is unneded. Just don't request SDL_DOUBLEBUF and render to a different surface instead and then blit that to the screen. This also circumvents any vsync as we don't have double buffering and does not flicker.

What I have found using SDL_HWSURFACE | SDL_DOUBLEBUF are :

1. It severely caps the speed.
2. At low clock speeds (under 200Mhz) foreground images intermittently flicker. The lower the clockspeed the worse it gets.

It also seems to throw in a totally unaligned frame occasionally causing a severe 'glitch'.

I am only using about, average, 5 updateable images per scene and even 50Mhz seems overkill for that.

Changing it to SDL_SWSURFACE | SDL_NOFRAME solves all this as far as I can tell. This is only my second SDL project but it seems to me the expected results are reversed. Almost as if the flags are switched.

 

[Trenki]

Changing it to SDL_SWSURFACE | SDL_NOFRAME solves all this as far as I can tell. This is only my second SDL project but it seems to me the expected results are reversed. Almost as if the flags are switched.

AFAIK the hw accelerated SDL will always return a SDL_HWSURFACE when you call SDL_SetVideoMode regardles of what you specify. Also I think SDL_NOFRAME does not have any effect since it is set automatically (I looked at the source). So the only difference to your SDL_HWSURFACE ... line is the missing SDL_DOUBLEBUF.

 

[Mr.Jabberwocky]

AFAIK the hw accelerated SDL will always return a SDL_HWSURFACE when you call SDL_SetVideoMode regardles of what you specify. Also I think SDL_NOFRAME does not have any effect since it is set automatically (I looked at the source). So the only difference to your SDL_HWSURFACE ... line is the missing SDL_DOUBLEBUF.

I guess it makes sense that SDL_NOFRAME has no funtionality on a console.

I just tried using SDL_HWSURFACE | SDL_NOFRAME and I am glad I took my epilepsy medication this morning :lol: . That results in some major v-synch problems.

It definitely does something different depending on that flag - using SDL_SWSURFACE | SDL_NOFRAME seems to deliver speed and v-synch. SDL_HWSURFACE | SDL_DOUBLEBUF results in a drifting v-synch plus a big slow down with added random screen glitch. SDL_HWSURFACE | SDL_NOFRAME just goes for it, throwing v-synch out altogether.

 

[Trenki]

I guess it makes sense that SDL_NOFRAME has no funtionality on a console.

I just tried using SDL_HWSURFACE | SDL_NOFRAME and I am glad I took my epilepsy medication this morning :lol: . That results in some major v-synch problems.

It definitely does something different depending on that flag - using SDL_SWSURFACE | SDL_NOFRAME seems to deliver speed and v-synch. SDL_HWSURFACE | SDL_DOUBLEBUF results in a drifting v-synch plus a big slow down with added random screen glitch. SDL_HWSURFACE | SDL_NOFRAME just goes for it, throwing v-synch out altogether.

Check the flags member of the surface returned by SDL_SetVideoMode and see wheter you got a SDL_SWSURFACE or a SDL_HWSURFACE and also check if you have SDL_DOUBLEBUF in the flag or not.

 

[paeryn]

Thats weird. I used the gcc that comes with the devkitGP2X. Don't know the exact version number though.
If I don't compile with the GP2X_DEBUG flag set my demo crashed when I hit Ctrl-C. Maybe i will give the GDB a try when I find the time.

Edit: Did you compile gcc-4.1.1 yourself? Is there an easy way to do this myself for the devkitGP2X or is there an already precompiled version out there?

I think devkitGP2X uses gcc-4.0.2, you can check it by running gcc with --version.
My toolchain is from the open2x svn (open2x/trunk/toolchain-new/) which needs compiling. Just thinking, is devkitGP2X just for windows? If it is I don't know about that as all my development is done through Linux.

 

[Trenki]

I think devkitGP2X uses gcc-4.0.2, you can check it by running gcc with --version.
My toolchain is from the open2x svn (open2x/trunk/toolchain-new/) which needs compiling. Just thinking, is devkitGP2X just for windows? If it is I don't know about that as all my development is done through Linux.

AFAIK devkitGP2X is for windows only. And I think you are right about the version number. Is the open2x toolchain compilable for windows using MSYS or something? Or is there a gcc 4.1.1 for the devkitGP2X?
Do you think that it may be the compiler that is messing up with the GP2X_DEBUG symbol?

 

[Oncer]

Ok, I crawled through this entire thread, and I'm still a bit clueless.

Can anyone tell me how to use the HW accelerated SDL properly?

Following situation:
- GP2X port of an SDL game, I need some extra FPS to reach 50
- Using 1.2.11 from open2x precompiled I get no acceleration at all
- Using the 1.2.9 16MB release (not the 21 one, the 16 MB release!) still no acceleration
- Using the 16MB release with SDL_HWSURFACE in SDL_SetVideoMode I get a great deal of acceleration, but the game flickers as hell.

I convert the surfaces with SDL_DisplayFormat, as suggested in the readme.
I'm running on firmware 2.1.2.
I'm using the Open2x toolchain.

My questions:
- Why is the newer (1.2.11) release HW accel not working? Do I have to call some of the new functions (e.g. void SDL_GP2X_AllowGfxMemory)?
- Why do I need to specify SDL_HWSURFACE? I thought it uses HWSURFACE anyway. There is a huge difference if I specify SWSURFACE (acceleration turned off)
- What's with all the flickering? I draw directly to the screen, about 500-1000 blits per frame as I have a tilemap, background and lots of sprites on the screen. For the screen update (after all the blits) I call SDL_Flip(screen). With software this works great, the HW blitter lets everything flicker horrible. Would it help if I lock the screen during the blits and unlock it before the update? Oh, and I can't use double buffering because I don't redraw the entire screen each frame.

Ok, that are the things I want to know. On 29 pages worth of posts I've seen a lot of people with the same problems. I'm willing to write a decent tutorial as soon as everything is sorted out for me.

Thanks for your attention
Simon

 

[Orkie]

Have you tried using SDL_DOUBLEBUF?

 

[woogal]

You need to use some kind of double buffering with hwsurfaces. This isn't anything special to the gp2x version, it's how SDL works. Easiest (and best) way is to ignore sdl_doublebuf (doesn't work well with tvout) and to write everything to your own surface, then blit that to the screen at the end of the loop.

 

[Oncer]

QUOTE
You need to use some kind of double buffering with hwsurfaces. This isn't anything special to the gp2x version, it's how SDL works. Easiest (and best) way is to ignore sdl_doublebuf (doesn't work well with tvout) and to write everything to your own surface, then blit that to the screen at the end of the loop.


Isn't SDL supposed to cache blits until I call UpdateRect or Flip?

Anyway, blitting to a seperate surface and then blitting this to the screen didn't solve anything. Yes, most of the flickering is gone, but it's still there. It's just not as bad because instead of little small surfaces there is just one big surface. But, especially when something moves on the screen you still see a bit of flickering tile borders.

It also seems to throw in a totally unaligned frame occasionally causing a severe 'glitch'.

This is what I mean.

So, all this fancy HW accelerated stuff isn't usable yet? Come on..

 

[Orkie]

Well I've never had any such problems myself, so it must be something you are doing wrong.

 

[kevcal]

May be worth posting your screen flip/blit code?
Don't know anything about sdl.. but do you need to wait for a vsync before blitting?

 

[paeryn]

Isn't SDL supposed to cache blits until I call UpdateRect or Flip?

Yes, normally it does but sdl uses shadow buffers to do this and at the moment my code doesn't - instead all single buffer writes are done directly to the screen. Not as elegant but that part was written way back when the HW code was just proof-of-concept.
QUOTE

Anyway, blitting to a seperate surface and then blitting this to the screen didn't solve anything. Yes, most of the flickering is gone, but it's still there. It's just not as bad because instead of little small surfaces there is just one big surface. But, especially when something moves on the screen you still see a bit of flickering tile borders.

Without double buffering the blit to the screen won't be v-synced automatically I'm sure I exposed the v-sync function to allow you to do it manually (I've not got the source at hand to check.)
QUOTE

It also seems to throw in a totally unaligned frame occasionally causing a severe 'glitch'.

This is what I mean.
If I could add a v-sync interrupt there'd be no problems (and a blitter interrupt would speed things up too), unfortunately without writing kernel modules or using the 940 I'm relying on a fairly crude method of detecting the v-sync.
QUOTE

So, all this fancy HW accelerated stuff isn't usable yet? Come on..

It is available if you use it properly, it's just that it's never been 100% complete - but I'm working on that to have it included as part of the official SDL.

 

[JyCet]

Anyway, blitting to a seperate surface and then blitting this to the screen didn't solve anything.

I use that for everything and it work very well, you just need to write or add a manual frame limiter

QUOTE

So, all this fancy HW accelerated stuff isn't usable yet? Come on..

Of course HW accelerated work very well with SDL from open2x libpack (or from this thread).
Try to compile your program with GPH sdl version and after with Open2x Libpack, compare the both you'll see a very big difference!

 

[Oncer]

Without double buffering the blit to the screen won't be v-synced automatically I'm sure I exposed the v-sync function to allow you to do it manually (I've not got the source at hand to check.)

You mean SDL_GP2X_WaitForBlitter()? It's not documented, what does it do?

My current game loop is built the following way (and I don't want to change it):
1)Blit everything (lots of small to medium sprites) to a temp (HW) surface
2)<wait>, depending on time elapsed since last wait
3)Blit temp to screen (HW->HW)

This doesn't show much flickering, but in some parts of the game you can still notice it (when there are many changes from frame to frame)

Where should I make the call to SDL_GP2X_WaitForBlitter, given that it is the right function. Will it slow down the game a lot?

JyCet: Yes, I use the open2x toolchain. I recently compiled it from sources.

 

[kevcal]

Just chuck a vsync in instead of your wait (2) and see what occurs?

 

[Oncer]

How do I do a vsync? I think the WaitForBlitter is just for the blitter to finish its work.
And I definitely need the wait to keep the game at 50 fps.

 

[JyCet]

How do I do a vsync? I think the WaitForBlitter is just for the blitter to finish its work.
And I definitely need the wait to keep the game at 50 fps.

I use frame limiter from gngeo2x in drill2x you can look the source and change the 35fps to 50fps without any problem
It's not perfect like a real vsync but it's very accurate

Unfortunately I dont know how use SDL_GP2X_WaitForBlitter, perhaps it can improve the rendering in single buffer I dont know.

Edit:
If you use lot of video memory and upper memory it can cause a slow down, you can use mmuhack module.