GSoC Sprite Sheets Shuger - Revision history

Egallager: header/link cleanup

2023-05-05T20:07:11Z

header/link cleanup

Shuger: /* Performane */

2010-04-18T21:12:49Z

‎Performane

Shuger: /* Tools */

2010-04-18T21:05:09Z

‎Tools

Shuger: /* Workflow */

2010-04-18T21:03:47Z

‎Workflow

Shuger: /* Implementation */

2010-04-16T21:37:36Z

‎Implementation

Shuger: /* Workfolw */

2010-04-16T21:32:57Z

‎Workfolw

Shuger: /* Implementation */

2010-04-16T21:32:46Z

‎Implementation

Shuger: /* Peroformane */

2010-04-16T21:32:23Z

‎Peroformane

Shuger: /* Memory */

2010-04-16T21:32:09Z

‎Memory

Crab: /* SoC Application */

2010-04-09T22:14:23Z

‎SoC Application

@@ Line 1: / Line 1: @@
 {{SoC2010Student_2|shuger|SoC Ideas SpriteSheets}}
-[[Category:SoC Ideas SpriteSheets]]
+==Description==
 ====Shuger - sprite sheet support====
 I want add sprite sheet support to Wesnoth. The general idea is to assemble multiple small images into few bigger
-=IRC=
+==IRC==
 Shuger
-=SoC Application=
+==SoC Application==
 [http://socghop.appspot.com/gsoc/student_proposal/review/google/gsoc2010/shuger/t127075149747 Wesnoth application]
-=Questionnaire=
+==Questionnaire==
-http://wiki.wesnoth.org/User:Shuger
+[[User:Shuger]]
-=Implementation=
+==Implementation==
-==Sprite Formats==
+===Sprite Formats===
 In my idea of implementation there are two possible sprite formats:
 * separate files
 * sprite sheet
-===separate files===
+====separate files====
 Current way of managing sprites, each image in a separate file.
 wml remains the same.
-===sprite sheet===
+====sprite sheet====
 This format is not for manual editing. It is created from separete files or normal sprite sheet automatically. To generate it special packing algorithms will be used to optimize it's size. This will be the format normally used. Generation should occur at build time uing a custom tool added to build process. It will be possible too run tool manually if someon desires.
@@ Line 53: / Line 51: @@
 Many sprites have image (say 72x72 pixels) where only a part is actually a sprite and the rest is wide transparent border. This doesn't considerably impact image size on disk, because of png compression but is taking significant amount of uneeded memory when loaded into SDL surface (which doesn't use compression). The point of this step is to crop the image by finding a minimal rectangle to fit entire sprite in and then store the size and offset of this rectangle in comparison to original image in order to blit image properly.
-==Performance==
+===Performance===
-===General info===
+====General info====
 When optimizing anything you can never assume anything that's why all things mentioned in this section must be profiled in prototype stage of implementation to see if they bring any considerable gains.
-===RLE Surfaces===
+====RLE Surfaces====
 SDL allows RLE surfaces. Typically RLE alogrithms are used to compress images, but SDL RLE surfaces are made for speed not for memory usage. This is going with some additional processsing that's needs to be done during loading. Despite for SDL RLE focus on speed in images like in wesnoth were there are long horizontal strips of the same color(example: transparent border) there is also smaller memory usage.
-===Caching===
+====Caching====
 Proper use of caching may lower memory requiements. Instead of holding spritesheets in memory at all times, only the needed ones should be loaded. This can be implemented by using a caching algorithm to manage what spritesheets to keep in memory an which ones to load/unload.
@@ Line 67: / Line 65: @@
 Other game code shouldn't have to concern itself with were the image is(memory/hard drive) so it should fetch them threw a special locator.
-===Packing===
+====Packing====
 Artists cannot be expected and shouldn't be bothered with making spritesheets memory efficient. Therefore during spritesheet loading all sprite frames from current group(ex. elf warrior) will be fetched from their respective sources and put on new generated spritesheet. Special packing algorithm will be used to make it efficient. This problem is algorithmically hard therefore different algorithm should be considered and tested before final choice can be made. One example algorithm is here: http://www-rcf.usc.edu/~skoenig/icaps/icaps04/icapspapers/ICAPS04KorfR.pdf
-==Tools==
+===Tools===
 Important part of making it easy for artists to work with spritesheets are tools. There will be a tool that would allow to generate spritesheets from multiple images and modify or create wml accordingly. It will also allow to update already done spritesheet if needed. It tool will be written in python with simple to use gui(pyQt or pyGTK can be used for this).

@@ Line 53: / Line 53: @@
 Many sprites have image (say 72x72 pixels) where only a part is actually a sprite and the rest is wide transparent border. This doesn't considerably impact image size on disk, because of png compression but is taking significant amount of uneeded memory when loaded into SDL surface (which doesn't use compression). The point of this step is to crop the image by finding a minimal rectangle to fit entire sprite in and then store the size and offset of this rectangle in comparison to original image in order to blit image properly.
