home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.mac.programmer
- Path: sparky!uunet!mcsun!sun4nl!rulway.LeidenUniv.nl!ruls41.LeidenUniv.nl!vosse
- From: vosse@ruls41.LeidenUniv.nl (Theo Vosse)
- Subject: Re: Arcade-style animation...
- Message-ID: <1993Jan25.094256.12845@rulway.LeidenUniv.nl>
- Sender: root@rulway.LeidenUniv.nl (System PRIVILEGED Account)
- Nntp-Posting-Host: ruls41.leidenuniv.nl
- Reply-To: vosse@ruls41.LeidenUniv.nl (Theo Vosse)
- Organization: Leiden University, Netherlands
- References: <1993Jan23.014127.5750@cs.ucla.edu>
- Date: Mon, 25 Jan 93 09:42:56 GMT
- Lines: 28
-
- In article <1993Jan23.014127.5750@cs.ucla.edu>, tj@kona.cs.ucla.edu (Tom
- Johnson) writes:
- |> Here is what I first envisioned in pseudo-code:
- |>
- |> foreach sprite
- |> CalculateNewLocation()
- |> foreach sprite
- |> EraseSprite() // by copying the sprites old location from
- |> // a bkgnd screen to an offscreen world
- |> foreach sprite
- |> DrawSprite() // by copying the sprite onto the offscreen
- |> // world
- |> UpdateScreen() // by copying the offscreen world onto the
- |> // screen.
- |> ...
- |> But! If I'm drawing directly to the screen, how do I handle the
- |> "EraseSprite()" function? Since I want to support a complex color
-
- Life is simple... Forget the UpdateScreen function, and implement the
- EraseSprite as a copy of the old contents (that were stored under the
- sprite) back to its original position. So, DrawSprite must copy the
- contents of the sprite's position before drawing the actual sprite.
-
- Theo Vosse
- ----------
- Unit for Experimental Psychology
- University of Leiden
- The Netherlands
-