PocketMatrix

Hi all,

I did some work on a generic benchmark class that we can use to test our toolkits. I did some preliminary tests and the difference in performance was probably too large between PocketFrog and GapiDraw so I will ask you guys for help in checking the PocketFrog test.

Here are the bitmaps I have chosen. A typical 32x32 sprite, and a typical menu graphics bitmap in 128x128 pixels:

Color keyed sprite 32x32

Alpha map used for AlphaBltFast (not available in PocketFrog 0.6)

Color keyed menu item 128x128

Alpha map used for AlphaBltFast (not available in PocketFrog 0.6)

Here is the class I used:
http://www.sanneblad.se/johan/temp/gfxbench.h

Here are the sample projects:
http://www.sanneblad.se/johan/temp/gfxbenchgd104.zip
http://www.sanneblad.se/johan/temp/gfxbenchgd300.zip
http://www.sanneblad.se/johan/temp/gfxbenchpf060.zip

Here are the results as an XLS file:
http://www.sanneblad.se/johan/temp/gfxbench.xls

And for those of you without Excel, here is a screen snapshot:


Please, give the PocketFrog sample a go! I compiled the PocketFrog library and the Blit sample with maximum optimizations in release mode.

//Johan

By the way.. I'm not sure how PocketFrog uses coordinates.. If I set the random coordinates using:

m_pRandTable[i] = rand() % (240-MAX_SURFACE_WIDTH+1);

And call FillRect() using Rect(x, y, x+MAX_SURFACE_WIDTH, y+MAX_SURFACE_WIDTH), will something be drawn if x and y are maxed? GapiDraw uses rectangles that are exclusive, which means that they will be drawn using this formula ("width" equals "right-left", not "right-left+1"). Does PF this also? If PF does not, then performance for PF on FillRect should probably be somewhat slower.

One might wonder why GD104 performs better than GD300 in so many cases

As I see it, there's evidently room for an alternative to GapiDraw.

Taking PocketFrog out of retirement, defining long term goals, including optional PocketHal support and making it officially an OpenSource project would definately be a big plus. We could all contribute our small effort to it.

Everyone would benefit from this, including GapiDraw users since there would be competition. The only person that would NOT benefit from this would probably be the poor sap maintaining the project, as people might simply run away with the code and not report bugs or improvements... But maybe that's just my dark side talking.

For those of us that cannot [ or will not, or don't want to] purchase a license for GapiDraw would we be screwed if it wasn't of Thierry's work, or what!

Getting Gapi/direct chip support into a library to the point where it works on all platforms must be such a nightmare...

--Eric

I believe Thierry originally stopped working on pocket frog since soo many people were using it and modifying the source, but there were not many contributions. I think this is why pockethal is in a lib form.

Would it be possible to make a new pocketfrog sort of plugin manager where as a few people could work together creating modules such as a fast blitter and then release it in a lib that linked into this new platform. This way small teams could work on different parts and add to the project without giving away proprietary code(if they were worried about it).