Plan for raising sprite frame limits

This article or section is not complete. If you wish, you may finish it, and remove this tag when you are done.

• More discussion is needed before we can formulate a plan for this.
• Raising max frames per set
  • (Maybe?) store each graphics-set as a separate file (not each frame). As a nice side-effect, could make sprite-set import/export hella easy
  • Changing the way Game and Custom treat sprites is a must. Frames need to be treated as individual bitmaps, in a separate UDT (Sprite would work). (partially done)
  • Given that, then Sprite Sets could be implemented either as an array in the context of whatever is using the sprites (eg, a hero has an array of frames that comprise its graphics) or as an abstraction (i.e. a Sprite is a collection of Frames).
• Using new frames
  • Heroes should have settings for which fames are used for which animations. These should all default to the current fixed frame numbers (this part can be done even before the max frame limit is raised)
  • Whatever scheme is developed here can later also be used for Plan for animating enemies

Proposal

This proposal is mostly just James thinking out loud, but he needed to write it down to sort his thoughts. Please discuss any glaring problems with these ideas

Definitions

• Sprite frame - a single frame of a sprite. It has a width and a height
• Sprite set - a collection of one or more sprites that have the same size and are related to each other
• Sprite type - a logical grouping of sprite sets and/or animations that are used for a specific purpose
• Sprite animation - a higher level abstraction of sprite animation which may involve frames from multiple sets. The storage format for sprite frames and sets does not need to be aware of it. This proposal does not discuss sprite animations.

Sprite Storage

Goals

• Store in a standard format, for ease of external utilities and editors
  • Our palette storage needs might lend themselves better to a custom sprite format.
  • It might be better to have external editors stick to using the import/export feature. (which could be streamlined or made batchable)
• Easily support many various different sizes
• Separate the storage and the in-editor presentation of sprite records

Proposal A (BMP)

• Store sprites in BMP format. We already have loaders/savers for it.
  • Our loaders for BMP are missing many extensions
• Store sprites in a simple custom format.
  • PNG support would be great also
• Each sprite frame should be a single file. This is an advantage over storing sprite sets together in a strip (like the export/import format) because it makes it very easy to leave out optional frames, which will be an important feature for enemies
• Sprite lump filenames are: (type)_(index)_(framename).bmp where framename might be prefixed with zero or more groups, if the frame is grouped in the layout.
  • For example, a hero sprite's standing picture set might be saved into hero_0_walk-stand.bmp
  • A Walkabout frame might be saved to walkabout_0_down-A.bmp
• For 4-bit and 8-bit (indexed-into-master) graphics, the palette attached to each BMP would be mostly for convenience only (a copy of the PAL palette); Custom & Game should ignore it.

Pros of BMP usage

• External editors can use existing BMP import/export code
• Exporting by copying files out of an .rpgdir is easy (not much help for importing)
• (minor) Users can open .rpgdirs and look through graphics

Cons of BMP usage

• The BMP format is actually much more complex than a simple home grown format would be: every version of Windows seems to add extensions to the BMP format, and we don't support most of them. For example GIMP by default produces 4-bit BMP files that we can't import (bug 957).
• 3rd-party editors/tools should still read and understand lumps describing the layout and other per-spriteset data
• A BMP header, palette, and other metadata per frame increases game file size
• (minor) The actual sprites, and associated per-spriteset data would be in separate files

Proposal B (Custom)

• Use a custom format for frames, something simple.
  • perhaps similar to the in-memory representation?
• Group the frames of a sprite set together in a RELOAD file.
• The filename could be something like (spritetype)_(setnum).reld
  • For example, walkabout sprite set 0 would be walkabout_0.reld

These format proposals still need more thought

Sprite Type Storage

Goals

• Replicate the simplicity of the existing fixed-size frames while allowing fancier and more complex animations, including mixed frame sizes within the same set.
• Support some animation features

Types

Type	old lump	new lump
hero	ohrrpgce.pt0	sprite_hero.reld
enemy A	ohrrpgce.pt1	sprite_enemy0.reld
enemy B	ohrrpgce.pt2	sprite_enemy1.reld
enemy C	ohrrpgce.pt3	sprite_enemy2.reld
walkabout	ohrrpgce.pt4	sprite_walkabout.reld
weapon	ohrrpgce.pt5	sprite_weapon.reld
attack	ohrrpgce.pt6	sprite_attack.reld
boxborder	ohrrpgce.pt7	sprite_boxborder.reld
portrait	ohrrpgce.pt8	sprite_portrait.reld

Proposal

The information about each sprite type would be stored in a RELOAD file.

• spritetype - root node.
  • layout - describes the expected frames for this type using one or more frame or group nodes. Does not strictly enforce this layout. FIXME: does this even belong in the .rpg file? Really only CUSTOM needs to use this, in the sprite editor for adding new sprites, and visually indicating whether a frame in a slice is expected or extra.
    • frame string - adds a named frame. The name must be lowercase alphanumeric, no punctuation.
      • miss string - If this node is present, it means that if the frame is requested but is missing, the named frame will be used instead.
    • group string - adds a named subgroup of frames. Child nodes are more frame or group nodes. The name must be lowercase alphanumeric, no punctuation.

The information about which sets are actually available would be cached in a RELOAD file.

• sets - zero or more set nodes describing sprite sets that belong to this type, ordered by index.
  • set int - one set node exists for each spriteset of this type. The int value is the index used in the storage bmp file name. (The only reason these nodes exist is because it is much cleaner than parsing a filesystem listing to check if the frames exist)

This proposal might still need more work.

layout examples

• layout "hero"
  • group "walk"
    • frame "stand"
    • frame "step"
  • group "attack"
    • frame "A"
    • frame "B"
  • frame "cast"
  • frame "hurt"
  • frame "weak"
  • frame "dead"

• layout "enemy"
  • group "walk"
    • frame "stand"
    • frame "step"
      • miss "walk-stand"
  • group "attack"
    • frame "a"
      • miss "walk-stand"
    • frame "b"
      • miss "walk-stand"
  • frame "cast"
    • miss "walk-stand"
  • frame "hurt"
    • miss "walk-stand"
  • frame "weak"
    • miss "walk-stand"
  • frame "dead"
    • miss "walk-stand"

• layout "walkabout"
  • group "north"
    • frame "0"
    • frame "1"
  • group "east"
    • frame "0"
    • frame "1"
  • group "south"
    • frame "0"
    • frame "1"
  • group "west"
    • frame "0"
    • frame "1"

• layout "weapon"
  • frame "a"
  • frame "b"

Adding Frames vs Inserting Frames

The latest revision of this proposal makes it possible to insert frames gracefully.

Walkabout Issues

The latest revision of this proposal not only makes it easy to mix short and tall walkabouts, but it also allows mixing of 2, 3, and 4-frame walkabouts, even withing different directions of the same walkabout set.

Editor Issues

The new sprite editor's browsing interface will need to be fancier. It needs to be able to show visual hints of grouping and of the miss or ign state of a given frame. The user needs to be clued in to the fact that:

• Some frames cannot be deleted, only blanked.
• Some frames can be deleted, causing them to become a clone of a specific other frame.
• Some frames can be deleted, causing them to be excluded entirely.

Frames Of Different Sizes In the Same Set

• This plan could allow frames of different sizes in the same set. I am not sure I will allow that in the first implementation of it, but it should be simple.
• For sprites being displayed using properly anchored and aligned slices, sudden changes of sized should be already taken care of.
  • Walkabouts already fit this category

See Also

• Plan for animating enemies
• Plan for hero sprite overlays