home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!haven.umd.edu!darwin.sura.net!jvnc.net!princeton!rutgers!ub!acsu.buffalo.edu!triantos
- From: triantos@acsu.buffalo.edu (Nick B Triantos)
- Newsgroups: comp.sys.mac.programmer
- Subject: Re: Game Techniques (was: NON-QUICKDRAW GAMES)
- Message-ID: <Bu8oyn.LD6@acsu.buffalo.edu>
- Date: 8 Sep 92 04:13:31 GMT
- References: <1992Sep8.004821.11323@adobe.com>
- Sender: nntp@acsu.buffalo.edu
- Organization: The University at Buffalo
- Lines: 44
- In-Reply-To: jholt@adobe.com's message of 8 Sep 92 00:48:21 GMT
- Originator: triantos@autarch.acsu.buffalo.edu
- Nntp-Posting-Host: autarch.acsu.buffalo.edu
-
- First, thanks to Joe Holt and Ben Haller, without whom I still wouldn't have a
- clue whether it is _really_ possible to do direct screen writes. I do have a
- question or four which have arisen from building a program based on Joe's words
- about finding the screen memory, though.
-
- On my Mac IIci, with a 640x480 color monitor working through a RasterOps 264
- card, 1K of memory is reserved for each row of screen pixels, although the
- monitor only uses the first 640 bytes of each 1024. So my question is this:
- Is this a standard behavior for 640x480 video cards? What about for those
- screens and video cards that produce 800+ pixels horizontally? They should
- still fit within the 1024 bytes. But how about the 21" monitors that provide
- some 1200+ pixels horizontally? Do those cards reserve 2K / row, or am I just
- generalizing something which only my video card is doing?
-
- Second, I changed the test part of the program as follows: I did
- while(!Button())
- *myScrnPtr++ = 0xAA
- and some other things. I make sure that I hit the button before I hit the end
- of the screen. Now, it seems as though the drawing is still slow (I'd say
- about 100 lines / sec). Is that slowdown all because of my while(!Button())?
- I didn't think that that function should be so burdensome to the CPU. Guess
- that's something I should try out on my own, but it can't hurt to ask.
-
- Related to that, I guess it doesn't seem as though my little test program
- places values in Screen memory at anything close to the rate of, say, moving a
- 400x300 window. For my example, the system would be moving ~120K bytes, and so
- it should go relatively quickly, but it seems really fast to me, considering it
- takes me almost as long to move 1200 bytes. Is the System's window moving code
- optimized to move more than words at a time? Does the 68000 have something
- similar to a MOVE.BLK <src>,<dst> instruction?
-
- Last question, directed more toward Ben Haller than most others. Does Solarian
- II use two screens worth of memory and switch between the two for such smooth
- animation? I understand that you're not animating the whole 640x480 screen at
- once, but it still does look really nice and smooth.
-
- Well, I guess that's all for now. So long, and thanks for all the fish.
-
- -Nick
- --
- Nick Triantos internet: triantos@acsu.buffalo.edu
- AOL: Triantos
- "Scientists tell us that the fastest animal on earth, with a top speed of
- 120 ft/sec, is a cow that has been dropped out of a helicopter." - Dave Barry
-