[Alephmodular-devel] Brainstorming on bitmaps

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

Still trying to deal with display foo in my head. And working from the 
leaves in that leaves me trying to manage 'what is a bitmap' before I 
can handle how to dole them out to other areas.

The part I've been having the most trouble with, up til now, was trying 
to cope with the arbitrary sizes that bitmaps uses. C++ classes aren't 
generally geared to being flexible in length, but I have some ideas and 
I think I can make this basis work for bitmaps.

Still got my fingers crossed on that one, but even so I think I got my 
head wrapped around the basics and the offset table to have that table 
be a separate allocation if need be.

-Jeremy Parsons

Bitmaps
Here is the current layout of a bitmap.

enum /* bitmap flags */
{
	_COLUMN_ORDER_BIT= 0x8000,
	_TRANSPARENT_BIT= 0x4000
};

const unsigned int FILE_SIZEOF_bitmap_definition = 30;
struct bitmap_definition
{
	int16 width, height; /* in pixels */
	int16 bytes_per_row; /* if ==NONE this is a transparent RLE shape */
	
	int16 flags; /* [column_order.1] [unused.15] */
	int16 bit_depth; /* should always be ==8 */
	
	int16 unused[8];
	
	pixel8 *row_addresses[1];
//serialization
	friend AIStream& operator>>(AIStream&, struct bitmap_definition&);
	friend AOStream& operator<<(AOStream&, struct bitmap_definition&);
};

/* ---------- prototypes/TEXTURES.C */

/* assumes pixel data follows bitmap_definition structure immediately */
pixel8 *calculate_bitmap_origin(struct bitmap_definition *bitmap);

/* initialize bytes_per_row, height and row_address[0] before calling */
void precalculate_bitmap_row_addresses(struct bitmap_definition 
*texture);

void map_bytes(uint8 *buffer, uint8 *table, int32 size);
void remap_bitmap(struct bitmap_definition *bitmap,	pixel8 *table);


We could work within this to provide working on a subset of the bitmap. 
Such work would create create the following needs. Such a workd would 
also only apply to a non RLE bitmap.

	width is width of subset
	height is height of subset
	offset_column, offset_row is added for subsets
	bytes_per_row is unchanged
	flags is unchanged
	bit_depth is unchanged
	row_addresses
		Is unchanged for shapes
		for a subset
			row_address[0] points to the resultant byte due to offsetting. This
			position is base_address+(offset_row*bytes_per_row)+offset_column. 
Adding
			bytes_per_row to this will hit each subsequent row with the handy
			offsets already applied.

What is interesting to note is that making a class of bitmap_definition 
is fairly hard. Between my requirements that limit our ability to 
subclass and derive.
...
Strike that, looks like subclassing can be handled 'nicely'

When loading collections, the first pass of shapes allocates size based 
upon sizeof bitmap_definition, and then copies the existing stream into 
place. We can intercedede in this by doing an 'in place new' (new(void 
*) T(val); ) that allocates and constructs the bitmap at the desired 
point. Roughly this would look something like

	void *source= (raw_collection + OffsetTable[k]);
	void *destination= (NewCollection + NewCollLocation);
	int32 length= OffsetTable[k+1] - OffsetTable[k];
	shape_bitmap_definition *bitmap= new (destination) 
shape_bitmap_definition(source, length);
	*(NewOffsetPtr++) = NewCollLocation;
	NewCollLocation +=
		AdjustToPointerBoundary(bitmap->sizeof());

Note that it is an inplace new.
The arguments are a spot in memory and and a length to process.
The sizeof method performs calculation to determine the actual length 
of the the bitmap +  its offset pointers + its actual data

Remember that something that frees up a collection should call delete 
on each bitmap just in case for the future :)


On a similar sort of note, a screen based bitmap can be pre-allocated, 
then created in place with one of its elments holding an auto_ptr to 
own its own allocation buffer.
	

So now, the base code can deal with bitmap_definition, and higher level 
code can deal with the specifics of a shape_bitmap_definition and a 
display(screen?)_bitmap_definition, which is mostly useful for 
construction in either case. Mmm, might want to add the control of its 
own managment to shape_bitmap_definition as well for someone wanting to 
create-edit bitmaps. If the memory doesn't need to be freed or is freed 
elsewhere, then the auto_ptr can be left not holding anything.