SpriteSheetApplicationSAB - Revision history

Aishiko at 01:27, 23 May 2014

2014-05-23T01:27:27Z

Aishiko: /* Phase Two */

2014-04-15T01:23:50Z

‎Phase Two

Aishiko: /* 13 Week Timeline */

2014-04-15T00:43:30Z

‎13 Week Timeline

Aishiko: /* 13 Week Timeline */

2014-04-15T00:42:29Z

‎13 Week Timeline

Aishiko: /* Proof of Concept */

2014-04-14T22:44:09Z

‎Proof of Concept

Aishiko at 22:35, 14 April 2014

2014-04-14T22:35:52Z

Aishiko: /* WML */

2014-03-30T23:15:20Z

‎WML

Aishiko: /* Goals */

2014-03-30T23:09:43Z

‎Goals

Aishiko: /* Problems */

2014-03-30T23:09:13Z

‎Problems

Aishiko: /* Problems */

2014-03-30T23:08:57Z

‎Problems

← Older revision		Revision as of 01:27, 23 May 2014
Line 328:		Line 328:
	that effect you as an user! And only those details, and thank you for helping		that effect you as an user! And only those details, and thank you for helping
	me make Wesnoth a little bit better.		me make Wesnoth a little bit better.
		+
		+	==Current Thoughts==
		+	To Happygrue
		+
		+	In implementing the spritesheets I am considering storing a vector with the SDC_Rect info (IE {x,y,h,w}) so that when image 5 is needed it pulls out element(5) or element(-1) if the sprites are numbered from 1 instead of 0. My plans for making this work are to create a spritesheet namespace and then when pulling out an image pass the surface (res) into the images_ cache where it will be handled as if it where a single image taken from the disk. In this way I won't have to change anything about how the images are handled for zooming, colouring, etc. But I'm finding that I really should work on getting the WML and parsing of the lua files done first.
		+
		+	I think going with the following tags would be a good way to go;
		+	[Spritesheet]
		+	File=file_path/name.png
		+	[Sprite]
		+	SpriteID=1
		+	SpriteName="Attack_1" this an optional feild
		+	Location=[x,y,w,h]
		+	[/Sprite]
		+	-- More Images here
		+	[/Spritesheet]
		+
		+	This differs from the proposal in that the [Image] tag already exists for another purpose, so I changed it to Sprite and changed the rest to match (uniformity and descriptive too) and Cooridante/Location now basically returns an SDL_Rect. [Frame] tags are also already taken in the animation section.
		+
		+	I think that for this to work I need to get the basics in place for the following by mid June.
		+	1) working cache
		+	a) load the spritesheet into the proper cache
		+	b) extract and put an unscaled copy into the correct cache (unscaled I think)
		+	2) wml
		+	a) spritesheet tags
		+	b) spritesheet animation syntax

@@ Line 153: / Line 153: @@
 test on that and I only have Windows in a VM, so most testing will be done under
 Linux I'll depend on the various developers that use windows to let me know how
-it is affecting the running under Windows)
+it is affecting the running under Windows & Macs)
 ==Deliverables==

@@ Line 255: / Line 255: @@
+|
 |June 1 - 15:
+|
 * Add a get_spritesheet_frame function to get the image of the sprite we need right now.
 * Start on the program to generate the WML spritesheet Code.

@@ Line 255: / Line 255: @@
+|
 |June 1 - 15:
+|
 * Add a get_spritesheet_frame function to get the image of the sprite we need right now.
 |-
+|
@@ Line 262: / Line 357: @@
+|
 * Implement new WML snytax for the spritesheets.
 |-
+|

@@ Line 21: / Line 21: @@
 This is not quite done, its still rigid and inflexiable to meet our artists needs, however that can be fixed.  It also doesn't send an error code and needs to be tested.  It relies on all the images in row being the same height and each column being the same width was the plan but it really should be fine with varying widths I think.  All the images need to be pressed right up to each other, with borders of 1 pixel in width all around them.  The first row needs to be blank put for pixel 0,0 for that contains the border colour and then Row1 HAS to start at pixel 1,0.  Otherwise its fine.  Ohhh and all it does is FIND the images and returns a std::vector<SDL_Rect> it doesn't actually do anything with them, no handling of malformed sheets, and no error codes or logging (though there is a place for it it just currently contains a comment).
