ccexplore, thanks for the link to the SDL porting advice, this sounds very much applicable.
Here's the sketch of the drawing order:
BITMAP* pre_screen; (this lives in RAM, too)
Torbit (owns a BITMAP*) osd; (It's not necessary that osd must be Torbit, BITMAP* would probably do.)
Map (inherits Torbit) map; (This must be Torbit in the current architecture, it's a canvas for drawing gameplay.)
State (owns a Torbit) current_state; (This holds the land, I have several states for networking backup or savestating.)
Cutbit interactive_object, lix_image, ...; (owns a BITMAP* with the entire spritesheet, can make sub-BITMAP*s that only have the desired frame. Cutbits do not change while the program is running! Maybe some more are loaded when new terrain is required from disk, but existing Cutbits don't change anymore.)
When drawing during the normal gameplay:
Clear the map rectangle visited by the current scrolling to the level's bg color.
Draw the interactive objects onto the map.
Draw the landscape from current_state's Torbit onto the map.
Draw the interactive objects onto the map that go in front of the landscape.
Draw the lixes onto the map.
Undraw osd, this removes the mouse cursor from the last time we were drawing and restores its background.
Draw GUI elements onto the osd that have changed since last time we were drawing.
Draw the mouse cursor onto the osd, saving its background.
Blit the map rectangle visited by the current scrolling onto pre_screen, without transparency.
Blit the osd onto the pre_screen, with transparency.
Blit the pre_screen to the physical screen in VRAM.
The landscape in current_state may be altered by the lix skills during calc()the logic calculation. This happens at a different time than draw(). Important is that the landscape will not necessarily be the same image upon the next call to draw(), I don't think about it as a sprite.
-- Simon