Dingoonity.org

Downloads: https://github.com/cxong/Slappa/releases/tag/1.0.1
opk: https://github.com/cxong/Slappa/releases/download/1.0.1/slappa.opk
GitHub: https://github.com/cxong/Slappa

This is a little game I made recently and ported to GCW-Zero. It's an arcade kungfu minigame with high scores, good for quick games.
This was originally a submission for pyweek recently: https://pyweek.org/e/Slappa/
But having recently received a GCW-Zero, I decided to port it. Right now there's an opk and Windows download, or if you have Python you can run the game directly (open source, MIT license, various open licenses for the content).

Incidentally, does anyone else have experience using pygame with GCW-Zero? Being quite new to both, I ran into a number of issues. Most are related to pygame, but there doesn't seem to be much in the way of guidelines online, so I thought I might share some tips I found here. Basically, Python and pygame are both pretty slow so in the end I couldn't maintain a smooth 60fps as soon as more than 4 sprites were on screen, so I had to opt for 30fps instead. I think it has something to do with the relatively large sprite sizes - I was working with 256x256 sprite sheets, perhaps that's too big considering the CPU's tiny caches. Next time I might try an OpenGL ES-based framework.

Anyway, here are some tips:
- Always use convert(), or convert_alpha() if you have to. This converts the surfaces to the same pixel format as the screen's, otherwise every blit will require a conversion.
- Use tick_busy_loop; tick is very imprecise.
- Perform as much processing ahead of time as possible - scaling, font rendering, rotations etc.
- Try to pre-render fonts; failing this, try not to use anti-aliasing, it's very slow. A few font renders is ok but rendering a screen full of text will kill your frame rate.
- Color key transparency is faster than surfaces with partial alpha
- Make the sprites as small as possible
- If there is audio crackling, try increasing the mixer buffer size, but not too much as it will increase latency
- Hide the mouse (unless your game needs it)

This game is absolutely rad, I am having a lot of fun playing it. Good job!
Would you be interested to have your game placed in the official GCW Zero repository: repo.gcw-zero.com?

Just two things I noticed:
* Is there a way to erase a typed letter in the hi-score entering dialog? Turns out I had to press B to erase a letter
* What is the keymapping on the right side of this picture? Is that for a device different than GCW Zero? It's quite confusing.


About USB OTG - that feature is not yet ready and is disabled in public firmware releases. But it's nice to know the game supports it.

As for your python questions/notes - the majority of software ported to GCW Zero was written using C/C++ & SDL backend, so we don't have much experience with pygame and your notes are valuable to us. Would you like to join our IRC channel (connection details) so we can help you debug/improve the game performance?

Your game may be slow but it's too easy to say that the GCW Zero is not powerful enough.
You should first work on optimizing your code; things like this will definitely be slow: https://github.com/cxong/Slappa/blob/master/animation.py#L30

Also, from what I can see you render at 640x480 then downscale to 320x240 in software. Don't do that! Instead, use 640x480 as the screen size, and add X-OD-NeedsDownscaling=true to your .desktop file.

Your game may be slow but it's too easy to say that the GCW Zero is not powerful enough.

I've profiled the code and the two most expensive tasks are fill() and blit(). If I disable sprite drawing and leave everything else, frame rate is very high. Based on this I conclude that either GCW Zero blitting, for large surfaces, is slow, or python/pygame. Given what I've seen from games written in C/SDL, I'd say it's a bit of both.

You should first work on optimizing your code; things like this will definitely be slow: https://github.com/cxong/Slappa/blob/master/animation.py#L30

That loop will usually run 0 or 1 times, making the difference immaterial. Actually I'm surprised you'd say that would be slow; even if I were writing optimised C I wouldn't worry about code like that, as it's just integer arithmetic, constant time stuff.

Also, from what I can see you render at 640x480 then downscale to 320x240 in software. Don't do that! Instead, use 640x480 as the screen size, and add X-OD-NeedsDownscaling=true to your .desktop file.

That's actually misleading; the game "world" behaves as if it's in a 640x480 space but I pre-scale everything. To demonstrate, you should find no pygame.transform.scale calls in the game loop at all.

Maybe you could try with SDL2 bindings? Then it would be GPU-accelerated.

Checking this out now!

Awesome.  I really appreciate having a high score table - a small touch but too many people don't bother with it. 

Thanks!