pybrian-devel Mailing List for Brian
Status: Alpha
Brought to you by:
gerrit
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Gerrit H. <ge...@nl...> - 2004-01-28 16:11:35
|
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. |
From: Gerrit H. <ge...@nl...> - 2003-03-04 15:32:18
|
This is a test message. -- Asperger Syndroom - een persoonlijke benadering: http://people.nl.linux.org/~gerrit/ Het zijn tijden om je zelf met politiek te bemoeien: http://www.sp.nl/ |