Talk:Plan for raising sprite frame limits

Bob the Hamster: I had originally thought that a total overhaul of sprite storage lumps would be mandatory before we could increase sprite frame limits, but now that upgrade() works in both game and custom, we can increase the sprite frame limits in the same way we increase the size of other binary records, using new entries in BINSIZE.BIN and a bit in FIXBITS.BIN to trigger any initialization of the new frames. A clean-up of the sprite format would still be desirable, but it is a goal that we can pursue separately from the plan for raising sprite frame limits

Raekuul: If we clean up the code first, wouldn't adding new frames be easier? And would a blank frame default to the walk frame, or would there be an option to mimic old behavior?

Bob the Hamster: Code cleanup is always a good thing, but changing a storage format requires careful thought to avoid painful backwards compatibility problems. I'm not sure yet how we will handle blank new frames, but yes, supporting the old behavior is essential.

New sprite file format

NeoTA: I was just thinking about the 'plan for bigger walkabouts' thread on the mailing list, and decided my comments had better go here:

Store each frame-set as a separate file (not each frame, nor each graphics-set). Consider a graphics-set as the sum of all the eligible frame-sets. For example, GS0.000, GS0.001, GS0.002, GS0.003 , GS1.000, GS2.000, GS2.001: graphicset 0 contains 4 framesets (presumably it's a walkabout set with the 4 cardinal directions)

This doesn't provide a way to classify graphic sets (eg hero, enemy, misc).

Perhaps GSH0.000, GSE0.000, GSM0.000 etc (use a filename character for classification) with hex number storage, this allows for <=1048576 graphics sets each containing <=4096 framesets in <=26 categories; in decimal, it would be <=100000 gsets with <= 1000 fsets each in <=26 categories. I think this is adequate.

A frameset could be stored in a format something like

W
H
N
FRAMEFRAMEFRAME

(this would occupy 2+2+2 + (N*W*H/2) bytes for 16color graphics, double that for 256color. A walkabout set like the current walkabout sets would be stored in 4 frameset files, each of which would be 406 bytes, totalling 1624 bytes, which is 24 more bytes than )

In the context of supporting custom-sized sprites, this avoids a lot of trouble; Upsides:

• allows you to reasonably postulate "all frames in a frameset must be the same size", without requiring that all frames in the graphicset are same size,
• avoids excessive I/O (resizing one frameset doesn't require rewriting a whole graphicset file),
• supports the possibility of different graphicsets having different numbers of frames
• utilizes the filename as storage space, which is more inspectable than some number inside a binary file.
• Only unlump the graphicsets you need

Downsides:

• export/import of graphicsets would be slightly more complex
• need to generate a temporary lump to help us lookup how many frames are in each graphic set. This should be trivially doable as part of unlumping, so should only incur a cost if running-without-unlumping is implemented.
• Running-without-unlumping is a better situation: it addresses the 'lump proliferation' problem well by eliminating the need to unlump:)
• Some things won't need animation at all and will be of uniform dimensions. Effectively storing each frame in a separate file seems a bit silly in this case. (what about something like GSM5.___ indicating that each 'frame' in the set should actually be treated as a separate 'frameset', and all frames for the graphicset are included in that one file)

Requirements:

• with variable numbers of frames, we'd probably need 'previous/next frame' keyboard shortcuts for the sprite editor, and possibly 'previous/next graphicset'
• and of course some way to resize a frameset's frames (as a whole)

Lastly, I just realized that it has a serious flaw (the above mentioned lump proliferation). I feel that with some changes this would be resolvable, however, so I'm still posting this.

NeoTA: Even if each graphicset were its own file, this would still be serious lump proliferation (500 graphicsets -> 500 files). Perhaps using sublumping would help: eg. HEROGFX.BIN -> contains 500 lumps, 1 per graphicset). These two measures would reduce the number of toplevel lumps per graphicset to equal the current PTx setup (that is, 1/NGRAPHICSETS -- 0.002 for the '500 sets' example)

---

