Team Members:

Steve Fox - Coder for implementation
Brandon Miller - Graphics
Anshuman Sehrawat - Coder for working with the user
Nick Wroblewski - Little bit of everything

Introduction:

Sample Program of what we will attempt to implement: http://193.151.73.87/games/lemmings/

Our idea is to implement the popular game lemmings done in many flavors of languages across the the years. It will consist of many different levels that contain a starting point where lemmings are dropped out of box, and then walk without purpose to a hopeful goal. Each lemming will have possible functions and jobs which are to be used to get the most lemmings to the end goal.

What the game looks like

Our Loading Screen that Gives you the choice of picking which level or exiting the game. The fourth level
The first level The fifth level
The second level The sixth level
The third level The seventh level

As you can see from the screenshots, only one job button is allowed to be pressed at once. If the pause button is pressed, everything is paused but the job buttons still can be pressed. As jobs are dealt out, the number on the different buttons decreases until 0 is reached in which no more jobs of that type can be used.

Problem Description:

The thing that seperates this project the most from the mp's is of course the complexity of it. More specifically however, would be the updating of the images for each lemming doing any one of the possible jobs going any possible direction. The scale of that alone is a daunting task. With that comes the logic and the numerous types of collision detection that has to be done, which never occured in past mps.

Implementation:

We used bit masking, mmx, image loading, and a lot of game loops and game environment handling to create this game.

The first thing we got to work on was bit masking. Most of our game has to load individual sprites for animation, different jobs, etc. Looking at the example code in the lab manual we were able to implement a few images onto the screen. We used that code to create a procedure in which u could send to it an image and a couple of information pieces and it would load the file and proceed to convert it to 24 bit all at once for convenience sake. Allocating memory became extremely tedious as the game implementation came about, so we created a function that simply was sent a lookup table of images , the size, etc and allocated memory for all of the variables in the look up table. This and the _LoadImages saved an immense amount of repetitive code in the program.

Once the image loading and such was taken care of, next had to come the bit masking code. Using some of the instructions suggested in class, we tried to use mmx instructions to handle multiple pixels at one time. It then occurred to us that wait, we're using 24 bits and not 32 or 16. Since mmx instructions only load dwords and such, we were going to have issues with handling the excess of 2 bytes not needed in the current calculation. So we first tried to simply load two bytes at a time from both the sprite and the buffer we were overwriting. Simply by adding all zeros to the end of the mmx register we could simply use the compare instruction followed by the pandn and the and instructions and viola we would have our overlay. Unfortunately, we forgot that when doing parallel compare, you need to have the words you are looking for to match exactly with the clear color. So we needed to split the two pixels into two double words and then compare them with a generic “clear” color that we created a variable for. So we simply loaded the entire quad word and then stored the last word of the mmx register from the buffer in a register so we don't loose information, put all 0's into the first word, shift the mmx register 8 bits to the left (since in mmx it will load the bytes right to left). This way we will have 00FF FFFF FFFF FF00 and we can simply compare that to our clear color. After doing this we realized that pandn was not working like we had assumed it would, so we then proceeded to use pxor instead which actually worked. Then by por'ing the two registers we could then proceed to set the image into the buffer. Also, we noticed that since we are always accessing two extra bytes as we load the next two pixels that we may have a segmentation fault with accessing memory that wasn't “ours” with the sprites. To solve this, we decided to add 2 to all allocated images so that way when you access the last two pixels of any image, the extra two bytes are allotted for each image.

With the images intact, next we had to work on animation. Animation was kind of tough since we would use two buffers and place one on the screen and then place the second on the screen with the correct next image followed by correct movement, deletion of incorrect pixels of where the sprite was and also keep track accordingly were the lemming is, and where it should go next. Not a simple feat, we might add. To do this we would need the aid of a timer interrupt. Using the code from the lab manual, we installed the timer and allocated the memory, which we attribute to the lab manual, but the actual timer interrupt was modified greatly. The idea in timer was to initially have a timer counter that would keep track of ticks and simply just increment it and be done. To handle this we set up a function call _gameLoop that at first waited for the just the ticks to send the appropriate buffer to the screen. First we got the lemmings to just walk by individually moving a pixel and filling behind the lemming all 0's in its place (all zeros is black as was the color of the background). Once that was working, we had to start implementing the game design.

