home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky rec.games.programmer:5228 comp.sys.amiga.programmer:17981
- Path: sparky!uunet!gatech!emory!wupost!usc!cs.utexas.edu!sun-barr!news2me.EBay.Sun.COM!exodus.Eng.Sun.COM!pepper.Eng.Sun.COM!cmcmanis
- From: cmcmanis@pepper.Eng.Sun.COM (Chuck McManis)
- Newsgroups: rec.games.programmer,comp.sys.amiga.programmer
- Subject: Re: Game timing
- Date: 31 Dec 1992 07:34:01 GMT
- Organization: Sun
- Lines: 88
- Message-ID: <lk58j9INN3k1@exodus.Eng.Sun.COM>
- References: <1992Dec17.144044.18199@westminster.ac.uk>
- NNTP-Posting-Host: pepper
-
- In article <1992Dec17.144044.18199@westminster.ac.uk> (Liaket Ali) writes:
- >A question (hypothetical) related to Game timing...
- >
- > For example, consider a flight simulator which, say, updates
- > 10 pixels in 1 frame in order to achieve a frame rate of 10fps.
- > I would like to be able to then update 5 pixels in 1 frame to achive 20fps.
- >
- > Is this possible? And how would I go about programming it.
-
- It is relatively simple mentally, somewhat less easy programatically.
-
- First you set up four processes/tasks.
- Task #1 sets up the timer.device to send it ticks on a regular
- basis (say every 10 ms or so)
- Task #2 moves the items in your game around based on their
- "velocity" (which is of course speed/time)
- Task #3 renders the current screen to the "hidden" buffer
- and then flips the viewed buffer.
- Task #4 is the "main" task and runs the game and provides
- the user interface.
-
- So in task 1, your doing something like :
- do {
- wait(tick);
- ticks_received++; /* global variable */
- } while (1); /* forever */
-
- In task 2 your doing something like :
- static last_ticks = 0, cur_ticks = 0;
-
- do {
- Wait(MovePort);
- cur_ticks = ticks_received; /* that global again */
- delta = cur_ticks - last_ticks;
- move_pieces(delta); /* does the work */
- /* check to see if scores should be made */
- if (collisions) {
- PutMsg(Mainport); /* tell game what happened */
- }
- PutMsg(RenderPort); /* tell the renderer to "go" */
- } while (1);
-
- In task 3, your renderer, you do something like :
- static CurView, OtherView, TmpView;
- do {
- Wait(RenderPort);
- /*
- * Draw all of the pieces into their new
- * positions in the "hidden" bitmap.
- */
- ...
- LoadView(OtherView);
- TmpView = CurView; /* Swap views */
- CurView = OtherView;
- OtherView = TmpView;
- PutMsg(MovePort);
- } while (1);
-
- In task 4, your "game process" you do something like:
- do {
- Wait(GameIO | MainPort);
- /* process user input, fire buttons etc */
- if (Fire1) {
- ...
- }
- if (Collision) {
- do_explosion();
- delete_items(exploded_items);
- score++;
- }
- ...
- } while (1);
-
-
- The effect of a design like this is that it runs correctly on *all*
- machines, from slow to fast. The only difference is the frame rate
- goes up if Task 3 completes sooner or if Task 2 completes sooner.
- Further you can do things like run in "2x" time mode simply by
- telling Task 1 to report that its seen twice as many ticks as it
- really has. Finally, once you've got the basic "engine" built you
- will notice that tasks 1, 2, and 3 are reusable in any game, and
- you only need to redo task 1 and the artwork for different games.
-
-
- --
- --Chuck McManis Mr. NIS+ Sunsoft
- uucp: {anywhere}!sun!cmcmanis BIX: <none> Internet: cmcmanis@Eng.Sun.COM
- These opinions are my own and no one elses, but you knew that didn't you.
-