Arkapic!

Project by:

Dave Booth: Sound and main program
Slawek Ciapala: Graphics engine, graphic block routines, main program
Steve Behling: Ball movement, scaling and trajectory calculations, main program
Timur Karatas: Input devices, hardware ISRs, collision detection, main program debugging

Introduction

Imagine a first-person Arkanoid-style game whose object is to uncover pictures rather than just destroy blocks. The playfield will consist of a 3D "well" whose back wall has layers of "blocks," the first of which is a blank, concealing layer.
Underlying layers will portray pictures from several possible categories. By moving a "paddle" around the screen, the trajectory of a ball bouncing between the screen and the playfield will be determined and the stricken tile will be removed. When the player can guess the content of the entire picture the score is stored and a correct guess resets the game.

Problem Description

We used single-buffered Super VGA graphics at 640 x 480 x 8-bit resolution.
Several aspects of this project gave it some unique challenges. First of all, mouse control needed to be implemented for the paddle, which is in the plane of the screen. Additionally, the "ball" was represented as a triangle fan ("T-fan") whose coordinates needed to be scaled to keep it in proper perspective (a good experience since a similar problem was part of the cancelled MP5). This project exposed us to sound card programming for the first time as well.
Other critical functionality includes being able to detect collisions between the "ball" and objects in the game field, namely walls to the right, left, top, and bottom, as well as the back wall (including individual blocks) and the paddle. Determining ball trajectories based on its position in space is likewise important, since the "ball" must not only rebound off walls in a believable manner, but it should also glance off the paddle at different angles depending on which part of the paddle it struck (ball "English").

Implementation

At the core of the game is the main program which invokes supplemental functions for the graphics engine, sound effects, installing interrupt service routines for the timer/keyboard, ball physics, mouse control, and collision detection.
General program flow is described below, but once keyboard and timer interrupt service routines have been installed, the game must initialize the frame buffer, initialize its mouse input routines, load and decompress PCX files into several segments, and initialize sound hardware.
Gameplay works by iterations. A player begins a game with a certain number of balls, one of which begins its initial trajectory. With each iteration, the main program needs to redraw the background, move the paddle coordinates according to the mouse input, move the ball coordinates according to the direction vector, check to see if a collision has occurred, and, if so, respond accordingly to that collision (changing direction vectors and possibly changing blocks on the back wall). These graphics need to be written to the frame buffer. Sounds need to be sent to the sound card.
If a player tells the program to quit or that he wants to enter in a guess for the picture, the code needs to respond to that request. If the player loses a ball (i.e. its Z-coordinate falls outside the playfield range), the total number of balls remaining should be decremented.
A correct guess of the picture causes a score tally and the game is reset to the next round.

Anticipated Data Structures and Variables

Segments for each graphic and sound file

A scratch segment for loading each PCX file

A 7-byte buffer for functions like BINASC/ASCBIN

A screen or "frame" buffer for writing graphics
This was multiple banks since Super VGA was used.


(paddleX, paddleY), A struct for representing the paddle "position" on the screen and variables for its dimensions (width, height).

Structs representing wall positions