The game design was developed behind two things: Strucs, a Level_Array, and an environment around a lemming. A lemming was basically a struc object that we used to create all the individual things a lemming needs to know “about itself”. As in its current position, its old position, its image, the count of its image, its job, activejob, etc, (look at our website for details), were just a few of the things that a lemming would need to be handled by the functions created to manipulate them. To create a lemming, we created a procedure _createLemming which was sent and x and y coordinates. It first allocated memory, put the location to the bottom of the Lemming_Array, and then initialized all of the lemmings inner variables to what they needed, its job, position, etc to start running. After lemmings were created we needed a way to keep track of their environment, so _getEnvironment was born.

Now comes the fun, we mean really crazy part of our game, to handle multiple objects at one time while keeping the game running and accessing multiple possible jobs. This was very hard to do because in order to do that you have to have an array created of what is in the level. So we had to make a method of loading all the bytes of an image into an array that contains the description of whether this pixel is empty, a wall, ground, etc. With that we could start placing the lemmings into the environment and start handling lemming movements. First we enacted walking, which was very basic, you just check if to the right, left and ground. Falling and walking were not too hard to implement. The issues came up as to when to check position and when to look at the environment followed by when you should update the lemmings' size. Unfortunately some of the lemming images were different sizes than others which made manipulating them and still checking the Level_Array extremely difficult. Making the walker, faller, and floater were not too hard. Digger took a little bit of time, but since there is only one direction to worry about modifying, down. When it came time for basher, miner, and climber, we ran into major set backs. Basher we had to figure out how to make the lemming delete to the right of the lemming, or to the left depending which direction it was going. Basher which should have been very straightforward created the most issues because of the way that it kept not doing what it was supposed to. At first we had it bash through a wall, but the issue was then that the lemming wouldn't clear out the last column of the array, and same with the first one. We played around with that so much that we eventually said, hell, if we can't delete one row, why not be safe and just simply take the entire space the lemming is in currently and just move empty into them. That worked after a lot, and we mean a lot of dumb bugs. What was worse is that as soon as we tried something, we sometimes would find something else that wasn't correct, and that could have been the reason that the object wasn't doing what it was supposed to.

Due to time constraints, we made miner really simple. Basher took forever, so we didn't want to take too much time in doing it, so one of our guys devised a way to “calculate” what the miner would do by clearing out the path that it would have taken. As in make a diagonal clearing space from the bottom right corner of the lemming. Not exactly how we would have liked to do it, but something is better than nothing. So now the lemming could bash left and right, mine left and right, and dig. Builder was made to simulate the direction it would take, as in move diagonally, but doesn't add “steps” to the _Level. That would have been nuts. Because we would have to detect that special block and on top of that make them move diagonally.

Another thing that we had to adapt was the positiong offsets around the lemming. At first we had a topleft, top, right, bottomright, bottom, bottomleft, left, which were the pixels just outside of the lemming. Since we had falling check for the middle of the lemming, it would then proceed to fall when it was halfway off the edge, not when it had actually walked off the edge. To help this we added four more offsets to the lemming: topr, topl, bottoml, bottomr. These were specifically the pixels to the left and right of the outside corners of the lemming. So when we walked left we could check bottomr for empty, and vice versa for walking right.

On the flip side, some of the guys in our group heavily worked on the button/job selection. That was a completely separate part of the project. The handling here was to use the mouse interrupt to select a button on the bottom, change its picture and of course handle making a lemming receive that specific job it handles. _FindLemming is a function that given a specific mouseX, mouseY looks through the entire _Leming_Array and checks to see if the x and y coordinates are within the lemmings width and height. If it was, then it would give the lemming the job that had been selected. We also had to implement counters for the Lemming buttons. As in you are only allowed to give a number of lemmings a specific job.

