GP32 Gamepark Sdk And Overclocking?

[jbb]

Hi guys,

I am developping a new game for my GP32, with the normal SDK (not Mirko's).

Everything is fine except that I am getting dangerously close to running in 2 frames rather than 1 at the default 66Mhz, with the amount of sprites and scroll I have in there.
I use the 8 bit mode, the GpTransBlt and GPBitBlt functions to draw gfx accross the screen, and GpSurfaceFlip to synchronise the double buffer.

Doesn't matter I thought: I'm only at half speed! BUT if I try to clock the GP32 differently, without pushing it: like 99, 102 or 133Mhz; unfortunately the graphics get all buggy, flickering a lot, like if not having time to draw before the vbl or something (starting by the bottom right).

I searched the forum for similar topics but had no luck... So here I am with my questions:

Any idea about what is going on? My GP32 is a brand new BLU, 166Mhz.
What's the point to have a GpClockSpeedChange function if we can't use it? Unless there is another function to use to tell the GP32 that other timings need adjustements?

Thanks for your attention! (and help if you can)

Cheerio,
JBB

 

[mr.spiv]

I assume you called GpClockSpeedChange() before initializing the LCD & Sound and Timers?

 

[RobertJ]

Are you setting the clockspeed at the start of GpMain, or are you setting it after you have initialised the LCD?

You really should do it before initing the display, as vblank rates are based on clockspeed.

 

[jbb]

Thnak you all for your prompt answer!

Inits? I think so... here is a chunck of my source below.
But I don't seem to "init" as such the LCD... what is the function for this?

Cheers,
JBB


void GpMain(void *arg)
{
GpClockSpeedChange(132000000, 0x24001, 2); // 133Mhz

GpKeyInit();
GpGraphicModeSet( GPC_DFLAG_8BPP, 0 );
GpLcdSurfaceGet(&gastDrawSurface[0], 0);
GpLcdSurfaceGet(&gastDrawSurface[1], 1);
GpSurfaceSet(&gastDrawSurface[0]);
...

 

[generalnmx]

If you have a wait loop (which I'm sure you do) which uses GpTickCountGet(), you must remember that the processor ticks increases speed when overclocked (of course).

 

[jbb]

Well, no... no waitloop really.
I always assumed GpSurfaceFlip was kind of waiting for the VBL itself... and it has always looked slick, and in 1 frame, 2 frames... without flickering, ever.

This said I was using GPTickCountGet() to calculate where I was in the frame (with the variable vbl_timer to compare with the frame before).

See below my main loop last part...

...
if (debug)
{
vbl_timer = ((GpTickCountGet() - vbl_timer)*100)/20;
ScoreDebugDisplay(vbl_timer, 260, 2, 3, 0);
}

// -- Double Buffer swap --

GpSurfaceFlip( &GET_DRAW_SURFACE );
giDrawBuffer = 1 - giDrawBuffer;
}

Do you think I need to add an additional wait loop in there then?...
And how do I know I'm synchronised with the LCD?

Cheers,
JBB

 

[mr.spiv]

Try GpSurfaceSet() instead of GpSurfaceFlip()... The difference between these two is that the GpSurfaceSet() doesn't flip the framebuffer in a middle of LCD refresh. Thus you get automatic synchronization.

 

[jbb]

Thanks.
I think I just got it: by putting the game screen in tripple buffering, and extending manually the wait between frames to 40ms mini (rather than 20ms for 50fps).
The GpFlip seems confused by the new 133Mhz timings and doesn't wait by itself.

Shame as a manual sync doesn't seem as stable to synchonise the LCD (I can see slight jerks in the ships movements now and then)

I'll try with SurfaceSet too tough, to check.
JBB

 

[jbb]

> I'll try with SurfaceSet too tough, to check.

Just tried... no real difference: still slightly out of sync. Not super-smooth like it used to be at 66Mhz with a simple Flip. Grr!
With the triple buffering, I lost the flickering but it was far too fast... I have put in there a waiting loop of 40ms, which is in theory 50fps (x 2 as we're at doubleclock). But it seems a tad fast, with a slight jerkiness...

What would you recommend to get it fully synchonised with the LCD?
by the way, what frame rate is the LCD running at anyway?

Cheerio,
JBB