Retro Invaders a space invaders clone by Chris Favreau. Written for the RetroMbuino development board from outrageouscircuits.com for the game programming contest.

Dependencies:   mbed

This is a space invaders clone written for the Retro Mbuino from outrageous circuits.

Development board: http://www.outrageouscircuits.com/shop/product/15 ).

The game itself is basic space invaders. Shoot them before they get to the bottom of the screen. It has a UFO saucer which you can shoot for extra points. You get 4 shields and each shield can be hit up to 4 times before it is gone. Hmm... as each level increases the speed of the invaders shots goes up. The invaders only speed up when there is less of them. You complete the level when you shoot all the invaders. The game ends when a) you run out of lives (you start with 3) or the invaders get to the bottom.

The LEDs turned out to be a pretty cool addition to the game. I wrote a class that blinks them and turns them on for a specified amount of time. They add a nice extra to the game. I use them on the intro screen and when the UFO is present.

The sound turned out to be really difficult for a few reasons. The biggest was that I had never written a sound engine before. The interrupt service routine working off the timer was the easier part. I also had a lot of trouble because there is no filter to filter out the PWM frequency to the speaker... so I had to run the PWM frequency way up there 30 kHz.

The graphics turned out to be a bit of a bear too. Thanks to Chris Taylor for his really great LCD API. I picked up a couple of frames per second from that. I had modified the DisplayN18 class for blitting a single line buffer to the LCD panel however his is a little faster for some reason? I used a different approach to doing the graphics (as I have very little experience with anything other than double buffered displays). I have a tile map and a list of sprites. Each tile/sprite is 1 bit 8x8. They could be bigger. I ran out of time. That much is not special. What is different from what I can tell is that I use a 1 line buffer that is 160 shorts long. The render function first adds the tile map data into the line buffer first. Then the sprites are added over the existing data. You can have a great deal of different sprites and maps going to the screen and just have to rewrite the LCD memory once per frame. After each line is composited, the line is then drawn to the LCD. Kind of like an Atari 2600. Each sprite/tile has a foreground and background color and can be different from the other tiles/sprites. There is one color reserved for Transparency.

There are 16 colors to choose from. I chose a palette based on the Macintosh OS 4.1 palette I found on WikiPedia. It is a very nice mix of colors.

I found a sprite editor called SpriteX ( https://code.google.com/p/spritesx-ed/ )... it works nicely except that the 16x16 sprites are in a weird format. Time limited me to 8x8 sprites. Oh well.

I used nokring to make the music. It makes RTTTL formatted ring tones which my sound api can play. Here is a useful site that has lots of arcade/video game ring tones with a link to nokring in the utilities page. http://arcadetones.emuunlim.com/files.htm

Other than all that stuff I used state machines to do most of the game logic. Please excuse the horrible coding as I tried to comment a lot of it however it is not very nice to look at. Lots of long functions...

Display/BurstSPI.h

Committer:
cfavreau
Date:
2015-03-03
Revision:
0:c79e1f29f029

File content as of revision 0:c79e1f29f029:

#ifndef BURSTSPI_H
#define BURSTSPI_H
 
#include "mbed.h"
 
 
/** An SPI Master, used for communicating with SPI slave devices at very high speeds
 *
 * The default mbed SPI class allows for communication via the SPI bus at high clock frequencies,
 * however at these frequencies there is alot of overhead from the mbed code.
 * While this code makes sure your code is alot more robust, it is also relative slow.
 * This library adds to your default SPI commands some extra commands to transmit data rapidly with
 * very little overhead. Downsides are that currently it is TX only (all RX packets are discarded),
 * and it requires some extra commands.
 *
 * Example:
 * @code
 *  //Send 1000 SPI packets as fast as possible
 *  spi.setFormat();
 *  for (int i = 0; i<1000; i++)
 *    spi.fastWrite(data[i]);
 *  spi.clearRX();
 * @endcode
 *
 * As an example, writing 76,800 16-bit data packets to an LCD screen at 48MHz requires 111ms with
 * the normal mbed library. With this library it takes 25ms, which is also the theoretical
 * amount of time it should take. If you are running at 1MHz this will do alot less.
 */
class BurstSPI : public SPI
{
public:
    /** Create a SPI master connected to the specified pins
    *
    * Pin Options:
    *  (5, 6, 7) or (11, 12, 13)
    *
    *  mosi or miso can be specfied as NC if not used
    *
    *  @param mosi SPI Master Out, Slave In pin
    *  @param miso SPI Master In, Slave Out pin
    *  @param sclk SPI Clock pin
    */
    BurstSPI(PinName mosi, PinName miso, PinName sclk) : SPI(mosi, miso, sclk) {};
 
    /** Put data packet in the SPI TX FIFO buffer
    *
    *  If there is no space in the FIFO buffer it will block until there is space.
    * The FIFO buffer will automatically send the packets. There is no receiving here, only transmitting.
    *
    *  @param data Data to be sent to the SPI slave
    */
    void fastWrite(int data);
 
    /** Use this function before fastWrite to set the correct settings
    *
    * It is not needed to use this if the last SPI commands were either normal SPI transmissions,
    * or setting different format/frequency for this object. It is required to call this
    * function when several SPI objects use the same peripheral, and your last transmission was
    * from a different object with different settings. Not sure if you should use it?
    * Use it, it takes very little time to execute, so can't hurt.
    */
    void setFormat( void ) {
        format(_bits, _mode);
        frequency(_hz);
    }
 
    /** After you are done with fastWrite, call this function
    *
    * FastWrite simply fills the SPI's (SSP's actually) TX FIFO buffer as fast as it can,
    * and that is the only thing it does. It doesn't do anything with received packages (currently, may change),
    * so the the RX buffer is full with unneeded packets. This function waits until transmission is finished,
    * and clears the RX buffer. You always have to call this before you want to receive
    * SPI data after using fastWrite.
    */
    void clearRX( void );
 
 
    //Just for documentation:
#if 0
    /** Configure the data transmission format
     *
     *  @param bits Number of bits per SPI frame (4 - 16)
     *  @param mode Clock polarity and phase mode (0 - 3)
     *
     * @code
     * mode | POL PHA
     * -----+--------
     *   0  |  0   0
     *   1  |  0   1
     *   2  |  1   0
     *   3  |  1   1
     * @endcode
     */
    void format(int bits, int mode = 0);
 
    /** Set the spi bus clock frequency
     *
     *  @param hz SCLK frequency in hz (default = 1MHz)
     */
    void frequency(int hz = 1000000);
 
    /** Write to the SPI Slave and return the response
     *
     *  @param value Data to be sent to the SPI slave
     *
     *  @returns
     *    Response from the SPI slave
    */
    virtual int write(int value);
#endif
 
};
 
#endif