This project develops a space shuttle shooter game on Altera DE2 board. The story of the game follows the classic alien attack on our Solar System. Before the aliens reach Earth, the Guardians of Earth sends our best soldiers to confront the enemy on planet Mars.
The objective of the game is to shoot down all the enemies in the game while manoeuvring the Space Shuttle through narrow spaces on planet Mars without colliding with any objects. The gamer earns points for shooting down enemies. The game ends when he exits the Mars landscape through the narrow exit, thus winning the game or if he crashes with any objects, thus losing the game. The space shuttle has constant speed in the horizontal direction. The gamer can control the vertical motion of the Space Shuttle and shoot at enemies by pressing on Up, Down and shoot keys respectively. The video game is displayed on VGA monitor and a background music is played with crash sound if the Space Shuttle crashes down or Victory music if the gamer wins.
The complete RTL schematic of the whole system is shown below.
In this section, the design of both hardware and software is explained along with the testing methodologies for both.
As can be seen from Figure 1, the Mars Attack system hardware design comprised of following modules.
The Reset delay module receives the 50 MHz clock as input and generates the reset signal for the VGA Audio PLL.
VGA Audio PLL
The VGA Audio PLL generates a clock for the Audio DAC ADC module. This module takes the on‑board 27MHz clock signal as the input to generate the required 18MHz clock for the audio. This module is generated from the Mega wizard utility from the Quartus II software.
The biggest module in the whole design of Mars Attack system is Video System module. This module is generated from the SOPC builder within Quartus II software. The Video System performs two major functionalities. First, it instantiates a NIOS II/e CPU along with On Chip Instruction Memory that stores the C program for the Mars Attack execution. Second, this module instantiates character and pixel buffers and then blends them together and feeds it to the VGA Controller to generate the required Video for the VGA display.
This module was borrowed from one of the examples from the Quartus II software example package and tested for correct functionality by porting it on the board and executing the C program. Once this module was tested and verified for the correct behaviour, the same was enhanced with additional components as required for the Space Shuttle system implementation. The Video System module is generated using the SOPC builder. The RTL schematic for the same is shown below in Figure 2.
The various sub modules within the Video System are explained below.
- NIOS II/e CPU
This is an economy version of the NIOS II processor. This is a 32 bit RISC processor that uses 600-700 Logic Elements and two M4K blocks internal memory. The Reset and Exception vectors are initialized at memory locations 0x84000 and 0x84020 respectively.
- On-Chip Memory
The On-Chip Memory is a M4K block based memory used to store the instructions compiled from the C program that controls the Mars Attack game flow. The memory implemented is 32 bit data width RAM with total of 16KB memory size.
- Pixel Buffer
This is a SRAM memory used to store the 640 X 480 image of the Video Game Screen. This is a standard module instantiated from the SOPC builder. This memory is used a pixel buffer for the video out.
- Pixel Buffer DMA
This is a DMA controller for a pixel buffer for the DE series board. This is also a standard module instantiated from the SOPC Builder. This module is configured for frame resolution of 640 X 480 and for 8-bit RGB Color Space Pixel format.
- Pixel RGB Resampler
This is a RGB resampler for the DE Series boards configured for 8 bit RGB incoming format and 30 bit RGB Outgoing format.
- Character Buffer
This module is a buffer for ASCII characters to be displayed on the VGA/LCD Screen. This module is also instantiated from the SOPC Builder. This module is connected to the On-board VGA DAC for the video output.
- Alpha Blender
This is the alpha blender module from Quartus SOPC Builder. It takes in two video streams one from the character buffer and another from the Pixel RGB Resampler, blends them and sends out the stream as one which contains both streams overlapped over one another. The Pixel buffer is in the background and character buffer in the foreground of the blended image. This module is operated in the Normal Mode.
- Dual Clock FIFO
This is a Dual Clock FIFO for the DE series boards instantiated from the SOPC Builder. This module is configured with 10 color bits and 3 color frames.
- VGA Controller
This is a VGA controller module for the DE series boards from the Altera Quartus software instantiated from the SOPC Builder. This module is connected to the VGA Connector on the DE2 board.
This module generates the modulation for the main oscillator. The modulator frequency is set differently for winning and losing audios. For the winning audio generation, the modulator frequency is set with 440 Hz tone while for losing audio generation the upper 14 bits of the switches SW[17:4] are read to set the modulator frequency.
This module reads lower 4 bits from the switches SW[3:0] and uses it set the modulator depth. This FM modulator depth is then fed to the sine FM decay module.
Sine FM decay
This module generates the FM modulated main sine wave to generate the sine decayed FM modulated audio output.
Audio DAC ADC
This module receives the two modulated audio waves in quadrature one from FM decay module and other from Sine FM decay module.
Once all the required hardware modules were instantiated, they were tested by drawing the basic boundary for the video game. The boundary were displayed without any hustle confirming the correct implementation of the hardware. Then the software was developed to draw the Mars surface structure. Once the boundary and lunar surface were ready, the software is designed to develop the Mars Attack game and display the same on the VGA Monitor. The flow chart for the software design is shown in Figure 4 below.
The execution starts with testing for whether Space Shuttle is within the boundary. If the shuttle crashes against either the Mars surface or any obstructions or with the enemies, the gamer loses and the game exists. If the Shuttle goes beyond the boundary without crashing against anything and goes through the prescribed space the game exits with victory to the gamer. In both cases, the game prints appropriate messages while playing either victory and crash sounds through the speaker.
On the other hand, if the Space Shuttle is still within the boundary, it checks if the VGA Vertical Sync (VS) has gone low. The program updates the Space Shuttle position and draws the Space Shuttle at the new position once per frame when the VGA VS is low. Once the program has redrawn the Space Shuttle, it checks if the Space Shuttle has crashed. If the Space Shuttle has crashed, it breaks out of the loop and proceeds as stated earlier else it’ll loop back for the next cycle of VGA_VS low.
During each frame, the program also checks if the gamer has fired any bullets. If so, the bullet position is also updated every frame. If the bullet hits the Mars surface or any obstructions the bullet vanishes. If the bullet hits the enemy, the enemy is destroyed along with the bullet. The program provides only one bullet at a time. The next bullet is loaded only after the first is either destroyed or goes out of the boundary. However, since the speed of the bullet is high, it gives a visual perception for the gamer as if there are multiple bullets.
The various requirements for this project are met. The Shuttle was launched with initial horizontal and vertical velocities of 1 pixel per frame. The constant acceleration in the vertical direction was enforced on the Shuttle due to gravity with acceleration of 10 pixels per squared frame. These values were chosen for the initial conditions by trial and error method for a good visual display.
The user controls are provided by means of Keys on DE2 board one each for Up and Down Movements and one for shooting bullets. Upon the game over, irrespective of win or lose, the user can reset the game by pressing Key 0. The screenshots of the Mars Attack are shown in Figure 4 and 5 below.
The motion of the Space Shuttle is modelled by various parameters such as the velocities and accelerations in vertical direction. As such, to calculate the new position of the Space Shuttle the model needed to relate acceleration, velocity and position. Keeping in mind that the video coordinate system has X axis increasing to the right and Y axis increasing downwards, the various mathematical equations that governs acceleration, velocity and position are developed. The various equations for the Space Shuttle are developed as shown below.
ax = 0 (no acceleration) and ay=g-thrust
vx(t+dt)=vx(t)+ax*dt and vy(t+dt)=vy+ay*dt
x(t+dt)=x(t)+vx*dt and y(t+dt)=y(t)+vy*dt
ax, ay – acceleration in x and y axis,
vx, vy – velocity in x and y axis
x, y – coordinates of the lunar lander
These equations were further simplified by assuming (dt = 1) since the parameters are calculated once per each frame. The simplified equation looks as shown below.
x(t+dt)=x(t)+ vx(t) and y(t+dt)=y(t)+vy + g-thrust
The similar expressions were used for bullets, however, the bullets only had horizontal motion as the vertical position of the bullet was fixed.
The above arithmetic calculations requires lot of floating point computations. There are two options for the arithmetic system that could be used to perform floating point computations namely fixed notation and floating point system. The floating point computation required special module which enables floating point computations. However, computations in floating point notations is slower. As such, the program made use of the fixed point notations. The values were converted to fixed point notations before computation. Then the values were used to compute the acceleration, velocity and position parameters. Once these parameters are computed, the values were converted back before drawing the Space Shuttle at the new location. To convert the floating point values to the fixed notation, the values were left shifted by 8 bits and to revert back the values were right shifted by 8 bits.
There are several improvements that can enhance the Mars Attack game. Some of the major improvements are mentioned in this section. First, instead of letting the Space Shuttle move from left to right direction, the Space shuttle can be fixed in the horizontal direction and move the Mars Game environment from Right to Left direction. This gives a better feel with longer time duration for the game. With the new game layout coming in, enemies and other obstructions can be placed randomly.
The second major enhancement that can be added is by adding the background image for the Mars Attack game. Thus, there will be two layers for the video game. The background will be the Mars planet background image, the foreground would contain the game environment.
The third enhancement will be in the characters. We can always use good characters for both Heros and Villains in the game. This can be achieved by designing the characters and loading the pictures in the game at the given locations.
The major objective of this lab was to give exposure to the CPU on FPGA. There were two options for CPU that could be used namely NIOS II or Pancake. The biggest task in this lab was to learn the CPU, instantiate it in the hardware and make use of it to develop the lunar lander application. Both CPUs had different set of challenges. While the NIOS II processor was a classic 32 bit RISC processor, the challenge with NIOS processor was in learning the Quartus tool, SOPC builder to instantiate the required processor and Altera Monitor or the NIOS IDE to develop the lunar lander application. On the other hand, Pancake Processor was a stack based processor and had a completely different set of instructions. The biggest challenge here was to understand the functioning of the stack based Pancake processor along with its assembly instruction to code for the lunar lander application. Both CPUs had its own pros and cons.