Difference between revisions of "SoC Ideas Sprite Sheets2011"

From The Battle for Wesnoth Wiki
m
(Additional Information)
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
{{Template:SoC2011Idea}}
 
{{Template:SoC2011Idea}}
= Submitted proposals: =
+
 
 +
= Description =
 +
<h2>Allow wesnoth to support spritesheets</h2>
 +
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.
  
 
{{#dpl:
 
{{#dpl:
Line 14: Line 34:
 
}}
 
}}
  
= Description =
+
= Additional Information =
<h2>Allow wesnoth to support spritesheets</h2>
+
* How to build those huge sheets from our current images set?
Page for the idea: [[SoC_Ideas_Sprite_Sheets2011]]
+
* 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)
  
Currently, all the Wesnoth unit animations are based on thousands of small png images, each
+
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.
image representing the unit in a single pose. 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 sprite sheet approach has huge gains in term of memory consumption, but
+
As part of the release packaging, spritesheets would be regenerated so distributed content would be spritesheet based
there are a couple of problems that need to be solved by the students
 
  
= Additional Information =
+
there are a few problems remaining with that, but i'll let you and any other potential student find them out and solve them :)
* 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.
 
  
= Whom to bug about this =
+
= Whom to ask about this =
 +
* Boucman (developer for the unit animation engine)
 +
* thespaceinvader (artist, for usability questions)

Latest revision as of 21:54, 31 March 2011


This page is related to Summer of Code 2011
See the list of Summer of Code 2011 Ideas



This is a Summer of Code 2011 Idea



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 6 submitted student proposals for this idea

Arthur Wulf - Spritesheets

I wish to reorganize the sprite system for units & terrain:
Creating an artist friendly workflow & implementing extensile spritesheet functionality.
Doing this I'm planning to accomplish two goals:

  1. Allow artists to make tweaks in animation more quickly and easily.
  2. Improve installation time and loading time of the game. It could also be of benefit to perforamance on ports to mobile devices.

It will simplify the process of adding new content by allowing artists to work with one single large image rather than many seperate files.
After receiving artists feedback we may also want to consider adding an in-game option to refresh sprites w/o exiting the game and restarting.
(In order to test tweaks more quickly)

In addition to working on the spritesheet system I will complete the transition to this new system by creating a tool that merges frames in seperate .png files into an organized spritesheet and creates a new .cfg files that is adjusted to use a spritesheet.
This will have the additional benefit of leaving the choice between the new and existing workflow in the hands of the artist.
See SoC Ideas Sprite Sheets2011 ArthurWulf for more information.

Tom Hadley - Sprite Sheet Creation/Implementation

The first step is to create the sprite sheets by taking the many small sprites that we already have and piecing them together to form a sheet. This sheet must be organized in such a way that the each individual sprite is still easily accessible.

I think the best way to go about accessing the sprites is to have them in a certain location in the sheet. This sheet could then be divided into different image-esque objects using a bi-dimensional pixel struct array, while certain sprites are given certain x-y locations.
See SoC Ideas Sprite Sheets2011 hadleyt for more information.

Nicolas Pépin-Perreault - Spritesheet Implementation

The idea is to implement support for a flexible sprite sheet mechanism within the Wesnoth code base; flexible implies the capacity to deal with variable-sized frames within the same sheet. The project would focus on implementing a 2D array interface to individual sprite sheets, allowing easy and efficient access to single sprites within the sheet with minimal change to the rest of the code base. Other goals would be the creation of a command-line tool to batch convert series of PNG images into a sprite sheet, and a GUI tool to allow artists to easily tweak the visual aspects of unit and terrain sheets.
See SoC Ideas Sprite Sheets2011 Npepinpe for more information.

Sajal- Implementation of images using spritesheets

The idea is to implement a spritesheet for loading images instead of individual png images.Basically, the idea is to design two seperate spritesheet - one for the characters and the other for objects in the environment.It would be flexible and have multiple-sized images.

The 2 spritesheets would be a large png image. If possible,a tool to merge images into a spritesheet would be created, so as to skip the "copy-paste" process . This will also enable other users to add the characters of their choice- which they could design via photoshop/other image-editing programs.
See SoC Ideas Sprite Sheets2011 Sajal for more information.

Karol Kozub - Spritesheets

I would like to implement a tool that would pack images into spritesheets. The tool would use an optimization algorithm to propose an arrangement to the artist, who then would be able to modify it using a GUI. It would also support adding/removing sprites to/from existing spritesheets. I would also implement an spritesheet manager in C++ that would load the images from spritesheets using configuration files generated by the tool.
See SoC2011 Automagic for more information.

Jacob Regan - Consolidation of .PNG's into Sprite Sheets

The goal is to create a logical system for ordering individual frames of animation into a single image file. The implementation of this system has two major parts. First, the code to implement those single image files needs to be developed and tested. Secondly an easy way to manipulate, modify, and add new sprite sheets needs to be implemented. To this end, I propose that each sprite sheet be arranged in a grid, with the rows each representing a different animation action (attack, idle, ect.) and each row representing a frame of the animation.
See SoC2011 Zippydaspinhead for more information.

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)
This page was last edited on 31 March 2011, at 21:54.