@ Skewworks’ post about his new device running Pacman and Rally-X reminded me about another game I was writing, it is still not finished but he might just have inspired me to get it done. I have not worked on it for months, but here is a quick vid of what I have so far.
You rock! I loved that game.
Very cool! Needs a little bit more speed I think. I see some good games coming out for Game-O.
Sigh I wish we have an emulator.
Thanks, I remember the game on the Atari…
@ Architect, it definitely needs more speed! Actually it would be interesting to see how easy it is to get it running on the Game-O.
I need to see how GHI managed to have the Game-O create a 320x240 bitmap with the limited memory on the STM32. I have a few guesses, but I can’t wait to see what they have done there.
This will be the next gameo update. You simply can’t have 320x240 in memory as it is about 150k. We are experimenting with setting different modes, with reduced color, or resolution. The emulator and default mode are probably going to be 160x120. We need couple days to complete it still.
And excellent work on the frogger.
@ Gus - Thank you for the info, I have been wracking my brain since I saw the sample code on the Kickstarter post, wondering how that was possible. I thought maybe you used memory that was on the display device or something like that.
It is possible through a special firmware that reduces the color. But we then decided to keep the color standard 16bpp and reduce the resolution.
I think lower resolution is the right way to go for a device like this, hopefully the SDK will allow programmatic selection of the resolution.
Is each object (car, log, etc) an individual object? Or are the rows sprite animations which loop in a horizontal manner?
Another very cool demo Chris, keep em coming
Definitely, we need more games here
Thank you sir. Each image is a separate sprite, so each of the log sizes is an individual sprite that is managed. Each turtle is a sprite on it’s own. I have a Lane class which manages the sprites in each lane and move them along etc.
I went for this approach for two reasons
- It saves memory
- I already have sprite collision support in my Game library so it required the least amount of rework to hand the collisions and carrying of the player sprite when jumping onto the logs/turtles etc.
@ HughB, @ Skewworks, Thanks guys, I enjoy writing this little retro games and it is even better when I hear of other projects making use of them esp. projects involving other hardware and in Skewworks case actually hosting the games within his NETMF OS, that is cool!
I will release the code to codeplex once it has moved along a little more, but in the meantime here is the sprite sheet that I put together for the game. Not all the artwork is used yet.
AWE & SOME
@ Jason - Thanks.
@ taylorza - I’m looking forward to seeing your code. Sprites were one of those things I remember typing in from the old Commodore 64 magazines back in the day but I never really understood how they worked. I think that’s one of the reasons I’ve avoided game programming for so many years
Were you able to find the graphics or did you have to create them?
@ ianlee74 - I got most of the sprites from MAME (http://mamedev.org/) by running the arcade version of the game and capturing what I needed.
But if you are interested in the general sprite handling, I am using the same sprite engine that I wrote for Pacman which has support for animated sprites etc. All three games, Pacman, Rally-X and Frogger share the same engine code.
Where is this running on the gameo emulator?
@ Gus - Sadly it is still running on my Hydra, but Game-O emulator is next
Actually, I say sadly as a joke. I like the Hydra very much, the only thing better would be a STM32 based OSHW board with external memory now that would be a power house gaming board…