Difference between revisions of "SoC Ideas SpriteSheets"

From The Battle for Wesnoth Wiki
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