home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / atari / st / tech / 4125 < prev    next >
Encoding:
Text File  |  1992-07-23  |  4.1 KB  |  84 lines
  1. Newsgroups: comp.sys.atari.st.tech
  2. Path: sparky!uunet!haven.umd.edu!wam.umd.edu!dmb
  3. From: dmb@wam.umd.edu (David M. Baggett)
  4. Subject: Re: Is page flipping safe, and I need to know about syncing
  5. Message-ID: <1992Jul23.184657.5699@wam.umd.edu>
  6. Sender: usenet@wam.umd.edu (USENET News system)
  7. Nntp-Posting-Host: rac2.wam.umd.edu
  8. Organization: University of Maryland, College Park
  9. References: <Bruq9M.FI7@acsu.buffalo.edu>
  10. Date: Thu, 23 Jul 1992 18:46:57 GMT
  11. Lines: 71
  12.  
  13. chu@acsu.buffalo.edu (John C. Chu) writes:
  14. >Is it ok to use Setscreen to do double buffered animation (i.e., draw
  15. >on one buffer while the other is being displayed and switch.
  16.  
  17. The Setscreen and Vsync (X)Bios calls work fine for double buffering
  18. (aka "page flipping").  There are some subtleties but for most
  19. practical purposes you'll get good results using these calls and your
  20. code will work with all versions of TOS (including, in theory, those
  21. that are forthcoming).  You want to call Setscreen first and then
  22. Vsync.  It doesn't work to call Vsync and then Setscreen.  Read the
  23. Setscreen docs for an explanation of why.
  24.  
  25. Video cards that have drivers that steal the (X)bios calls should
  26. also work.  I don't know how this translates in the real world though,
  27. since I don't have a special video card.
  28.  
  29. >Also, a little while back, someone (Dave Baggett??) was talking about
  30. >how one should sync one's game to update the screen every n vblanks
  31. >(where n depends on how much is happening in the program), which will
  32. >among other things, insure that the game plays at the same speed
  33. >across variants of ST-type computers. Unfortunately, I wasn't paying
  34. >attention at the time. How do I do this?
  35.  
  36. The scenario: You write a game with sprites, sampled sounds, and maybe
  37. a scrolling window.  Chances are your game isn't going to complete
  38. all of its processing for each "game turn" within 1/60th of second on
  39. a stock 8Mhz ST.  This means that it will take 2 or more vertical
  40. retrace periods to update the screen.  This isn't a problem in terms
  41. of smoothness; most commercial games run at 2, 3, or 4 vertical
  42. retraces per game turn and they look fine.
  43.  
  44. The problem: when you run your game on a faster machine (e.g., a Dave
  45. Small 50Mhz accelerated '030 ST) your game might actually do all its
  46. work within a single vertical retrace period (or at least in fewer
  47. retrace periods than it would on a stock ST).  The result is that
  48. your game runs way too fast.
  49.  
  50. The solution:
  51.  
  52. Instead of syncing to every single vertical blank, write a short
  53. routine that checks the frclock system global and doesn't return
  54. until at least n vertical blanks have passed.  That way if you're
  55. running on a 100 MIPS supercharged ST your game will finish all its
  56. processing for a particular game turn in the blink of an eye and then
  57. just sit there waiting until the given number of vblanks have passed.
  58. If it seems criminal to waste so many cycles I suppose you could
  59. use the extra time to make the enemies more intelligent if you
  60. were careful about it.  Or compute primes, for that matter.  :)
  61.  
  62. You need to tune your game to the minimum number of vertical retrace
  63. periods that the slowest supported machine requires to complete all the
  64. processing for a game turn.  You can do this scientifically by keeping
  65. track of how many vertical blanks are happening per game turn on
  66. average at the most "busy" point in the game, or you can just play it
  67. by ear and pick a high value (6, for example) and then bump it down
  68. stepwise until you see no difference in gameplay from one step to the
  69. next.
  70.  
  71. A concrete example:  HacMan II uses the value 4 here, largely because
  72. the ghosts' "thinking" algorithms are quite slow (relative to the
  73. drawing speeds, at least).  I think Blox runs with 3 vsyncs per game
  74. turn.  In the case of Blox the 11kHz samples slow down a stock ST quite
  75. a bit.  But even if you use DMA stereo sound (which requires no CPU
  76. cycles) the game will still run 3 vsyncs per game turn; hence game play
  77. is totally unaffected by either your choice of CPU or sound D/A device.
  78.  
  79. The frclock system global is documented by Atari and guaranteed not to
  80. change, so you should be safe using it.
  81.  
  82. Dave Baggett
  83. dmb@wam.umd.edu
  84.