-However I see this as becoming a powerful tool that dev that can compile wesnoth can compile as well, and as a standalone it means the artists that don't mess with the code do not have to compile wesnoth once fully implemented.
+However I see this as becoming a powerful tool that devs that can compile wesnoth can compile as well, and as a standalone, it means the artists that don't mess with the code do not have to compile wesnoth once fully implemented.
 ==Implementation Ideas==

@@ Line 13: / Line 13: @@
 Aishiko, Aishiko_laptop
-==Prelim Implementation Ideas==
+==Patches==
 ===Goals===
 Eliminate as many small single images as possible from the program.
@@ Line 46: / Line 57: @@
 will be dropped.
-==Plan A==
+==The Plan==
 ===How This Will Work===
 The way this will work is each sheet will be a grid of one colour that is not
 used in any of the sprites (say a shade of pink) this RGBA colour is a Primary
-Key, it will lay out a grid of equal sized areas within our spritesheet.  Then
+Key, it will lay out a grid of areas within our spritesheet.  Then
 each of those grid squares (or rectangles) each frame/image has a second border
 of colour, say a different shade of pink.  Each unit's spritesheet will then be
@@ Line 65: / Line 76: @@
 *Lower X
-So each Spritesheet will generate a SpriteAddress Object and will have objects
+Each sprite will be returned as a SDL_Rect in a vector, that vector will be named whatever the unit is.
 ===WML===
 Each Spritesheet will have a Spritesheet set of tags in the unit config file, it will look something like:
@@ Line 147: / Line 105: @@
 Each animation sequence called by doing a call like:
-  image="units/Elvish_Sorceress[1~10,1,2].png:[80*5,100*2,80*5]"
+  $Elvish_Sorceress[1~10,1,2]:[80*5,100*2,80*5] or <Elvish_Sorceress>[1~10,1,2]:[80*5,100*2,80*5]
-Almost like a normal call but to a single image file inste4ad of several files.  Out of the Elvish_Sorceress.png, images 1-10 and then 1 and finally 2 are called for the attack sequence in this case.
+Almost like a normal call but to a single image file instead of several files.  Out of the Elvish_Sorceress.png, images 1-10 and then 1 and finally 2 are called for the attack sequence in this case.
 ===Spritesheet Details===
-Each Spritesheet will have each unit outlined in a box (Colour and size matters not in this version unless we want to implement a side program that will parse out the correct information for the artists.)  everytime there is an added frame the artist just needs to add the correct information as above to add it in, they will not have to be in any sort of order IE Image 1 can be beside Image 50.  There is the added overhead on the artist to make sure they add the right Xs and Ys to make it work.  However this way has less processing overhead to make it work and see more positive gains from moving to spritesheets.
+Each Spritesheet will have each unit outlined in a box (Colour and size matters not in this version unless we want to implement a side program that will parse out the correct information for the artists.)
 On loading an image if the [SpriteSheet] tags are found then it will automatically check for each called image within the spritesheet's definition pulling out the requried frames as needed.  This method will require no more parsing overhead then the usual requirements of parsing the data in the config (IE no need to "scan" the image file looking for grids or borders or anything like that.  The spritesheet can be packed as tightly as desired by the artist, and even notes left in the file, such as a block of text that says "Attack animation here".  Each unit can have more then 1 spritesheet however, they can only have 1 image with an ImageID, this is unique to the unit not the spritesheet file.

@@ Line 21: / Line 21: @@
 #* Terrain
 #* etc
-# Menus, mouse pointers, etc. Optional Goal  I doubt at this point that I'll
+# Menus, mouse pointers, etc. Optional Goal  I doubt at this point that I'll make it this far.
 # Reuse as much as the existing syntax as possible
-# Create Unit Tests to make sure that the areas modified are as good as I can
+# Create Unit Tests to make sure that the areas modified are as good as I can make them.
-make them.
+# Make it easy for the artists to add sprites to a sprite sheet:
 # Make it easy for the artists to add sprites to a sprite sheet:
 ===Problems===
 * Not all units and terrain are 72x72

@@ Line 31: / Line 31: @@
 * Not all units and terrain are 72x72
 * Adding a boarder around each image to make it easier for the artists to see what sort of space they have to work with will make taking the current images and converting them a bit harder as well as creating a script to convert them (which remains a soft goal, ie if I have to do it AFTER the summer, I'll do that.)  Stupid perfectionist leanings, at least for what I think of to get the project ready!
-* Syntax making sure that its easy to use and understand for the
+* Syntax making sure that its easy to use and understand for the average user
 ===First Steps===