home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / mac / programm / 21227 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  3.1 KB

  1. Path: sparky!uunet!haven.umd.edu!mimsy!afterlife!mssmith
  2. From: mssmith@afterlife.ncsc.mil (M. Scott Smith)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Direct screen writing; getting to (x,y)
  5. Message-ID: <1993Jan11.235448.22675@afterlife.ncsc.mil>
  6. Date: 11 Jan 93 23:54:48 GMT
  7. Organization: The Great Beyond
  8. Lines: 68
  9.  
  10. Howdy..
  11.  
  12.    In my spare time (ha -- "spare time"?  Yeah, right..) I've been fiddling
  13. around with doing direct-screen writing on the Mac.  (That is, writing
  14. directly to the video memory to get fast(er) graphics than the traditional
  15. (but usually adequate) Quickdraw calls.)
  16.  
  17.    I'm familiar with the concept of writing LONGS out to the video RAM to
  18. achieve speed, but I want to have a function that simply plots ONE pixel
  19. point.  (Color's not the issue at this point.)  You pass an x- and y-, and
  20. it jumps to the memory location representing that coordinate.
  21.  
  22.    Here's something I threw together:  (Think C code)
  23.  
  24. void PlotPoint(long x, long y, long color)
  25. {
  26.   if (SCR_X == 640)
  27.     *(char *)(base_addr + x + ((y << 7) + (y << 9))) = color;
  28.   else if (SCR_X == 512)
  29.     *(char *)(base_addr + x + (y << 9)) = color;
  30.   else if (SCR_X == 1024)
  31.     *(char *)(base_addr + x + (y << 10)) = color;
  32.   else
  33.     *(char *)(base_addr + x + (row_bytes * y)) = color;
  34. }
  35.  
  36.    Actually, x- and y- should be integers, or can be, or whatever.  base_addr
  37. is the base address of the video memory.  (Corresponds to (0,0) in all cases,
  38. I hope!)  row_bytes is the number of bytes in each row on the monitor.
  39. Color is just some hexadecimal value.
  40.  
  41.    And SCR_X is the width of the monitor, in pixels.
  42.  
  43.    The concept behind this code is that to get to (X,Y), I take the base
  44. address, add x to it, and then add (y * row_bytes) to get down to the right
  45. place.
  46.  
  47.    For speed's sake, I'm doing some tricks with the left shifts.  If the
  48. width of the monitor is a nice multiple of 2 (say 640, 512, or 1024), then
  49. I perform left shifts to take care of the (y * row_bytes) part.  If all
  50. else fails, I multiply the long way.
  51.  
  52.    Anyway, this code seems to work.  I'd like a few suggestions on better ways
  53. of doing this.  Do I have the right idea, or did I miss the boat completely?
  54.  
  55.    One thing I plan on trying is to create an array of rowbyte values for
  56. every y- position on the monitor, at the initialization part of the program.
  57.  
  58.    That is, say the monitor is 480 lines vertical; I'd then make an array
  59. 480 long and manually compute row_bytes*y for each y position, plugging the
  60. value into the array.  Then I could simply do something like:
  61.  
  62. base_addr + x + line[y]
  63.  
  64.    To get where I want to go.  Intuitively it seems like this would be much
  65. quicker; after all, you're not doing any multiplication, which is the most
  66. expensive part of this routine.  But, on second thought, C is really doing
  67. multiplication anytime you access a subscript of an array, right?  (For
  68. example, if you want line[50], then it does some multiplication to go from
  69. the base address -- line -- up 50*sizeof(line) to get the value, right?)
  70.  
  71.    Any thoughts on topics I've raised, or direct-screen graphics in general,
  72. would be very appreciated.
  73.  
  74. Thanks!
  75.  
  76. M. Scott Smith
  77.   (mssmith@afterlife.ncsc.mil)
  78.