On Fri, Apr 30, 2010 at 02:07:25AM +1200, Ralph Versteegen wrote: > > >> 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
What would happen if you started a Hero sprite dissolving, and then change its frame? > > 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. Color zero is fine. Or maybe the background color defined in the UI colors menu. I just meant being able to choose between fully opaque and having transparency. > Making backdrop slices optionally transparent sounds reasonable. In > fact I'm pretty sure translparent backgrounds (for textboxes?) is a > feature request. Yeah, optional transparency for backdrops. Transparent backgrounds behind text boxes would be pretty great. They would work nicely for the Gigantor character portraits that I see a lot of recent RPG's using. (I browse the screenshots on http://rpgamer.com/ frquently to keep up to date new RPGs... even if I practically never play any of them :) > > 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? *shrug* Just because we don't have such a thing yet. > > 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. By "animation" are you talking about the dissolve animations, or about a future animate feature of sprites? What if a dissolve applied to a multi-frame sprite would dissolve all frames in parallel? That way if you continue animating, it will (probably) look like the sprite is dissolving while running or jumping or whatever. > 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. Hmmm... maybe a "clone sprite slice" command? > > 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. Hmmm... Yeah, that sounds okay. > > 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. If they defaulted to parentless, what would be the point of leaving them parentless? Although I don't think we can gc slices, we could certainly gc arrays or other data objects. And the existance of arrays would remove the reason to have invisible slices for data holding, which would eliminate (most of) the need for garbage collecting slices. --- James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
