Re: [Alephmodular-devel] Clipping oneself into a corner

[Br'fin <br...@ma...>]

On Monday, March 10, 2003, at 12:33  AM, Alexander Strange wrote:
> On Monday, March 10, 2003, at 12:16  AM, Br'fin wrote:
>> I think this both completely rocks, and I have no idea how to fold it 
>> into AlephOne.
>>
>> -Jeremy Parsons
>
> What's the basic Carbon mechanism it uses? I'd really like to see this 
> in A1, as my primary machine can't do OpenGL...
>

The basic strategy for MacOS X involves rendering directly to the back 
buffer of a Carbon window. At which point updating changes from being a 
copybits to doing QDFlushPortBuffer on the window.

However, setup gets a lot trickier. Marathon's initial assumption is 
that the drawing buffer is exactly the right size to be 
drawing/rendering into. So the normal world_pixels is an offscreen 
buffer that is exactly 640x320 if you're running in 100%.

Rendering is pretty well behaved and it's easy to get it to draw 
someplace else. You don't even need to get the height and width of your 
bitmap all small if you don't want to since the view_data generally 
specifies the desired height and width already. But you do need to 
offset the bitmap.

bitmap.row_addresses[0] =
	bitmap.row_addresses[0] +
	(horizontal_offset * pixel_size) +
	(vertical_offset * bitmap.bytes_per_row);

Where pixel_size is 1 for 8 bit, 2 for 16 bit, and 4 for 32 bit.

Also, you need to muck with the origin of where you are drawing to for 
any drawing based commands (Such as text, the terminal, fps, the map). 
As well as setup appropriate clipping areas for the same.

On top of this, for low-res mode you need to rework where the source 
and destination are. I personally did this by saying... you want 640 x 
480 pixel doubled? Then your effective drawing area is 320 x 240 *AND* 
it is offset within that original area by 320 x 240. In other words, 
everything is initially clipped to the lower-right hand area of the 
total space, and then the normal pixel doubling routine runs with all 
pointers looking into the same effective bitmap space.

The CClippingBuffer I developed was specifically for handling the above 
cases, to make a  portion of a much larger GrafPort seem like it was a 
complete and separate smaller port.

-Jeremy Parsons