Slab Splitter (Arkanoid style game)

                                 "Slab Splitter"

This is my first game for the Arduboy system. It’s more or less a clone of breakout/arkenoid style games. It runs at 60fps (maybe 120fps, not sure how the display handles that) and features animations for destroying bricks.
The ball physics are fairly decent, you can control the bounce angle of the ball based on where it hits your paddle.

Video

                                  "Download"

You can grab the Zip file from my website here: https://alwyn.tech/~breakout.html

I’m not going to make any claims about the code being beautiful. But it’s written in a way that isn’t too difficult to understand, with object orientation and some commenting. So feel free to have a rummage around it.

5 Likes

A display update takes less than 1.5ms. At 120fps, each frame will have a duration of 8ms. Subtracting the 1.5ms for display(), that leaves 6.5ms to do all the other work for a frame.

If you want to know if you’re actually achieving the frame rate you’ve specified, use nextFrameDEV() in place of nextFrame(). Any frame that takes longer than the specified time will cause the yellow TX LED, near the USB connector, to light. (Remember to change back to nextFrame() before releasing your sketch.)

1 Like

Hi,

I have been mostly working on the assumption that I have been hitting frame targets, since the physics are tied to the frame rate, and the physics don’t feel slower than they used to.
But nextFrameDEV() sounds like something I should keep in mind, should be super useful, Thanks for that info.

My uncertainty comes from not knowing how the hardware/library’s work. For example, my code may have been running happily at 120hz, and drawing at that speed, but if the screen has a max refresh rate of 60hz, it’s not going to matter. Since it would be drawing twice per display update (which could cause tearing*).

When I tried to look into the screens hardware I saw a YouTube video of someone claiming to have the screen running at 500hz. So I decided to program the game for 120hz and hope for the best xD

But once again, thanks for that explanation :slight_smile:

*tearing is very unlikely though, since its programmed to only update the pixels that need updating, rather than rendering the entire display each frame. (and at the end of the day, the game is mostly static).

1 Like

Like I said, calling display() takes a fixed time of about 1.5ms to execute (for the next release of the library this will be closer to 1.2ms). So if you did nothing but update the screen, like:

while (true) {
  arduboy.display();
}

your frame rate would be about 660fps. However, refreshing an unchanging display at that rate isn’t very useful :wink:

1 Like