On 8 July 2014 09:53, James Paige <[email protected]> wrote: > 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.
Well, do you mean that it doesn't have anything to do with this (which I agree with), or that it's a bad idea? I'm undecided; I give it even chances of being a bad idea :) > 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? Yes, I definitely agree. >> >> >> 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 :) Yes, in general in order to be able to change sprites to whatever size you want they need anchor points (origins/offsets) to describe their placement. Eg the point at which a walkabout, hero, or enemy sprite slice is/will be attached, normally center-bottom edge where it stands. Ideally you'd be free to place the anchors rather than them being fixed to the bottom edge. Otherwise the tail snake-man's walkabout sprite wouldn't be able to extend past the bottom of the tile, for example, without the use of a script. I was fond of the idea of using "anchor rectangles" instead of points, which would usually the same size as the current fixed frame sizes. But single anchor points would be simpler. However using anchor rectangles would mean that rectangle could be used as the slice size when the frame is loaded as a slice, which will be very useful for anchoring a slice, or attaching things to it, while it animating if the animation frames have different sizes, without everything jumping about from frame to frame. >> >> 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 It took me a number of re-reads to understand what you mean, but I guess you mean that if frames are named, then we basically want either a mapping from frame numbers to names, or from (group, frame) pairs to frames. But the names aren't attributes of (in-memory) Frames. I think you're right there. > --- > James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
