1945 Clone?

soshimo

I wrote a 1945 clone for the BREW platform (ARM7) a few years back. I was eventually planning on publishing it but my company's funding fell through and it ended up on the back burner. I would very much like to resurrect it for the Hydra. I'm using parts of Ari Feldmans spritelib as well as some custom sprites done by me. They are all 16 color. I'm not sure if there is a limitation with the Props video generator or not - but most lcds on cell phones back in 2004/2005 were very limited in color and refresh rates, basically they were Smile and you had to take great pains to ensure things like proper byte alignment for fast blits (basically all the old school tricks). I really miss the challenges of embedded game development. Anybody can write a huge slow monster in XNA these days and it will run on just about any PC or xbox 360, where's the challenge in that? Although Zune development is exciting, but I digress. The game is written in C (BREW was a C framework) so I would have some work to convert it and the distict lack of structures leaves me scratching my head how I can easily model my game elements - but I have the Hydra book on order to help me acclimate to the environment.

Again, I digress - back to my original question. Would a 1945 clone be a good game to showcase the Hydra's power and/or has it been done already? I can't imagine that it hasn't been done yet, it was a very popular game and still is on lots of platforms, but nothing turned up in a cursory google search.

potatohead

I think that would present as a great challenge!

There is a shooter demo that comes with the HYDRA, that is on par with 1945. You might check that out for some hints as to what the challenges would be.

We've got SD-Card now, meaning background tile maps and progressive enemy sprites can be spooled in and out. The shooter demo just fits it all into 32K and that's it!

This game is within the limits of prop video. I suspect you will have to build your own rendering engine though. Generic tile, char mode, bitmap drivers consume a lot of the system RAM. The most potent approach seen so far is to setup one COG to render scanlines, and that's it!

Other COG's assemble scan-line data, based on the game display state, and feed the scan line cog, thus allowing for more than one COG to be building the screen.

SPIN is plenty fast enough for the core game logic. PASM is needed for video, I/O and sound.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!