potatohead's Blog - KABOOM! on Propeller

RSS Bot · December 14, 2007

I've some free time, and seriously like this game. Perfect for a first pass Propeller project. The screenie attached to this post is the core video driver code up and running with one sprite active. The score lines are full-on character mode graphics, with a small font table defined to handle the score. The middle of the screen utilizes a scan line buffer, filled with the background color needed for the next line, while the current line is drawing.

Sprites are being written as strips, just like A8 bit PM graphics are. I've got one strip running, and it appears there is time enough in one COG (one of 8 CPU's, running in parallel on the thing), to build two sprites. The paddle in KABOOM is doubled. Not sure how I'm gonna do that just yet. If it's doable, I'll set a flag to double up sprite strip #2, for those scan lines. If not, I'll just multiplex the two sprites, leaving some flicker on the paddle scan lines. Because I've got access to the scan line buffer, I can multiplex that every other scan line. Really want to see what can be done with one video COG only.

Sprite data is a series of two longs per scanline, organized in series, two longs per scan line to form 8 full-color pixels. There is a render table that contains the scanline background color, sprite x positions, and one so far unused byte. (likely to be the double sprite flag, if possible) Vertical movement is done by moving the sprite data up and down in the sprite table. Horizontal is done by changing the x position in the render table, thus allowing for scan line, by scan line positioning of the sprite images.

The speed tests of SPIN were interesting. I did some basic stuff, like counting numbers on screen, moving blocks of memory, etc... SPIN, the on-chip high-level interpreted language, appears to run at about 70 to 90 percent native 6502 assembly on a real Atari 8 bit computer does! Plenty fast for game logic, input, etc...

Should this end up messy, there are plenty of COG's in the chip, worst case, re-write the video such that one COG is rendering scan lines, another is building images for them. That technique is being used in lots of games done so far.

Sound is up in the air at the moment. Might make sense to get one COG to act somewhat like a TIA. Input will be mouse to get the game up and running. I'll build a simple paddle interface after that and just use a paddle or driving controller.

The blur seen on the moving sprite happens to be an artifact that results from the sprite scan line positions being changed, without sync to the display. That's coming up in the next driver code pass, along with sprite number two. Took quite a while to figure out how to and and or all the data together to build the moving sprite. Could have looked some code over and avoid reinventing the wheel, but I really need to work through that exercise for future projects. The blue color really is just filler data to verify the sprite strip is on the display.

Check out screenie number two! It's an excellent port of DEFENDER! Runs on the chip, in 32K, with sound too boot. Input is keyboard, game controller. Damn cool, and maybe something I can approach some day. The journey is fun though. Motion blur is likely an artifact of my capture card. That one is done and playable on most any Propeller setup.

Attached thumbnail(s)