A table for representing the back wall. Each "block" to be hit will have at least a concealing layer and possible sections of a picture. Only one of these is displayed at any one time. The first time a block is hit, the concealing layer should change into another picture portion. The next time the block is hit, that picture should "flip" to reveal part of another picture (this adds to the game's complexity since hitting the same block two or more times can make it harder to guess the subject!). Each block has a position and dimension much like the paddle.

A struct to represent a direction vector for the ball (deltaX, deltaY, deltaZ), most likely in integer math.

A struct to represent the ball itself, which is a tri-fan:

v1-----v2

   v3-----v4------v5

v6-----v7

Each vertex is interconnected--in this case the ball is a hexagon comprised of 7 vertices (adjacent triangles in wheel-shape formation). Each vertex has a position (X, Y, Z), most likely in integer math.

Functions may be implemented with jump tables.

Variables for holding scaling constants will be needed for drawing the ball in perspective, as well as tables for drawing the polygons.

Game Flow Procedure by the Entire Team

• GameMain

• Purpose: This function does the following:

  1. Installs and de-installs keyboard, timer, mouse, and sound handlers.
  2. Displays introductory sequence.
  3. Gets level, category and player information.
  4. Plays background and completion MIDI and .wav sounds.
  5. Loads initial pictures.
  6. Waits for break keys (esc ends game at any time) and mouse click on "guess" button, exiting game and switching to guess mode, respectively.
  7. Turns over portions of the PCX file upon a collision.
  8. Calculates trajectories of ball after detecting collisions.
  9. Matches correct guesses and calls next level.
  10. Returns incorrect guesses to game with score penalty.
  11. Counts number of paddle hits.
  12. Keeps track of paddle position to detect collisions.
  13. Anything else we come across in our final project endeavor!
  

• Inputs:
  • Keyboard inputs and mouse coordinates/clicks
• Outputs:
  • The game Arkapic!

MIDI and .wav Sound Procedures by Dave Booth

• RegisterMIDI

  Purpose This function will register an XMIDI format file by address for playback, using INT 66h (MIDPAK driver). It will also use DOS filehandles to take the file and store it in a specified memory offset
  Inputs:

  AX = 704h
  BX = Offset of XMIDI data
  CX = Segment of XMIDI data
  SI = Low word of length of XMIDI data
  DI = High word of length of XMIDI data
  Outputs:

  AX = 0 Unable to register XMIDI data
  AX = 1 XMIDI registered, held in MIDPAK's buffer
  AX = 2 XMIDI file registered, but keep data at same address
  

• PlayMIDI

• Purpose: This function will play the midi file utilizing the MidPak driver that is suggested for use in the ECE 291 resources web page. Note that the driver installation will be a key part of this function working.
• Inputs:
  • AX = 702h
  • BX = sequence
• Outputs:
  • AX = 1 Sequence is being played
  • AX = 0 Sequence not available

• StopMIDI

• Purpose: This function will stop the file that is being played using the MidPak driver once again.
• Inputs:
  • AX = 705h
• Outputs:
  • None

• SetMIDIVol

• Purpose:This function sets the volume of the MIDI sequence to any volume (1-100%) given to it by the calling function. It is fun to play with, but for the most part just makes sure the volume is all the way up before it plays.
• Inputs:
  • Volume (1-100)
• Outputs:
  • Loud or soft MIDI music

• InitializeDMA

• Purpose: This function will initialize the DMA controller in order to make a transfer across it. Among other things, it will find the page/offset of the controller, write the transfer mode, page number, base address, and count across the port.
• Inputs:
  • None
• Outputs:
  • One fully set-up DMA controller

• ResetDSP

• Purpose: This function uses the macros given in DMASTEP7.asm to reset the DSP.
• Inputs:
  • None
• Outputs:
  • One fully reset DSP

• LoadWav

• Purpose: This function will put a .wav file (the raw data file) and place it into our specified segment of memory so we can access it later. This function will use DOS calls (21h, 3dh) and (21h, 3fh).
• Inputs:
  • Waveoffset - offset of file
• Outputs:
  • File contents in wavseg at offset wavpad

• PlayWav

• Purpose: This function loads the file given to it by offset address into its own segment of memory, then resets the DSP and programs the volume levels. Next it follows a list of DMA initialization procedures: 1) turn off DMA channel 2) clear byte ptr flip flop 3) set mode 4) write page offset 5) write length 6)write page offset 7)Re-enable the channel.
• Inputs:
  • offset of desired sound
• Outputs:
  • Sound plays

• GetBlasterInfo

• Purpose: This function loops through DOS environment variables to get information about the sound blaster (BLASTER). It will retrieve the base address, IRQ #, and DMA channel.
• Inputs:
  • none
• Outputs:
  • Sets BASE_ADDR, SB_IRQ, and DMAChannel

Trajectory Calculation, Initialization, Ball Animation and scaling by Stephen Behling

• InitializeTrajectory