While working on our final project, we learned that you have to depend on other people to complete the task at hand and help motivate others in doing so. There is definitely no way this could have been completed without the group because there was simply too much work that had to be done. The benefit received from being in a group gave a sense of pride and teamwork during the course of this final project.

Our final piece wasn't as quite as ironed out as we had hoped, but it was pretty much left as a very much well playable game. In retrospect, our choice of project might have been a bit too difficult of a task to complete in the allocated time, but we feel we still learned enough and got plenty accomplished to have a robust working game.

There will be two counters running in the background, one will stand for the amount of lemmings left on the screen as to know when to check if the player won or lost and will decrement by 1 when a lemming dies, becomes a blocker (they are unusable), or gets to the goal. The second counter will increment to respresent the number of lemmings that have completed the course, and will be used to check if the user has won or lost.

A check function for making the active struct object 0 or 1 in the lemming array for each lemming based on the current job.

Struct Lemming
created to keep track of each lemming in the game. has essential data for each specific lemming to allow us to simply create an array of strucs and therefore simply access a lemming by access the data inside the struc
 Environment Objects – All possible objects in the game that are given a specific number in an array, which gets turned into graphics based on the value.

.index resb 1 ;number lemming was created
.direction resb 1 ; 0 =right 1=left
.job resb 1 ;what job it currently has and is doing
.activeJob resb 1 ;what job it has been assigned to such as DIG or BLOCK,etc
.active resb 1 ;signals its activeJob has been activated (0=not active, 1=active)
.killed resb 1 ;flag that a lemming has been killed and sends lemming to _kill_Lemming
.fallCount resw 1 ;number of pixels lemmign has currently fallen to tell if it should die
.imgCount resb 1 ;counter for images of the current job so as to loop through the images created for animation
.currentX resd 1 ;this is the "currentX" position before a new position has been created
.currentY resd 1 ;this is the "currentY" position before a new position has been created
.nextX resd 1 ;this is the nextX position for the lemming to be put into the _ScreenBuffer
.nextY resd 1 ;this is the nextY position for the lemming to be put into the _ScreenBuffer
.img resd 1 ;this is the lemmings job image currently loaded into memory
.img_count resd 1 ;this count is the curent counter image stored if the lemming is a bomb
;these next three are used to remove lemmings from the buffers
;old widht, height and width*3, which is useful when the lemming changes size
.oldwidth resd 1
.oldwidth3 resd 1
.oldheight resd 1

  • the curent lemming width in pixels
    .width resd 1
    .width3 resd 1
    .height resd 1
  • some jobs are slower than others therefore we have counter to slow down the lemmings movement and image rotation
    .slowcount resb 1 ;for slower images
    .newjobselected resb 1 ;used for button management to keep track of if a button counter should be decreased
    .newjob resb 1
    .isBomb resb 1 ;flag, when 1 means has been activated as a bomb
    .myCounter resb 1 ;counter for when the lemmings becomes a bomb
    .count_slow resb 1 ;when a lemming is a bomb, this will delay the counter to slow down bomb action time
    .slab_count resb 1 ;counter for number of slabs a builder has put down (actually simply a timer)

    .topleft resd 1 ;A index of the top left pixel of leming, one pixel row above and one pixel column to left
    .topl resd 1 ;B index of the top left pixel of lemming, one row above
    .top resd 1 ;C middle of lemming one row above lemming
    .topr resd 1 ;D index of the top right pixel of lemming, one pixel row above
    .topright resd 1 ;E index of the top right pixel of lemming, one pixel row above and one pixel column to right
    .right resd 1 ;F ;index of center of lemming height, one pixel column to right of lemming
    .bottomright resd 1 ;G index of the bottom right pixel of lemming, one pixel row below and one pixel columng to the right
    .bottomr resd 1 ;H index of the bottom right pizel of lemming, one pixel row below lemming
    .bottom resd 1 ;I index of the middle bottom of lemming, one row below
    .bottoml resd 1 ;J ;index of bottom left, one pixel below the bottom of the lemming
    .bottomleft resd 1 ;K index of the bottom left pixel of lmeming, one pixel row below and one pixel column to the left
    .left resd 1 ;L ;index of center of lemming height, one pixel column to left of lemming
    .pos resd 1 ;M ;keeps actual index off of the _Level_Array of the top left corner of lemming
  1. FreeSpace.
  2. Walls
  3. Fire
  4. Lemming Blocker
  5. Start Door
  6. End Door
  7. Lemming
  8. Buildign Slabs/Blocks
  9. Dug hole
  10. Ground
  11. Border Climber
  12. Bashed ground
  13. Mined ground left
  14. Mined ground right
  15. Mined tunnel left
  16. Mined tunnel right
  17. Timer for the Bomb
  18. Bashed left
  19. Bashed right
