home *** CD-ROM | disk | FTP | other *** search
/ Amiga Format 39 / af039a.adf / month2.doc < prev    next >
Encoding:
Text File  |  1992-09-17  |  7.3 KB  |  136 lines
  1. ********************************************************************************
  2. *                   oo                              oo                           *
  3. *                 \(  )/      Bullfrog Demo      \(  )/                           *
  4. *                 ^ ^^ ^         Month 2         ^ ^^ ^                           *
  5. *                  All code and text by Scott Johnston                           *
  6. ********************************************************************************
  7.  
  8. Welcome back.  If you managed to follow last months article then well done.  If
  9. not go back and do so.  This month we will tie the movement of our sprite into
  10. the joystick.  If you run demo then you will find that the man now runs left
  11. and right with momentum.  The exit key has changed to Q because when escape was
  12. pressed you got the repeat of your last input.  The program work?  Great.  
  13. Your going make him run up and down the screen as well.
  14.  
  15. If you look inside of move.s you will notice a couple of new things.  At the top
  16. of the file is a small list of equates.  These are used to control the graphics
  17. for our man and the speed at which he accelerates and moves.  Try changing the 
  18. two equates for the speeds.  The man should move differently depending on the
  19. numbers you put in.  If you change the animation equates the man could start
  20. doing strange things.  Another example of equates can be found in draw.s on
  21. the two asr.w lines, with the word FOUR.  Much easier to understand than placing
  22. a 2 on the line.  Anyway back to move.s.
  23.  
  24. After this we have the subroutine _move_all.  Last month we placed all our code
  25. here, but this month we will place our code into new subroutines which _move_all
  26. calls.
  27.  
  28. Our man now has 5 variables.  These are as follows:-
  29.  
  30.     man_x        where abouts he is horizontally on the screen.
  31.     man_y        where abouts he is vertically on the screen.
  32.     man_vx        the speed and direction in which he is travelling horizontally.
  33.     man_vy        the speed and direction in which he is travelling vertically.
  34.     man_frame    the current frame of animation that is displayed.
  35.  
  36. Inside the first of our new routines _man_x is the code to read the joystick,
  37. and move the man left and right.  Study this.  Now if you copy this and place it
  38. into _man_y, change the variable names to their Y counterparts and the change
  39. the lines
  40.  
  41.         cmp.w    #300*4,d1    to    cmp.w    #176*4,d1
  42. and        move.w    #300*4,d1    to    move.w    #176*4,d1
  43. and place an  asr.w    #FOUR,d1 into draw.s at line 14.
  44.  
  45.  
  46. We should, fingers crossed, have momentum on the Y axis.  Try it.  Did it work?
  47. If not go back and study the code some more.  You probably made a small mistake
  48. some where along the line.  Right, now change the names of the dotlabels, those
  49. that start with '.', to what they are actually doing.  Good, now did you under-
  50. stand that code, if so that see if you can change it so that instead of the man
  51. stopping when he reaches the edge of the screen, he bounces off.  Basically you
  52. change four commands from a move.w to a neg.w.
  53.  
  54. If you did not understand it, never fear because I will now try and explain what
  55. it is doing.
  56.  
  57. To start with we pick up the velocity of the man, and the direction in which
  58. the joystick is being moved.  The joystick will be a 1 if the joystick is going
  59. right, 0 if it not moving and -1 if it is going left.  We then multiply the
  60. joystick direction by the acceleration and add it to our current velocity.  Now
  61. the velocity needs to be checked to make sure that we are not going faster than
  62. we want in either direction.  I start off by checking in the right direction,
  63. and if it is scale it down to the maximum speed.  Then check off the other side
  64. and again scale it down if we need to.  Ok thats the velocity just about done.
  65.  
  66. We now get our current x position and add the velocity to it.  Check the new
  67. x position with the left hand side of the screen, and if we have gone off then
  68. move us back onto the screen and stop the velocity.  Test the other side of the
  69. screen, and again stop the velocity and move us back on if we have gone off.
  70.  
  71. The final piece of code we have in this routine is the slow down.  This checks 
  72. to see if we are moving the joystick, if we are then we dont want to slow the
  73. man down.  After this we find out in which direction we are moving.  If we are
  74. going left we want to increase our velocity to slow it down.  Sounds strange but
  75. the maximum left speed is in fact -16, or whatever you change MAX_SPEED to.  If
  76. we are going right we want to decrease our speed.  The reason we subtract 2 then
  77. add a 1 to our velocity is so that we dont have to branch past the going left
  78. section.
  79.  
  80. Follow that OK.  Wade through the code in _man_anim and see if you can work out
  81. what is going on.
  82.  
  83. You will have noticed that there are loads of other files which we never really
  84. touch.  The only ones we have used so far are move.s demo.s and draw.s.  If you
  85. have looked at demo.s then you will see that loads of things are included from
  86. here.  Most of these files are for various set ups, ie read the joystick.  Other
  87. are called from various places inside our code, for example the sprite draw
  88. section.  One of the more important of these files is display.s.
  89.  
  90. If you have a look inside of display then you will see the main loop of our
  91. program.  It starts off by waiting for the vbi.  The vbi, or vertical blank
  92. interrupt, happens every 50th of a second, and is the time in which the video
  93. beam is travelling from the bottom of the screen, back upto the top.
  94.  
  95. We then clear the screen, this is so we dont have the previous screen display
  96. at the same time.  Clearing the screen is not always the quickest way of
  97. doing things, for example you could remove the sprites, and then redraw them.
  98.  
  99. Draw all calls the routines inside of draw.s, and this is where we draw every
  100. thing, the man the blocks the objects, everything.
  101.  
  102. We then swap the screens.  We are using a system called double buffering.  This
  103. is where we see one thing on the screen, whilst we are drawing the next scene
  104. on another screen.  The screens then swap places, and we draw the next scene
  105. (scene 3) on the first screen.  Swap places again and so on.  This prevents
  106. the graphics from flickering when they are drawen.
  107.  
  108. We then go on to the movement routines, and here we move everything, advance
  109. the animation counters, detect for collision, can kill off the hero if we can.
  110.  
  111. Check for a key press, if it hasnt been pressed, then loop around and do it all
  112. over again.   Otherwise exit from here, turn everything back to normal, and
  113. terminate the program.
  114.  
  115. Thats just about it for this month.  Next month we will start to make our small
  116. program into a platform game.  This includes the need for gravity.  See if you
  117. can change the routine for man_y so that gravity plays a part.  Good Luck.
  118.  
  119. The Animation of the Man.
  120.  
  121. We what the man to look like he is actually going the way he is facing.  There
  122. are several ways in which we can do this.  The way I have done this to pick up
  123. the current frame of our man.  Then have a look at the mans velocity, if this
  124. is a zero that means our man is not moving, therefore we want to display the 
  125. man facing towards the screen.  If on the other hand the number was negative
  126. then the man is running to the left.  We have four four frames of animation
  127. for our man in both directions, so we need to check that the current frame
  128. does not exceed the allowed frames, or that if it does we set it back to an
  129. allowed frame.
  130.  
  131. New Commands
  132.  
  133. Neg.w    d0.
  134. This reverses all the bits in d0.  This is very helpful when you wish to change
  135. the signs of numbers.  For example 5 becomes -5, and -9 will become 9.
  136.