• Purpose: Sets the ball's initial direction vector (called before each round)
• Inputs:
  • NumBalls (Number of remaining balls), TotalBalls (the maximum # of balls)
• Outputs:
  • Sets initial direction vector of ball in memory
• Notes:
  • This function lets us give the player a different starting angle for the ball with each round.
  • The function is called once before each round.
  • The vector is chosen by the number of balls remaining.
  • This function is implemented with a jump table.
  • The vector is stored as a struct in memory.

• InitializeBall

• Purpose:Initializes the ball position (called before each round)
  • Inputs:
    • None
  • Outputs:
    • None

• FindTrajectory

• Purpose: Recalculates the ball trajectory after a collision has been detected (from any surface--walls, back image, paddle).
• Inputs:
  • Wall Surface
• Outputs:
  • Stores new ball trajectory vector to memory
• Reads:
  • Existing ball trajectory and ball vertices
  • Paddle position and dimensions for ball "English"
• Notes:
  • This function is called after every collision.
  • Must recalculate the direction vector depending on which surface the ball collided with.
  • For the paddle, a form of ball "English" is strongly recommended.
  • A ball striking the center of the paddle should rebound at only a slight angle, but a ball striking the side of the paddle should be deflected at a larger angle (this was done in hardware on all early 1970s light-tennis games).

• MoveBall

• Purpose: Animates the movement of the ball by adjusting the ball's position in space according to its current direction vector.
• Inputs:
  • None
• Outputs:
  • Writes new vertex coordinates for the ball to memory
• Reads:
  • Ball vertex coordinates
  • Current Direction Vector
• Notes:
  • Outputs are saved to memory as the new ball position in space.
  • Operations should be applied to EACH vertex of the ball
  • This function is called every game iteration before the ball vertices are adjusted for perspective and drawn.

• ScaleCoordinate

• Purpose: Scales an individual coordinate for drawing triangles in perspective
• Inputs:
  • global 3D coordinates for a single ball vertex, scaling factor
• Outputs:
  • (tempScreenX, tempScreenY) --to be moved to screen coords

• ScaleBall

• Purpose: Scales every ball vertex for screen display
• Inputs:
  • ScaleConstant (screen scaling factor)
• Outputs:
  • Stores new screen ball coordinates to memory

• DrawBall

• Purpose: Draws the ball to the screen using screenball coordinates (scaled into perspective).
• Inputs:
  • None
• Outputs:
  • Invokes Timur's customized DrawTriangle for each polygon

• BackWallCollide

• Purpose: Determines which of the 16 blocks was hit and sets which picture should be displayed
• Inputs:
  • None
• Outputs:
  • Adjusts BlockTable entries to reflect a different image for each of the 16 blocks (4 x 4 grid).

Game Graphics Functions by Slawek Ciapala

VidMode:

• Purpose: Change the video mode
• Inputs:
• Mode #
• Outputs:
• Sets video mode

Putpixel

• Purpose: Displays given color on give location on the screen  i n SVGA mode (640x480  with 256 colors).
• Inputs:
• Color - color of the pixel (one of 256 colors)
• X - coordinate of the pixel on the screen
• Y - coordinate of the pixel on the screen
• Outputs:
• Displays pixel on the screen

DrawBackWall:

• Purpose: Finds the desired image of the back wall cell
• Inputs:
• WhichBlock: Block number from 0 to 15 to uncover  tail that is maped to that number
• WhichSeg: Segment of the tailed picture to be display on the back wall
• Outputs:
• Displays the tails on the screen

DrawBlock:

• Purpose: Rutine that updates the segment with  the uncovered  taisl .
• Inputs:
•  xstart - x coordinate of a tail
•  ystart - y coordinate of the tail
• sourceseg - segmet of the tail
• soroff - offset of the tail
• Outputs:
• Updates the segment that displays the tails on the screen

Film:

• Purpose: Displays the pcx files on th e introduction that make the beginnig of the movie effect
• Inputs:
• pcx files

Output:

Displays pcx on the screen in a smooth motion

DrawPadle:
• Purpose: Rutine that draw the padle on the screen used by mouse the padle is transparent and is 60x40 pixels .
• Inputs:
•  x - x coordinate of a p[addle
•  y - y coordinate of the paddle
• sourceseg - segmet of the tail
• soroff - offset of the tail
• Outputs:
 Displays the Paddle on the screen

LoadSegments:

• Purpose: Loads the segments with pictures in pcx format.
• Inputs:
• address of pcx file
• segments - where where the file will be stored
• offset - where the file begins
• Outputs:
• Stores given pcx file in a given segment

LoadPCX:

• Purpose: Loads and decodes several 320x200 PCX files (fonts, images, cell graphics, etc.) into memory segments and sets VGA palette registers to those used by the images.
• Inputs:
• Destination segment addresses.
• Pointers to null-terminated strings containing the filenames
• Outputs:
• Fills destinations (DestSeg:0) with image data.
• Fills VGA palette registers with image colors
• Uses ScratchPad to hold compressed image data
• Notes:
• Maps 8-bit RGB values to 6-bit RGB by dividing by four.
• Sets VGA Palette using OUT commands to port 03C8h and 03C9h

Input, Interrupts, Custom DrawTriangle and Collision Detection by Timur Karatas

• MousePos

• Purpose: Gets mouse position and button status
• Inputs:
  • None
• Outputs:
  • mouse x-coordinate
  • mouse y-coordinate
  • mouse button status
• Notes:
  • Returned values will be for 320 x 200 VGA screen mode unless Super VGA is used. It will call int 33h function AX = 0003h and AX = 0004h

• InitMouseDriver

• Purpose: Initializes the hardware and software so that the mouse is ready to be used.
• Inputs:
  • None
• Outputs:
  • None
• Notes:
  • It assumes that mouse is installed and has three buttons.
  • Calls int 33h with function AX = 0000h

• CollDet

• Purpose: Checks if a collision has occurred between the ball and side/top walls, pad, back wall). Invokes FindTrajectory for each hit wall.
• Inputs:
  • x-coordinate
  • y-coordinate
  • z-coordinate
• Outputs:
  • BL = 0 : no collision
    = 5 : back wall
    = 7 : a ball was lost
    

• DrawTriangle

• Purpose: Draws a triangle on the screen. This has been modified from the MP4 routine. It supports Super VGA graphics and does NOT implement a Z-buffer (something we had no space for and could not afford a performance hit for).
• Inputs:
  • three screenball (scaled) coordinates
• Outputs:
  • Draws a triangle on the screen using PutPixel

External Routines

This project will borrow some functionality from previous MPs, specifically timer and keyboard interrupt handling similar to that of MP3 and polygon/PCX loading routines resembling those of MP4. The former has been customized, however. Sound routines in part use existing code (e.g. MidPak).