Difference between revisions of "SoC Ideas SpriteSheets"
m |
(→Additional Information) |
||
Line 5: | Line 5: | ||
=Additional Information= | =Additional Information= | ||
+ | |||
+ | currently, all the wesnoth unit animations are based on png images, each image representing the unit in a single pose. In a spritesheet approch, 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 spritesheet approch has huge gains in term of memory consumption, but there are a couple of problems that need to be solved | ||
+ | |||
+ | * 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 approch to the problem will not work |
Revision as of 09:04, 7 March 2010
This page is related to Summer of Code 2010 |
See the list of Summer of Code 2010 Ideas |
This is a Summer of Code 2010 Idea |
Description
Allow wesnoth to support spritesheets
Wesnoth units are made of thousands of small png files, each containing the image of the unit in a given stance. This has the advantage of (arguably) being easier for artists. However this has a huge cost in term of memory usage. The point of this SoC would be to allow wesnoth to support spritesheets : huge images containing a mosaic of all images and related tools/code support
Additional Information
currently, all the wesnoth unit animations are based on png images, each image representing the unit in a single pose. In a spritesheet approch, 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 spritesheet approch has huge gains in term of memory consumption, but there are a couple of problems that need to be solved
- 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 approch to the problem will not work