GP2X Synchro Vbl

[jbb]

Hi guys,

Got my very first program ported from the GP32 to the GP2x: ... the good old Bolcataxian from ADIC2004.

It worked pretty quickly, but without sound, as I had to disable SDL_mixer till there is a fully working lib...

But, but... well, erm: it's kind of slow.
About half the speed of the GP32 version which was working with direct screen access.

I was wondering:
1- Is SDL pretty optimised?
2- I didn't find a way to properly wait for the VBL (yet) in SDL, if you guys had the ideal timings I am suppose to wait? Maybe I am just waiting too long at the moment with 20ms? (see below, bit of code I was using fine on the Win32/macOS port a few months back)

Any better idea??

Cheerio!
JBB


current_ticks = SDL_GetTicks();

// wait for 60fps
int d = (current_ticks - ticks);
if ( d < 20 )
{
SDL_Delay( 20 - d ); // wait for 50fps
ticks = current_ticks + d;
}
else
{
ticks = current_ticks; // over 1 frame! eek.
}
SDL_Flip(screen);

 

[codesmith]

Hi guys,

Got my very first program ported from the GP32 to the GP2x: ... the good old Bolcataxian from ADIC2004.

It worked pretty quickly, but without sound, as I had to disable SDL_mixer till there is a fully working lib...

But, but... well, erm:  it's kind of slow.
About half the speed of the GP32 version which was working with direct screen access.

I was wondering:
1- Is SDL pretty optimised?
2- I didn't find a way to properly wait for the VBL (yet) in SDL, if you guys had the ideal timings I am suppose to wait? Maybe I am just waiting too long at the moment with 20ms?  (see below, bit of code I was using fine on the Win32/macOS port a few months back)

Any better idea??

Cheerio!
JBB


        current_ticks = SDL_GetTicks();

        // wait for 60fps
        int d = (current_ticks - ticks);
        if ( d < 20 ) 
        {
              SDL_Delay( 20 - d );  // wait for 50fps
              ticks = current_ticks + d; 
        }
        else
        {
              ticks = current_ticks; // over 1 frame! eek.
        }
        SDL_Flip(screen);

​

No need to call SDL_Delay if you want to wait for vblank. From the SDL HTML manual (emphasis mine):

SDL_Flip
Name
SDL_Flip -- Swaps screen buffers
Synopsis


#include "SDL.h"

int SDL_Flip(SDL_Surface *screen);

Description

On hardware that supports double-buffering, this function sets up a flip and returns. The hardware will wait for vertical retrace, and then swap video buffers before the next video surface blit or lock will return. On hardware that doesn't support double-buffering, this is equivalent to calling SDL_UpdateRect(screen, 0, 0, 0, 0)

The SDL_DOUBLEBUF flag must have been passed to SDL_SetVideoMode, when setting the video mode for this function to perform hardware flipping.
Return Value

This function returns 0 if successful, or -1 if there was an error.
See Also

SDL_SetVideoMode, SDL_UpdateRect, SDL_Surface

 

[miq01]

It worked pretty quickly, but without sound, as I had to disable SDL_mixer till there is a fully working lib...

Have you read this thread? Depending on what you need from SDL_mixer, the new theoddbot SDL libs could work. I've built a game that plays OGG files and it works...

 

[jbb]

Hi all,

Bad news...
I've tried removing the wait, keeping SDL_flip() only... it works fine as is and syncs wiith the VBL fine indeed.
BUT : it is still VERY slow.

Like I said before, Bolcataxian runs about half the speed of my previous build for the GP32 using the good gp libraries, nothing special, clocked at 133Mhz...

Mmmm
What is going on?
Am I the only one being disappointed by the raw speed on the Gp2x?

Linux & SDL are probably slowing things down a little, but not by this ratio... my game is plain unplayable as is, withough any sound, and it was nicely in 60Hz with mod playback on the good old Gp32.

Thoughts?
JBB

 

[BradN]

You could find out if it's a raw processing issue or an I/O (or really library in the more likely case) issue by trying out your gp32 code on a fake framebuffer in RAM, but you'd have to adjust for the different screen layout for it to be accurate.

 

[jbb]

I'll do some further tests... I unfortunately don't have nmy GP32 with me so i can't compare raw speed without graphic routines and so on.

But, anybody else recompiling their GP32 apps finding the GP2X under SDL much slower?

I wonder if it could just be slow in 8bpp screenmode only? (the GP32 was lighting fast in 8bit)... I know SDL has quite a few layers of color depth conversions and stuff...
I'll try in 15bit to see maybe.

Cheers,
JBB (puzzled)

 

[lemon]

The SDL_DOUBLEBUF flag must have been passed to SDL_SetVideoMode, when setting the video mode for this function to perform hardware flipping.

And if passing the SDL_DOUBLEBUF flag, then the SDL libraries don't initialize, so this is not the way.

Anyone knows how to wait for vblank using SDL on the gp2x?

 

[jbb]

Indeed... I was wondering about that too.
What does it flip to?

Also, we seem to have to use SW_SURFACE (software) according to the Wiki... When I try HW it bails right away. Seems like SDL is at fault really, it's slow and doesn't seem to be hardware accelerated in any way, for now.

Shame really: it's all a bit of an anti-climax to be honest...
I was expecting to see my old apps to run twice as fast, not twice as slow!!!
JBB

 

[woogal]

SDL_Flip is always double buffered, it just uses hardware support if you enable HW_SURFACE and SDL_DOUBLEBUF (which you can't use on the gp2x as there's no hardware support). I can't really say that I've noticed SDL being slow though. It's going to be slightly slower than other software based methods, but I don't see why it should be that slow for you. My Quake and Duke3D ports both use SDL, although admittedly the only real graphic functions used are for setting up the screen then flipping, and I was suprised with how well SDL performs.

Just out of interest, what version of gcc are you using? and have you tried playing around with different -O values?

 

[BradN]

I meant running the gp32 code on the gp2x, just to see what kind of performance difference there is running identical code (obviously it won't display anything, but you could still discern FPS if you display that separately). You'd have to recompile it for linux too, but that shouldn't affect performance at runtime much.

 

[jbb]

I'm using the compiler setup on MacOSx (arm-linux-g++).
I think it's all the latest stuff, ie: gcc4.0.2
In the makefile I use -O2, which I think it's pretty optimised?

I'll try to prepare a little benchmark proggy that can be compiled on both system, to compare raw speed in integer calculations, floats, buffer flips, blits, direct pixel read and write stuff.

But so far I'm sorry to say I am un-impressed by the GP2x general speed.
Plus, everytime I crash, it's all pretty obscure... and then I have to reboot the damn thing with its 20s Linux bootloader, unintuitive main menu defaulting to NAND everytime and so on.
Just too damn fiddly & slow turnaround.

I'm now compiling directly for MacOS first, in a 320x240 window... nicer, quicker and slick xcode debugger and so on, then I port on Gp2x at the end.
A bit of a shame, as I'd really do Gp2x specific stuff, just like in the old days on the GP32 and its nice emu Geepee32!

Mmmm. Maybe I just jumped on the boat too early?
JBB

 

[jbb]

Hi all,

today I tried to replace the SDL blit functions by a manual pixel per pixel copy...
And guess what: it went from 33ms down to 23ms per frame! Not quite as fast as the GP32 @ 133Mhz, but close... (still no music though)
So it seems this first release of SDL is pretty slow indeed!
JBB