home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / amiga / programm / 17517 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.6 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!tulane!agwbbs!Paul_Trauth
  2. From: Paul_Trauth@agwbbs.new-orleans.LA.US (Paul Trauth)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Game timing
  5. Distribution: world
  6. Message-ID: <Paul_Trauth.1a52@agwbbs.new-orleans.LA.US>
  7. Date: 18 Dec 92 02:30:18 CST
  8. Organization: The Amiga GateWay BBS * New Orleans, La.
  9. Lines: 47
  10.  
  11. In a message dated Thu 17 Dec 92 11:28, Fkpec@westminster.ac.uk (liaket Ali
  12. wrote:
  13.  
  14.  FA> A question (hypothetical) related to Game timing...
  15.  
  16.  FA> I have an AMIGA 500 and will soon be getting a 1200 which is a faster
  17.  FA> computer.
  18.  FA> The game that I'm currently writing runs at 10 frames per second on
  19.  FA> the A500.
  20.  FA> However, I would like the game to run at 20fps on the A1200 but be
  21.  FA> smoother.
  22.  FA> This means that it will not zoom past at twice the speed but instead
  23.  FA> will increment the display view by half increments.
  24.  
  25. Hmmm, i'd hate to be your artist if it's not a 3d game: "What?!? You want
  26. me to inbetween EVERY SINGLE FRAME?!?"
  27.  
  28.  FA> For example, consider a flight simulator which, say, updates 10
  29.  FA> pixels in 1 frame in order to achieve a frame rate of 10fps.
  30.  FA> I would like to be able to then update 5 pixels in 1 frame to achive
  31.  FA> 20fps.
  32.  
  33.  FA> Is this possible? And how would I go about programming it.
  34.  
  35. 2 ideas:
  36. 1. if cpu>=[your definition of a really gnarly system] then halve all your
  37. deltas (that is, reduce the amount everything moves per frame)
  38. 2. seperate into two threads. one thread handles the game logic and moves
  39. everything about, in the simplest form possible (say, an XYZ point and a
  40. vector or two); the other thread samples the first thread's output as fast
  41. as it can, and renders the frame. (this way, you could possibly always get
  42. the maximum framerate possible for the amount of stuff you're throwing
  43. around at the moment. as things got more complex, the framerate would slow
  44. down, but the objects would still be moving at the same absolute speed)
  45.  
  46. Note that this is just off the top of my head. Idea 1 seems a lot easier to
  47. implement; idea 2 is closer to being the Right Thing, as if done properly
  48. it would work on future machines with nauseating speeds.
  49.  
  50. -- Via DLG Pro v0.995
  51.  
  52. - be zorch, daddi-o --------------- paul (raccoon) trauth ----------------
  53. --------------------------------------------------------------------------
  54. Internet -> paul_trauth@agwbbs.new-orleans.LA.US        \\\///\\\///\\\
  55. Usenet   -> rex!agwbbs!paul_trauth                      \\\///\\\///\\\
  56. --------------------------------------------------------------------------
  57.   "eagles may fly, but a weasel will never get sucked into a jet engine"
  58.