On 28 April 2010 05:20, James Paige <[email protected]> wrote: > 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?
Nope. Since I cleaned up the sprite cache it could be done much more easily now. > 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? Maybe... but I guess it works fine as it is. > 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" Hmm, only one of those functions is actually used anywhere. I can't remember what was worrying me. >> 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. I'm not sure that that actually gains anyway >> 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. Why not just use colour 0? I see no reason for anyone to need more than one transparent colour per sprite. Making backdrop slices optionally transparent sounds reasonable. In fact I'm pretty sure translparent backgrounds (for textboxes?) is a feature request. > 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? Why not just use a 120x120 256 colour sprite in the first place? >> > 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? I'm not sure. If you can change the frame, then clearly you should be able to start an animation too. But what if it's already animating when it's turned into a Bitmap? Either the animation would have to cancel, or a BitmapSlice would be the same as a SpriteSlice, because it has an animation state. I'm also wondering whether it should be possible to premanently (for that particular slice) modify the frames of a sprite set. When you could create more instances of it by duplicating it. >> 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) Don't worry about that. Recall that the Plan involves turning all places where a script object can be stored into proper typed variables. And if you try to store a slice handle somewhere that doesn't take script objects, like writegeneral, you'll get an error. > 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. It would be possible if slices defaulted to being parentless floating slices, inaccessible except via their handle, but it's too late to make that change, so I guess this idea is dead. > --- > James Paige > _______________________________________________ > 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