To handle each level a dataset must be created
  • to load levels, we need to make an array of the level objects bytes in memory for handling lemmings behind the scenes
    therefore we created an array thta has a byte for every pixel on our screen
  • in each byte will be a constant that represents a specific type of object (GROUND,WALL,EMPTY)
    inorder to do this we decided to let the computer do the tediousness of the task
  • each level has specific types of rows (nothing rows, rows w/ random grounds empties etc
  • in _Load_Level "X" there will be aloop, and the first number implies how many pixels to in the row, left to right
    should be the second constant in _Level_Array.
  • the loop keeps handling this until the first number in each list is a zero(aka all are zero terminated
  

Lemming's Jobs Procedure and Algorithms (Screenshots taken from Source Game)

Miner

Becomes Active:
Left Direction: If Bottom Left is ground and not Border and Bottom environmental object is ground or dug hole or mined ground right or mined tunnel right.
Right Direction: If Bottom Right is ground and not Border and Bottom environmental object is ground or dug hole or mined ground left or mined tunnel left.
Becomes Deactive:
Left Direction: If Bottom environmental object is not ground or is Border.
Right Direction: If Bottom environmental object is not ground or is Border.

 Floater

Becomes Active:
Check Bottom environment object for not ground or not dug ground.
Becomes Deactive:
Check Bottom environment object for ground or dug ground or mined ground or water or fire.

Blocker

Becomes Active:
If mouse clicked and Bottom environment object is ground or dug ground or bashed ground or mined ground or mined ground or mind tunnel.
Becomes Deactive:
If Left or Right environment object is a lemming with a job of a bomber with a counter set to 0.

Climber

Becomes Active:
Left Direction: Check Left environment object is a wall.
Right Direction: Check Right environment object is a wall.
Becomes Deactive:
Left Direction: Top Left environment object is not a wall or not a Lemmings Blocker and Top environment object is FreeSpace.
Right Direction: Top Right environment object is not a wall or not a Lemmings Blocker and Top environment object is FreeSpace.

Bomber

Becomes Active:
When mouse clicked (graphics also get displayed for timer Bomb)
Becomes Deactive:
When bomber timer count gets to 0, also sets killed status to 1 (timer bomb graphics get sets to free space environment object).

Builder

Becomes Active:
On mouse clicked.
Becomes Deactive:
Left Direction: When Top Left and Top environment ojbet is a building slab/block or a wall or # of slabs left to build is 0.
Right Direction: When Top Right and Top environment object is a building slab/block or a wall or # of slabs left tot build is 0.

Basher

Becomes Active:
Left Direction: If Left environment object is a wall at instantaneous mouse click.
Right Direction: If Right environment object is a wall at instantaneous mouse click.
Becomes Deactive:
Left Direction: If Left environment object is a freespace or border.
Right Direction: If Right environment object is a freespace or border.

Digger

Becomes Active:
On mouse click if the Bottom environment object is a ground or dug ground or mind ground or mind tunnel.
Becomes Deactive:
If Bottom environment object is a border or free space.

Procedures:

_updateinitialbuttonsimages
  • Author: Anshuman Sehrawat
  • Purpose : Invokes _updateButtonsBuffer procedure to send offset of appropriate buttons to the screen buffer
  • Invokes : _updateButtonsBuffer
  • Notes : Allows the initial buttons in there released condition to be set in the buffer.
_Start
  • Author: Steve Fox
  • Purpose : Sets the starting image and waits for amouse click then starts game implementation
  • Invokes : _CopyToScreen
  • Modifies: _update, _mouseState, _startflag, doneflag
_updateinitiallevelimages
  • Author: Anshuman Sehrawat
  • Purpose : Loads the initial image of a specific level to the screen
  • Invoke : _LoadImage
  • Modifies: _level_selected
_pick_level
  • Author: Anshuman Sehrawat
  • Purpose : Based on the mouse click, the appropriate environment for a specific level is called upon to be loaded
  • Calls : _Load_Level_1, _Load_Level_2,_Load_Level_3,_Load_Level_4,_Load_Level_5,_Load_Level_6,_Load_Level_7
  • Modifies: _level_selected
_game_over
  • Author: Steve Fox
  • Purpose : sends to the screen the game_over screen when the game exits
  • Invokes : _CopyToScreen
  • Modifies: _update
_game_loop
  • Author: Steve Fox
  • Purpose : Basic loop in game which waits for timercount to get to specific value to invoke the copy
    _CopytoScreen command and show the buffer
  • Invokes : _createLemming, _updateLemming, _toScreen, _updateBuffer
  • Modifies: create_anew_lemming, _update, _mouseState, buffer, timercount
  • Notes : Loop to create lemmings as well as update lemmings location based on certain flags and sending different buffers to screen.
_updateBuffer
  • Author: Steve Fox
  • Purpose : takes the buffer sent to it, clears all its lemmings objects and draws into it the next timed images of the lemmings
  • Inputs : offset of buffer to take in
  • Invokes : _toBuffer, _setNext_Position
  • Modifies: Lemming objects in the lemming struct
  • Notes : Loops through all the lemmings in _Lemming_Array
_setNext_Position
  • Author: Steve Fox
  • Purpose : takes as an input an lemming struc and procedes to mov into the lemming's nextX,nextY, currentX+directionX, currentY+directionY
  • Inputs : Lemmings struct
  • Invokes : _kill_Lemming, _checkMovement, _getEnvironment
  • Calls : _bomb_count_draw
  • Modifies: Lemming objects in the lemming struct
_manipulateEnvironment
  • Author: Steve Fox
  • send a lemming to it, and it will manipulate the environment around it
  • if it is a miner, builder,or a basher (and maybe digger)
  • Purpose : manipulates the environment of the lemmings array depending on what job is selected
  • Notes : doesn't implement building....
_bomb_count_draw
  • Author: Steve Fox
  • implements when a lemming becomes a bomb and draws a counter to thee screen
  • Purpose : when a lemmings becomes a bomb, handles how to count and when to make a lemming a BOMB_JOB and blow it up
  • Modifies: lemming struct,
  • Notes : is called by man
_kill_Lemming
  • Author: Steve Fox
  • takes given lemmings and moves all lemmings in array up by one accordingly to which were after the deleted lemming
_checkMovement
  • Author: Steve Fox
  • Purpose: send a lemming to this and it will take its "next" environment and check to make sure that it can move inits current direction and alters the lemmings direction, job, and/or images needed to change movement in comparison to the level_array
  • Calls : set_builder,set_walking,set_falling,set_blocking,set_builder,set_basher,set_miner,set_digger
  • Manipulates: the lemming structs to their positions
  • Note : uses information set by _getEnvironmetn and _LEvel_Array
_set_miner
  • Author: Steve Fox
  • Purpose: Utility function used by checkMovement. It takes current job/width height and makes into builder
  • Notes: dl=> 0->right, 1->left
_set_builder
  • Author: Steve Fox
  • utility function used by checkMovement ->takes current job/width height and makes into builder
  • dl=> 0->right
  • 1->left
_set_basher
  • Author: Steve Fox
  • utility function used by checkMovement ->takes current job/width height and makes into basher
  • dl=> 0->right
  • 1->left
_set_climber
  • Author: Steve Fox
  • utility function used by checkMovement ->takes current job/width height and makes into climber
  • dl=> 0->right
  • 1->left
_set_blocker
  • Author: Steve Fox
  • utility function used by checkMovement ->takes current job/width height and makes into blocker
_set_digger
  • Author: Steve Fox
  • utility function used by checkMovement ->takes current job/width height and makes into digger
_set_falling
  • Author: Steve Fox
  • utility function used by checkMovement ->takes current job/width height and makes into falling
  • dl=> 0->right
  • 1->left
_set_walking
  • Author: Steve Fox
  • utility function used by checkMovement ->takes current job/width height and makes into walking
  • dl=> 0->right
  • 1->left
_set_old_dimensions
  • Author: Steve Fox
  • utility function used by checkMovement. ->is supposed to make the previous width and height available to overwrite the image on the screen (doesn't quite work yet)
  • note: ebx MUST be a lemming struct
_getEnvironment
  • Author: Steve Fox
  • Purpose: Send a lemming and the level array it is in currently it will set all of its position indexes
  • Inputs: Offset of a Lemming
  • Modifies: Lemming Struct
_createLemming
  • Author: Steve Fox
  • Purpose: creates a Lemming struct object and appens itto _lemming_array at pos x,y as inputed
_InstallMouse
  • Author: came from lab manual
  • Purpose : installs our isr, or mousecall back into the real mode accessed vector table which is pointed to by _mouseOff and _mouseSeg using funciton 0Ch stored in ax of int 33
  • Reads : - _mouseOff,_mouseSeg
  • style : procedure
  • Modifies: DPMI_EAX,DPMI_ECX, DPMI_ES
  • invokes : _LockArea, _Get_RMCB
  • Calls : _DPMI_Int
  • Notes : LEFT_BUTTON |RIGHT_BUTTON|MIDDLE_BUTTON set the mouse callBack to look for those specific bits
_RemoveMouse
  • Author: came from lab manual
  • Purpose : calls function 0Ch of int 33 with reset values to reset the mouse interupt
  • style : procedure
  • Modifies: DPMI_EAX, DPMI_EXC, DPMI_EDX, DPMI_ES
  • Invokes : _Free_RMCB
  • Calls : DPMI_Int
_MouseCallback
  • Author: Steve Fox
  • Purpose : when the mouse interrupt executes this code handles what the mouse inputs are
  • Reads : - _mouseState, .DPMIRegsPtr, DPMI_ECX_off, DPMI_EDX_off, DPMI_EAX_off
  • style : protected procedure
  • Modifies: _mouseState, _mouseX, _mouseY
  • Calls : None
  • Notes : DPMI_ECX contains _mouseX, DPMI_EDX contains _mouseY, and DPMI_EAX contains _mouseState
_Allocate_Job_Images
  • Author: Steve Fox
  • Purpose : send the number of images, the lookup table, and the number of bytes needed
  • Reads : - _mouseState, .DPMIRegsPtr, DPMI_ECX_off, DPMI_EDX_off, DPMI_EAX_off
  • style : protected procedure
  • Modifies: .job_img
  • Calls : _AllocMem
_LoadImage
  • Author: Steve Fox
  • Purpose: Takes as inputs filename, where is it to be stored, size of image( pixel wise)
  • Invokes: _LoadPNG
  • Inputs: FileName, ConvertOffset, and Pixel Size
  • Outputs: Loads the png into ImageOffset, converts from 32 to 24 bit color and stores it into the given memory location to store it
_toScreen
  • Author: Steve Fox
  • Purpose: send image offset, width of the image, height of image and the x,y coords
  • Invokes: _CopyToScreen
  • Output: sets the image to the screen
_toBuffer
  • Author: Steve Fox
  • input: send image offset, width, height, xCoord,yCoord
  • output: image is layed into memory buffer at xCoord and yCoord
  • note: will use image overlay to eliminate backgrounds on
_installTimer
  • Author: came from lab manual
  • Purpose : intsalls the timer interupt
  • invokes : _LockArea, and _Install_Int
_UpdateButtons
  • Author: Anshuman Sehrawat
  • Purpose: Updates the screen buffer for buttons when they are pressed or released
  • Modifies: _ButtonsPressed1, _ButtonsPressed2, _ButtonsPressed3
  • Invokes: _updateButtonsBuffer
_update_num_count
  • Author: Anshuman Sehrawat
  • Purpose: Updates the number of specific tasks based on the button that are available for the Lemming
  • Inputs: Current Number based on the specific button
  • Outputs: Updates the value of the offset that was passed as input.
_updateButtonsBuffer
  • Author: Anshuman Sehrawat
  • Purpose: Based on the number available of a specific button, it updates the button buttons in buffers accordingly.
  • Invokes: _toBuffer
  • Inputs: X and Y Location for the image to be sent to the buffer, image offset, and button number for a given type of button
_FindLemming
  • Author: Anshuman Sehrawat
  • Purpose: See if mouse click has selected an image and accordingly update the job of the lemming
  • Invokes: _updateNumCount, _updateButtonsBuffer
  • Modifies: Lemming.active, Lemming.activeJob
_updateLemming
  • Author: Steve Fox
  • Purpose : When the _update flag has been raised by a mouse click, it sends the x,y of the mouse click to this function and then proceeds to find a lemming and modifies it.
  • Inputs : X and Y Location for Lemming
_Allocate_All
  • Author: Steve Fox
  • Purpose : One massive function to allovate all the memory needed
  • Invokes : _AllocMem, _Allocate_Job_Images
_Load_All
  • Author: Steve Fox
  • Purpose : One massive function to load all the images based on the buffer offset
  • Invokes : _LoadImage
_Load_Level_*
  • Author: Nick Wroblewski
  • Replace the * with 1-7 for the 7 levels, no reason to put all of them here
  • Purpose : To update the Level Array with items in the current environment for Level *
  • Calls : .loop_top
  • Modifies: _Level_Array

 

Image Processing:
-need to make the .png files and lots of them
-create a queue of image files to load for each lemming and objects in the environment that are modified by lemmings. The queue will help maintain fluidity of image handling.

Environmental Updating:
-with timer interrupt every time the clock rises, we need to signal for an update of all the environmental objects as in the lemmings need to be updated in next and current position and check all job specifications.

Mouse Interrupts:
Screen is broken up into three sections:
-the button bar at the bottom of the screen
-The info bar above that
-The lemmings environment above

The button bar consists of buttons that will simply be specific regions of space that the mouse can click on. These buttons will be the “jobs” that you can specify lemmings to do. Also there is a pause button, a nuke button (which kills all remaining lemmings on the screen) and a speed up button.

The info bar consists of a timer clock counting down which is the allotted amount of time for the level. Also contains a space that when you click on a button it describes what the button does. The bar will also tell you how many lemmings are out, how many lemmings you have in general, how many lemmings are “in”, and how many lemmings you have to save to pass the level.

The main screen will have a cursor for the mouse that when you have selected a job and you hover over a lemming, it changes to a aiming cursor to indicate which lemming you are hovering over. Also when you click on a lemming the screen space will be broken up into designated blocks depending on the size of the images for lemmings. As in it will select the closest lemming to where you click.

Look up Table - It will contain each job which will call about 4 .gif combos which will rotate the .gifs to simulate animation, whether it's a job or just walking. One "function" for every possible job. Each lemming will be a jpg with a clear background so it can be placed anywhere and easily moved around. GIFs have

Finish - after an execution this will be called to check the counters mentioned in implementation, to see if the user has won or lost or neither.

Start - Will be called and will continuiously be throwing out a lemming until the counter reaches the total

Background - some sort image map representing the background and that can be altered when digging or building is done.

Mouse controls - this will be a pretty large job, with things that have to be clicked for the job types as well clicking the actual lemming to make them that job. We will have to keep track of the location on the screen where the cursor is to check what is clicked. It will most likely be a block of pixels that is checked and represent the location of the cursor.

Timer - Require a timer interrupt for updating movements, graphics, and values in arrays.

 

External Routines:

_installMouse, _removeMouse, and _installTimer