Description

Allow wesnoth to support spritesheets

Page for the idea: SoC_Ideas_Sprite_Sheets2011

Currently, all the Wesnoth unit animations are based on thousands of small png images, each image representing the unit in a single pose. For terrains the situation is the same, it has a base image with a lot of transitions to other terrains, which are now stored as seperate images.

In a sprite sheet approach, each unit is represented by a single, huge, image where all the unit images are put on a mosaïc pattern and the game knows where to look for a given image.

The advantage of having a large image with all positions is that it's more efficient in memory. Also one large file is more effecient on the harddisk and faster to load than a lot of smaller files. So the change to spritesheets will have a lot of advantages.

Regarding the implementation the student is free to come up with his/her own solution and discuss that with the developers during the application period.

There are no submitted student proposals for this idea

Additional Information

How to build those huge sheets from our current images set?
Wesnoth does not have a fixed number of frames per unit, nor does it have a fixed size for each unit frame. A naïve approach to the problem will not work.

Small mail sent on the dev ML but of general interest for any student studying that proposal

The big problem with spritesheets is that a unit is made of lots of images each with different sizes, and we would like to be able to work with spritesheed in a non-tedious manner

not tedious for artists that want to work with single images, which means either a tool to automate building spritesheets or being able to mix frames from images and from spritesheets or both. being able to re-split a spritesheet would probably be usefull too
not tedious for animation developers, i.e never have to calculate coordinates and sizes to fill WML data, it could either be generated from the spritesheet, or the spritesheet could somehow contain the information (like a pink border around frames)
not tedious (of course) for artists that like working directly with spritesheets. I don't know very well what their constraints would be
not having to change the current WML would be a plus

your proposal doesn't really explain how to solve all these problems,nor did you show that you studied how images are currently loaded in wesnoth, and now current code would be impacted. Hint: that's all in src/image.?pp

here is an idea on how to do it, though you should build on it, not just redescribe what i'm putting below.

WML is unchanged, i.e WML refer to image files without any special information

in every image directory we add an image with a special name that is the spritesheet for that directory, and a WML file that matches filenames from that directory with the position in the spritesheet
when the game is looking for an image, if the file exists it loads the file, if not it loads it from the spritesheet
a tool is provided to take all images in a directory and make the spritesheet + WML (a reverse tool could be usefull but not mandatory)

So, if an artist edits a spritesheet, the new image is loaded correctly, if an artist would rather use the image instead, he just has to add the image in the directory and it would complement the spritesheet or replace what's on the spritesheet transparently.

As part of the release packaging, spritesheets would be regenerated so distributed content would be spritesheet based

there are a few problems remaining with that, but i'll let you and any other potential student find them out and solve them :)

Whom to ask about this

Boucman (developer for the unit animation engine)
thespaceinvader (artist, for usability questions)