home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.mac.programmer
- Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!paladin.american.edu!news.univie.ac.at!hp4at!mcsun!news.funet.fi!funic!nntp.hut.fi!vipunen.hut.fi!jmunkki
- From: jmunkki@vipunen.hut.fi (Juri Munkki)
- Subject: Re: Fast copies from offscreen buffer to screen.
- Message-ID: <1993Jan10.163338.12128@nntp.hut.fi>
- Sender: usenet@nntp.hut.fi (Usenet pseudouser id)
- Nntp-Posting-Host: vipunen.hut.fi
- Reply-To: jmunkki@vipunen.hut.fi (Juri Munkki)
- Organization: Helsinki University of Technology
- References: <1993Jan10.031829.25011@samba.oit.unc.edu>
- Date: Sun, 10 Jan 1993 16:33:38 GMT
- Lines: 21
-
- In article <1993Jan10.031829.25011@samba.oit.unc.edu> Michael.Kohne@launchpad.unc.edu (Michael Kohne) writes:
- >Currently we are considering a 'dirty-rectangles' system, however, it is
- >likely that most of the screen will change on each frame (lots of moving
- >objects.) I know this sort of thing IS possible, I own hellcats over the
- >pacific and it looks like it's updating the whole screen each frame.
-
- Hellcats only draws pixels that change from frame to frame. I guess that's
- the "secret" of the speed. My polygon routines do the same thing. It requires
- some overhead to find out what pixels one should change, but it's well worth
- it in 8 bit deep displays of more than 320x200 resolution.
-
- If you want to see this in action, all you have to do is write an FKEY
- that wipes the whole screen to a solid color.
-
- On most Macs, there simply isn't enough memory bandwidth to do full screen
- updates quickly. From discussions in rec.games.programmer, I gather that
- the situation is much worse on most PCs.
-
- --
- Juri Munkki Windsurf: fast sailing
- jmunkki@hut.fi Macintosh: fast software
-