Re: [Alephmodular-devel] Brainstorming on bitmaps

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

On Monday, February 24, 2003, at 02:16  AM, Mark Levin wrote:

>> Typical usage would be:
>> 	Request current buffer from display system
>> 		(it is limited as in dimensions, display system knows this)
>> 	Lock down the buffer
>> 	Get a bitmap from the buffer
>> 	Render operations on the bitmap
>> 	Release the bitmap
>> 	Perform drawing operations on the buffer (access to platform native 
>> elements available?)
>> 	Unlock the buffer
>> 	Ask display system to swap buffers
>
> Add "Obtain the dimensions of the buffer" (oh, you got to that later).
>
> What do you think about the ability to move the origin of a context? 
> Aleph One does the main screen layout with this; it makes the game 
> view size and screen size essentially independent, but I personally 
> find it very confusing to do layout in this fashion. Perhaps it would 
> be better to do some complex calculations and rebuilding of buffers 
> when the screen is resized instead of a large number of simple (but 
> annoying) calculations every frame.

I'm definitely looking at locking these two values together. Why? So 
that for MacOS X I can effectively set world_pixels to essentially be a 
clipped-rectangle version of the screen_window. In other words, I get a 
back buffer from someplace else, either a window's back buffer, display 
sprockets, or something equivalent, and then manage it with CDisplay 
and CBuffer.

My Vindication comment the other day was in building a 
clipped-rectangle version of a CBitmap and passing it through the 
renderer so that the renderer was using a 640 x 320 portion of a 1024 x 
768 window's buffer.

>> Locking pixels.
>
> Are you talking about the original MacOS LockPixels() concept (which 
> IIRC was meant to protect pixmaps from memory manager housekeeping) or 
> some sort of mutex for multithreaded drawing? The former is probably 
> obsolete on everything except OS9.

Lock Pixels is very much alive and well in Carbon. I don't know about 
normal buffers and maybe one or two existing LockPixels calls were 
misplaced in the Marathon code, but I definitely needed to call 
LockPixels on the window before I could access it's pixels. Otherwise I 
wrote directly to the screen.

>> Ponder... Setting the drawing context should occur seperately
>
> Maybe this should be changed to a stack-based mechanism (like Quartz) 
> instead of requiring the program itself to cache and restore the 
> previous state.

I haven't seen Quartz's method, but I feel you're right. I just haven't 
figured out who should own the drawing context yet. It does seem that 
some other class to encapsulate drawing options is appropriate. (A 
singleton CDrawingContext with the auto-releasing method I'd mentioned?)

>> 	world_pixels is used as the offscreen buffer for saved game preview 
>> pictures :/
>
> With proper abstraction it should be trivial to temporarily point the 
> renderer at an offscreen buffer instead.

True. And in this one case I'd look into having the saved game preview 
possibly create its own buffer, wrap it in a CBuffer and ask it to have 
its thumbnail map rendered. It seems kinda low-priority. Creating the 
thumbnails as I do worked under 10.1.*, but while the navigation 
preview resources are created under 10.2, the finder and Navigation 
Services dialogs won't use them anymore :/

>
> Rectangle representation: Do we use OS9-style absolute boundaries 
> (left/top/right/bottom) or "relative" rectangles (x/y/width/height)? 
> Is the origin at the physical top or bottom of a buffer? (Carbon and 
> OpenGL disagree on this last bit, which has caused me its share of 
> confusion too. How do Windows and SDL work?)

screen_rectangle as used by Marathon is a left/top/right/bottom affair. 
Which is annoying as x/y/width/height feels like it suits my needs for 
CBitmap clipping control better. And yes that does place the origin at 
the physical top and left of the buffer, expanding down and to the 
right.

-Jeremy Parsons