-==Performane==
+==Performance==
 ===General info===
 When optimizing anything you can never assume anything that's why all things mentioned in this section must be profiled in prototype stage of implementation to see if they bring any considerable gains.
@@ Line 66: / Line 66: @@
 Other game code shouldn't have to concern itself with were the image is(memory/hard drive) so it should fetch them threw a special locator.
 ==Tools==
 Important part of making it easy for artists to work with spritesheets are tools. There will be a tool that would allow to generate spritesheets from multiple images and modify or create wml accordingly. It will also allow to update already done spritesheet if needed. It tool will be written in python with simple to use gui(pyQt or pyGTK can be used for this).

← Older revision		Revision as of 21:05, 18 April 2010
Line 68:		Line 68:

	==Tools==		==Tools==
−	Important part of making it easy for artists to work with spritesheets are tools. There ~~should~~ be a tool that would allow to generate spritesheets from multiple images and modify or create wml accordingly. ~~Such~~ tool will be written in python with simple to use gui(pyQt or pyGTK can be used for this).	+	Important part of making it easy for artists to work with spritesheets are tools. There will be a tool that would allow to generate spritesheets from multiple images and modify or create wml accordingly. It will also allow to update already done spritesheet if needed. It tool will be written in python with simple to use gui(pyQt or pyGTK can be used for this).

@@ Line 66: / Line 66: @@
 Other game code shouldn't have to concern itself with were the image is(memory/hard drive) so it should fetch them threw a special locator.
 ==Tools==
 Important part of making it easy for artists to work with spritesheets are tools. There should be a tool that would allow to generate spritesheets from multiple images and modify or create wml accordingly. Such tool will be written in python with simple to use gui(pyQt or pyGTK can be used for this).

← Older revision		Revision as of 21:37, 16 April 2010
Line 73:		Line 73:

	3. Special tool will be run at build time to process al images and sprite sheets		3. Special tool will be run at build time to process al images and sprite sheets
		+
		+	==Tools==
		+	Important part of making it easy for artists to work with spritesheets are tools. There should be a tool that would allow to generate spritesheets from multiple images and modify or create wml accordingly. Such tool will be written in python with simple to use gui(pyQt or pyGTK can be used for this).

@@ Line 67: / Line 67: @@
 Other game code shouldn't have to concern itself with were the image is(memory/hard drive) so it should fetch them threw a special locator.
-==Workfolw==
+==Workflow==
 . Artist makes sprite bay making separate images or normal sprite sheet.

← Older revision		Revision as of 21:32, 16 April 2010
Line 66:		Line 66:

	Other game code shouldn't have to concern itself with were the image is(memory/hard drive) so it should fetch them threw a special locator.		Other game code shouldn't have to concern itself with were the image is(memory/hard drive) so it should fetch them threw a special locator.
−
−	~~==Performance==~~
−	~~Croping sprites will increase blitting speed beacause there will be less data for SDL to process in blitting functions.~~

	==Workfolw==		==Workfolw==

@@ Line 53: / Line 53: @@
 Many sprites have image (say 72x72 pixels) where only a part is actually a sprite and the rest is wide transparent border. This doesn't considerably impact image size on disk, because of png compression but is taking significant amount of uneeded memory when loaded into SDL surface (which doesn't use compression). The point of this step is to crop the image by finding a minimal rectangle to fit entire sprite in and then store the size and offset of this rectangle in comparison to original image in order to blit image properly.
-==Memory==
+==Peroformane==
-First gain for the memory will come from cropping sprites as described earlier. Second will come from using a cache. There is no need to store every spritesheet in uncompressed format as it will requie a lot of memory even if not needed. On the other hand disk operations are very slow so reading spriteshhets during game should be avoided. The solution to this is to hold currently unused sprites in compressed format. SDL_image allows it. Instead of directly loading into a surface images can be loaded without parsing into memory. It will take only as much memory as file on hard drive. Also compressing one big image gives better results then many small ones.
+===General info===
-First step is to load image from hard drive using SDL_RWFromFile function. Then once cached sprite sheet will be needed it will unpacked using IMG_Load_RW (this is from SDL_image library). Once not needed anymore, uncompressed surface will be deleted from memory.
+Because loading an image from hard drive can be slow(disk operations in general then to be very slow) cache can hold currently unused spritesheets in unprocessed format which has the same size as image on the hard drive. SDL supports it (IMG_Load_RW, SDL_RWFromFile, etc).
 This may require some changes to Wesnoth cache code. Also while it may seem that uncompressing raw data is performance loss, it's actually not that slow compared to reading from disk which takes most of the time neded to load image completely.
 ==Performance==