home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / mac / programm / 22281 < prev    next >
Encoding:
Internet Message Format  |  1993-01-27  |  3.1 KB
  1. Path: sparky!uunet!ukma!darwin.sura.net!dtix.dt.navy.mil!uranus!tecsun1!afterlife!mssmith
  2. From: mssmith@afterlife.ncsc.mil (M. Scott Smith)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: Arcade-style animation...
  5. Message-ID: <1993Jan27.232803.20061@afterlife.ncsc.mil>
  6. Date: 27 Jan 93 23:28:03 GMT
  7. References: <1993Jan25.094256.12845@rulway.LeidenUniv.nl> <34994@goofy.apple.COM> <1k6pol$bvn@agate.berkeley.edu>
  8. Organization: The Great Beyond
  9. Lines: 55
  10.  
  11.  
  12.    Maybe I'm missing something..  But isn't it quite possible to find out the
  13. base address of a video card -- most video cards, Apple and non-Apple alike?
  14.  
  15.    I hope so, because I've been doing this the past several months in a game
  16. I'm writing and it seems to work fine so far on a variety of platforms.
  17.  
  18.    I wrote routines that scroll the screen to the right and left as well --
  19. and they seem very quick.  I'm not using any "scrolling" features of a video
  20. card; all you need to do to scroll a screen is move the bits around in the
  21. right places -- the only limitation might be speed, but this doesn't seem
  22. to be a problem either.
  23.  
  24.    I might not be doing everything safe, and I'm sure my routines will "break"
  25. under certain circumstances, but -- a lot of programs write directly to the
  26. screen and work fine.  System 7's one of them.
  27.  
  28.    Now I've got a few questions for the experts..
  29.  
  30.    I wrote a library of functions to handle "sprites" (for lack of better word;
  31. pictures, whatever) -- I have one program which transforms high-level
  32. graphics created with paint programs, etc., into the low-level bits that
  33. I need to plot directly on the screen.  I then wrote a program that takes
  34. the output of this program and writes a C function out of it -- this function,
  35. when called, basically "stamps" the picture on the screen.
  36.  
  37.    I should note that it stamps the picture on screen much, MUCH quicker than
  38. can conceivably be achieved with any of the Quickdraw calls.  It is very, very
  39. fast.
  40.  
  41.    But, since I will most likely have lots of graphics in any program I have,
  42. is this a good approach?  That is, what effect will be representing graphics
  43. as C _code_ instead of data in a data file or the like?
  44.  
  45.    Already, with a few graphics, the program is HUGE (in terms of numbers of
  46. lines; I don't think the size of the object code is much greater than if I
  47. kept the bits in a PICT resource or something) -- how will this affect program
  48. execution?
  49.  
  50.    Oh well..  Maybe I'm talking about something else, but if anyone needs
  51. help with direct-screen graphics, I could probably help out a bit.  (But I
  52. don't want to divulge *too* many of my secrets!  :)  I've labored hard to
  53. find out how to do this stuff!)
  54.  
  55. Later,
  56.  
  57. M. Scott Smith
  58.   (mssmith@afterlife.ncsc.mil || umsmith@mcs.drexel.edu)
  59.  
  60. P.S. I've found that working low-level is less of a headache than working
  61. with all the Quickdraw calls, when looking for fast animation, etc.  The
  62. Quickdraw graphics calls are ideal in most circumstances, but they couldn't
  63. handle the kind of animation I'm looking for..  It would be nice if some of
  64. this stuff was thoroughly documented somewhere, so it wasn't as much of a
  65. mystery..  But I s'pose it's safest to stay with Quickdraw most of the time.
  66.