CXT105@psuvm.psu.edu (Christopher Tate) (04/23/91)
I'm trying to figure out how to do direct-to-screen drawing, in the course
of working on things like antialiasing. The problems I'm running into are
strange, though....
If I open a CWindow, its baseAddr is the address of the main screen buffer.
Okay; well, I guess I'll just draw directly onto the screen (since I'm not
worried about being friendly to other apps just yet :-). Unfortunately
I'm getting crashes when I try to write to the screen in certain ways that
*look* like they should work...
Example: base is an (unsigned char *) that points to the screen buffer. I
can verify this by saying *base = 33, and seeing the pretty red dot appear
in the top left corner of the screen.
However, if I try to set up pointer arithmetic of the form
*(base + x + rowBytes*y) = 33;
a couple of different things happen. If x, y, and rowBytes are declared as
type short, then it works -- sort of. I get strange wraparound to the top
of the screen which I assume is because of overflow problems in the
multiplication.
If x, y, and rowBytes are declared long, it crashes. Every time. Anyone
have any ideas why? Or, alternatively, has anyone already worked out the
nitty-gritty of direct screen bit-twiddling to a color window?
-------
Christopher Tate | "Hear perfect strangers call you by name,
cxt105@psuvm.psu.edu | Pay good money to hear "Fire and Rain"
..!psuvax1!psuvm.bitnet!cxt105 | Again and again and again....
cxt105@psuvm.bitnet | That's why I'm here!" -- James Taylorjmunkki@hila.hut.fi (Juri Munkki) (04/25/91)
In article <91113.105146CXT105@psuvm.psu.edu> CXT105@psuvm.psu.edu (Christopher Tate) writes: > *(base + x + rowBytes*y) = 33; >If x, y, and rowBytes are declared long, it crashes. Every time. Anyone >have any ideas why? Or, alternatively, has anyone already worked out the >nitty-gritty of direct screen bit-twiddling to a color window? First of all, you're assuming an 8-bit screen. This is Ok, if you have checked that you really do have one, but be careful. rowBytes has some extra flag bits that you have to strip out. There are quite a few non-obvious things about drawing directly onto a color screen, so unless you are 100% sure that you want to do it, don't. Actually, Inside Mac V says that bit 15 is used and that bits 13 and 14 should always be 0. Develop I, page 9 says that 32 bit QD allows rowBytes to be up to $3FFE, so they have obviously made some changes. I used to mask off the top three bits, but now I only strip out the most significant bit. At least that's how I interpret the current documentation. Quiz question: Why is the limit $3FFE and not $3FFF. I know why, but if you can't figure it out in 3 seconds, you probably shouldn't be messing with direct screen writes. rmsism: [Actually, what I mean is that you shouldn't be writing commercial or widely distributed software without source distribution, because someone will then obviously stumble in a bug and not be able to fix it.] ____________________________________________________________________________ / Juri Munkki / Helsinki University of Technology / Wind / Project / / jmunkki@hut.fi / Computing Center Macintosh Support / Surf / STORM / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sokoloff@athena.mit.edu (James T Sokoloff) (04/30/91)
> Actually, Inside Mac V says that bit 15 is used and that bits 13 and 14 > should always be 0. Develop I, page 9 says that 32 bit QD allows rowBytes > to be up to $3FFE, so they have obviously made some changes. Only stripping the most significant bit is dangerous. It is *most correct* to strip the two most significant bits. (Obviously, if bit 14 is zero, this yields the same result. However, who is to say that bit 14 will be forever zero. Apple has told us that these two bits are not to be included in calculations with rowbytes, let's just believe them and follow their code examples...) Jim Sokoloff sokoloff@athena.mit.edu