On 30 April 2010 04:47, James Paige <[email protected]> wrote: > 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
Opps, I was in the middle of typing something here (notice lack of full stop) > What would happen if you started a Hero sprite dissolving, and then > change its frame? Manually changing sprite frames should always have behaviour consistent with sprite animations; so if adopting your dissolve-while-animating proposal, it would continue dissolving. I'm not sure whether it's a good idea to create a difference between a dissolve animation, and applying a (non-animating one-off) dissolve effect to a sprite (instead causing a transform into a Bitmap). Or should a (non-Bitmap) sprite slice be able to permanently remember that it's 65% dissolved? Dissolving slices should probably delete themselves when done, by default, or everyone is going to forget to delete them. >> > 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. But that's not what uiBackground is for. I suggested added a ui colour for the default colour of blank sprites and tilesets, as part of the fix for the remaining part of that uiBackground bug. I think we should be much more liberal with adding new ui colours instead of reusing them in a hunderd places each. >> 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? Normal (to be implemented) animations, not dissolve animations. > 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. That could be done. If it's genuinely useful, I guess we should do so. >> 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? We already have "clone sprite". But I think it should be generalised to "clone slice" >> > 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? Only to read pixel data, or reading something related to number of frames or animations defined on it. > 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. I guess what I was thinking of was garbage collecting bitmaps, which are likely to be used just as 2D pixel arrays rather than slices. But I definitely don't want to code special behaviour for bitmaps. > --- > 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
