GP32 Gpsurfaceflip And Gpsurfaceset Take 24ms

[Alex.]

I've been playing around with the official SDK (EABI, devkitpro r25). All is going well except that flipping the framebuffers takes a very long time, killing all performance. Here's the code:

CODE
GPDRAWSURFACE gpDraw[2];

void GpMain(void *arg)
{
GpGraphicModeSet(16, NULL);
for(int i = 2; i--; ) GpLcdSurfaceGet(&gpDraw, i);

int flip = 1;
GpSurfaceSet(&gpDraw[0]);

while(1) {
// draw a box or something simple
// etc.

unsigned int timer = GpTickCountGet();
GpSurfaceFlip(&gpDraw[flip]);
timer = GpTickCountGet() - timer; /**** timer == 24! ****/

flip ^= 1;
}
}


I don't mess around with clock speed or anything, just simple things. I tried using both GpSurfaceFlip and GpSurfaceSet to flip the buffers, and they both take around 22-24 ms from call to return.

I'd appreciate any help from any of you one or two people that still haunt these forgotten parts of GP32x

 

[Alex.]

I did a little more testing. I installed devkitARM r14 and the old OABI GPSDK, but there is no difference (which is a great). It seems that at times the call to the screen flipper takes a very small amount of time, though most of the time it is very large as described above.

I'd appreciate it if you would download and run this test FXE, and tell me the numbers it displays on the screen.

For example, mine shows
35
24 2 25

Where 35 = fps, 24 = current time it took to flip the screen, 2 = min. time, 25 = max. time. I wonder if this has something to do with my GP32 being a BLU+, though hopefully it's just my code that's missing or misusing something

Thanks!

 

[greenmikey]

I put this on a card today. Then I got drunk, I can't find my gp32. I'm sorry.

 

[trooper]

Hi Alex,

I`ve just run your test program, And am getting the numbers displayed below. The first number on the second
line constantly fluctuates between 17 and 18.

44
17/18 17 18

Btw, My GP32 is a standard Blu (non Blu+) with the pencil trick.

Hope this helps.

EDIT: Just ran it a few more times, Out of curiosity, And i get the same results every time. But looking at the first
number on the second line, It could be either 16/17 or 17/18, But it fluctuates so fast, It`s difficult to tell.

Not sure if that makes a lot of difference ?.

Regards

Trooper

 

[Alex.]

Thank you very much Trooper! (and mikey too

This is weird, it means that achieving 60fps with 16bit graphics at default clock speed is impossible - I doubt this is true. I'm still trying to find out what I'm doing wrong, especially since changing the clockspeed in gpstart.c to 133MHz makes a very small difference, the time it takes to flip the framebuffer only goes down to 21ms from 24ms.

Now I allocate my own framebuffer which I memcpy to the set GPDRAWSURFACE every frame, and I get 58fps at stock clock Still, I'd prefer to use the hardware flipper since I assume ideally it would be much faster. I've also read that abusing memory like this can lead to sound crackling later on, which would be a real shame.

If any past or present GPSDK users see this and know anything which could potentially help, please tell me anytime

 

[Reesy]

Yeah the offical SDK has always been slow when flipping the frame buffer. I would recommend just ripping out the lcd init and flipping code out of the Mr Mirko SDK and using this on top of the official SDK.

http://reesy.gp32x.de/MrMirko_SDK.zip

I believe the sound crackling problem was caused by having a sound buffer which was not aligned correctly, I can't remember the exact reason though. Again for sound I would use the sound buffer code created by .... well I can't remember who created the original code but its bloody good. You can get a copy of the code in the DrMD source code

http://reesy.gp32x.de/source/DrMDv5b8_source.zip

Its in the DrMD sub folder and its called gp32_snd.c. It creates a sound buffer that raises an irq when the buffer needs refilling, it works really well.

Later
Reesy

 

[Alex.]

Thanks Reesy!

That's disappointing to hear about the SDK. I wonder how the GP32's official games managed this, perhaps they used memcpy too :closedeyes: I'm surprised I did not see this issue discussed more on these boards, I guess almost everyone used Mr Mirko's libraries.

Thanks for the code, I'll keep my hands off MirkoSDK since my stuff isn't GPLed, but I'll keep the sound file around in case the crackling ever comes up.

 

[Exophase]

It's strange, because a flip should take almost no time. It's just changing a pointer, which should be stored in a hardware register somewhere. On GP2X and Wiz this operation is basically free.

If vsync is being waited on then that's another story. The Wiz hardware is kinda cool in that it'll actually wait until vsync for you, before it refreshes the registers.

 

[slaanesh]

I`ve just run your test program, And am getting the numbers displayed below.

44
17/18 17 18

Btw, My GP32 is a standard Blu (non Blu+)

I'm getting exactly the same results as trooper.

I have a theory as to what is happening:

Whilst the GP32 doesn't have a real vsync, you can read what part of the screen is being drawn, specifically line and column. GpSurfaceFlip() is probably waiting until it gets to the end of the screen. The test program is always doing the same thing so the amount of time taken is pretty much always the same.

If you were to introduce random sleep times (say, in the range of a 1-9 milliseconds) I bet you will find that the numbers above will be reduced by that same amount. ie. sleeping for 5 milliseconds before calling GpSurfaceFlip would result in the 17/18 being 12/13.