On 16 April 2010 06:27, James Paige <[email protected]> wrote: > I was about to start on an implementation of BackdropSlice, and I > noticed the comments in slices.bi above the SpriteSliceData type. > > 'FIXME: This is limited to unmodified 4-bit sprites with flipping tacked > on; generalise! > > I am pretty happy with the way SpriteSlice currently works. How might we > generalize it to support arbitrary frames without losing the current > convenient interface to sprite data records?
I'm not really sure what you mean by "convenient interface to sprite data records" However, I should point out that SpriteSets should in future wrap SpritesStates, not Frames. Well, once they are fully implemented, anyway. But that is definitely the direction we need to be headed, to add animations to sprite slices. When I wrote that comment, I was imagining that SpriteSlice should be generalised to draw any Frame, but I don't think that anymore. We should just have a separate BitmapSlice as you suggest if it makes the code simpler, because the differences don't have to be exposed to scripts (see below). The thing that (now) annoys me most about SpriteSlice is how inefficient/thoughtless flipping is (plus also these Change*Slice and Get*SliceData functions scare me a bit) And how are we going to handle more complex transforms, like enemy dissolves? We should probably allow automatically advanced dissolve animations, and also applying dissolve transforms one off to a sprite (at a given percentage completion): but now that I think of it, it makes most sense to support this only for BitmapSlices. Still, I'd rather that all sprite slices appear the same to scripts as much as possible. Just because we have separate SpriteSlices and BackdropSlices doesn't mean that we shouldn't allow "replace attack sprite" to work on a backdrop sprite. That is, embrace duck typing. Backdrops could behave like 1 frame sprites, but when animations are implemented, attempting to call an animation on a backdrop would always be an error because that just doesn't make sense (unless we implement animating backdrops... hey! There's no reason we couldn't do that! It would actually be pretty easy: backdrops could just be stored as sprites) > I am reluctant to have the same slice type to represent Sprites, > Backdrops, and arbitrary Frames that you can paint on. I gues that I > could make .spritetype and .record become meaningless for arbitrary > SpriteSlices, and I could make .pal become meaningless for backdrops, > but does it make sense to do it that way? > > Another approach would be to have three separate slice types > > SpriteSlice -- current functionality > > BackdropSlice -- would have a .record property, but not .spritetype or > .pal or .frame > > BitmapSlice -- resizeable and paintable full-color Frame. There would be > commands to draw pixels or lines onto these, or to blit one onto > another. There would be a command to convert SpriteSlice or Backdrop > Slice into one of these. > > Scripting using these might look something like this: > > variable(ship, gun) > > # load the space ship body > ship := bitmap(load medium enemy sprite(5)) > gun := load medium enemy sprite(14) > blit (ship, gun) > flip sprite horiz(gun) > blit (ship, gun) > free slice (gun) > > I dunno... I haven't really thought out blit()... And you leaked medium enemy sprite 5? Speaking of which, I don't like the fact that slices require manual deletion: I think it would be cool if they were garbage collected (by the script interpreter) in certain conditions like this one (but I'm not sure what those should be). > --- > James > _______________________________________________ > Ohrrpgce mailing list > [email protected] > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