The Mad Cacti: When you talked about sublumping, did you mean to say one lump per graphics set or one lump per frameset? Or would the idea be to lump the framesets for each graphicset up?

Thanks greatly for writing this, I've been thinking about the new graphics format for a while, but with uncertainty. One sublump per graphics set or frameset, lumped up by type seems like a good way to go.

You didn't mention animation, but I'll digress into it:

The end goal that I've been thinking about is flexible sprite animation. An animation would not just be a frame-set, but a set of frames and an animation pattern (I'm guessing you intended this), similar to tile animations patterns but with various improvements.

Thinking with a focus on animations rather than frames or sprite sets, my idea was for a spriteset as an otherwise unorganised bunch of frames each of arbitrary size. This way you could have a single frame appearing in multiple animations, which is actually quite likely.

For example, walkabout sets converted would have an animation for walking in each direction, and one for standing facing in each direction. When actually editing a sprite, you could select a frame from an animation, and have previous/next keys as you described, to switch to the neighbouring frames in that animation.

A problem with this scheme is that you can't say anything about what a frame is without reading the complex animation description. But there should definitely be a way to rearrange the order of the frame so you can give them some logical grouping.

Anyway, the idea in allowing each frame to have an individual size is so that you could draw over the 'edge of the frame' if you wanted to, such as one exceptionally wide frame in a sword swinging animation. The sprite set type would have a set base size - 20x20 for walkabouts - and each frame would have an offset from this, so that have an inherent placement, eg wrt the tile on which a sprite is standing. I imagine that the sprite editor would also place the frames as so to align them as you switch between.

Each animation would have a name, and I envision 3 types:

• Default animations, such as standing animations and attack patterns that suitable graphics sets get automatically. Replaceable, but prehaps not actually stored to file.
• Nondefault predefined meaning. For example "walking left", however also includes animations not added by default when converting old games, eg "walking up-left"
• User defined animations. Callable by name from scripts or other places, such as "Play hero animation" on textboxes.

Is there really any difference to the ease with which nohrio can manipulate graphics between: every frameset of every graphics set having a different size; and every frame a different size?

---

NeoTA: I try to compartmentalize my thinking about this kind of problem; the capabilities of nohrio didn't inform this description. (however, it's true that nohrio could handle either. memmapping works with fixed-width records, however, so a file containing variable-width records would need to be 'mapped' through a wrapper class if you wanted to read many records with random access.)

The limitation of all frames in a set being the same size is to avoid alignment problems, inconsistencies, and complexities. For example, if a frame is drawn according to a centre coordinate, and frames change between an odd width and an even width, it will bounce one pixel to the side (unless we store an anchor point to allow us to control this).

By allowing variance in frame widths, you actually discard the implicit data indicating alignment, and as you said, have to add it back manually. In my opinion, the complexity introduced by variable-size frames is much greater than cost of the pixels wasted in non-wide/tall frames. but if you think of all frames as homogenous, I can understand why you might need to do this.. What about this: rather than every frame being variable size, allow sets of frames which share a size and an alignment .. this reduces the burden of choice on the user.

I also think that the animation system ought to allow us to provide an additional offset per 'virtual frame' (ie. individual frame in an individual animation). (think about this: what do we do about bounding boxes and eg. weapon handles etc?)

Similarly, while I agree with the idea of animation patterns, I think they are also in danger of creating excessive complexity. (without the concept of multiple framesets, next/prev frame is not really sufficient IMO -- when frames > 64, being able to jump to a specific frame or in large steps is needed) If we can work out a GUI position for editing these that 'fits' well, I'll retract that.

