Yay! This all sounds great so far. I will only comment on a few things On Mon, Jul 7, 2014 at 2:15 PM, Ralph Versteegen <[email protected]> wrote:
> Notice that a Frame is independent of palette information, and doesn't > even know whether it's an 8 bit or 4 bit sprite. And it makes most > sense to store palette information (default 16 colour palette, and/or > master palette number if we support using multiple master palettes at > once) only for an entire spriteset rather than per-frame because all > frames should share a palette. > I agree about all frames sharing a palette. it might be a mistake to bring multiple-master-palette support into this. I think that by thinking of palettes as 16-color vs 256 color, we are making things harder on ourselves than we need to. What we *really* want is N-color palettes, where that number can be anything from 1 to 256 We could convert existing 16 color palettes to N-color palettes that all happen to be 16 colors long. If I am making a sprite, and I need 17 colors, I just add one more. if I need 32 colors, I add those. It might be tempting to try and (partially) remove the palette abstraction, and switch the sprite editor into 256-color mode where you are picking colors directly from the master all the time, but then we lose something useful, which is the ability to say "this manageable palette of colors right here, these are the ones I am working with right now" I know I often miss that functionality when I am working in the maptile editor. Does that make any sense? > > I don't see much problem with allowing different frames in the same > sequence to have different sizes, though. So here's my suggestion, > based on thinking about how you would organise spritesheets: > I guess my complaints about mixing frame sizes was about stuff being positioned by top left corner, but that has already be fixed for NPCs, and any other place where it needs to be fixed can be dealt with. I have no objection :) > > In order to preserve current manual setsliceframe animation and > walktall we can continue to view a spriteset as a list of frames > numbered 0, ..., N-1, each frame of any size, and variable N. Each > spriteset can also have its own animation definitions, because those > are often unique. To support interchangeability abstract to frame > groups. (We could also allow naming individual frames and referring to > them by name (eg "Dead"), but that only goes partway.) Groups are also > numbered from 0, and could optionally have names; each is a list of > consecutive frames, and every frame is in one group. Eg. for an > existing 8 frame walkabout groups 0-3 would contain frames 0-1, 2-3, > 4-5, 6-7. In the sprite editor groups would be visually separated a > bit. > That sounds great. We won't lose any of the existing simplicity, but we will gain a whole lot of benefits. The Reload tree I'm imagining looks like > > *spritesets > **spriteset > ***groups > ****group > *****start (frame number). No need to specify end, it's implicit > *****name (optional) > ***animations > ****... > ***frames > ****frame > *****name (optional) > *****... > > I think that once you have Frame serialisation there's not a very > great advantage to using a single generic skeletal Reload tree > structure for all graphics types, but it wouldn't be hard. That > skeleton would just be the above without groups or animations. > I think the "name" nodes are in the wrong place in this tree. You would be assigning names to specific frame positions within a hypothetical set. I don't think you should be assigning names to individual frames within a set.... Of course I might be misunderstanding this tree --- James
_______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
