Hi archive reader,
this is here because I didn't want to pollute CVS with a README file
containing only this note, and I did want to store it for later
generations ;-)
The current problem with blitting is that a Sprite either appears behind
or in front of another Sprite. This is caused by the fact that Sprites
with their drawparts are ordered according to their .priority attribute,
which is the same for the whole sprite. The solution would be to not
sort the Sprites, but another object, which holds both the sprite and
the part to be drawn, with a common priority. The exact implementation
remains to be seen, however. "Left-oriented-perspective" should probably
be hardcoded because the graphics are static as well. Since everything
should appear behind the left side of walls and such, this left side has
to be drawn as last, so it has the highest priority. The right side of
walls has ordinary priority.
This type, lets call it 'Piece', has to compare with other Pieces in
exactly the drawing order, so it will never compare equal. It knows
about its Sprite, its part of the Surface to be blitted, and whether
this part 'extends'. The 'extending' part of a Sprite is a Rect object
(set of Rect objects? Area object?) carried by the Sprite. Pieces will
be created by Screen. It's very necessary if the Sprite has a
non-emtpy 'extending' attribute or if only a part of the sprite needs to
be redrawn. But other's will also have a Piece creating because of
sorting. Caching Pieces is not necessary, because the sprites that don't
change don't end up in Spritedict at all. All Pieces disappear each
frame.
It is tolerable to first draw an entire wall, than the sprite, and then
again a part of the sprite.
This all means the 'behindwall' code and such can be removed. This speeds
things up a lot, the former solution was not only incorrect, incomplete
and ugly, but also slow. Let's hope the above idea works better...
I probably forgotten something, in that case I'll followup on this.
Gotta go to the mensa now :-)
Gerrit.
|
