Spritesheets instead of single images

[Spixi]

Hi there,

i see that Wesnoth contains lots of single image files. This is not always necessary, because it costs disk space (because of the image headers), memory and lots of disk accesses. It would be much more efficient if images which belong together (e. g. animation frames of a unit type, attack icons ...) are merged into one single file. Some files, e. g. portraits or story images should remain as they are.

Imagemagick offers a tool called "montage" for this purposes and Wesnoth has the CROP image path function to show the correct part of the image to the user. Spritesheets are, alongside tiles and overlays, a common way to reduce file sizes and to increase the performance of software. Many websites make use of Spritesheets, including Google, Facebook, Twitter and MySpace.

Unfortunately I lost my SD Card where I prepared an example scenario which made use of spritesheets. So I created a new spritesheet (I forgot transparency, however ...)

Herea are some useful macros to make working with spritesheets easier.
E. g.:

# Core macros
# Abstract sprite class
#define SPRITE IMAGE X Y W H
"{IMAGE}~CROP({X},{Y},{W},{H})"
#enddef

# Concrete sprite class
#define SPRITE_UNIT IMAGE X Y
{SPRITE {IMAGE} {X} {Y} 72 72}
#enddef
...

------

# Sprite definitions in a separate configuration file for each spritesheet

# Definition of the spritesheet: name convention: prefix spritesheet-
#define spritesheet-fencer
spritesheet-fencer.png
#enddef

# Definition of the sprites: name convention: prefix sprite-
# They can be generated by a script
# montage has a -identify option which prints information about each file which is processed
...
#define sprite-fencer-attack-7
{SPRITE_UNIT {spritesheet-fencer} 144 0}
#enddef
#define sprite-fencer-attack-8
{SPRITE_UNIT {spritesheet-fencer} 144 72}
#enddef
...
-----

# Using the sprite in a scenario
image={sprite-fencer-attack-7}

What do you think about this?

[8680]

See also t29311.

[Astoria]

CABD.

[Spixi]

I know that it CABD. But why isn't it done in mainline? Are there any reasons for that?

[alluton]

So how much memory could you save whit this? Is it 1mb,10mb or rather 50 mb?

[Astoria]

So how much memory could you save whit this? Is it 1mb,10mb or rather 50 mb?

None I think. It's still the same amount of pixels. It'd just cut the amount of files.

[Spixi]

You will save the overhead of each image and you will save memory while decompressing the image

[Astoria]

You will save the overhead of each image and you will save memory while decompressing the image

Even if it would save memory, it's nothing you would notice:

All unit images together are only 16.2 MB, and everything together is 343.7 MB. So even if spritesheets would save 50% space (which is a very large number), it would still only be 8.1 MB. So for something that is less easy to use, you decrease size by 2.5%. This isn't worth it in my opinion.

[alluton]

Saving few mbs doesn't really sound worth it. But if you want to do it you could ask some dev. Saving few mbs is always good thing afterall.

[thespaceinvader]

Honestly, IIRC, the reason why it's not done is because it's not the way it was chosen to do it, and amending all the WML and images to change schema would be a monumental amount of work for basically no benefit. Since it CABD, it could be done for newer content, but again, we have macros and code snippets for making individual-frame animations, and not for spritesheets, so it's not worth the trouble.

[Dixie]

Also (Although I'm not sure if it's preventing this), animations are not necessarily uniform, the number of frames is not always the same for attack animations across all units, sometimes even across a single unit line (AFAIK). There are also various overlays which may or may not be a problem with this...?

[ancestral]

I’ve looked into this, and I didn’t see any savings of file size. But from a design standpoint, it possibly could make it easier to manage.

[Astoria]

I’ve looked into this, and I didn’t see any savings of file size. But from a design standpoint, it possibly could make it easier to manage.

To me it seems to be harder to manage, simply because of the fact that making unit .cfgs requires more and more complex wml to make it work, as well as it being harder to match images to wml coding. Compare archer-attack-1.png to archer.png~CROP(360,144,72,72). Making the macros suggested in the OP will help with those problems somewhat, but to me it seems a waste of time to edit all the animation macros (some of don't work as simply using this method), rewrite all the units and make all the unit images into sprite sheets.

[lipk]

To me it seems to be harder to manage, simply because of the fact that making unit .cfgs requires more and more complex wml to make it work, as well as it being harder to match images to wml coding. Compare archer-attack-1.png to archer.png~CROP(360,144,72,72). Making the macros suggested in the OP will help with those problems somewhat, but to me it seems a waste of time to edit all the animation macros (some of don't work as simply using this method), rewrite all the units and make all the unit images into sprite sheets.

How about this?

Code: Select all

[spritesheet]
  id=fancy_unit_sheet
  path="~/add-ons/Battle_for_Blahblah/images/units/Fancy_Unit.png"
  rows=3
  columns=3
  frame_ids=base,defend-1,defend-2,attack-1,attack-2,attack-3,die-1,die-2,die-3
[spritesheet]
...
[unit]
...
spritesheet=fancy_unit_sheet
...
[frame]
  duration=100
  frame=attack-1
[/frame]
[frame]
  duration=100
  frame=attack-2
[/frame]
...

That actually looks simpler than the current method. Jetrel also mentioned a couple times that it would be cool to have spritesheets (it would make it simpler to do colorshifts), so I guess the only but crucial obstacle in the way is the lack of a developer willing to work on the idea.

[Astoria]

To me it seems to be harder to manage, simply because of the fact that making unit .cfgs requires more and more complex wml to make it work, as well as it being harder to match images to wml coding. Compare archer-attack-1.png to archer.png~CROP(360,144,72,72). Making the macros suggested in the OP will help with those problems somewhat, but to me it seems a waste of time to edit all the animation macros (some of don't work as simply using this method), rewrite all the units and make all the unit images into sprite sheets.

How about this?

Code: Select all

[spritesheet]
  id=fancy_unit_sheet
  path="~/add-ons/Battle_for_Blahblah/images/units/Fancy_Unit.png"
  rows=3
  columns=3
  frame_ids=base,defend-1,defend-2,attack-1,attack-2,attack-3,die-1,die-2,die-3
[spritesheet]
...
[unit]
...
spritesheet=fancy_unit_sheet
...
[frame]
  duration=100
  frame=attack-1
[/frame]
[frame]
  duration=100
  frame=attack-2
[/frame]
...

That actually looks simpler than the current method. Jetrel also mentioned a couple times that it would be cool to have spritesheets (it would make it simpler to do colorshifts), so I guess the only but crucial obstacle in the way is the lack of a developer willing to work on the idea.

And the lack of someone to do it might be a crucial part. It does seem like a lot of work to change a system that already works.