GSoC-SpriteSheets Gabba - Revision history

Esr: Hide historical instance of "SVN" from mediawiki search to avoid false positives.

2013-03-20T23:21:58Z

Hide historical instance of "SVN" from mediawiki search to avoid false positives.

Gabba at 22:00, 10 April 2010

2010-04-10T22:00:13Z

Crab: /* SoC Application */

2010-04-09T22:07:49Z

‎SoC Application

Gabba: /* Project */

2010-04-09T03:18:27Z

‎Project

Gabba: /* Project */

2010-04-09T03:16:47Z

‎Project

Gabba: /* Project */

2010-04-09T03:15:32Z

‎Project

Gabba: /* Uniform sprite sheets output */

2010-04-09T03:15:05Z

‎Uniform sprite sheets output

Gabba: /* Artists' workflow */

2010-04-09T03:10:14Z

‎Artists' workflow

Gabba: /* About Me */

2010-04-09T03:07:42Z

‎About Me

Gabba: /* Uniform sprite sheets output */

2010-04-09T02:49:58Z

‎Uniform sprite sheets output

@@ Line 25: / Line 25: @@
 ==Source material==
-It will be possible to keep '''individual pngs''' on svn, to make life easier for artists which prefer working like that.
+It will be possible to keep '''individual pngs''' on s&shy;&shy;v&shy;&shy;n, to make life easier for artists which prefer working like that.
 * Some artists would prefer to work directly with spritesheets, and the general policy of Wesnoth may end up stating that all artists must work with those (not sure, since up to now I've seen widely varying opinions among devs and artists on the topic). Therefore I will also offer support for what we could call '''"uniform grid" sprite sheets''' such as this one:<br>http://forums.wesnoth.org/download/file.php?id=39338#.png
 *Support is in fact already in Wesnoth for this kind of sprite sheet: an artist can put one together manually, which is easy if you're starting a unit from scratch, and use<br>
@@ Line 52: / Line 52: @@
 When distributing the game (except in source form), we'd include only spritesheets and the generated .cfg files, not original .png or .cfg files.
-*This said, we could consider doing an "artist distribution" of the game, that includes the unprocessed images and WML files, so they can browse this material in a more friendly format, without having to use svn. I would also give them a better idea of the preferred format in which to submit their work.
+*This said, we could consider doing an "artist distribution" of the game, that includes the unprocessed images and WML files, so they can browse this material in a more friendly format, without having to use s&shy;&shy;v&shy;&shy;n. I would also give them a better idea of the preferred format in which to submit their work.
 ==The tool==
@@ Line 133: / Line 133: @@
 ''Concrete example from the drake glider (Glider.cfg):''
-*What it'll look like on svn or in the potential "artists' distro" (i.e., same as now):
+*What it'll look like on s&shy;&shy;v&shy;&shy;n or in the potential "artists' distro" (i.e., same as now):
     [attack_anim]
         (...)
@@ Line 153: / Line 153: @@
     [/attack_anim]
-*What an artist can change it to (in '''any''' version of the game, be it svn, artists' distro or regular package), in order to test a new image:
+*What an artist can change it to (in '''any''' version of the game, be it s&shy;&shy;v&shy;&shy;n, artists' distro or regular package), in order to test a new image:
     [attack_anim]
         (...)

@@ Line 25: / Line 25: @@
 ==Source material==
-* It will be possible to keep '''individual pngs''' on svn, to make life easier for artists which prefer working like that.
+It will be possible to keep '''individual pngs''' on svn, to make life easier for artists which prefer working like that.
 * Some artists would prefer to work directly with spritesheets, and the general policy of Wesnoth may end up stating that all artists must work with those (not sure, since up to now I've seen widely varying opinions among devs and artists on the topic). Therefore I will also offer support for what we could call '''"uniform grid" sprite sheets''' such as this one:<br>http://forums.wesnoth.org/download/file.php?id=39338#.png
-**Support is in fact already in Wesnoth for this kind of sprite sheet: an artist can put one together manually, which is easy if you're starting a unit from scratch, and use "my_sprite_sheet.png~CROP(''sprite_sheet_region'')" in WML to refer to individual frames. [[ImagePathFunctionWML#Crop_Function| ~CROP()]] is currently not memory-efficient, but I intend to fix it as part of my project.
+*Support is in fact already in Wesnoth for this kind of sprite sheet: an artist can put one together manually, which is easy if you're starting a unit from scratch, and use<br>
-**Taking existing .pngs for one unit and putting them together on this kind of uniform grid sprite sheet may become a goal, depending on Wesnoth policy. However this is not trivial, since from what I understood there's zero guarantee that even frames of the same animation will be of the same size. See [[GSoC-SpriteSheets_Gabba#Planned_output| Planned output]] for more details.
+  my_sprite_sheet.png~CROP(''sprite_sheet_region'')
 In the context of my new system, both individual images and uniform grid sprite sheets are the equivalent of "source code", that is, they are what contributors work with since it's handy and "human-friendly". However in the build process I intend to reorganize all frames freely to place them onto optimized sprite sheets, "compiled code" that's only intended to be used by the game engine.
@@ Line 82: / Line 85: @@
 http://www.clanlib.org/beta/images/b/bd/Example_texturepacker.png
 ====Uniform grid sprite sheets output====
-I will also add a uniform sprite sheet generation feature to the tool; this generation will follow these steps:
+Taking existing .pngs for one unit, and putting them together on a uniform grid sprite sheet with which an artist can work directly, may be desirable. However this is not trivial, since from what I understood there's zero guarantee that even frames of the same animation will be of the same size.
 #Extract image list (for instance, all the frames of the Drake Burner)
 #Detect and sort together all images that are of the same height AND/OR attempt to detect the animation order in the WML file, so that related frames are placed together and in order

@@ Line 12: / Line 12: @@
 =SoC Application=
-[http://socghop.appspot.com/gsoc/student_proposal/review/google/gsoc2010/gabba/t127042311772 t127042311772]
+[http://socghop.appspot.com/gsoc/student_proposal/review/google/gsoc2010/gabba/t127042311772 Wesnoth Sprite Sheets]
 =About Me=

@@ Line 22: / Line 22: @@
 How I'll achieve this is by introducing a distinction between source material (human-friendly material artists work with) and generated material (optimized, memory friendly material that the game engine actually uses). The differences between the two will be small enough that the game engine will still be able to run using source material directly, as if sprite sheets had never been added.
-After discussing sprite sheets at lenght with various wesnoth developers and artists, I have concluded that there currently isn't a common opinion on how sprite sheets should be implemented. My source/generated material distinction, in particular, was deemed interesting by some but doesn't gather unanimity. I've therefore revised this proposal to be flexible enough to handle any change in policy that might happen mid-GSoC or later. [[GSoC-SpriteSheets_Gabba#Uniform_grid_sprite_sheets_output| This]] in particular should ensure my proposal stays relevant no matter what.
+After discussing sprite sheets at lenght with various wesnoth developers and artists (both [http://forums.wesnoth.org/viewtopic.php?f=2&t=29311&start=0 in this thread] and on IRC), I have concluded that there currently isn't a common opinion on how sprite sheets should be implemented. My source/generated material distinction, in particular, was deemed interesting by some but doesn't gather unanimity. I've therefore revised this proposal to be flexible enough to handle any change in policy that might happen mid-GSoC or later. [[GSoC-SpriteSheets_Gabba#Uniform_grid_sprite_sheets_output| This]] in particular should ensure my proposal stays relevant no matter what.
 ==Source material==

@@ Line 20: / Line 20: @@
 The general idea of this project is to introduce sprite sheets and their memory, loading time and disk space benefits, while disturbing the workflow of artists as little as possible. They shouldn't need to go through any more hassles than now to keep contributing.
-How I'll achieve this is by introducing a distinction between source material (what artists work with) and generated material (what the game engine actually uses). The differences between the two will be small enough that the game engine will still be able to run using source material directly, as if sprite sheets had never been added.
+How I'll achieve this is by introducing a distinction between source material (human-friendly material artists work with) and generated material (optimized, memory friendly material that the game engine actually uses). The differences between the two will be small enough that the game engine will still be able to run using source material directly, as if sprite sheets had never been added.
 After discussing sprite sheets at lenght with various wesnoth developers and artists, I have concluded that there currently isn't a common opinion on how sprite sheets should be implemented. My source/generated material distinction, in particular, was deemed interesting by some but doesn't gather unanimity. I've therefore revised this proposal to be flexible enough to handle any change in policy that might happen mid-GSoC or later. [[GSoC-SpriteSheets_Gabba#Uniform_grid_sprite_sheets_output| This]] in particular should ensure my proposal stays relevant no matter what.

@@ Line 125: / Line 125: @@
 =Artists' workflow=
-So, how would implementing this system affect how artists work now? In short: not at all, once they've understood the distinction between source and generated content, as you can see below:
+So, supposing the source vs generated material distinction is introduced, how would it affect how artists work now? In short: not at all, once they've understood the distinction between source and generated content, as you can see below:
 ''Concrete example from the drake glider (Glider.cfg):''

@@ Line 15: / Line 15: @@
 =About Me=
-See http://wiki.wesnoth.org/User:Gabba.
+See [[User:Gabba]].
 =Project=

@@ Line 84: / Line 84: @@
 I will also add a uniform sprite sheet generation feature to the tool; this generation will follow these steps:
 #Extract image list (for instance, all the frames of the Drake Burner)
-#Detect and sort together all images that are of the same height
+#Detect and sort together all images that are of the same height AND/OR attempt to detect the animation order in the WML file, so that related frames are placed together and in order
-#Place rows of same-height images on the sprite sheet, leaving a configurable amount of padding between images
+#Place rows of sorted images on the sprite sheet, leaving a configurable amount of padding between images
 #Surround each image with a border of configurable width, to help the artists know where each image stops
 #Output modified WML referring to the new image locations within sprite sheets