re: sublumping: the graphicset format is not specified (since it's basically just a collection of framesets). it also using sublumping seems likely (esp. for ease of CUSTOM operation)

re: identifying frames: In this case, it makes sense to me to have a separate lump listing names for each frame, since this would be quite useful for editing and irrelevant to running. Empty named frames could be implicitly named <name of animation><index into animation> (eg WALKL02) and this name could be written upon changing it.

So, I officially agree that your 'collection of frames + animation patterns referencing them' idea is more practical than my 'graphicsets containing framesets' idea. We do still need a way to categorize graphics+animations though (walk, enemy, attack etc.. this scheme we are working on should render much of the old PT? design obsolete.)

fileformat sketching:

Animations:

(one animation-describing file for each category, with one lump for each animation.. ugh. could be improved. A lighterweight 'lump-like' format seems about right:

RECORDSIZE(SHORT) # size of an animation frame record
ID(SHORT? or INT?)
NRECORDS(SHORT)
DATA(BYTES)
[ID NRECORDS DATA...]

Arguably this is partly-redundant with BINSIZE.BIN, but I'd argue that having record-size information stored locally to a lump makes things more robust, reduces i/o, makes utility writing easier, and arguably just makes more intuitive sense)

FRAMEID
XOFFSET 
YOFFSET
VALUE1
VALUE2 [...repeats]

(special operations being implemented via negative FRAMEID, eg 'wait 5 ticks' : FRAMEID = -1, VALUE1 = 5; 'loop to animation start': FRAMEID=-99, VALUE1=1, 'loop to 6th vframe': FRAMEID=-99, VALUE1 = 5, 'loop to -3th vframe'. i assume this kind of thing is what you meant by more advanced features)

VALUE2 is intended for commands like 'loop to start 2 times' (FRAMEID=-99 VALUE1=0 VALUE2=2)

frame data format:

W
H
XOFFSET 
YOFFSET 
DATA (what is X/Y offset relative to? (bottom center of 'base box' seems appropriate to me.)

)

multiple frames are lumped (in some way). we need a strategy for balancing lumping I/O cost vs quick access when unlumped, this will be an issue as number of frames rise. A categorization of frame types (weapon, hero, etc.) will help here.

---

The Mad Cacti: Took some time to think about this

What about this: rather than every frame being variable size, allow sets of frames which share a size and an alignment .. this reduces the burden of choice on the user.

I don't follow: what logical unit would such a set of frames comprise?

I think most of the alignment/bounding box issues you mentioned are easily solved by the base size boxes; a better explanation: the base box would be the bounding box, because Game would only work with base boxes, and be completely unaware of the real size (and offset) of each frame except in special circumstances (eg. drawing the hero picker menu) where visual instead of logical size needs to be considered. I suppose placing attack graphics over an inbattle sprite would be one of these.

It occurs to me now that you ought be able to set the base box per graphics set rather than being fixed per graphics type, due to the Plan for non-tile-based walking. I guess this means that you ought to be allowed to place weapon handle points outside of the box.

If the frame size defaults to the base size, then the user doesn't have to choose a larger frame size for the whole by guessing how much space they'll need. Does this increase or decrease the "burden of choice"?

what is X/Y offset relative to? (bottom center of 'base box' seems appropriate to me.)

But placing the origin at top left of base box would most directly specifies position and 'extents' over base box in each direction. The engine can place the sprite based on the base size box however it like: in some cases, you would want to anchor the center of the bottom edge at a screen position.

Similarly, while I agree with the idea of animation patterns, I think they are also in danger of creating excessive complexity. (without the concept of multiple framesets, next/prev frame is not really sufficient IMO -- when frames > 64, being able to jump to a specific frame or in large steps is needed) If we can work out a GUI position for editing these that 'fits' well, I'll retract that.

I definitely agree that complexity will have a potentially very high bound. (Not sure what is meant by 'GUI position'.) I imagine that you would be able to select a frame either from the animation, or from the graphics set; next/prev frame would navigate through the appropriate sequence. With key repeat you could move through 64 frames very quickly (though imprecisely).

Perhaps we could create a menu with a 'view' of an animation as just the sequence of all the frames (loops optionally unrolled) to allow easy scrolling and selection. Also, if it necessary to compare two or more frames that are not sequential in any animation, you could reorder the graphics set to place them (possibly temporarily) sequentially; and assumably they are logically related.

Naming frames sounds like a good idea, especially with a way to reorder the frames in the graphics set (which of course updates all animations): for use by scripts. At least one person requested the ability to name tilesets.

We do still need a way to categorize graphics+animations though (walk, enemy, attack etc.. this scheme we are working on should render much of the old PT? design obsolete.)

It might seem to make sense to combine small/medium/large enemy sprites, but the possible complications of doing so seem very difficult. But after the old scheme is obsolete, the logical conclusion seems to be that all sizes of enemy are equal. (However there is a problem with formations: enemies are placed by top left coordinate, and you don't know what size enemy will spawn into an empty slot).

Also, Plan for implementing battlescripting#An alternate possible plan could blur the distinction between walkabout, enemy, and hero graphics.

A lighterweight 'lump-like' format seems about right:

RECORDSIZE(SHORT)

ID(SHORT? or INT?)

NRECORDS(SHORT)

DATA(BYTES)

[ID NRECORDS DATA...]

Ambiguity in your description: is the recordsize per animation, or per animation operation. I guess that's one way to have variable length records: size all records to the largest.

FRAMEID XOFFSET YOFFSET VALUE1 VALUE2 [...repeats]

If X/YOFFSET are only used by frames, then this is redundant to VALUE1/2. A triplet per animation operation would do.

I'm not sure about specifying the offset for every frame. I think modifying the offset would to be fairly rare, such as when creating a hoping animation. Alternatively, you could have an explicit 'set offset' operation, which stays in effect. It's a pretty minor detail though.

Tile animations are rather limiting in length, number, tileset layout requires, etc. and ought to be replaced. It would be nice to use the same animation format, but the operations are somewhat different. I thought that perhaps we could specify some animation operations specific to sprites, others to tiles. Would switching from animation 'template' patterns to one animation per animated tile be a good idea? Maybe ideally support both? This is a mess.

we need a strategy for balancing lumping I/O cost vs quick access when unlumped, this will be an issue as number of frames rise.

Odd, I only realised after multiple readthroughs that you suggested storing each frame in a lump. I suppose that is doable, but is it very benficial? The benefit is to be able to extract a frame as a self contained file; but it is not really self contained, since the bitdepth was not specified. Would the filename encode any information?

Loading an RPG (without unlumping) by creating an index of all lumps and sublumps and subsublumps starts to become large and expensive - clearly you would only want to index the sublumps of a graphics set when loading it. I don't see why you would need fast random access to a specific frame without loading the whole graphics set.

Animation Patterns

tl;drt; (too long, didn't read thoroughly)

Here are my thoughts:

It would not be a bad idea to look at how other games/engines handle sprites/animations. Off hand, the Doom engine would not be a bad program to model our system after.

ZDoom's DECORATE format

Now, granted, DECORATE is overkill. DECORATE is used to create entire 3d entities with behaviour and stuff, which we don't need. However, we could use the Actor States format to define our animations. It looks something like (adapted to how we might use it):

Idle:
BOB A 5
BOB B 5
BOB C 5
goto Idle

Attack:
BOB D 8
BOB E 3
BOB F 3
BOB A 2
end

#etc...

BOB is the name of the sprite set, and A, B, C, etc are the names of the individual frames.

SIDEBAR: Doom uses A, B, C, etc, because each frame actually corresponds to 8/16 direction sprites, depending on the angle from the Player

So, our Idle animation would consist of three frames, each being on screen for 5 ticks, before looping. Our Attack animation is four frames (one of which is part of the Idle animation), on screen for variable times, etc.

Another thing that DECORATE has is Actions, whereby each animation frame can also have some sort of behaviour defined with it. In Doom, it might be A_Chase, which causes the actor to try and go after its target. But, in the OHR, we might have A_ShowWeapon(5,6) (which shows the weapon sprite at (5, 6), if any) or such things.

So, all this is fine for a single actor, but what about the other 600 enemies that have the exact same animation, just different sprite names? Well, what if we allow this syntax:

Idle:
* A 5
* B 5
* C 5
goto Idle

#etc

This is not part of DECORATE, by the way, just something I thought up now. In the enemy editor (for example), you could choose the sprite (set), and the animation pattern, and that would be that. If you wanted certain animations to be different, you might do something like:

@import "generic-enemy"
Idle:
* A 10
* B 3
* C 3
goto Idle

And, this would have the same patterns as the hypothetical generic enemy, just a different Idle animation.

"What would the specific labels do?"

Good question. I suppose that we could have a number of "fixed" labels, which always mean the same thing. For example, Idle, Attack, etc in battle which mean the same thing for everyone. Plus, we could allow (say) attacks to have animations attached to them that cause the attacker or attackee to use a specific animation if they have it, or fall back to "Attack"/"Defend" if they don't.

Hopefully someone other than me can make sense of this, because it could be really cool and flexible...

---

The Mad Cacti: Feature-wise, this is nearly a subset of the above, except that you are separating patterns and the frames they operate on, and can therefore make one pattern inherit from another. (But the set of animations for a graphics set generally won't be large enough for me to see how you would justify the added complexity of inheritance.) Also, you seem to allow jumping from one animation to another, but that could be supported in the above format with "Play animation" or "Change animation" animation operations. Other than that, it's got some strange artifacts, and is less flexible.

You might well want to have a bunch of graphics sets which all use the same animation patterns, so that you can just create one template, copy, and draw over it, good also for external editing. Well, except for variable sized frames. But this definitely sounds like a good feature to have; I don't know yet how to incorporate it into the above plan.

In the enemy editor (for example), you could choose the sprite (set), and the animation pattern, and that would be that

The sprite sets are drawn for a certain animation pattern, and I don't see any reasonable exception (we can add conditional aniamtion operations), so it wouldn't make sense to do anything other than set a certain pattern for each sprite set.

File format-wise, I don't think such a textual format is a good idea. It's a pain to parse and generate. What is the point if users create the animation in an editor instead of writing them manually anyway?

This particular format seems to limit graphics sets to 26 frames (or 52?)

---

Mike C.: Bear in mind that this is just an idea...

This particular format seems to limit graphics sets to 26 frames (or 52?)

DECORATE does, yes, but we don't have to. We could just as easily use numbers instead of letters. They use letters because there's another level of abstraction involved.

Feature-wise, this is nearly a subset of the above, except that you are separating patterns and the frames they operate on, and can therefore make one pattern inherit from another.

I'll be honest: I haven't looked closely at what I believe may be a specification of a format above, because it's a wall of text. Make it look nice like my examples, and then I'll be more able to comment on it.

(But the set of animations for a graphics set generally won't be large enough for me to see how you would justify the added complexity of inheritance.) Also, you seem to allow jumping from one animation to another, but that could be supported in the above format with "Play animation" or "Change animation" animation operations. Other than that, it's got some strange artifacts, and is less flexible.

Currently, the set of animations aren't large enough, but with a flexible format like this, there's no reason you can't have 30 different animation patterns, for various things. And, the idea behind the inheritance, etc is that... well, let's pretend we have a bunch of heroes with similar animations. For some animations, they're the same (victory, weak, etc). But, for others, they aren't (Bob swinging his hammer is different from James tossing his Spam is different from ...).

File format-wise, I don't think such a textual format is a good idea. It's a pain to parse and generate. What is the point if users create the animation in an editor instead of writing them manually anyway?

No matter what format one uses, it is going to be complicated to write an editor for. The file format is almost an afterthought, compared to that.

And, speaking of which, I believe a text-based format would be superior to a binary one. There's no reason NOT to allow someone to edit it manually.

Also, please keep in mind that I'm not advocating using DECORATE. Like I said above, that's stupid. I'm just bringing up an example of a format that's used in other projects successfully, which we might adapt in some form to this one.

---

NeoTA:

I've resolved the 'RECORDSIZE' ambiguity.

If X/YOFFSET are only used by frames, then this is redundant to VALUE1/2. A triplet per animation operation would do.

If your VM is designed in that way, I suppose that's fine. I like the idea of making offset adjustments with a special op (they must be absolute with the origin being whatever the reference point is for the bounding box). I suppose also that each normal frame should imply 'wait 1' (as it clearly does in Mike's example)

Odd, I only realised after multiple readthroughs that you suggested storing each frame in a lump. I suppose that is doable, but is it very benficial? The benefit is to be able to extract a frame as a self contained file; but it is not really self contained, since the bitdepth was not specified.

.. each frame in a 'lump' (which could be a normal lump, or something that's very similar), to be precise. What else are you going to do? bitdepth is simply something I didn't think to add (I was assuming 16 color) The benefit in my opinion is not to be able to extract a frame as a self-contained file per se, but to access it as a discrete entity. Storing each frame individually in the top-level RPG file and avoiding sublumping that way is perfectly doable, but we would definitely want to avoid unlumping 'unnecessary' stuff if we did this.

Naming frames is sensible, but in the above scheme would be limited to 8 characters (MYFRAME1.FRM?)

GUI position

just means -- where the heck are you going to fit animation pattern editing in the GUI that will be readily accessible most times you need it? That's all.

I don't follow: what logical unit would such a set of frames comprise?

The idea behind 'sets of frames of the same size' was to divide up the graphics in a category by dimensions. For instance, all up/down walkabouts might have the same dimensions, as could all left/right walkabouts.

If the frame size defaults to the base size, then the user doesn't have to choose a larger frame size for the whole by guessing how much space they'll need. Does this increase or decrease the "burden of choice"?

It keeps it the same. To be fair, technically, you could implement either autocropping (and auto-offset-adjustment) for individual frames or autosizing for the frame set.

I'm +1 on textual formats, and inheritance (it's actually more like chaining), and labels. The idea of wildcards needs more work in order to consider whatever naming system we eventually decide on, IMO. Action sets seem like a useful idea if we do use a textual format, I think they need more work to clarify how they will interact with named(or even named+numbered) frames.

Textual formatting: I think if a textual format is used, it needs to have clearer separation between labels and their 'content'. An easy way to do this: output all non-label lines with a fixed indentation, but ignore all whitespace when reading. This makes it readable without demanding the user do anything particular with their whitespace (they could eg. have alternating indentation levels to distinguish between sub-phases)

The Mad Cacti: (Responding just to Mike): Too bad there's no maintenance page that shows long pages including other namespaces; after this edit this'll be the 3rd longest page on the wiki, not including other talk pages.

OK, so I suppose your suggestion is basically just "text, not binary, and separate animation patterns and sprite sets". It wasn't really necessary to mention DECORATE, though considering precedents is not something we do enough of.

So someting like this:

:walking left
frame 3
wait 4
frame 4
iftagon 35 frame 5
iftagon 35 setoffset 5 -5
wait 2
repeat

I'm not against the idea. I notice that it would be nearly identical effort to use a binary file format and add textual import/export as with textboxes, or stick it in nohrio. So what's the advantage?

Have to think more about graphics/pattern separation.

No matter what format one uses, it is going to be complicated to write an editor for. The file format is almost an afterthought, compared to that.

Editing animations and drawing them are completely separate. It would be good for utilities to be able to operate on animations easily too. Of course textual format is easier for some things, and some utilities such as shell scripts.

Currently, the set of animations aren't large enough, but with a flexible format like this, there's no reason you can't have 30 different animation patterns, for various things.

Sure, but you could just copy the animation pattern set and make a few changes. Inheritance would be a huge hassle for us.

The Mad Cacti:

I suppose also that each normal frame should imply 'wait 1' (as it clearly does in Mike's example)

Actually, they don't: when multiple frames are specified on the same line, they each have the same length. Anyway, I think an implicit 'wait 1' is a bad idea for a large number of reasons. But since a frame followed by a wait will be so common, we could combine the two into a single operation. It'll make animations much easier to read in the editor.

.. each frame in a 'lump' (which could be a normal lump, or something that's very similar), to be precise. What else are you going to do?

Concatenate the frames. That's basically the same as a lumped file, but without the lump names. Also, an 8 character limit for frame names isn't very good, so it looks like the lump names wouldn't be anything other than the frame number.

Storing each frame individually in the top-level RPG file and avoiding sublumping that way is perfectly doable, but we would definitely want to avoid unlumping 'unnecessary' stuff if we did this.

There is no unnecessary unlumping if no unlumping at all is done. However, you might still do unnecessary indexing (scanning a lumped file to index the contained lumps)

just means -- where the heck are you going to fit animation pattern editing in the GUI that will be readily accessible most times you need it?

Space on screen? Well clearly there isn't enough space in any of the existing menus. Plan: Replace the existing sprite set menu with one that looks very similar, with 4 modes (excuse the names): spritesets-frames, spritesets-animations, frames, animations. Default to spritesets-frames.

• Spritesets-frames: displays the first few frames of each spriteset, so that each spriteset takes up a small fixed amount of screen space. Switch to Frames on selection
• Spritesets-animations: as above, but preview first few animations and switches to Animations. Exists for symmetry.
• Frames: select a frame to enter sprite editor. Allows copying, pasting, creating, deleting and rearranging frames and setting frame names
• Animations: similar to Frames, but leads to the animation editor (which in turn can also enter the sprite editor)

I'm +1 on textual formats, and inheritance (it's actually more like chaining), and labels. The idea of wildcards needs more work in order to consider whatever naming system we eventually decide on, IMO.

Chaining? I don't know what you mean. It doesn't look a thing like chaining animations to me. As for the wildcards, that looks some relic of DECORATE that's pointless unless we allow a single animation to use frames from several different sprite sets, which sounds like a mess to me. ...As for labels, just noticed you mentioned this. That could be a good idea; haven't thought about it.

Action sets seem like a useful idea

What's an action set? Mike didn't mention them. If you mean the states such as Idle, I don't think a state is any different to an animation. Both animations and DECORATE states can continue forever without finishing.

Mike C.:

The Mad Cacti said:

As for the wildcards, that looks some relic of DECORATE that's pointless

Actually, I made that part up. That's not part of DECORATE.

The Mad Cacti: Right, I meant, specifying the sprite name on each line is a strange relic.

New Proposal

--Hieran Del8 (talk) 07:19, 7 June 2012 (PDT): (Just about the bmp file name) Why would the dimensions be stored in the file name? Do we have access to the bmp header? Would it be less meaningful to call it (set)_(frame).bmp, or per the discussion, just (frame).bmp?

Bob the Hamster (talk): yes, I think you are right. There is no advantage to putting the width and height in the filename. I do like having the number of frames in the set in the filename, but the width and height is pretty pointless

The Mad Cacti (talk):I'm not sold on using BMPs. I added a section exploring my thoughts. My conclusion is that there are no major arguments for or against them. As for PNGs, we had a discussion on the mailing list with the conclusion that using PNGs would be pretty bad idea.

I agree that this proposal is quickly improving. I still want per-spriteset animations (with user-defined per-type default animations). I think it would be bad if you had to add more frame groups to a layout and a one-off global animation to give one sprite a specific animation. Or if you couldn't customise the frame times for global animations like attacking.

(Aside: I don't want to get totally sidetracked into animations right now, but I'd want to make it easy to avoid having to create lots of per-sprite animations. Animations ought to have a command "play all frames in group X in sequence, with delay Y between each" so that they can be robust, and I'd also like to see animation definitions shareable between multiple spritesets without having to be the default)

Naming frames is the solution to the problem with the previous proposal, which was "can you change the spriteset of a sprite to an identically laid-out modification (eg. to indicate that your weapon is charged) without having to worry about its current animation?" Actually, I'm surprised, your solution is more complex than mine. I proposed numbering frame ranges, rather than naming individual frames. Naming frame ranges/groups and just numbering the frames within each group consecutively would be another option.

I think "ign" and "miss" flags are mostly there due to the lack of per-sprite animations. Because of the "editor issues" I would want to get rid of them, but they might be useful for switching a sprite's spriteset, in the middle of an animation, to one that isn't identically laid-out.

Actually I don't understand how the "ign" flag is meant to work.