home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / mac / programm / 21262 < prev    next >
Encoding:
Text File  |  1993-01-12  |  2.6 KB  |  70 lines
  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!relay!relay2!afterlife!mssmith
  3. From: mssmith@afterlife.ncsc.mil (M. Scott Smith)
  4. Subject: Re: Direct screen writing; getting to (x,y)
  5. Message-ID: <1993Jan12.081850.12759@afterlife.ncsc.mil>
  6. Organization: The Great Beyond
  7. References: <1993Jan11.235448.22675@afterlife.ncsc.mil> <1993Jan12.021320.7406@nntp.hut.fi>
  8. Date: Tue, 12 Jan 1993 08:18:50 GMT
  9. Lines: 59
  10.  
  11. Juri -- thanks for the information.
  12.  
  13. > If SCR_X is indeed the width of the display, you will run into trouble
  14. > with most Macintosh video cards. If it's the same as row_bytes, then
  15. > things should be almost ok.
  16.  
  17.    I re-wrote the function I posted so that I don't think it uses SCR_X
  18. anymore.  Well, here's the new one:
  19.  
  20. I do the following when I init the program:
  21.  
  22.   for (y=0; y<=(*screen_len_y); y++)
  23.     line[y] = ((*row_bytes) * y);
  24.  
  25. And here's my PlotPoint function:
  26.  
  27. void PlotPoint(long x, long y, long color)
  28. {
  29.   *(char *)(base_addr + x + line[y]) = color;
  30. }
  31.  
  32.  
  33.    That avoids the use of SCR_X (and also seems to be about 1.5 times quicker
  34. than my original version); does this avoid the problem you mentioned?  I'd
  35. like this to be as compatible as possible with all video configurations,
  36. including bit depth.  What would be the easiest way to handle different
  37. bit depths?  My primary concern for now is 8-bit.
  38.  
  39. > Of course, it doesn't really work. It only works on some hardware, but
  40. > it will cause big problems with a lot of machines.
  41.  
  42.    Is my new routine a bit more friendly, or does it still have a problem?
  43.  
  44. > As I said earlier, the keys to compatibly do direct video writes are:
  45. >
  46. >     SwapMMUMode
  47. > and ShieldCursor
  48.  
  49.    I haven't messed with ShieldCursor before, so I'll look into that.  I
  50. assume I should be calling SwapMMUMode in my PlotPoint function, right
  51. before and after I do the plot.  Does this eat up much processor time?
  52. It seems if I'm plotting hundreds of points, then making those hundreds of
  53. calls might have a performance penalty.  But I don't know.  (And I guess
  54. it's necessary in some cases anyway.)
  55.  
  56. > This works as long as no one changes the screen resolution suddenly. It
  57. > usually doesn't happen, but I think it's possible under some circumstances.
  58.  
  59.    Someone would do that??  How rude.  :)  Would the best strategy be to
  60. periodically check the depth of the screen you're working with, like in the
  61. event loop, and then to do whatever's necessary if the bit depth suddenly
  62. changes?  (Like maybe put up a dialog that say "hey, don't do that!", or
  63. re-compute everything.)
  64.  
  65. Well, thanks for all of your information.  It was very helpful.
  66.  
  67. M. Scott Smith
  68.   (mssmith@afterlife.ncsc.mil)
  69.  
  70.