On Wed, Apr 21, 2010 at 12:54:42PM +1200, Ralph Versteegen wrote: > 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"
I just mean that you can easily request a different sprite record or a different frame by number. As opposed to, for example, Surfaces in SDL, where there is no biult-in concept of records or frames, and you have to spin your own mapping of such things to filenames and subsurface offsets. > 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. Yes. > 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). Cool. I agree. > 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) Flipping is still not cached, right? The purpose Change*Slice is to have a single place for sanity-checking values. For example, if you change a spriteslice's record to a type that doesn't support as many frames, the frame needs to be checked to make sure it doesn't overflow. Or if you change a rectangles background color, its style needs to be unset. Maybe it would be cleaner to have separate setters for each such property? As for the Get*SliceData functions they are all a fairly pointless convenience wrappers for getting the ->dat member. They were never indended to be "getters" in the same sense that Change*Slice are "setters" > 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. I imagine that if you tell a sprite to dissolve, it transforms into a BitmapSlice (if it isn't one already) and then does the animation. > 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. Excellent. That seems entirely doable. > 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 forgot about those animations! Yes, we could do that. I would like to make it possible to designate a transparent color for a BackdropSlice. I am not sure how to do that. Oh, that remind sme of another thing I was thinking. Suppose I have a 120x120 256 color sprite drawn as a backdrop. Then I load it as a sprite in my plotscript, and make the background color transparent. What if I could "trim" off the unused transparent space around it? So the result would be 120x120 instead of 320x200. Does that sound crazy? > > 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? Yeah, that would leak it. But that isn't what I wanted. Maybe something like this: ship := load medium enemy sprite(5) gun := load medium enemy sprite(14) blit (ship, gun) flip sprite horiz(gun) blit (ship, gun) free slice (gun) Where the blit command just does a behind-the-scenes conversion from SpriteSlice to BitmapSlice, and the scripter is none the wizer. Now, would the act of turning a SpriteSlice into a BitmapSlice mean that subsequent attempts to change the slices frame would fail? Or should it lose its modifications and transform back into a SpriteSlice? > 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). I was worried about this myself, but in practice it has been pretty manageable. After I read your mail a few nights ago, I had a dream about garbage collection of sprites, and even in the spirit-world I couldn't figure out a way to make it work. Because slice handles are just integers, we don't have any way of knowing when a slice ceases to be used. Suppose we don't have any handles left in local or global variables. Can we free the slice? Nope. Because we might have handles in some other slice's extra data, or in an NPC's extra data, or even in some other crazy place (I actually do this already) But even if we have no handles whatsoever, we still can't free it, because maybe it is a floating caption that is supposed to just sit there and say "Hello World". Even if it is invisible and offscreen we can't free it, because we might bring it back onscreen later by moving its parent, or we might get a new handle for it with lookup slice. --- James Paige _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
