other bits of interesting code, handle_pad_idle() which handles when player motion stops:
Code: Select all
/**
* handle_pad_idle()
*/
void handle_pad_idle(void)
{
// Change to idle state if pad is idle.
switch(stamps[STAMP_LAST_STATE(i)])
{
case STATE_PLAYER_RIGHT:
stamps[STAMP_STATE(i)]=STATE_PLAYER_RIGHT_IDLE;
break;
case STATE_PLAYER_LEFT:
stamps[STAMP_STATE(i)]=STATE_PLAYER_LEFT_IDLE;
break;
case STATE_PLAYER_UP:
stamps[STAMP_STATE(i)]=STATE_PLAYER_UP_IDLE;
break;
case STATE_PLAYER_DOWN:
stamps[STAMP_STATE(i)]=STATE_PLAYER_DOWN_IDLE;
break;
}
}
and handle_player_in_box():
Code: Select all
/**
* handle_player_in_box()
* Handle when player is in box.
*/
void handle_player_in_box(void)
{
if (stamps[STAMP_XTRA_A(i)]>0)
{
if (stamps[STAMP_XTRA_B(i)] != 0)
{
stamps[STAMP_XTRA_A(i)]=0;
}
else
{
stamps[STAMP_Y(i)]=PIXEL_BOX_Y(6)-1; // 6 is the Y for the box.
if (sec==0) // 0 means approximately 1 second elapsed.
stamps[STAMP_XTRA_A(i)]--; // Decrement timer
}
}
else
{
stamps[STAMP_Y(i)]=PIXEL_BOX_Y(5); // Pop out of box.
if (i==0)
{
yellow_door_state=CLOSED;
}
else
{
blue_door_state=CLOSED;
}
}
}
sec is a variable that simply counts from 49 to 0 (I am using shiru's drop-frame consistent PAL tick rate).
get_current_box() is a function that sets a quad of variables, a,b,c,d:
Code: Select all
/**
* get_current_box()
* Get the current dungeon box for player
* i = the stamp to return in a,b,c,d
* a = the X box
* b = the Y box
* c = the dungeon box #
* d = the box data.
*/
void get_current_box(void)
{
a=div24(stamps[STAMP_X(i)]+8);
b=div24(stamps[STAMP_Y(i)]+8);
c=(b*10)+a; // C is now the box #
d=dungeon[c];
score1[0]=div24(stamps[STAMP_X(0)]+8)+1;
score1[1]=div24(stamps[STAMP_Y(0)]+8)+1;
}
These are then used for collision detection. Since the whole maze is on a grid, and everything is bound to move along that grid, full bounding box collision detection is unnecessary for traversing the maze. (player to player/enemy detection will be another story)
I will also change the move_monsters() code to utilize the same code (with the exception that directions will be picked randomly), so that monster movement isn't so pedestrian. (Right now, monster movement is very rank and file).
It will also make computer AI easier, as all it needs to do is pick the closest monster, and attempt a straight line to it, while shooting when it's in the same lateral position on the grid.
Yes, I KNOW this code is really weird. I've never written C code that uses this many globals or goto's (and I've written CODECs!)... but you can't really write clean C code for a 6502 and have it fit or be somewhat efficient.
-Thom