home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / rec / games / programm / 5174 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  1.1 KB
  1. Path: sparky!uunet!paladin.american.edu!howland.reston.ans.net!wupost!crcnis1.unl.edu!moe.ksu.ksu.edu!kuhub.cc.ukans.edu!ozma
  2. From: ozma@kuhub.cc.ukans.edu
  3. Newsgroups: rec.games.programmer
  4. Subject: Re: The Correct Way to Control Game Speed
  5. Message-ID: <1992Dec23.171411.45880@kuhub.cc.ukans.edu>
  6. Date: 23 Dec 92 17:14:11 CST
  7. References: <1992Dec19.190258.15117@midway.uchicago.edu> <1992Dec21.103840.1737@nntp.hut.fi> <1992Dec22.231252.25258@midway.uchicago.edu>
  8. Organization: University of Kansas Academic Computing Services
  9. Lines: 15
  10.  
  11. > }The Time Manager provides drift-free millisecond and microsecond timers
  12. > }and should be much better suited for timing tasks once you learn how to
  13. > }use it.
  14. > 
  15. > I think you're right about TickCount, but by my bet is to go with
  16. > the Vertical Retrace Manager rather than the Time Manager
  17. > for video animation.
  18.  
  19. But then you're saddled with the problem of differing frame rates for different
  20. monitors (since the retrace time will differ as well).  If you have a game
  21. where you can scale the physics to match the frame rate of the monitor, then
  22. your in - otherwise the Time Manager or Ticks are the way to go.
  23.  
  24. john calhoun-
  25.  
  26.