home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / mac / programm / 15112 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  3.0 KB

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