home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / mac / programm / 21240 < prev    next >
Encoding:
Text File  |  1993-01-11  |  3.7 KB  |  90 lines
  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!mcsun!news.funet.fi!funic!nntp.hut.fi!vipunen.hut.fi!jmunkki
  3. From: jmunkki@vipunen.hut.fi (Juri Munkki)
  4. Subject: Re: Direct screen writing; getting to (x,y)
  5. Message-ID: <1993Jan12.021320.7406@nntp.hut.fi>
  6. Sender: usenet@nntp.hut.fi (Usenet pseudouser id)
  7. Nntp-Posting-Host: vipunen.hut.fi
  8. Reply-To: jmunkki@vipunen.hut.fi (Juri Munkki)
  9. Organization: Helsinki University of Technology
  10. References: <1993Jan11.235448.22675@afterlife.ncsc.mil>
  11. Date: Tue, 12 Jan 1993 02:13:20 GMT
  12. Lines: 76
  13.  
  14. In article <1993Jan11.235448.22675@afterlife.ncsc.mil> mssmith@afterlife.ncsc.mil (M. Scott Smith) writes:
  15. >void PlotPoint(long x, long y, long color)
  16. >{
  17. >  if (SCR_X == 640)
  18. >    *(char *)(base_addr + x + ((y << 7) + (y << 9))) = color;
  19. >  else if (SCR_X == 512)
  20. >    *(char *)(base_addr + x + (y << 9)) = color;
  21. >  else if (SCR_X == 1024)
  22. >    *(char *)(base_addr + x + (y << 10)) = color;
  23. >  else
  24. >    *(char *)(base_addr + x + (row_bytes * y)) = color;
  25. >}
  26. >
  27. >   Actually, x- and y- should be integers, or can be, or whatever.  base_addr
  28. >is the base address of the video memory.  (Corresponds to (0,0) in all cases,
  29. >I hope!)  row_bytes is the number of bytes in each row on the monitor.
  30. >Color is just some hexadecimal value.
  31.  
  32. >   And SCR_X is the width of the monitor, in pixels.
  33.  
  34. It looks like you are hard-coding for 8 bit deep displays. That's of
  35. course up to you, if you want to limit yourself to a certain bit depth.
  36.  
  37. If SCR_X is indeed the width of the display, you will run into trouble
  38. with most Macintosh video cards. If it's the same as row_bytes, then
  39. things should be almost ok.
  40.  
  41. If a screen is 640 pixels wide, it doesn't mean that the next row starts
  42. 640 bytes after the first one. Most video cards leave some unused bytes
  43. to the right of the screen and use a rowBytes field of 1024.
  44.  
  45. >   For speed's sake, I'm doing some tricks with the left shifts.  If the
  46. >width of the monitor is a nice multiple of 2 (say 640, 512, or 1024), then
  47. >I perform left shifts to take care of the (y * row_bytes) part.  If all
  48. >else fails, I multiply the long way.
  49.  
  50. A multiply isn't all that slow, unless you are running on the 68000 (which
  51. isn't the case, since you are assuming 8 bits per pixel). I think you are
  52. wasting a lot of time with those ifs.
  53.  
  54. >   Anyway, this code seems to work.  I'd like a few suggestions on better ways
  55. >of doing this.  Do I have the right idea, or did I miss the boat completely?
  56.  
  57. Of course, it doesn't really work. It only works on some hardware, but
  58. it will cause big problems with a lot of machines.
  59.  
  60. As I said earlier, the keys to compatibly do direct video writes are:
  61.  
  62.     SwapMMUMode
  63. and    ShieldCursor
  64.  
  65. The first one will make you compatible with any video cards that are only
  66. visible with 32-bit addressing on (the new PowerBooks are an example of this
  67. and any video card with more than 1MB of VRAM is another example).
  68.  
  69. The second one makes you compatible with all sorts of kludges. I seem
  70. to remember that something called "Soft Pivot" requires this and most
  71. SCSI-video interfaces probably also work by watching calls to ShieldCursor
  72. and ShowCursor.
  73.  
  74. >   One thing I plan on trying is to create an array of rowbyte values for
  75. >every y- position on the monitor, at the initialization part of the program.
  76.  
  77. This works as long as no one changes the screen resolution suddenly. It
  78. usually doesn't happen, but I think it's possible under some circumstances.
  79.  
  80. >But, on second thought, C is really doing
  81. >multiplication anytime you access a subscript of an array, right?
  82.  
  83. Not really, if the element size is a multiple of 2. The 68020 has addressing
  84. modes that internally do the multiplication and in any case you can do it
  85. with a shift.
  86.  
  87. -- 
  88.   Juri Munkki                           Windsurf: fast sailing
  89.  jmunkki@hut.fi                          Macintosh: fast software
  90.