On Mon, Oct 11, 2010 at 4:07 AM, Mike Caron <caron.m...@gmail.com> wrote: > First off, a disclaimer: This is not an actual proposal for a data format > for the OHR. This is something I've cooked up for another project which may > or may not ever see the light of day (hopefully, it will, but it's > immaterial to this discussion). > > This is how I've implemented sprites and animations in this other project: > > First, all pixel data is stored in sprite sheets. These are PNGs that > contain all the sprites for a given on-screen entity. I wanted to use a sprite-sheet based system in my proposition, but so far I don't see how to avoid dumping a load of complexity on the user. (as a user, arranging images on a sprite sheet is something I don't want to deal with. Defining some nominal 'default dimensions' and padding to that when adding new sprites would help.)
> Technically, as I am > writing it in .NET, nothing is stopping them from being BMP or JPG or > something, but I prefer PNG for its true-colour and transparency support. > > Then, with each sprite sheet, there is an XML document that describes it: > > <spriteset xmlns="http://mike-caron.com/za" name="link1" file="link.png"> > <frame x="33" y="1" width="16" height="22" ox="8" oy="19" > name="stand-down" /> > > <frame x="3" y="31" width="16" height="22" ox="8" oy="19" > name="walk1-down" /> > <frame x="33" y="31" width="16" height="22" ox="8" oy="19" > name="walk2-down" /> > > <!-- etc. --> > > Each frame has a name, a position and size on the sheet, and an origin. The > origin is aligned up with the actual entity's origin (which, ATM is always > their (x,y) position, but that may be customizable later on) > > Then, after the frame definitions, we have the animation definitions: > > <animation name="stand" deftime="1" loop="no"> > <dir dir="down"> > <frame>stand-down</frame> > </dir> > <dir dir="up"> > <frame>stand-up</frame> > </dir> > <dir dir="right"> > <frame>stand-right</frame> > </dir> > <dir dir="left"> > <frame>stand-left</frame> > </dir> > </animation> > > This is mostly self explanitory. Every frame has either one or four > directions defined, depending on if the sprite has meaningful directions (an > item on the ground, for example, probably only has one direction. An NPC, on > the other hand, will have all four). > > Each frame in a direction can have a time parameter, which describes how > many ticks the frame is displayed for. deftime is just the default such > value. Obviously, as well, if loop is yes, the animation will start from the > beginning. If no, it will just stop on the last frame forever. > > Finally, every entity in the game references both a sprite sheet and an > animation. The idea is that you could change one or the other. For example, > if you get a better shield, the sprite sheet changes from "link1" to > "link2". And, obviously, the animation changes based on what is happening in > the game. Ugh, you're giving me all these awesome ideas :) I'll have to cut down, there are already too many ops. > > A few notes on this structure: > > - There is no accounting for palettes. If you wanted to use a paletted > sprite, then by all means you are able, but don't expect to be able to > change that palette in game. The canonical way to add palette swaps is to > have a different sprite sheet with the same animations (and, I may add some > way to automate this. Eg, "this sprite sheet is exactly the same as this > oth er sprite sheet, so use those definitions") I'm a bit ambivalent now. TMC's proposition of attaching a set of palette indices to each sprite "makes my common-sense tingle" :) I think we need to look at how frequently color swapping is used vs a number of sprites sharing the same palette. If it's high, that favors individually defined frames. If it's low, blobs of glued-together frames. > > - There is also no way to get any fancier animations. I.e, there's no way > to automatically oscillate or go backwards or whatever. The way to achieve > these effects would be to duplicate the frames in the animation. > - I may or may not add sprite flipping. > > - The way the images are laid out on the sheet has absolutely nothing to do > with how they are animated or displayed. If you wanted the same frame, but > offset by 5 pixels or whatever, you just modify the origin. No muss, no > fuss. > > - Also, there are no inherent limitations on how large or small the sprite > is. If you want to make a 2d version of Shadow of the Colossus, then be my > guest! (just, don't expect the video card to necessarily play along ;) > > So... yeah. Make of that what you will, I'm just adding ideas to the pot. I > am aware that this format, as is, is unsuitable for the OHR. It's just my > two cents. > _______________________________________________ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > _______________________________________________ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org