Spent some quality time with RETRO today…before leaping into building my own game(s), I figured it’d make sense to start by modding the Pong game that comes pre-loaded. Here’s the result of a few tweaks:
[video=vimeo]116026610
I added text for the lives remaining, and added scoring. Also modified the speed initialization, so it starts a little faster, and bumps the speed every time you score the next 100 points (currently it resets to the default if you lose a life). Also added sounds when the ball bounces off the walls, as well as a sound when you lose a life, or the game is over.
And no, those aren’t my hands…that’s my youngest playing. He and his brother both thought it was pretty fun, which is high praise coming from the Xbox generation.
@ devhammer: Nice indeed! Yesterday I received my Retro and had the same idea of first doing some mods to gain understanding. I saw your mods and thought it would be nice to to include those. Could you perhaps publish your forked version on the mbed portal?
Cool! I just imported it an will add the mod I just prepared to it.
Then (ofcourse) I will publish that version so you can see if you like my addition.
An updated overview of the changes can be found in game.cpp
Thanks to devhammer for his mods and GHI for the initial version.
Most fun to debug: making the accelerometer usable in the game. At first attempt my mod slowed the game down to an ugly repaint frenzy. I don’t know if GHI put this in on purpose as a bonus-challenge, but the I2C was set to 400Hz, causing readings to take 210 Ms. Changing it to 400 kHz (I2C fast mode) and seeing it work made me smile…
@ maxint - Nice updates, particularly the non-flickering paddle.
One result of the anti-flicker update, however, is that it appears that the collision detection code needs to be updated to bounce off the paddle a touch earlier, as the ball currently goes into the paddle a bit. This may have been a bug in my code, but not noticeable with the flickering.
Also, the mute code isn’t wired to a button, or at least, it seems to be wired to the same button as the mode switch code, so you can’t really tell that it’s muted.
May be Chris can share some light if he did any comparison.
I don’t really care about bitmaps just yet, but I would like to get as much performance as possible.
@ Architect - I think whichever library you use, one of the important modifications will be ensuring that you only draw what’s absolutely necessary and only when necessary.
As @ maxint showed, for example, in the default firmware, the paddle is drawn every tick, regardless of whether or not it moved, which no doubt is costly in terms of performance, in addition to resulting in a lot of flicker.
One of the next things I’ll be working on in my other game is figuring out the best way (or at least the best way I’m capable of) to detect when objects overlap and only draw the one on top.
[quote=“devhammer”] One result of the anti-flicker update, however, is that it appears that the collision detection code needs to be updated to bounce off the paddle a touch earlier, as the ball currently goes into the paddle a bit. This may have been a bug in my code, but not noticeable with the flickering.[/quote] Yes, I noticed that and had a quick look at the collision function, but couldn’t fix that behaviour in due time. Decided to commit this version anyways as most other bugs I introduced were much more visible and after some debugging these were gone.
[quote=“devhammer”]
Also, the mute code isn’t wired to a button, or at least, it seems to be wired to the same button as the mode switch code, so you can’t really tell that it’s muted.
[/quote] No, I didn’t wire it to the mode-button, but to the space-ship button. Hit it during gameplay to mute and the right led will show the muting. Works fine on my console…
[quote=“devhammer”] in the default firmware, the paddle is drawn every tick, regardless of whether or not it moved, which no doubt is costly in terms of performance, in addition to resulting in a lot of flicker.[/quote] That is indeed one of the things I learned from this implementation. Moreover, I don’t quite appreciate the use of wait_ms() to time the game. Now adding functionality will change the game speed, as I noticed when implementing the tilt-paddle-function. Instead I would use a timer to have individual parts animate on specific timed intervals.
@ maxint - My bad on the mute…I had originally wired my code to the mode button, so that was what I was expecting.
Regarding the speed, in one of the other project I’m working on, I just added a speed variable and divide the wait time by the speed variable:
Agree that this is probably not optimal, since it changes everything globally, so I'll probably revisit and provide individual game elements their own speed, in addition to a master speed, for more precise control.
I never did any tests to compare with what GHI provided, the library I put together was published before GHI had published their library.
The only thing I did do and test was that I used native SPI on the LPC11U24 and fallback to mbed wrappers for other devices, this make quite a big difference in the frame rates I could achieve. The mbed wrappers incur quite a bit of overhead, the primary area that hurts the wrappers is how they have implemented support for multiple devices on the SPI bus. Using my library you need to manually switch context (the library has a function to make it easy) but by not doing this on every SPI integration makes a significant difference in the throughput. When I first implemented the library I connected the logic analyzer and noticed I was not achieving the frequencies specified, sure a byte was sent at 15MHz, but the latency between bytes was huge (relatively speaking) which lead me to investigate further.
So as to not appear biased (I am sure I am ) I would like someone else to take it for a spin, I actually have a few other performance enhancements, but those are still a work in progress.
) I would like someone else to take it for a spin, I actually have a few other performance enhancements, but those are still a work in progress.