https://wiki.wesnoth.org/api.php?action=feedcontributions&feedformat=atom&user=AishikoThe Battle for Wesnoth Wiki - User contributions [en]2026-04-23T13:19:25ZUser contributionsMediaWiki 1.31.16https://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=55061SpriteSheetApplicationSAB2014-05-23T01:27:27Z<p>Aishiko: </p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Patches==<br />
Pull Request 119<br />
Pull Request 130<br />
===Proof of Concept===<br />
https://github.com/Aishiko/getSprite<br />
<br />
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).<br />
<br />
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.<br />
<br />
==Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet:<br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* 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! <br />
* Syntax making sure that its easy to use and understand for the average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===Cache===<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
==The Plan==<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
Each sprite will be returned as a SDL_Rect in a vector, that vector will be named whatever the unit is.<br />
<br />
===WML===<br />
Each Spritesheet will have a Spritesheet set of tags in the unit config file, it will look something like:<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Upper_X=x<br />
Upper_Y=y<br />
Lower_X=x<br />
Lower_Y=y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
OR<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Coordinates=[x,y,x,y] --upper followed by lower x,y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
<br />
<br />
Each animation sequence called by doing a call like:<br />
$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]<br />
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.<br />
<br />
<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
<image>[1~30][80*5,100*2,80*5]", which expands to <image>1:[80],<image>2:[80],<image>3:[80],etc<br />
<br />
or<br />
<br />
$image[2.1~2.10,2.1~2.2]:[80*5,100*2,80*5]<br />
This should take the current<br />
markup language and merely extand it to allow for calling an SDL_Rect from the spritesheet. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated Autogenerated Spritesheet WML added to each. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
===Making WML Painless===<br />
I'll implement a standalone tool that will take 1 or 2 inputs, if 1 just the spritesheet it will then find each image and ask the user to define the image (attack_1 etc) it will then generate a barebones spritesheet config file to be appended to the unit.cfg. If 2 it will take the old unit.cfg, and look for NEW images and REMOVED images, and only add or remove those changed so it doesn't require the user to double check or change image numbers by 1 or 2 everywhere to make adding/removing/changing an image so painful they don't want to do it.<br />
<br />
===Spritesheet Details===<br />
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.)<br />
<br />
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.<br />
<br />
==Testing==<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows & Macs)<br />
<br />
==Deliverables==<br />
{| align="center" border="1"<br />
|Status<br />
|Requirement Level<br />
|Number ID<br />
|Goal Defined<br />
|-<br />
|<br />
|Required<br />
|1A<br />
|Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
|-<br />
|<br />
|Required<br />
|1B <br />
|dynamic so that low mem devices are not adversely effected.<br />
|-<br />
|<br />
|Plan A Only!<br />
|2<br />
|Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
|-<br />
|<br />
|Required<br />
|3A<br />
|Spritesheets that are flexible and easy for artists and WML users to implement.<br />
|-<br />
|<br />
|Required<br />
|3B<br />
|Spritesheets that do not have a fixed size for every frame they hold.<br />
|-<br />
|<br />
|Plan A Only!<br />
|3C<br />
|Nor a Fixed grid size that holds each frame in its border.<br />
|-<br />
|<br />
|Plan A Only! Optional<br />
|3D <br />
|Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
|-<br />
|<br />
|Plan B Only! Optional<br />
|3D <br />
|Not require the borders be a particular width.<br />
|-<br />
|<br />
|Required<br />
|4 <br />
|WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
|-<br />
|<br />
|Required<br />
|5 <br />
|No negative or negible impact on loading times<br />
|}<br />
==Packages Required==<br />
{| align="center" border="1"<br />
|Package Name<br />
|Reason<br />
|Status<br />
|-<br />
|SDL<br />
|Needed for getting the colour information<br />
|Plan A required otherwise Not needed<br />
|-<br />
|Boost<br />
|Might be able to provide a performance boost (no pun intended)<br />
|Optional<br />
|}<br />
<br />
==13 Week Timeline==<br />
{| align="center" border="1"<br />
|<br />
===Status===<br />
|<br />
===Start/End_Dates=== <br />
|<br />
===Goals===<br />
|-<br />
|Current<br />
|March 20 - April 20:<br />
| <br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
|-<br />
|Next<br />
|April 21 - May 18:<br />
|<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
|-<br />
|<br />
|May 19 - June 1: <br />
|<br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant.<br />
|-<br />
|<br />
|June 1 - 15: <br />
|<br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
* Start on the program to generate the WML spritesheet Code.<br />
|-<br />
|<br />
|June 16 - 29:<br />
|<br />
* Implement new WML snytax for the spritesheets. <br />
* Continue on the program to generate the WML spritesheet Code, and have ready to go.<br />
|-<br />
|<br />
|June 23 - 27: <br />
|<br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
|-<br />
|<br />
|June 30 - July 13:<br />
|<br />
* Modify any existing functions that need to be modified to handle sheets that broke.<br />
|-<br />
|<br />
|July 14 - 27: <br />
|<br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
|-<br />
|<br />
|July 28 - Aug 10: <br />
|<br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/python script to convert all the images to spritesheets.<br />
|-<br />
|<br />
|Aug 3: <br />
|<br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
|-<br />
|<br />
|Aug 11 - 17: <br />
|<br />
* Documentation and clean up anything that hasn't yet be done.<br />
|-<br />
|<br />
|Aug 22: <br />
|<br />
* Final evaluation and send the required code snippets to Google.<br />
|}<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.<br />
<br />
==Current Thoughts==<br />
To Happygrue<br />
<br />
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.<br />
<br />
I think going with the following tags would be a good way to go;<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Sprite]<br />
SpriteID=1<br />
SpriteName="Attack_1" this an optional feild<br />
Location=[x,y,w,h]<br />
[/Sprite]<br />
-- More Images here<br />
[/Spritesheet]<br />
<br />
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.<br />
<br />
I think that for this to work I need to get the basics in place for the following by mid June.<br />
1) working cache<br />
a) load the spritesheet into the proper cache<br />
b) extract and put an unscaled copy into the correct cache (unscaled I think)<br />
2) wml<br />
a) spritesheet tags <br />
b) spritesheet animation syntax</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54754SpriteSheetApplicationSAB2014-04-15T01:23:50Z<p>Aishiko: /* Phase Two */</p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Patches==<br />
Pull Request 119<br />
Pull Request 130<br />
===Proof of Concept===<br />
https://github.com/Aishiko/getSprite<br />
<br />
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).<br />
<br />
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.<br />
<br />
==Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet:<br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* 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! <br />
* Syntax making sure that its easy to use and understand for the average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===Cache===<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
==The Plan==<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
Each sprite will be returned as a SDL_Rect in a vector, that vector will be named whatever the unit is.<br />
<br />
===WML===<br />
Each Spritesheet will have a Spritesheet set of tags in the unit config file, it will look something like:<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Upper_X=x<br />
Upper_Y=y<br />
Lower_X=x<br />
Lower_Y=y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
OR<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Coordinates=[x,y,x,y] --upper followed by lower x,y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
<br />
<br />
Each animation sequence called by doing a call like:<br />
$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]<br />
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.<br />
<br />
<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
<image>[1~30][80*5,100*2,80*5]", which expands to <image>1:[80],<image>2:[80],<image>3:[80],etc<br />
<br />
or<br />
<br />
$image[2.1~2.10,2.1~2.2]:[80*5,100*2,80*5]<br />
This should take the current<br />
markup language and merely extand it to allow for calling an SDL_Rect from the spritesheet. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated Autogenerated Spritesheet WML added to each. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
===Making WML Painless===<br />
I'll implement a standalone tool that will take 1 or 2 inputs, if 1 just the spritesheet it will then find each image and ask the user to define the image (attack_1 etc) it will then generate a barebones spritesheet config file to be appended to the unit.cfg. If 2 it will take the old unit.cfg, and look for NEW images and REMOVED images, and only add or remove those changed so it doesn't require the user to double check or change image numbers by 1 or 2 everywhere to make adding/removing/changing an image so painful they don't want to do it.<br />
<br />
===Spritesheet Details===<br />
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.)<br />
<br />
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.<br />
<br />
==Testing==<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows & Macs)<br />
<br />
==Deliverables==<br />
{| align="center" border="1"<br />
|Status<br />
|Requirement Level<br />
|Number ID<br />
|Goal Defined<br />
|-<br />
|<br />
|Required<br />
|1A<br />
|Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
|-<br />
|<br />
|Required<br />
|1B <br />
|dynamic so that low mem devices are not adversely effected.<br />
|-<br />
|<br />
|Plan A Only!<br />
|2<br />
|Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
|-<br />
|<br />
|Required<br />
|3A<br />
|Spritesheets that are flexible and easy for artists and WML users to implement.<br />
|-<br />
|<br />
|Required<br />
|3B<br />
|Spritesheets that do not have a fixed size for every frame they hold.<br />
|-<br />
|<br />
|Plan A Only!<br />
|3C<br />
|Nor a Fixed grid size that holds each frame in its border.<br />
|-<br />
|<br />
|Plan A Only! Optional<br />
|3D <br />
|Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
|-<br />
|<br />
|Plan B Only! Optional<br />
|3D <br />
|Not require the borders be a particular width.<br />
|-<br />
|<br />
|Required<br />
|4 <br />
|WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
|-<br />
|<br />
|Required<br />
|5 <br />
|No negative or negible impact on loading times<br />
|}<br />
==Packages Required==<br />
{| align="center" border="1"<br />
|Package Name<br />
|Reason<br />
|Status<br />
|-<br />
|SDL<br />
|Needed for getting the colour information<br />
|Plan A required otherwise Not needed<br />
|-<br />
|Boost<br />
|Might be able to provide a performance boost (no pun intended)<br />
|Optional<br />
|}<br />
<br />
==13 Week Timeline==<br />
{| align="center" border="1"<br />
|<br />
===Status===<br />
|<br />
===Start/End_Dates=== <br />
|<br />
===Goals===<br />
|-<br />
|Current<br />
|March 20 - April 20:<br />
| <br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
|-<br />
|Next<br />
|April 21 - May 18:<br />
|<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
|-<br />
|<br />
|May 19 - June 1: <br />
|<br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant.<br />
|-<br />
|<br />
|June 1 - 15: <br />
|<br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
* Start on the program to generate the WML spritesheet Code.<br />
|-<br />
|<br />
|June 16 - 29:<br />
|<br />
* Implement new WML snytax for the spritesheets. <br />
* Continue on the program to generate the WML spritesheet Code, and have ready to go.<br />
|-<br />
|<br />
|June 23 - 27: <br />
|<br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
|-<br />
|<br />
|June 30 - July 13:<br />
|<br />
* Modify any existing functions that need to be modified to handle sheets that broke.<br />
|-<br />
|<br />
|July 14 - 27: <br />
|<br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
|-<br />
|<br />
|July 28 - Aug 10: <br />
|<br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/python script to convert all the images to spritesheets.<br />
|-<br />
|<br />
|Aug 3: <br />
|<br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
|-<br />
|<br />
|Aug 11 - 17: <br />
|<br />
* Documentation and clean up anything that hasn't yet be done.<br />
|-<br />
|<br />
|Aug 22: <br />
|<br />
* Final evaluation and send the required code snippets to Google.<br />
|}<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54753SpriteSheetApplicationSAB2014-04-15T00:43:30Z<p>Aishiko: /* 13 Week Timeline */</p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Patches==<br />
Pull Request 119<br />
Pull Request 130<br />
===Proof of Concept===<br />
https://github.com/Aishiko/getSprite<br />
<br />
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).<br />
<br />
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.<br />
<br />
==Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet:<br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* 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! <br />
* Syntax making sure that its easy to use and understand for the average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===Cache===<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
==The Plan==<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
Each sprite will be returned as a SDL_Rect in a vector, that vector will be named whatever the unit is.<br />
<br />
===WML===<br />
Each Spritesheet will have a Spritesheet set of tags in the unit config file, it will look something like:<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Upper_X=x<br />
Upper_Y=y<br />
Lower_X=x<br />
Lower_Y=y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
OR<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Coordinates=[x,y,x,y] --upper followed by lower x,y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
<br />
<br />
Each animation sequence called by doing a call like:<br />
$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]<br />
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.<br />
<br />
<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
<image>[1~30][80*5,100*2,80*5]", which expands to <image>1:[80],<image>2:[80],<image>3:[80],etc<br />
<br />
or<br />
<br />
$image[2.1~2.10,2.1~2.2]:[80*5,100*2,80*5]<br />
This should take the current<br />
markup language and merely extand it to allow for calling an SDL_Rect from the spritesheet. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated Autogenerated Spritesheet WML added to each. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
===Making WML Painless===<br />
I'll implement a standalone tool that will take 1 or 2 inputs, if 1 just the spritesheet it will then find each image and ask the user to define the image (attack_1 etc) it will then generate a barebones spritesheet config file to be appended to the unit.cfg. If 2 it will take the old unit.cfg, and look for NEW images and REMOVED images, and only add or remove those changed so it doesn't require the user to double check or change image numbers by 1 or 2 everywhere to make adding/removing/changing an image so painful they don't want to do it.<br />
<br />
===Spritesheet Details===<br />
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.)<br />
<br />
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.<br />
<br />
==Testing==<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows)<br />
<br />
==Deliverables==<br />
{| align="center" border="1"<br />
|Status<br />
|Requirement Level<br />
|Number ID<br />
|Goal Defined<br />
|-<br />
|<br />
|Required<br />
|1A<br />
|Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
|-<br />
|<br />
|Required<br />
|1B <br />
|dynamic so that low mem devices are not adversely effected.<br />
|-<br />
|<br />
|Plan A Only!<br />
|2<br />
|Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
|-<br />
|<br />
|Required<br />
|3A<br />
|Spritesheets that are flexible and easy for artists and WML users to implement.<br />
|-<br />
|<br />
|Required<br />
|3B<br />
|Spritesheets that do not have a fixed size for every frame they hold.<br />
|-<br />
|<br />
|Plan A Only!<br />
|3C<br />
|Nor a Fixed grid size that holds each frame in its border.<br />
|-<br />
|<br />
|Plan A Only! Optional<br />
|3D <br />
|Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
|-<br />
|<br />
|Plan B Only! Optional<br />
|3D <br />
|Not require the borders be a particular width.<br />
|-<br />
|<br />
|Required<br />
|4 <br />
|WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
|-<br />
|<br />
|Required<br />
|5 <br />
|No negative or negible impact on loading times<br />
|}<br />
==Packages Required==<br />
{| align="center" border="1"<br />
|Package Name<br />
|Reason<br />
|Status<br />
|-<br />
|SDL<br />
|Needed for getting the colour information<br />
|Plan A required otherwise Not needed<br />
|-<br />
|Boost<br />
|Might be able to provide a performance boost (no pun intended)<br />
|Optional<br />
|}<br />
<br />
==13 Week Timeline==<br />
{| align="center" border="1"<br />
|<br />
===Status===<br />
|<br />
===Start/End_Dates=== <br />
|<br />
===Goals===<br />
|-<br />
|Current<br />
|March 20 - April 20:<br />
| <br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
|-<br />
|Next<br />
|April 21 - May 18:<br />
|<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
|-<br />
|<br />
|May 19 - June 1: <br />
|<br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant.<br />
|-<br />
|<br />
|June 1 - 15: <br />
|<br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
* Start on the program to generate the WML spritesheet Code.<br />
|-<br />
|<br />
|June 16 - 29:<br />
|<br />
* Implement new WML snytax for the spritesheets. <br />
* Continue on the program to generate the WML spritesheet Code, and have ready to go.<br />
|-<br />
|<br />
|June 23 - 27: <br />
|<br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
|-<br />
|<br />
|June 30 - July 13:<br />
|<br />
* Modify any existing functions that need to be modified to handle sheets that broke.<br />
|-<br />
|<br />
|July 14 - 27: <br />
|<br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
|-<br />
|<br />
|July 28 - Aug 10: <br />
|<br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/python script to convert all the images to spritesheets.<br />
|-<br />
|<br />
|Aug 3: <br />
|<br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
|-<br />
|<br />
|Aug 11 - 17: <br />
|<br />
* Documentation and clean up anything that hasn't yet be done.<br />
|-<br />
|<br />
|Aug 22: <br />
|<br />
* Final evaluation and send the required code snippets to Google.<br />
|}<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54752SpriteSheetApplicationSAB2014-04-15T00:42:29Z<p>Aishiko: /* 13 Week Timeline */</p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Patches==<br />
Pull Request 119<br />
Pull Request 130<br />
===Proof of Concept===<br />
https://github.com/Aishiko/getSprite<br />
<br />
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).<br />
<br />
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.<br />
<br />
==Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet:<br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* 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! <br />
* Syntax making sure that its easy to use and understand for the average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===Cache===<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
==The Plan==<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
Each sprite will be returned as a SDL_Rect in a vector, that vector will be named whatever the unit is.<br />
<br />
===WML===<br />
Each Spritesheet will have a Spritesheet set of tags in the unit config file, it will look something like:<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Upper_X=x<br />
Upper_Y=y<br />
Lower_X=x<br />
Lower_Y=y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
OR<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Coordinates=[x,y,x,y] --upper followed by lower x,y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
<br />
<br />
Each animation sequence called by doing a call like:<br />
$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]<br />
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.<br />
<br />
<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
<image>[1~30][80*5,100*2,80*5]", which expands to <image>1:[80],<image>2:[80],<image>3:[80],etc<br />
<br />
or<br />
<br />
$image[2.1~2.10,2.1~2.2]:[80*5,100*2,80*5]<br />
This should take the current<br />
markup language and merely extand it to allow for calling an SDL_Rect from the spritesheet. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated Autogenerated Spritesheet WML added to each. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
===Making WML Painless===<br />
I'll implement a standalone tool that will take 1 or 2 inputs, if 1 just the spritesheet it will then find each image and ask the user to define the image (attack_1 etc) it will then generate a barebones spritesheet config file to be appended to the unit.cfg. If 2 it will take the old unit.cfg, and look for NEW images and REMOVED images, and only add or remove those changed so it doesn't require the user to double check or change image numbers by 1 or 2 everywhere to make adding/removing/changing an image so painful they don't want to do it.<br />
<br />
===Spritesheet Details===<br />
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.)<br />
<br />
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.<br />
<br />
==Testing==<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows)<br />
<br />
==Deliverables==<br />
{| align="center" border="1"<br />
|Status<br />
|Requirement Level<br />
|Number ID<br />
|Goal Defined<br />
|-<br />
|<br />
|Required<br />
|1A<br />
|Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
|-<br />
|<br />
|Required<br />
|1B <br />
|dynamic so that low mem devices are not adversely effected.<br />
|-<br />
|<br />
|Plan A Only!<br />
|2<br />
|Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
|-<br />
|<br />
|Required<br />
|3A<br />
|Spritesheets that are flexible and easy for artists and WML users to implement.<br />
|-<br />
|<br />
|Required<br />
|3B<br />
|Spritesheets that do not have a fixed size for every frame they hold.<br />
|-<br />
|<br />
|Plan A Only!<br />
|3C<br />
|Nor a Fixed grid size that holds each frame in its border.<br />
|-<br />
|<br />
|Plan A Only! Optional<br />
|3D <br />
|Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
|-<br />
|<br />
|Plan B Only! Optional<br />
|3D <br />
|Not require the borders be a particular width.<br />
|-<br />
|<br />
|Required<br />
|4 <br />
|WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
|-<br />
|<br />
|Required<br />
|5 <br />
|No negative or negible impact on loading times<br />
|}<br />
==Packages Required==<br />
{| align="center" border="1"<br />
|Package Name<br />
|Reason<br />
|Status<br />
|-<br />
|SDL<br />
|Needed for getting the colour information<br />
|Plan A required otherwise Not needed<br />
|-<br />
|Boost<br />
|Might be able to provide a performance boost (no pun intended)<br />
|Optional<br />
|}<br />
<br />
==13 Week Timeline==<br />
{| align="center" border="1"<br />
|<br />
===Status===<br />
|<br />
===Start/End_Dates=== <br />
|<br />
===Goals===<br />
|-<br />
|Current<br />
|March 20 - April 20:<br />
| <br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
|-<br />
|Next<br />
|April 21 - May 18:<br />
|<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
|-<br />
|<br />
|May 19 - June 1: <br />
|<br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant.<br />
|-<br />
|<br />
|June 1 - 15: <br />
|==13 Week Timeline==<br />
{| align="center" border="1"<br />
|<br />
===Status===<br />
|<br />
===Start/End_Dates=== <br />
|<br />
===Goals===<br />
|-<br />
|Current<br />
|March 20 - April 20:<br />
| <br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
|-<br />
|Next<br />
|April 21 - May 18:<br />
|<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
|-<br />
|<br />
|May 19 - June 1: <br />
|<br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant.<br />
|-<br />
|<br />
|June 1 - 15: <br />
|<br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
* Start on the program to generate the WML spritesheet Code.<br />
|-<br />
|<br />
|June 16 - 29:<br />
|<br />
* Implement new WML snytax for the spritesheets. <br />
* Continue on the program to generate the WML spritesheet Code, and have ready to go.<br />
|-<br />
|<br />
|June 23 - 27: <br />
|<br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
|-<br />
|<br />
|June 30 - July 13:<br />
|<br />
* Modify any existing functions that need to be modified to handle sheets that broke.<br />
|-<br />
|<br />
|July 14 - 27: <br />
|<br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
|-<br />
|<br />
|July 28 - Aug 10: <br />
|<br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/python script to convert all the images to spritesheets.<br />
|-<br />
|<br />
|Aug 3: <br />
|<br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
|-<br />
|<br />
|Aug 11 - 17: <br />
|<br />
* Documentation and clean up anything that hasn't yet be done.<br />
|-<br />
|<br />
|Aug 22: <br />
|<br />
* Final evaluation and send the required code snippets to Google.<br />
|}<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
* Start on the program to generate the WML spritesheet Code.<br />
|-<br />
|<br />
|June 16 - 29:<br />
|<br />
* Implement new WML snytax for the spritesheets. <br />
* Continue on the program to generate the WML spritesheet Code, and have ready to go.<br />
|-<br />
|<br />
|June 23 - 27: <br />
|<br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
|-<br />
|<br />
|June 30 - July 13:<br />
|<br />
* Modify any existing functions that need to be modified to handle sheets that broke.<br />
|-<br />
|<br />
|July 14 - 27: <br />
|<br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
|-<br />
|<br />
|July 28 - Aug 10: <br />
|<br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/python script to convert all the images to spritesheets.<br />
|-<br />
|<br />
|Aug 3: <br />
|<br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
|-<br />
|<br />
|Aug 11 - 17: <br />
|<br />
* Documentation and clean up anything that hasn't yet be done.<br />
|-<br />
|<br />
|Aug 22: <br />
|<br />
* Final evaluation and send the required code snippets to Google.<br />
|}<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54751SpriteSheetApplicationSAB2014-04-14T22:44:09Z<p>Aishiko: /* Proof of Concept */</p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Patches==<br />
Pull Request 119<br />
Pull Request 130<br />
===Proof of Concept===<br />
https://github.com/Aishiko/getSprite<br />
<br />
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).<br />
<br />
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.<br />
<br />
==Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet:<br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* 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! <br />
* Syntax making sure that its easy to use and understand for the average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===Cache===<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
==The Plan==<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
Each sprite will be returned as a SDL_Rect in a vector, that vector will be named whatever the unit is.<br />
<br />
===WML===<br />
Each Spritesheet will have a Spritesheet set of tags in the unit config file, it will look something like:<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Upper_X=x<br />
Upper_Y=y<br />
Lower_X=x<br />
Lower_Y=y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
OR<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Coordinates=[x,y,x,y] --upper followed by lower x,y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
<br />
<br />
Each animation sequence called by doing a call like:<br />
$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]<br />
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.<br />
<br />
<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
<image>[1~30][80*5,100*2,80*5]", which expands to <image>1:[80],<image>2:[80],<image>3:[80],etc<br />
<br />
or<br />
<br />
$image[2.1~2.10,2.1~2.2]:[80*5,100*2,80*5]<br />
This should take the current<br />
markup language and merely extand it to allow for calling an SDL_Rect from the spritesheet. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated Autogenerated Spritesheet WML added to each. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
===Making WML Painless===<br />
I'll implement a standalone tool that will take 1 or 2 inputs, if 1 just the spritesheet it will then find each image and ask the user to define the image (attack_1 etc) it will then generate a barebones spritesheet config file to be appended to the unit.cfg. If 2 it will take the old unit.cfg, and look for NEW images and REMOVED images, and only add or remove those changed so it doesn't require the user to double check or change image numbers by 1 or 2 everywhere to make adding/removing/changing an image so painful they don't want to do it.<br />
<br />
===Spritesheet Details===<br />
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.)<br />
<br />
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.<br />
<br />
==Testing==<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows)<br />
<br />
==Deliverables==<br />
{| align="center" border="1"<br />
|Status<br />
|Requirement Level<br />
|Number ID<br />
|Goal Defined<br />
|-<br />
|<br />
|Required<br />
|1A<br />
|Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
|-<br />
|<br />
|Required<br />
|1B <br />
|dynamic so that low mem devices are not adversely effected.<br />
|-<br />
|<br />
|Plan A Only!<br />
|2<br />
|Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
|-<br />
|<br />
|Required<br />
|3A<br />
|Spritesheets that are flexible and easy for artists and WML users to implement.<br />
|-<br />
|<br />
|Required<br />
|3B<br />
|Spritesheets that do not have a fixed size for every frame they hold.<br />
|-<br />
|<br />
|Plan A Only!<br />
|3C<br />
|Nor a Fixed grid size that holds each frame in its border.<br />
|-<br />
|<br />
|Plan A Only! Optional<br />
|3D <br />
|Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
|-<br />
|<br />
|Plan B Only! Optional<br />
|3D <br />
|Not require the borders be a particular width.<br />
|-<br />
|<br />
|Required<br />
|4 <br />
|WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
|-<br />
|<br />
|Required<br />
|5 <br />
|No negative or negible impact on loading times<br />
|}<br />
==Packages Required==<br />
{| align="center" border="1"<br />
|Package Name<br />
|Reason<br />
|Status<br />
|-<br />
|SDL<br />
|Needed for getting the colour information<br />
|Plan A required otherwise Not needed<br />
|-<br />
|Boost<br />
|Might be able to provide a performance boost (no pun intended)<br />
|Optional<br />
|}<br />
<br />
==13 Week Timeline==<br />
{| align="center" border="1"<br />
|<br />
===Status===<br />
|<br />
===Start/End_Dates=== <br />
|<br />
===Goals===<br />
|-<br />
|Current<br />
|March 20 - April 20:<br />
| <br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
|-<br />
|Next<br />
|April 21 - May 18:<br />
|<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
|-<br />
|<br />
|May 19 - June 1: <br />
|<br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant.<br />
|-<br />
|<br />
|June 1 - 15: <br />
|<br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
|-<br />
|<br />
|June 16 - 29:<br />
|<br />
* Implement new WML snytax for the spritesheets. <br />
|-<br />
|<br />
|June 23 - 27: <br />
|<br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
|-<br />
|<br />
|June 30 - July 13:<br />
|<br />
* Modify any existing functions that need to be modified to handle sheets that broke.<br />
|-<br />
|<br />
|July 14 - 27: <br />
|<br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
|-<br />
|<br />
|July 28 - Aug 10: <br />
|<br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/python script to convert all the images to spritesheets.<br />
|-<br />
|<br />
|Aug 3: <br />
|<br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
|-<br />
|<br />
|Aug 11 - 17: <br />
|<br />
* Documentation and clean up anything that hasn't yet be done.<br />
|-<br />
|<br />
|Aug 22: <br />
|<br />
* Final evaluation and send the required code snippets to Google.<br />
|}<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54750SpriteSheetApplicationSAB2014-04-14T22:35:52Z<p>Aishiko: </p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Patches==<br />
Pull Request 119<br />
Pull Request 130<br />
===Proof of Concept===<br />
https://github.com/Aishiko/getSprite<br />
<br />
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).<br />
<br />
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.<br />
<br />
<br />
==Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet:<br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* 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! <br />
* Syntax making sure that its easy to use and understand for the average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===Cache===<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
==The Plan==<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
Each sprite will be returned as a SDL_Rect in a vector, that vector will be named whatever the unit is.<br />
<br />
===WML===<br />
Each Spritesheet will have a Spritesheet set of tags in the unit config file, it will look something like:<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Upper_X=x<br />
Upper_Y=y<br />
Lower_X=x<br />
Lower_Y=y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
OR<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Coordinates=[x,y,x,y] --upper followed by lower x,y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
<br />
<br />
Each animation sequence called by doing a call like:<br />
$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]<br />
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.<br />
<br />
<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
<image>[1~30][80*5,100*2,80*5]", which expands to <image>1:[80],<image>2:[80],<image>3:[80],etc<br />
<br />
or<br />
<br />
$image[2.1~2.10,2.1~2.2]:[80*5,100*2,80*5]<br />
This should take the current<br />
markup language and merely extand it to allow for calling an SDL_Rect from the spritesheet. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated Autogenerated Spritesheet WML added to each. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
===Making WML Painless===<br />
I'll implement a standalone tool that will take 1 or 2 inputs, if 1 just the spritesheet it will then find each image and ask the user to define the image (attack_1 etc) it will then generate a barebones spritesheet config file to be appended to the unit.cfg. If 2 it will take the old unit.cfg, and look for NEW images and REMOVED images, and only add or remove those changed so it doesn't require the user to double check or change image numbers by 1 or 2 everywhere to make adding/removing/changing an image so painful they don't want to do it.<br />
<br />
===Spritesheet Details===<br />
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.)<br />
<br />
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.<br />
<br />
==Testing==<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows)<br />
<br />
==Deliverables==<br />
{| align="center" border="1"<br />
|Status<br />
|Requirement Level<br />
|Number ID<br />
|Goal Defined<br />
|-<br />
|<br />
|Required<br />
|1A<br />
|Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
|-<br />
|<br />
|Required<br />
|1B <br />
|dynamic so that low mem devices are not adversely effected.<br />
|-<br />
|<br />
|Plan A Only!<br />
|2<br />
|Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
|-<br />
|<br />
|Required<br />
|3A<br />
|Spritesheets that are flexible and easy for artists and WML users to implement.<br />
|-<br />
|<br />
|Required<br />
|3B<br />
|Spritesheets that do not have a fixed size for every frame they hold.<br />
|-<br />
|<br />
|Plan A Only!<br />
|3C<br />
|Nor a Fixed grid size that holds each frame in its border.<br />
|-<br />
|<br />
|Plan A Only! Optional<br />
|3D <br />
|Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
|-<br />
|<br />
|Plan B Only! Optional<br />
|3D <br />
|Not require the borders be a particular width.<br />
|-<br />
|<br />
|Required<br />
|4 <br />
|WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
|-<br />
|<br />
|Required<br />
|5 <br />
|No negative or negible impact on loading times<br />
|}<br />
==Packages Required==<br />
{| align="center" border="1"<br />
|Package Name<br />
|Reason<br />
|Status<br />
|-<br />
|SDL<br />
|Needed for getting the colour information<br />
|Plan A required otherwise Not needed<br />
|-<br />
|Boost<br />
|Might be able to provide a performance boost (no pun intended)<br />
|Optional<br />
|}<br />
<br />
==13 Week Timeline==<br />
{| align="center" border="1"<br />
|<br />
===Status===<br />
|<br />
===Start/End_Dates=== <br />
|<br />
===Goals===<br />
|-<br />
|Current<br />
|March 20 - April 20:<br />
| <br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
|-<br />
|Next<br />
|April 21 - May 18:<br />
|<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
|-<br />
|<br />
|May 19 - June 1: <br />
|<br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant.<br />
|-<br />
|<br />
|June 1 - 15: <br />
|<br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
|-<br />
|<br />
|June 16 - 29:<br />
|<br />
* Implement new WML snytax for the spritesheets. <br />
|-<br />
|<br />
|June 23 - 27: <br />
|<br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
|-<br />
|<br />
|June 30 - July 13:<br />
|<br />
* Modify any existing functions that need to be modified to handle sheets that broke.<br />
|-<br />
|<br />
|July 14 - 27: <br />
|<br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
|-<br />
|<br />
|July 28 - Aug 10: <br />
|<br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/python script to convert all the images to spritesheets.<br />
|-<br />
|<br />
|Aug 3: <br />
|<br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
|-<br />
|<br />
|Aug 11 - 17: <br />
|<br />
* Documentation and clean up anything that hasn't yet be done.<br />
|-<br />
|<br />
|Aug 22: <br />
|<br />
* Final evaluation and send the required code snippets to Google.<br />
|}<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54309SpriteSheetApplicationSAB2014-03-30T23:15:20Z<p>Aishiko: /* WML */</p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet:<br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* 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! <br />
* Syntax making sure that its easy to use and understand for the average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===Cache===<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
==Plan A==<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of equal sized areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects<br />
in it that give the information about each frame (given above we'll call it a<br />
SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its<br />
SpriteFrameAddress Objects will be stored in the same cache as the spritesheet<br />
itself (so we won't have to refind each frame.<br />
<br />
===WML===<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress<2.1~2.10,2.1~2.2>.png:[80*5,100*2,80*5]"<br />
<br />
Another option is to do:<br />
<br />
image="units/elves-wood/Elvish_Sorceress<25,35,77,107>.png:[80]"<br />
<br />
In this case we would call it with the x,y of the 2 corners need to pull it out.<br />
This might be a good starting point for getting them to just work however I would still wish to get it more streamlined and less prone to errors.<br />
<br />
<br />
In the Elvish Sorceress example the first [] set would translate out to: row 4, columns 1-4, and the second set would stay the timing with times of 5ms, 75ms,<br />
100ms, and then 130ms for the images in order. This should take the current<br />
markup language and merely extand it to allow for rows and columns be the<br />
callers for an image. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
4.5 would be 4th row 5th column. I would take the current syntax and modify it<br />
slightly to work with rows and columns. The block of [4.1~4.4] might be<br />
<4.1~4.4> depending on whether or not its more readable.<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated SpriteAddressObject for the needed SpriteFrameAddresses<br />
This could be extended to so there is a SpriteAnimation object that will read<br />
the configs for the unit and have say the Attack Animation instead of calling<br />
each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all<br />
the Row, Column, and X,Y data for each image might be all that is needed and<br />
will work fine. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
==Plan B==<br />
===WML===<br />
Each Spritesheet will have a Spritesheet set of tags in the unit config file, it will look something like:<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Upper_X=x<br />
Upper_Y=y<br />
Lower_X=x<br />
Lower_Y=y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
OR<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Coordinates=[x,y,x,y] --upper followed by lower x,y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
<br />
<br />
Each animation sequence called by doing a call like:<br />
image="units/Elvish_Sorceress[1~10,1,2].png:[80*5,100*2,80*5]" <br />
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.<br />
<br />
===Spritesheet Details===<br />
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.<br />
<br />
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.<br />
<br />
==Testing==<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows)<br />
<br />
==Deliverables==<br />
{| align="center" border="1"<br />
|Status<br />
|Requirement Level<br />
|Number ID<br />
|Goal Defined<br />
|-<br />
|<br />
|Required<br />
|1A<br />
|Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
|-<br />
|<br />
|Required<br />
|1B <br />
|dynamic so that low mem devices are not adversely effected.<br />
|-<br />
|<br />
|Plan A Only!<br />
|2<br />
|Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
|-<br />
|<br />
|Required<br />
|3A<br />
|Spritesheets that are flexible and easy for artists and WML users to implement.<br />
|-<br />
|<br />
|Required<br />
|3B<br />
|Spritesheets that do not have a fixed size for every frame they hold.<br />
|-<br />
|<br />
|Plan A Only!<br />
|3C<br />
|Nor a Fixed grid size that holds each frame in its border.<br />
|-<br />
|<br />
|Plan A Only! Optional<br />
|3D <br />
|Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
|-<br />
|<br />
|Plan B Only! Optional<br />
|3D <br />
|Not require the borders be a particular width.<br />
|-<br />
|<br />
|Required<br />
|4 <br />
|WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
|-<br />
|<br />
|Required<br />
|5 <br />
|No negative or negible impact on loading times<br />
|}<br />
==Packages Required==<br />
{| align="center" border="1"<br />
|Package Name<br />
|Reason<br />
|Status<br />
|-<br />
|SDL<br />
|Needed for getting the colour information<br />
|Plan A required otherwise Not needed<br />
|-<br />
|Boost<br />
|Might be able to provide a performance boost (no pun intended)<br />
|Optional<br />
|}<br />
<br />
==13 Week Timeline==<br />
{| align="center" border="1"<br />
|<br />
===Status===<br />
|<br />
===Start/End_Dates=== <br />
|<br />
===Goals===<br />
|-<br />
|Current<br />
|March 20 - April 20:<br />
| <br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
|-<br />
|Next<br />
|April 21 - May 18:<br />
|<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
|-<br />
|<br />
|May 19 - June 1: <br />
|<br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant.<br />
|-<br />
|<br />
|June 1 - 15: <br />
|<br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
|-<br />
|<br />
|June 16 - 29:<br />
|<br />
* Implement new WML snytax for the spritesheets. <br />
|-<br />
|<br />
|June 23 - 27: <br />
|<br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
|-<br />
|<br />
|June 30 - July 13:<br />
|<br />
* Modify any existing functions that need to be modified to handle sheets that broke.<br />
|-<br />
|<br />
|July 14 - 27: <br />
|<br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
|-<br />
|<br />
|July 28 - Aug 10: <br />
|<br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/python script to convert all the images to spritesheets.<br />
|-<br />
|<br />
|Aug 3: <br />
|<br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
|-<br />
|<br />
|Aug 11 - 17: <br />
|<br />
* Documentation and clean up anything that hasn't yet be done.<br />
|-<br />
|<br />
|Aug 22: <br />
|<br />
* Final evaluation and send the required code snippets to Google.<br />
|}<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54308SpriteSheetApplicationSAB2014-03-30T23:09:43Z<p>Aishiko: /* Goals */</p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet:<br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* 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! <br />
* Syntax making sure that its easy to use and understand for the average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===Cache===<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
==Plan A==<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of equal sized areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects<br />
in it that give the information about each frame (given above we'll call it a<br />
SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its<br />
SpriteFrameAddress Objects will be stored in the same cache as the spritesheet<br />
itself (so we won't have to refind each frame.<br />
<br />
===WML===<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress<2.1~2.10,2.1~2.2>.png:[80*5,100*2,80*5]"<br />
<br />
Another option is to do:<br />
<br />
image="units/elves-wood/Elvish_Sorceress<25,35,77,107>.png:[80]"<br />
<br />
In this case we would call it with the x,y of the 2 corners need to pull it out.<br />
This might be a good starting point for getting them to just work however I would still wish to get it more streamlined and less prone to errors.<br />
<br />
<br />
In the Elvish Sorceress example the first [] set would translate out to: row 4, columns 1-4, and the second set would stay the timing with times of 5ms, 75ms,<br />
100ms, and then 130ms for the images in order. This should take the current<br />
markup language and merely extand it to allow for rows and columns be the<br />
callers for an image. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
4.5 would be 4th row 5th column. I would take the current syntax and modify it<br />
slightly to work with rows and columns. The block of [4.1~4.4] might be<br />
<4.1~4.4> depending on whether or not its more readable.<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated SpriteAddressObject for the needed SpriteFrameAddresses<br />
This could be extended to so there is a SpriteAnimation object that will read<br />
the configs for the unit and have say the Attack Animation instead of calling<br />
each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all<br />
the Row, Column, and X,Y data for each image might be all that is needed and<br />
will work fine. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
==Plan B==<br />
===WML===<br />
Each Spritesheet will have a Spritesheet set of tags in the unit config file, it will look something like:<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Upper_X=x<br />
Upper_Y=y<br />
Lower_X=x<br />
Lower_Y=y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
OR<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Coordinates=[x,y,x,y] --upper followed by lower x,y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
<br />
<br />
Each animation sequence called by doing a call like:<br />
image="units/Elvish_Sorceress[1~10,1,2].png:[80*5,100*2,80*5]" <br />
Almost like normal to say Elvish_Sorceress.png, images 1-10 and then 1 and finally 2 for the attack sequence in this case.<br />
<br />
===Spritesheet Details===<br />
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.<br />
<br />
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.<br />
<br />
==Testing==<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows)<br />
<br />
==Deliverables==<br />
{| align="center" border="1"<br />
|Status<br />
|Requirement Level<br />
|Number ID<br />
|Goal Defined<br />
|-<br />
|<br />
|Required<br />
|1A<br />
|Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
|-<br />
|<br />
|Required<br />
|1B <br />
|dynamic so that low mem devices are not adversely effected.<br />
|-<br />
|<br />
|Plan A Only!<br />
|2<br />
|Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
|-<br />
|<br />
|Required<br />
|3A<br />
|Spritesheets that are flexible and easy for artists and WML users to implement.<br />
|-<br />
|<br />
|Required<br />
|3B<br />
|Spritesheets that do not have a fixed size for every frame they hold.<br />
|-<br />
|<br />
|Plan A Only!<br />
|3C<br />
|Nor a Fixed grid size that holds each frame in its border.<br />
|-<br />
|<br />
|Plan A Only! Optional<br />
|3D <br />
|Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
|-<br />
|<br />
|Plan B Only! Optional<br />
|3D <br />
|Not require the borders be a particular width.<br />
|-<br />
|<br />
|Required<br />
|4 <br />
|WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
|-<br />
|<br />
|Required<br />
|5 <br />
|No negative or negible impact on loading times<br />
|}<br />
==Packages Required==<br />
{| align="center" border="1"<br />
|Package Name<br />
|Reason<br />
|Status<br />
|-<br />
|SDL<br />
|Needed for getting the colour information<br />
|Plan A required otherwise Not needed<br />
|-<br />
|Boost<br />
|Might be able to provide a performance boost (no pun intended)<br />
|Optional<br />
|}<br />
<br />
==13 Week Timeline==<br />
{| align="center" border="1"<br />
|<br />
===Status===<br />
|<br />
===Start/End_Dates=== <br />
|<br />
===Goals===<br />
|-<br />
|Current<br />
|March 20 - April 20:<br />
| <br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
|-<br />
|Next<br />
|April 21 - May 18:<br />
|<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
|-<br />
|<br />
|May 19 - June 1: <br />
|<br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant.<br />
|-<br />
|<br />
|June 1 - 15: <br />
|<br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
|-<br />
|<br />
|June 16 - 29:<br />
|<br />
* Implement new WML snytax for the spritesheets. <br />
|-<br />
|<br />
|June 23 - 27: <br />
|<br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
|-<br />
|<br />
|June 30 - July 13:<br />
|<br />
* Modify any existing functions that need to be modified to handle sheets that broke.<br />
|-<br />
|<br />
|July 14 - 27: <br />
|<br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
|-<br />
|<br />
|July 28 - Aug 10: <br />
|<br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/python script to convert all the images to spritesheets.<br />
|-<br />
|<br />
|Aug 3: <br />
|<br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
|-<br />
|<br />
|Aug 11 - 17: <br />
|<br />
* Documentation and clean up anything that hasn't yet be done.<br />
|-<br />
|<br />
|Aug 22: <br />
|<br />
* Final evaluation and send the required code snippets to Google.<br />
|}<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54307SpriteSheetApplicationSAB2014-03-30T23:09:13Z<p>Aishiko: /* Problems */</p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll<br />
make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can<br />
make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* 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! <br />
* Syntax making sure that its easy to use and understand for the average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===Cache===<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
==Plan A==<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of equal sized areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects<br />
in it that give the information about each frame (given above we'll call it a<br />
SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its<br />
SpriteFrameAddress Objects will be stored in the same cache as the spritesheet<br />
itself (so we won't have to refind each frame.<br />
<br />
===WML===<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress<2.1~2.10,2.1~2.2>.png:[80*5,100*2,80*5]"<br />
<br />
Another option is to do:<br />
<br />
image="units/elves-wood/Elvish_Sorceress<25,35,77,107>.png:[80]"<br />
<br />
In this case we would call it with the x,y of the 2 corners need to pull it out.<br />
This might be a good starting point for getting them to just work however I would still wish to get it more streamlined and less prone to errors.<br />
<br />
<br />
In the Elvish Sorceress example the first [] set would translate out to: row 4, columns 1-4, and the second set would stay the timing with times of 5ms, 75ms,<br />
100ms, and then 130ms for the images in order. This should take the current<br />
markup language and merely extand it to allow for rows and columns be the<br />
callers for an image. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
4.5 would be 4th row 5th column. I would take the current syntax and modify it<br />
slightly to work with rows and columns. The block of [4.1~4.4] might be<br />
<4.1~4.4> depending on whether or not its more readable.<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated SpriteAddressObject for the needed SpriteFrameAddresses<br />
This could be extended to so there is a SpriteAnimation object that will read<br />
the configs for the unit and have say the Attack Animation instead of calling<br />
each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all<br />
the Row, Column, and X,Y data for each image might be all that is needed and<br />
will work fine. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
==Plan B==<br />
===WML===<br />
Each Spritesheet will have a Spritesheet set of tags in the unit config file, it will look something like:<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Upper_X=x<br />
Upper_Y=y<br />
Lower_X=x<br />
Lower_Y=y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
OR<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Coordinates=[x,y,x,y] --upper followed by lower x,y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
<br />
<br />
Each animation sequence called by doing a call like:<br />
image="units/Elvish_Sorceress[1~10,1,2].png:[80*5,100*2,80*5]" <br />
Almost like normal to say Elvish_Sorceress.png, images 1-10 and then 1 and finally 2 for the attack sequence in this case.<br />
<br />
===Spritesheet Details===<br />
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.<br />
<br />
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.<br />
<br />
==Testing==<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows)<br />
<br />
==Deliverables==<br />
{| align="center" border="1"<br />
|Status<br />
|Requirement Level<br />
|Number ID<br />
|Goal Defined<br />
|-<br />
|<br />
|Required<br />
|1A<br />
|Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
|-<br />
|<br />
|Required<br />
|1B <br />
|dynamic so that low mem devices are not adversely effected.<br />
|-<br />
|<br />
|Plan A Only!<br />
|2<br />
|Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
|-<br />
|<br />
|Required<br />
|3A<br />
|Spritesheets that are flexible and easy for artists and WML users to implement.<br />
|-<br />
|<br />
|Required<br />
|3B<br />
|Spritesheets that do not have a fixed size for every frame they hold.<br />
|-<br />
|<br />
|Plan A Only!<br />
|3C<br />
|Nor a Fixed grid size that holds each frame in its border.<br />
|-<br />
|<br />
|Plan A Only! Optional<br />
|3D <br />
|Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
|-<br />
|<br />
|Plan B Only! Optional<br />
|3D <br />
|Not require the borders be a particular width.<br />
|-<br />
|<br />
|Required<br />
|4 <br />
|WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
|-<br />
|<br />
|Required<br />
|5 <br />
|No negative or negible impact on loading times<br />
|}<br />
==Packages Required==<br />
{| align="center" border="1"<br />
|Package Name<br />
|Reason<br />
|Status<br />
|-<br />
|SDL<br />
|Needed for getting the colour information<br />
|Plan A required otherwise Not needed<br />
|-<br />
|Boost<br />
|Might be able to provide a performance boost (no pun intended)<br />
|Optional<br />
|}<br />
<br />
==13 Week Timeline==<br />
{| align="center" border="1"<br />
|<br />
===Status===<br />
|<br />
===Start/End_Dates=== <br />
|<br />
===Goals===<br />
|-<br />
|Current<br />
|March 20 - April 20:<br />
| <br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
|-<br />
|Next<br />
|April 21 - May 18:<br />
|<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
|-<br />
|<br />
|May 19 - June 1: <br />
|<br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant.<br />
|-<br />
|<br />
|June 1 - 15: <br />
|<br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
|-<br />
|<br />
|June 16 - 29:<br />
|<br />
* Implement new WML snytax for the spritesheets. <br />
|-<br />
|<br />
|June 23 - 27: <br />
|<br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
|-<br />
|<br />
|June 30 - July 13:<br />
|<br />
* Modify any existing functions that need to be modified to handle sheets that broke.<br />
|-<br />
|<br />
|July 14 - 27: <br />
|<br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
|-<br />
|<br />
|July 28 - Aug 10: <br />
|<br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/python script to convert all the images to spritesheets.<br />
|-<br />
|<br />
|Aug 3: <br />
|<br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
|-<br />
|<br />
|Aug 11 - 17: <br />
|<br />
* Documentation and clean up anything that hasn't yet be done.<br />
|-<br />
|<br />
|Aug 22: <br />
|<br />
* Final evaluation and send the required code snippets to Google.<br />
|}<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54306SpriteSheetApplicationSAB2014-03-30T23:08:57Z<p>Aishiko: /* Problems */</p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll<br />
make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can<br />
make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* 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! <br />
* Syntax making sure that its easy to use and understand for the<br />
average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===Cache===<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
==Plan A==<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of equal sized areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects<br />
in it that give the information about each frame (given above we'll call it a<br />
SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its<br />
SpriteFrameAddress Objects will be stored in the same cache as the spritesheet<br />
itself (so we won't have to refind each frame.<br />
<br />
===WML===<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress<2.1~2.10,2.1~2.2>.png:[80*5,100*2,80*5]"<br />
<br />
Another option is to do:<br />
<br />
image="units/elves-wood/Elvish_Sorceress<25,35,77,107>.png:[80]"<br />
<br />
In this case we would call it with the x,y of the 2 corners need to pull it out.<br />
This might be a good starting point for getting them to just work however I would still wish to get it more streamlined and less prone to errors.<br />
<br />
<br />
In the Elvish Sorceress example the first [] set would translate out to: row 4, columns 1-4, and the second set would stay the timing with times of 5ms, 75ms,<br />
100ms, and then 130ms for the images in order. This should take the current<br />
markup language and merely extand it to allow for rows and columns be the<br />
callers for an image. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
4.5 would be 4th row 5th column. I would take the current syntax and modify it<br />
slightly to work with rows and columns. The block of [4.1~4.4] might be<br />
<4.1~4.4> depending on whether or not its more readable.<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated SpriteAddressObject for the needed SpriteFrameAddresses<br />
This could be extended to so there is a SpriteAnimation object that will read<br />
the configs for the unit and have say the Attack Animation instead of calling<br />
each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all<br />
the Row, Column, and X,Y data for each image might be all that is needed and<br />
will work fine. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
==Plan B==<br />
===WML===<br />
Each Spritesheet will have a Spritesheet set of tags in the unit config file, it will look something like:<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Upper_X=x<br />
Upper_Y=y<br />
Lower_X=x<br />
Lower_Y=y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
OR<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Coordinates=[x,y,x,y] --upper followed by lower x,y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
<br />
<br />
Each animation sequence called by doing a call like:<br />
image="units/Elvish_Sorceress[1~10,1,2].png:[80*5,100*2,80*5]" <br />
Almost like normal to say Elvish_Sorceress.png, images 1-10 and then 1 and finally 2 for the attack sequence in this case.<br />
<br />
===Spritesheet Details===<br />
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.<br />
<br />
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.<br />
<br />
==Testing==<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows)<br />
<br />
==Deliverables==<br />
{| align="center" border="1"<br />
|Status<br />
|Requirement Level<br />
|Number ID<br />
|Goal Defined<br />
|-<br />
|<br />
|Required<br />
|1A<br />
|Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
|-<br />
|<br />
|Required<br />
|1B <br />
|dynamic so that low mem devices are not adversely effected.<br />
|-<br />
|<br />
|Plan A Only!<br />
|2<br />
|Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
|-<br />
|<br />
|Required<br />
|3A<br />
|Spritesheets that are flexible and easy for artists and WML users to implement.<br />
|-<br />
|<br />
|Required<br />
|3B<br />
|Spritesheets that do not have a fixed size for every frame they hold.<br />
|-<br />
|<br />
|Plan A Only!<br />
|3C<br />
|Nor a Fixed grid size that holds each frame in its border.<br />
|-<br />
|<br />
|Plan A Only! Optional<br />
|3D <br />
|Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
|-<br />
|<br />
|Plan B Only! Optional<br />
|3D <br />
|Not require the borders be a particular width.<br />
|-<br />
|<br />
|Required<br />
|4 <br />
|WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
|-<br />
|<br />
|Required<br />
|5 <br />
|No negative or negible impact on loading times<br />
|}<br />
==Packages Required==<br />
{| align="center" border="1"<br />
|Package Name<br />
|Reason<br />
|Status<br />
|-<br />
|SDL<br />
|Needed for getting the colour information<br />
|Plan A required otherwise Not needed<br />
|-<br />
|Boost<br />
|Might be able to provide a performance boost (no pun intended)<br />
|Optional<br />
|}<br />
<br />
==13 Week Timeline==<br />
{| align="center" border="1"<br />
|<br />
===Status===<br />
|<br />
===Start/End_Dates=== <br />
|<br />
===Goals===<br />
|-<br />
|Current<br />
|March 20 - April 20:<br />
| <br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
|-<br />
|Next<br />
|April 21 - May 18:<br />
|<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
|-<br />
|<br />
|May 19 - June 1: <br />
|<br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant.<br />
|-<br />
|<br />
|June 1 - 15: <br />
|<br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
|-<br />
|<br />
|June 16 - 29:<br />
|<br />
* Implement new WML snytax for the spritesheets. <br />
|-<br />
|<br />
|June 23 - 27: <br />
|<br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
|-<br />
|<br />
|June 30 - July 13:<br />
|<br />
* Modify any existing functions that need to be modified to handle sheets that broke.<br />
|-<br />
|<br />
|July 14 - 27: <br />
|<br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
|-<br />
|<br />
|July 28 - Aug 10: <br />
|<br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/python script to convert all the images to spritesheets.<br />
|-<br />
|<br />
|Aug 3: <br />
|<br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
|-<br />
|<br />
|Aug 11 - 17: <br />
|<br />
* Documentation and clean up anything that hasn't yet be done.<br />
|-<br />
|<br />
|Aug 22: <br />
|<br />
* Final evaluation and send the required code snippets to Google.<br />
|}<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54305SpriteSheetApplicationSAB2014-03-30T22:30:22Z<p>Aishiko: </p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll<br />
make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can<br />
make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* Adding a boarder around each image to make it easier for the<br />
artists to see what sort of space they have to work with will make taking the<br />
current images and converting them a bit harder as well as creating a script to<br />
convert them (which remains a soft goal, ie if I have to do it AFTER the summer,<br />
I'll do that.) Stupid perfectionist leanings, at least for what I think of to<br />
get the project ready! <br />
* Syntax making sure that its easy to use and understand for the<br />
average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===Cache===<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
==Plan A==<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of equal sized areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects<br />
in it that give the information about each frame (given above we'll call it a<br />
SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its<br />
SpriteFrameAddress Objects will be stored in the same cache as the spritesheet<br />
itself (so we won't have to refind each frame.<br />
<br />
===WML===<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress<2.1~2.10,2.1~2.2>.png:[80*5,100*2,80*5]"<br />
<br />
Another option is to do:<br />
<br />
image="units/elves-wood/Elvish_Sorceress<25,35,77,107>.png:[80]"<br />
<br />
In this case we would call it with the x,y of the 2 corners need to pull it out.<br />
This might be a good starting point for getting them to just work however I would still wish to get it more streamlined and less prone to errors.<br />
<br />
<br />
In the Elvish Sorceress example the first [] set would translate out to: row 4, columns 1-4, and the second set would stay the timing with times of 5ms, 75ms,<br />
100ms, and then 130ms for the images in order. This should take the current<br />
markup language and merely extand it to allow for rows and columns be the<br />
callers for an image. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
4.5 would be 4th row 5th column. I would take the current syntax and modify it<br />
slightly to work with rows and columns. The block of [4.1~4.4] might be<br />
<4.1~4.4> depending on whether or not its more readable.<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated SpriteAddressObject for the needed SpriteFrameAddresses<br />
This could be extended to so there is a SpriteAnimation object that will read<br />
the configs for the unit and have say the Attack Animation instead of calling<br />
each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all<br />
the Row, Column, and X,Y data for each image might be all that is needed and<br />
will work fine. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
==Plan B==<br />
===WML===<br />
Each Spritesheet will have a Spritesheet set of tags in the unit config file, it will look something like:<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Upper_X=x<br />
Upper_Y=y<br />
Lower_X=x<br />
Lower_Y=y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
OR<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Coordinates=[x,y,x,y] --upper followed by lower x,y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
<br />
<br />
Each animation sequence called by doing a call like:<br />
image="units/Elvish_Sorceress[1~10,1,2].png:[80*5,100*2,80*5]" <br />
Almost like normal to say Elvish_Sorceress.png, images 1-10 and then 1 and finally 2 for the attack sequence in this case.<br />
<br />
===Spritesheet Details===<br />
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.<br />
<br />
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.<br />
<br />
==Testing==<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows)<br />
<br />
==Deliverables==<br />
{| align="center" border="1"<br />
|Status<br />
|Requirement Level<br />
|Number ID<br />
|Goal Defined<br />
|-<br />
|<br />
|Required<br />
|1A<br />
|Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
|-<br />
|<br />
|Required<br />
|1B <br />
|dynamic so that low mem devices are not adversely effected.<br />
|-<br />
|<br />
|Plan A Only!<br />
|2<br />
|Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
|-<br />
|<br />
|Required<br />
|3A<br />
|Spritesheets that are flexible and easy for artists and WML users to implement.<br />
|-<br />
|<br />
|Required<br />
|3B<br />
|Spritesheets that do not have a fixed size for every frame they hold.<br />
|-<br />
|<br />
|Plan A Only!<br />
|3C<br />
|Nor a Fixed grid size that holds each frame in its border.<br />
|-<br />
|<br />
|Plan A Only! Optional<br />
|3D <br />
|Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
|-<br />
|<br />
|Plan B Only! Optional<br />
|3D <br />
|Not require the borders be a particular width.<br />
|-<br />
|<br />
|Required<br />
|4 <br />
|WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
|-<br />
|<br />
|Required<br />
|5 <br />
|No negative or negible impact on loading times<br />
|}<br />
==Packages Required==<br />
{| align="center" border="1"<br />
|Package Name<br />
|Reason<br />
|Status<br />
|-<br />
|SDL<br />
|Needed for getting the colour information<br />
|Plan A required otherwise Not needed<br />
|-<br />
|Boost<br />
|Might be able to provide a performance boost (no pun intended)<br />
|Optional<br />
|}<br />
<br />
==13 Week Timeline==<br />
{| align="center" border="1"<br />
|<br />
===Status===<br />
|<br />
===Start/End_Dates=== <br />
|<br />
===Goals===<br />
|-<br />
|Current<br />
|March 20 - April 20:<br />
| <br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
|-<br />
|Next<br />
|April 21 - May 18:<br />
|<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
|-<br />
|<br />
|May 19 - June 1: <br />
|<br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant.<br />
|-<br />
|<br />
|June 1 - 15: <br />
|<br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
|-<br />
|<br />
|June 16 - 29:<br />
|<br />
* Implement new WML snytax for the spritesheets. <br />
|-<br />
|<br />
|June 23 - 27: <br />
|<br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
|-<br />
|<br />
|June 30 - July 13:<br />
|<br />
* Modify any existing functions that need to be modified to handle sheets that broke.<br />
|-<br />
|<br />
|July 14 - 27: <br />
|<br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
|-<br />
|<br />
|July 28 - Aug 10: <br />
|<br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/python script to convert all the images to spritesheets.<br />
|-<br />
|<br />
|Aug 3: <br />
|<br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
|-<br />
|<br />
|Aug 11 - 17: <br />
|<br />
* Documentation and clean up anything that hasn't yet be done.<br />
|-<br />
|<br />
|Aug 22: <br />
|<br />
* Final evaluation and send the required code snippets to Google.<br />
|}<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54304SpriteSheetApplicationSAB2014-03-30T22:26:52Z<p>Aishiko: /* WML */</p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll<br />
make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can<br />
make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* Adding a boarder around each image to make it easier for the<br />
artists to see what sort of space they have to work with will make taking the<br />
current images and converting them a bit harder as well as creating a script to<br />
convert them (which remains a soft goal, ie if I have to do it AFTER the summer,<br />
I'll do that.) Stupid perfectionist leanings, at least for what I think of to<br />
get the project ready! <br />
* Syntax making sure that its easy to use and understand for the<br />
average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===Cache===<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
==Plan A==<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of equal sized areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects<br />
in it that give the information about each frame (given above we'll call it a<br />
SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its<br />
SpriteFrameAddress Objects will be stored in the same cache as the spritesheet<br />
itself (so we won't have to refind each frame.<br />
<br />
===WML===<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress<2.1~2.10,2.1~2.2>.png:[80*5,100*2,80*5]"<br />
<br />
Another option is to do:<br />
<br />
image="units/elves-wood/Elvish_Sorceress<25,35,77,107>.png:[80]"<br />
<br />
In this case we would call it with the x,y of the 2 corners need to pull it out.<br />
This might be a good starting point for getting them to just work however I would still wish to get it more streamlined and less prone to errors.<br />
<br />
<br />
In the Elvish Sorceress example the first [] set would translate out to: row 4, columns 1-4, and the second set would stay the timing with times of 5ms, 75ms,<br />
100ms, and then 130ms for the images in order. This should take the current<br />
markup language and merely extand it to allow for rows and columns be the<br />
callers for an image. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
4.5 would be 4th row 5th column. I would take the current syntax and modify it<br />
slightly to work with rows and columns. The block of [4.1~4.4] might be<br />
<4.1~4.4> depending on whether or not its more readable.<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated SpriteAddressObject for the needed SpriteFrameAddresses<br />
This could be extended to so there is a SpriteAnimation object that will read<br />
the configs for the unit and have say the Attack Animation instead of calling<br />
each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all<br />
the Row, Column, and X,Y data for each image might be all that is needed and<br />
will work fine. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
==Plan B==<br />
===WML===<br />
Each Spritesheet will have a Spritesheet set of tags in the unit config file, it will look something like:<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Upper_X=x<br />
Upper_Y=y<br />
Lower_X=x<br />
Lower_Y=y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
OR<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Coordinates=[x,y,x,y] --upper followed by lower x,y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
<br />
<br />
Each animation sequence called by doing a call like:<br />
image="units/Elvish_Sorceress[1~10,1,2].png:[80*5,100*2,80*5]" <br />
Almost like normal to say Elvish_Sorceress.png, images 1-10 and then 1 and finally 2 for the attack sequence in this case.<br />
<br />
===Spritesheet Details===<br />
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.<br />
<br />
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.<br />
<br />
==Testing==<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows)<br />
<br />
==Deliverables==<br />
{| align="center" border="1"<br />
|Status<br />
|Requirement Level<br />
|Number ID<br />
|Goal Defined<br />
|-<br />
|<br />
|Required<br />
|1A<br />
|Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
|-<br />
|<br />
|Required<br />
|1B <br />
|dynamic so that low mem devices are not adversely effected.<br />
|-<br />
|<br />
|Plan A Only!<br />
|2<br />
|Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
|-<br />
|<br />
|Required<br />
|3A<br />
|Spritesheets that are flexible and easy for artists and WML users to implement.<br />
|-<br />
|<br />
|Required<br />
|3B<br />
|Spritesheets that do not have a fixed size for every frame they hold.<br />
|-<br />
|<br />
|Plan A Only!<br />
|3C<br />
|Nor a Fixed grid size that holds each frame in its border.<br />
|-<br />
|<br />
|Plan A Only! Optional<br />
|3D <br />
|Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
|-<br />
|<br />
|Plan B Only! Optional<br />
|3D <br />
|Not require the borders be a particular width.<br />
|-<br />
|<br />
|Required<br />
|4 <br />
|WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
|-<br />
|<br />
|Required<br />
|5 <br />
|No negative or negible impact on loading times<br />
|}<br />
==Packages Required==<br />
SDL: Needed for getting the colour information<br />
Boost: Might be able to provide a performance boost (no pun intended)<br />
<br />
==13 Week Timeline==<br />
{| align="center" border="1"<br />
|<br />
===Status===<br />
|<br />
===Start/End_Dates=== <br />
|<br />
===Goals===<br />
|-<br />
|Current<br />
|March 20 - April 20:<br />
| <br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
|-<br />
|Next<br />
|April 21 - May 18:<br />
|<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
|-<br />
|<br />
|May 19 - June 1: <br />
|<br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant.<br />
|-<br />
|<br />
|June 1 - 15: <br />
|<br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
|-<br />
|<br />
|June 16 - 29:<br />
|<br />
* Implement new WML snytax for the spritesheets. <br />
|-<br />
|<br />
|June 23 - 27: <br />
|<br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
|-<br />
|<br />
|June 30 - July 13:<br />
|<br />
* Modify any existing functions that need to be modified to handle sheets that broke.<br />
|-<br />
|<br />
|July 14 - 27: <br />
|<br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
|-<br />
|<br />
|July 28 - Aug 10: <br />
|<br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/python script to convert all the images to spritesheets.<br />
|-<br />
|<br />
|Aug 3: <br />
|<br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
|-<br />
|<br />
|Aug 11 - 17: <br />
|<br />
* Documentation and clean up anything that hasn't yet be done.<br />
|-<br />
|<br />
|Aug 22: <br />
|<br />
* Final evaluation and send the required code snippets to Google.<br />
|}<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54303SpriteSheetApplicationSAB2014-03-30T22:24:45Z<p>Aishiko: </p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll<br />
make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can<br />
make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* Adding a boarder around each image to make it easier for the<br />
artists to see what sort of space they have to work with will make taking the<br />
current images and converting them a bit harder as well as creating a script to<br />
convert them (which remains a soft goal, ie if I have to do it AFTER the summer,<br />
I'll do that.) Stupid perfectionist leanings, at least for what I think of to<br />
get the project ready! <br />
* Syntax making sure that its easy to use and understand for the<br />
average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===Cache===<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
==Plan A==<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of equal sized areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects<br />
in it that give the information about each frame (given above we'll call it a<br />
SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its<br />
SpriteFrameAddress Objects will be stored in the same cache as the spritesheet<br />
itself (so we won't have to refind each frame.<br />
<br />
===WML===<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress<2.1~2.10,2.1~2.2>.png:[80*5,100*2,80*5]"<br />
<br />
Another option is to do:<br />
<br />
image="units/elves-wood/Elvish_Sorceress<25,35,77,107>.png:[80]"<br />
<br />
In this case we would call it with the x,y of the 2 corners need to pull it out.<br />
This might be a good starting point for getting them to just work however I would still wish to get it more streamlined and less prone to errors.<br />
<br />
<br />
In the Elvish Sorceress example the first [] set would translate out to: row 4, columns 1-4, and the second set would stay the timing with times of 5ms, 75ms,<br />
100ms, and then 130ms for the images in order. This should take the current<br />
markup language and merely extand it to allow for rows and columns be the<br />
callers for an image. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
4.5 would be 4th row 5th column. I would take the current syntax and modify it<br />
slightly to work with rows and columns. The block of [4.1~4.4] might be<br />
<4.1~4.4> depending on whether or not its more readable.<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated SpriteAddressObject for the needed SpriteFrameAddresses<br />
This could be extended to so there is a SpriteAnimation object that will read<br />
the configs for the unit and have say the Attack Animation instead of calling<br />
each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all<br />
the Row, Column, and X,Y data for each image might be all that is needed and<br />
will work fine. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
==Plan B==<br />
===WML===<br />
Each Spritesheet will have a Spritesheet set of tags in the unit config file, it will look something like:<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Upper_X=x<br />
Upper_Y=y<br />
Lower_X=x<br />
Lower_Y=y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
OR<br />
[Spritesheet]<br />
File=file_path/name.png<br />
[Image]<br />
ImageID=1<br />
ImageName="Attack_1"<br />
Coordinates=[x,y,x,y] --upper followed by lower x,y<br />
[/Image]<br />
-- More Images here<br />
[/Spritesheet]<br />
<br />
<br />
Each animation sequence called by doing a call like:<br />
image="units/Elvish_Sorceress[1~10,1,2].png:[80*5,100*2,80*5]" <br />
Almost like normal to say Elvish_Sorceress.png, images 1-10 and then 1 and finally 2 for the attack sequence in this case.<br />
<br />
===Spritesheet Details===<br />
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.<br />
<br />
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.<br />
<br />
==Testing==<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows)<br />
<br />
==Deliverables==<br />
{| align="center" border="1"<br />
|Status<br />
|Requirement Level<br />
|Number ID<br />
|Goal Defined<br />
|-<br />
|<br />
|Required<br />
|1A<br />
|Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
|-<br />
|<br />
|Required<br />
|1B <br />
|dynamic so that low mem devices are not adversely effected.<br />
|-<br />
|<br />
|Plan A Only!<br />
|2<br />
|Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
|-<br />
|<br />
|Required<br />
|3A<br />
|Spritesheets that are flexible and easy for artists and WML users to implement.<br />
|-<br />
|<br />
|Required<br />
|3B<br />
|Spritesheets that do not have a fixed size for every frame they hold.<br />
|-<br />
|<br />
|Plan A Only!<br />
|3C<br />
|Nor a Fixed grid size that holds each frame in its border.<br />
|-<br />
|<br />
|Plan A Only! Optional<br />
|3D <br />
|Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
|-<br />
|<br />
|Plan B Only! Optional<br />
|3D <br />
|Not require the borders be a particular width.<br />
|-<br />
|<br />
|Required<br />
|4 <br />
|WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
|-<br />
|<br />
|Required<br />
|5 <br />
|No negative or negible impact on loading times<br />
|}<br />
==Packages Required==<br />
SDL: Needed for getting the colour information<br />
Boost: Might be able to provide a performance boost (no pun intended)<br />
<br />
==13 Week Timeline==<br />
{| align="center" border="1"<br />
|<br />
===Status===<br />
|<br />
===Start/End_Dates=== <br />
|<br />
===Goals===<br />
|-<br />
|Current<br />
|March 20 - April 20:<br />
| <br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
|-<br />
|Next<br />
|April 21 - May 18:<br />
|<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
|-<br />
|<br />
|May 19 - June 1: <br />
|<br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant.<br />
|-<br />
|<br />
|June 1 - 15: <br />
|<br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
|-<br />
|<br />
|June 16 - 29:<br />
|<br />
* Implement new WML snytax for the spritesheets. <br />
|-<br />
|<br />
|June 23 - 27: <br />
|<br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
|-<br />
|<br />
|June 30 - July 13:<br />
|<br />
* Modify any existing functions that need to be modified to handle sheets that broke.<br />
|-<br />
|<br />
|July 14 - 27: <br />
|<br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
|-<br />
|<br />
|July 28 - Aug 10: <br />
|<br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/python script to convert all the images to spritesheets.<br />
|-<br />
|<br />
|Aug 3: <br />
|<br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
|-<br />
|<br />
|Aug 11 - 17: <br />
|<br />
* Documentation and clean up anything that hasn't yet be done.<br />
|-<br />
|<br />
|Aug 22: <br />
|<br />
* Final evaluation and send the required code snippets to Google.<br />
|}<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54302SpriteSheetApplicationSAB2014-03-30T21:41:58Z<p>Aishiko: </p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll<br />
make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can<br />
make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* Adding a boarder around each image to make it easier for the<br />
artists to see what sort of space they have to work with will make taking the<br />
current images and converting them a bit harder as well as creating a script to<br />
convert them (which remains a soft goal, ie if I have to do it AFTER the summer,<br />
I'll do that.) Stupid perfectionist leanings, at least for what I think of to<br />
get the project ready! <br />
* Syntax making sure that its easy to use and understand for the<br />
average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of equal sized areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects<br />
in it that give the information about each frame (given above we'll call it a<br />
SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its<br />
SpriteFrameAddress Objects will be stored in the same cache as the spritesheet<br />
itself (so we won't have to refind each frame.<br />
<br />
<br />
===Plan A===<br />
====WML Phase One====<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress<2.1~2.10,2.1~2.2>.png:[80*5,100*2,80*5]"<br />
<br />
Another option is to do:<br />
<br />
image="units/elves-wood/Elvish_Sorceress<25,35,77,107>.png:[80]"<br />
<br />
In this case we would call it with the x,y of the 2 corners need to pull it out.<br />
This might be a good starting point for getting them to just work however I would still wish to get it more streamlined and less prone to errors.<br />
<br />
<br />
In the Elvish Sorceress example the first [] set would translate out to: row 4, columns 1-4, and the second set would stay the timing with times of 5ms, 75ms,<br />
100ms, and then 130ms for the images in order. This should take the current<br />
markup language and merely extand it to allow for rows and columns be the<br />
callers for an image. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
4.5 would be 4th row 5th column. I would take the current syntax and modify it<br />
slightly to work with rows and columns. The block of [4.1~4.4] might be<br />
<4.1~4.4> depending on whether or not its more readable.<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated SpriteAddressObject for the needed SpriteFrameAddresses<br />
This could be extended to so there is a SpriteAnimation object that will read<br />
the configs for the unit and have say the Attack Animation instead of calling<br />
each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all<br />
the Row, Column, and X,Y data for each image might be all that is needed and<br />
will work fine. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
====Cache====<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
===Testing===<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows)<br />
<br />
===Plan B===<br />
<br />
===Deliverables===<br />
#* Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
#* dynamic so that low mem devices are not adversely effected.<br />
# Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
#* Spritesheets that are flexible and easy for artists and WML users to implement.<br />
#* Spritesheets that do not have a fixed size for every frame they hold.<br />
#* Nor a Fixed grid size that holds each frame in its borderl.<br />
#* Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
# WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
# No negative or negible impact on loading times<br />
<br />
==Packages Required==<br />
SDL: Needed for getting the colour information<br />
Boost: Might be able to provide a performance boost (no pun intended)<br />
<br />
==13 Week Timeline==<br />
{| align="center" border="1"<br />
|<br />
===Status===<br />
|<br />
===Start/End_Dates=== <br />
|<br />
===Goals===<br />
|-<br />
|Current<br />
|March 20 - April 20:<br />
| <br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
|-<br />
|Next<br />
|April 21 - May 18:<br />
|<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
|-<br />
|<br />
|May 19 - June 1: <br />
|<br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant.<br />
|-<br />
|<br />
|June 1 - 15: <br />
|<br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
|-<br />
|<br />
|June 16 - 29:<br />
|<br />
* Implement new WML snytax for the spritesheets. <br />
|-<br />
|<br />
|June 23 - 27: <br />
|<br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
|-<br />
|<br />
|June 30 - July 13:<br />
|<br />
* Modify any existing functions that need to be modified to handle sheets that broke.<br />
|-<br />
|<br />
|July 14 - 27: <br />
|<br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
|-<br />
|<br />
|July 28 - Aug 10: <br />
|<br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/python script to convert all the images to spritesheets.<br />
|-<br />
|<br />
|Aug 3: <br />
|<br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
|-<br />
|<br />
|Aug 11 - 17: <br />
|<br />
* Documentation and clean up anything that hasn't yet be done.<br />
|-<br />
|<br />
|Aug 22: <br />
|<br />
* Final evaluation and send the required code snippets to Google.<br />
|}<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54301SpriteSheetApplicationSAB2014-03-30T21:40:24Z<p>Aishiko: /* 13 Week Timeline */</p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll<br />
make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can<br />
make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* Adding a boarder around each image to make it easier for the<br />
artists to see what sort of space they have to work with will make taking the<br />
current images and converting them a bit harder as well as creating a script to<br />
convert them (which remains a soft goal, ie if I have to do it AFTER the summer,<br />
I'll do that.) Stupid perfectionist leanings, at least for what I think of to<br />
get the project ready! <br />
* Syntax making sure that its easy to use and understand for the<br />
average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of equal sized areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects<br />
in it that give the information about each frame (given above we'll call it a<br />
SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its<br />
SpriteFrameAddress Objects will be stored in the same cache as the spritesheet<br />
itself (so we won't have to refind each frame.<br />
<br />
====WML Phase One====<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress<2.1~2.10,2.1~2.2>.png:[80*5,100*2,80*5]"<br />
<br />
Another option is to do:<br />
<br />
image="units/elves-wood/Elvish_Sorceress<25,35,77,107>.png:[80]"<br />
<br />
In this case we would call it with the x,y of the 2 corners need to pull it out.<br />
This might be a good starting point for getting them to just work however I would still wish to get it more streamlined and less prone to errors.<br />
<br />
<br />
In the Elvish Sorceress example the first [] set would translate out to: row 4, columns 1-4, and the second set would stay the timing with times of 5ms, 75ms,<br />
100ms, and then 130ms for the images in order. This should take the current<br />
markup language and merely extand it to allow for rows and columns be the<br />
callers for an image. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
4.5 would be 4th row 5th column. I would take the current syntax and modify it<br />
slightly to work with rows and columns. The block of [4.1~4.4] might be<br />
<4.1~4.4> depending on whether or not its more readable.<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated SpriteAddressObject for the needed SpriteFrameAddresses<br />
This could be extended to so there is a SpriteAnimation object that will read<br />
the configs for the unit and have say the Attack Animation instead of calling<br />
each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all<br />
the Row, Column, and X,Y data for each image might be all that is needed and<br />
will work fine. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
====Cache====<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
===Testing===<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows)<br />
<br />
===Deliverables===<br />
#* Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
#* dynamic so that low mem devices are not adversely effected.<br />
# Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
#* Spritesheets that are flexible and easy for artists and WML users to implement.<br />
#* Spritesheets that do not have a fixed size for every frame they hold.<br />
#* Nor a Fixed grid size that holds each frame in its borderl.<br />
#* Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
# WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
# No negative or negible impact on loading times<br />
<br />
==Packages Required==<br />
SDL: Needed for getting the colour information<br />
Boost: Might be able to provide a performance boost (no pun intended)<br />
<br />
==13 Week Timeline==<br />
{| align="center" border="1"<br />
|<br />
===Status===<br />
|<br />
===Start/End_Dates=== <br />
|<br />
===Goals===<br />
|-<br />
|Current<br />
|March 20 - April 20:<br />
| <br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
|-<br />
|Next<br />
|April 21 - May 18:<br />
|<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
|-<br />
|<br />
|May 19 - June 1: <br />
|<br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant.<br />
|-<br />
|<br />
|June 1 - 15: <br />
|<br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
|-<br />
|<br />
|June 16 - 29:<br />
|<br />
* Implement new WML snytax for the spritesheets. <br />
|-<br />
|<br />
|June 23 - 27: <br />
|<br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
|-<br />
|<br />
|June 30 - July 13:<br />
|<br />
* Modify any existing functions that need to be modified to handle sheets that broke.<br />
|-<br />
|<br />
|July 14 - 27: <br />
|<br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
|-<br />
|<br />
|July 28 - Aug 10: <br />
|<br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/python script to convert all the images to spritesheets.<br />
|-<br />
|<br />
|Aug 3: <br />
|<br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
|-<br />
|<br />
|Aug 11 - 17: <br />
|<br />
* Documentation and clean up anything that hasn't yet be done.<br />
|-<br />
|<br />
|Aug 22: <br />
|<br />
* Final evaluation and send the required code snippets to Google.<br />
|}<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54300SpriteSheetApplicationSAB2014-03-30T21:37:18Z<p>Aishiko: /* 13 Week Timeline */</p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll<br />
make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can<br />
make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* Adding a boarder around each image to make it easier for the<br />
artists to see what sort of space they have to work with will make taking the<br />
current images and converting them a bit harder as well as creating a script to<br />
convert them (which remains a soft goal, ie if I have to do it AFTER the summer,<br />
I'll do that.) Stupid perfectionist leanings, at least for what I think of to<br />
get the project ready! <br />
* Syntax making sure that its easy to use and understand for the<br />
average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of equal sized areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects<br />
in it that give the information about each frame (given above we'll call it a<br />
SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its<br />
SpriteFrameAddress Objects will be stored in the same cache as the spritesheet<br />
itself (so we won't have to refind each frame.<br />
<br />
====WML Phase One====<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress<2.1~2.10,2.1~2.2>.png:[80*5,100*2,80*5]"<br />
<br />
Another option is to do:<br />
<br />
image="units/elves-wood/Elvish_Sorceress<25,35,77,107>.png:[80]"<br />
<br />
In this case we would call it with the x,y of the 2 corners need to pull it out.<br />
This might be a good starting point for getting them to just work however I would still wish to get it more streamlined and less prone to errors.<br />
<br />
<br />
In the Elvish Sorceress example the first [] set would translate out to: row 4, columns 1-4, and the second set would stay the timing with times of 5ms, 75ms,<br />
100ms, and then 130ms for the images in order. This should take the current<br />
markup language and merely extand it to allow for rows and columns be the<br />
callers for an image. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
4.5 would be 4th row 5th column. I would take the current syntax and modify it<br />
slightly to work with rows and columns. The block of [4.1~4.4] might be<br />
<4.1~4.4> depending on whether or not its more readable.<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated SpriteAddressObject for the needed SpriteFrameAddresses<br />
This could be extended to so there is a SpriteAnimation object that will read<br />
the configs for the unit and have say the Attack Animation instead of calling<br />
each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all<br />
the Row, Column, and X,Y data for each image might be all that is needed and<br />
will work fine. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
====Cache====<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
===Testing===<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows)<br />
<br />
===Deliverables===<br />
#* Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
#* dynamic so that low mem devices are not adversely effected.<br />
# Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
#* Spritesheets that are flexible and easy for artists and WML users to implement.<br />
#* Spritesheets that do not have a fixed size for every frame they hold.<br />
#* Nor a Fixed grid size that holds each frame in its borderl.<br />
#* Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
# WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
# No negative or negible impact on loading times<br />
<br />
==Packages Required==<br />
SDL: Needed for getting the colour information<br />
Boost: Might be able to provide a performance boost (no pun intended)<br />
<br />
==13 Week Timeline==<br />
{| align="center" border="1"<br />
|<br />
===Status===<br />
|<br />
===Dates===<br />
|<br />
===Goals===<br />
|-<br />
|Current<br />
|March 20 - April 20:<br />
| <br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
|-<br />
|<br />
|April 21 - May 18:<br />
|<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
|-<br />
|<br />
|May 19 - June 1: <br />
|<br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant.<br />
|-<br />
|<br />
|June 1 - 15: <br />
|<br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
|-<br />
|<br />
|June 16 - 29:<br />
|<br />
* Implement new WML snytax for the spritesheets. <br />
|-<br />
|<br />
|June 23 - 27: <br />
|<br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
|-<br />
|<br />
|June 30 - July 13:<br />
|<br />
* Modify any existing functions that need to be modified to handle sheets that broke.<br />
|-<br />
|<br />
|July 14 - 27: <br />
|<br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
|-<br />
|<br />
|July 28 - Aug 10: <br />
|<br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/python script to convert all the images to spritesheets.<br />
|-<br />
|<br />
|Aug 3: <br />
|<br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
|-<br />
|<br />
|Aug 11 - 17: <br />
|<br />
* Documentation and clean up anything that hasn't yet be done.<br />
|-<br />
|<br />
|Aug 22: <br />
|<br />
* Final evaluation and send the required code snippets to Google.<br />
|}<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54246SpriteSheetApplicationSAB2014-03-26T15:13:21Z<p>Aishiko: /* Deliverables */</p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll<br />
make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can<br />
make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* Adding a boarder around each image to make it easier for the<br />
artists to see what sort of space they have to work with will make taking the<br />
current images and converting them a bit harder as well as creating a script to<br />
convert them (which remains a soft goal, ie if I have to do it AFTER the summer,<br />
I'll do that.) Stupid perfectionist leanings, at least for what I think of to<br />
get the project ready! <br />
* Syntax making sure that its easy to use and understand for the<br />
average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of equal sized areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects<br />
in it that give the information about each frame (given above we'll call it a<br />
SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its<br />
SpriteFrameAddress Objects will be stored in the same cache as the spritesheet<br />
itself (so we won't have to refind each frame.<br />
<br />
====WML Phase One====<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress<2.1~2.10,2.1~2.2>.png:[80*5,100*2,80*5]"<br />
<br />
Another option is to do:<br />
<br />
image="units/elves-wood/Elvish_Sorceress<25,35,77,107>.png:[80]"<br />
<br />
In this case we would call it with the x,y of the 2 corners need to pull it out.<br />
This might be a good starting point for getting them to just work however I would still wish to get it more streamlined and less prone to errors.<br />
<br />
<br />
In the Elvish Sorceress example the first [] set would translate out to: row 4, columns 1-4, and the second set would stay the timing with times of 5ms, 75ms,<br />
100ms, and then 130ms for the images in order. This should take the current<br />
markup language and merely extand it to allow for rows and columns be the<br />
callers for an image. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
4.5 would be 4th row 5th column. I would take the current syntax and modify it<br />
slightly to work with rows and columns. The block of [4.1~4.4] might be<br />
<4.1~4.4> depending on whether or not its more readable.<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated SpriteAddressObject for the needed SpriteFrameAddresses<br />
This could be extended to so there is a SpriteAnimation object that will read<br />
the configs for the unit and have say the Attack Animation instead of calling<br />
each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all<br />
the Row, Column, and X,Y data for each image might be all that is needed and<br />
will work fine. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
====Cache====<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
===Testing===<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows)<br />
<br />
===Deliverables===<br />
#* Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
#* dynamic so that low mem devices are not adversely effected.<br />
# Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
#* Spritesheets that are flexible and easy for artists and WML users to implement.<br />
#* Spritesheets that do not have a fixed size for every frame they hold.<br />
#* Nor a Fixed grid size that holds each frame in its borderl.<br />
#* Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
# WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
# No negative or negible impact on loading times<br />
<br />
==Packages Required==<br />
SDL: Needed for getting the colour information<br />
Boost: Might be able to provide a performance boost (no pun intended)<br />
<br />
==13 Week Timeline==<br />
March 20 - April 20:<br />
<br />
* Get more details and further flesh out the details of proposal. Create more<br />
patches (at least one every 1-2 weeks that is some bug or feature request,<br />
something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and<br />
encouraging to others that want to create a patch.<br />
<br />
April 21 - May 18:<br />
*More details hammered out and continue doing what I'd been doing during Mar 20<br />
- April 20. Perhaps begin a little pre-coding to test theories.<br />
<br />
May 19-June 1: <br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold<br />
all the sprite sheets once loaded. It will have to be felxible (in size and<br />
what's loaded) and perstant.<br />
<br />
June 1-15: <br />
* Add a get_spritesheet_frame function to get the image of the sprite we need<br />
right now.<br />
<br />
June 16-29:<br />
* Implement new WML snytax for the spritesheets.<br />
parsed. <br />
<br />
June 23-27: <br />
* Mid-term evaluation, I would like to receive feedback before this point so<br />
that if I'm not performing up to par I can work harder/longer.<br />
<br />
June 30-July 13:<br />
* Modify any existing functions that need to be modified to handle sheets that<br />
broke.<br />
<br />
July 14-27: <br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure<br />
its as robust as I can make it in the timeframe allotted to make it all work.<br />
<br />
July 28-Aug 10: <br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't<br />
expect and only a fool doesn't plan for the worst, so that is what this is, this<br />
is my, "OH CRAP" time. Where I have some time to address the parts that take<br />
longer or where I work on optional extended tasks like writing a shell/pythonn<br />
script to convert all the images to spritesheets.<br />
<br />
Aug 3: <br />
* End of all major code additions/changes, begin of code clean-up and Minor<br />
fixes begin.<br />
<br />
Aug 11-17: <br />
* Documentation and clean up anything that hasn't yet be done.<br />
<br />
Aug 22: <br />
* Final evaluation and send the required code snippets to Google.<br />
<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54241SpriteSheetApplicationSAB2014-03-26T14:49:09Z<p>Aishiko: /* WML Phase One */</p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll<br />
make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can<br />
make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* Adding a boarder around each image to make it easier for the<br />
artists to see what sort of space they have to work with will make taking the<br />
current images and converting them a bit harder as well as creating a script to<br />
convert them (which remains a soft goal, ie if I have to do it AFTER the summer,<br />
I'll do that.) Stupid perfectionist leanings, at least for what I think of to<br />
get the project ready! <br />
* Syntax making sure that its easy to use and understand for the<br />
average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of equal sized areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects<br />
in it that give the information about each frame (given above we'll call it a<br />
SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its<br />
SpriteFrameAddress Objects will be stored in the same cache as the spritesheet<br />
itself (so we won't have to refind each frame.<br />
<br />
====WML Phase One====<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
I envision it to be more like one of these to work as with a spritesheet:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress<2.1~2.10,2.1~2.2>.png:[80*5,100*2,80*5]"<br />
<br />
Another option is to do:<br />
<br />
image="units/elves-wood/Elvish_Sorceress<25,35,77,107>.png:[80]"<br />
<br />
In this case we would call it with the x,y of the 2 corners need to pull it out.<br />
This might be a good starting point for getting them to just work however I would still wish to get it more streamlined and less prone to errors.<br />
<br />
<br />
In the Elvish Sorceress example the first [] set would translate out to: row 4, columns 1-4, and the second set would stay the timing with times of 5ms, 75ms,<br />
100ms, and then 130ms for the images in order. This should take the current<br />
markup language and merely extand it to allow for rows and columns be the<br />
callers for an image. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
4.5 would be 4th row 5th column. I would take the current syntax and modify it<br />
slightly to work with rows and columns. The block of [4.1~4.4] might be<br />
<4.1~4.4> depending on whether or not its more readable.<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated SpriteAddressObject for the needed SpriteFrameAddresses<br />
This could be extended to so there is a SpriteAnimation object that will read<br />
the configs for the unit and have say the Attack Animation instead of calling<br />
each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all<br />
the Row, Column, and X,Y data for each image might be all that is needed and<br />
will work fine. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
====Cache====<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
===Testing===<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows)<br />
<br />
===Deliverables===<br />
# Properly working Spritesheet cache to speed up loading and elimnate glithy and<br />
laging animations do to disk access times.<br />
## dynamic so that low mem devices are not adversely effected.<br />
# Properly parse spritesheets and quickly be able to pass that information on<br />
for each frame.<br />
# Spritesheets that are flexible and easy for artists and WML users to<br />
implement.<br />
## Spritesheets that do not have a fixed size for every frame they hold.<br />
## Nor a Fixed grid size that holds each frame in its borderl.<br />
## Not require to have the gridlines or the borders be a particular width<br />
(optional, could be axed for performance reasons).<br />
# WML syntax for Spritesheets that is not long, complex, hard to understand, or<br />
prone to errors.<br />
# No negative or negible impact on loading times<br />
<br />
==Packages Required==<br />
SDL: Needed for getting the colour information<br />
Boost: Might be able to provide a performance boost (no pun intended)<br />
<br />
==13 Week Timeline==<br />
March 20 - April 20:<br />
<br />
* Get more details and further flesh out the details of proposal. Create more<br />
patches (at least one every 1-2 weeks that is some bug or feature request,<br />
something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and<br />
encouraging to others that want to create a patch.<br />
<br />
April 21 - May 18:<br />
*More details hammered out and continue doing what I'd been doing during Mar 20<br />
- April 20. Perhaps begin a little pre-coding to test theories.<br />
<br />
May 19-June 1: <br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold<br />
all the sprite sheets once loaded. It will have to be felxible (in size and<br />
what's loaded) and perstant.<br />
<br />
June 1-15: <br />
* Add a get_spritesheet_frame function to get the image of the sprite we need<br />
right now.<br />
<br />
June 16-29:<br />
* Implement new WML snytax for the spritesheets.<br />
parsed. <br />
<br />
June 23-27: <br />
* Mid-term evaluation, I would like to receive feedback before this point so<br />
that if I'm not performing up to par I can work harder/longer.<br />
<br />
June 30-July 13:<br />
* Modify any existing functions that need to be modified to handle sheets that<br />
broke.<br />
<br />
July 14-27: <br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure<br />
its as robust as I can make it in the timeframe allotted to make it all work.<br />
<br />
July 28-Aug 10: <br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't<br />
expect and only a fool doesn't plan for the worst, so that is what this is, this<br />
is my, "OH CRAP" time. Where I have some time to address the parts that take<br />
longer or where I work on optional extended tasks like writing a shell/pythonn<br />
script to convert all the images to spritesheets.<br />
<br />
Aug 3: <br />
* End of all major code additions/changes, begin of code clean-up and Minor<br />
fixes begin.<br />
<br />
Aug 11-17: <br />
* Documentation and clean up anything that hasn't yet be done.<br />
<br />
Aug 22: <br />
* Final evaluation and send the required code snippets to Google.<br />
<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54240SpriteSheetApplicationSAB2014-03-26T14:28:46Z<p>Aishiko: </p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll<br />
make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can<br />
make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* Adding a boarder around each image to make it easier for the<br />
artists to see what sort of space they have to work with will make taking the<br />
current images and converting them a bit harder as well as creating a script to<br />
convert them (which remains a soft goal, ie if I have to do it AFTER the summer,<br />
I'll do that.) Stupid perfectionist leanings, at least for what I think of to<br />
get the project ready! <br />
* Syntax making sure that its easy to use and understand for the<br />
average user<br />
<br />
===First Steps===<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. I'll need a spritesheet for this, preferably a big<br />
one. Through this whole process if it breaks it should only break on the sprite<br />
sheets until then it shouldn't break anything exisiting.<br />
<br />
===How This Will Work===<br />
The way this will work is each sheet will be a grid of one colour that is not<br />
used in any of the sprites (say a shade of pink) this RGBA colour is a Primary<br />
Key, it will lay out a grid of equal sized areas within our spritesheet. Then<br />
each of those grid squares (or rectangles) each frame/image has a second border<br />
of colour, say a different shade of pink. Each unit's spritesheet will then be<br />
read at loading into the cache, each grid square will be searched for an image<br />
if found it will be loaded into an object that will contain the following<br />
information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects<br />
in it that give the information about each frame (given above we'll call it a<br />
SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its<br />
SpriteFrameAddress Objects will be stored in the same cache as the spritesheet<br />
itself (so we won't have to refind each frame.<br />
<br />
====WML Phase One====<br />
The current syntax is:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
to work as a spritesheet with something like:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]<br />
"<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress<2.1~2.10,2.1~2.2>.png:[80*5,100*2,80*5]<br />
"<br />
<br />
which would translate out to: row 4, columns 1-4, with times of 5ms, 75ms,<br />
100ms, and then 130ms for the images in order. This should take the current<br />
markup language and merely extand it to allow for rows and columns be the<br />
callers for an image. The <sheetName> will either relate to a memory address of<br />
the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
4.5 would be 4th row 5th column. I would take the current syntax and modify it<br />
slightly to work with rows and columns. The block of [4.1~4.4] might be<br />
<4.1~4.4> depending on whether or not its more readable.<br />
<br />
When the WML goes for the individual images that create that animation it'll<br />
look at the generated SpriteAddressObject for the needed SpriteFrameAddresses<br />
This could be extended to so there is a SpriteAnimation object that will read<br />
the configs for the unit and have say the Attack Animation instead of calling<br />
each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all<br />
the Row, Column, and X,Y data for each image might be all that is needed and<br />
will work fine. The idea of holding a config of where each image is located and<br />
saving that would remove the overhead of searching everytime a frame is called. <br />
These frames would then be passed to the normal cache used and stored there,<br />
until they expire.<br />
<br />
====Cache====<br />
In cache the spritesheets need to be parsed, either all at once or only those<br />
grids that are currently needed and the found corners saved as above. When an<br />
image is needed from a spritesheet it will gotten out of the sheet and then<br />
passed into the cache that will using and holding that image such as the<br />
scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until<br />
the game is exited completely or the cache is full the oldest referenced image<br />
will be dropped.<br />
<br />
===Testing===<br />
====Phase One====<br />
I will create a test program that will allow me to make sure that the sprites<br />
are being parsed properly. This program will be intergrated and become the<br />
spritesheet core of the program. Having this out by itself will allow me to see<br />
what sort of difference there is when parsing just the needed gridboxes and the<br />
whole sheet. This will allow me to come up with some decent error messages for<br />
malformed sprite boxes.<br />
<br />
====Phase Two====<br />
In addition to creating unit tests, I'll try out various hardware to see what<br />
sort of performance changes I can detect during the course of getting things<br />
working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB<br />
RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not<br />
test on that and I only have Windows in a VM, so most testing will be done under<br />
Linux I'll depend on the various developers that use windows to let me know how<br />
it is affecting the running under Windows)<br />
<br />
===Deliverables===<br />
# Properly working Spritesheet cache to speed up loading and elimnate glithy and<br />
laging animations do to disk access times.<br />
## dynamic so that low mem devices are not adversely effected.<br />
# Properly parse spritesheets and quickly be able to pass that information on<br />
for each frame.<br />
# Spritesheets that are flexible and easy for artists and WML users to<br />
implement.<br />
## Spritesheets that do not have a fixed size for every frame they hold.<br />
## Nor a Fixed grid size that holds each frame in its borderl.<br />
## Not require to have the gridlines or the borders be a particular width<br />
(optional, could be axed for performance reasons).<br />
# WML syntax for Spritesheets that is not long, complex, hard to understand, or<br />
prone to errors.<br />
# No negative or negible impact on loading times<br />
<br />
==Packages Required==<br />
SDL: Needed for getting the colour information<br />
Boost: Might be able to provide a performance boost (no pun intended)<br />
<br />
==13 Week Timeline==<br />
March 20 - April 20:<br />
<br />
* Get more details and further flesh out the details of proposal. Create more<br />
patches (at least one every 1-2 weeks that is some bug or feature request,<br />
something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and<br />
encouraging to others that want to create a patch.<br />
<br />
April 21 - May 18:<br />
*More details hammered out and continue doing what I'd been doing during Mar 20<br />
- April 20. Perhaps begin a little pre-coding to test theories.<br />
<br />
May 19-June 1: <br />
* Add a cache for just the spritesheets <br />
** Here I'll add a spritesheets cache it will be the cache that will hold<br />
all the sprite sheets once loaded. It will have to be felxible (in size and<br />
what's loaded) and perstant.<br />
<br />
June 1-15: <br />
* Add a get_spritesheet_frame function to get the image of the sprite we need<br />
right now.<br />
<br />
June 16-29:<br />
* Implement new WML snytax for the spritesheets.<br />
parsed. <br />
<br />
June 23-27: <br />
* Mid-term evaluation, I would like to receive feedback before this point so<br />
that if I'm not performing up to par I can work harder/longer.<br />
<br />
June 30-July 13:<br />
* Modify any existing functions that need to be modified to handle sheets that<br />
broke.<br />
<br />
July 14-27: <br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure<br />
its as robust as I can make it in the timeframe allotted to make it all work.<br />
<br />
July 28-Aug 10: <br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't<br />
expect and only a fool doesn't plan for the worst, so that is what this is, this<br />
is my, "OH CRAP" time. Where I have some time to address the parts that take<br />
longer or where I work on optional extended tasks like writing a shell/pythonn<br />
script to convert all the images to spritesheets.<br />
<br />
Aug 3: <br />
* End of all major code additions/changes, begin of code clean-up and Minor<br />
fixes begin.<br />
<br />
Aug 11-17: <br />
* Documentation and clean up anything that hasn't yet be done.<br />
<br />
Aug 22: <br />
* Final evaluation and send the required code snippets to Google.<br />
<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
Week 2: May 26 to June 1<br />
Week 3: June 2 to June 8<br />
Week 4: June 9 to June 15<br />
Week 5: June 16 to June 22<br />
Week 6: June 23 to June 29<br />
Week 7: June 30 to July 6<br />
Week 8: July 6 to July 13<br />
Week 9: July 14 to July 20<br />
Week 10: July 21 to July 27<br />
Week 11: July 28 to August 3<br />
Week 12: August 4 to August 10<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no<br />
particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to<br />
http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details<br />
that effect you as an user! And only those details, and thank you for helping<br />
me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54202SpriteSheetApplicationSAB2014-03-23T19:20:26Z<p>Aishiko: /* First Steps */</p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* 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! <br />
* Syntax making sure that its easy to use and understand for the average user<br />
<br />
===First Steps===<br />
At this point I think I would take 1 sprite (character) and create a spritesheet of it, and then test with that one. To allow testing I'd likely have it check for a spritesheet if it finds one it uses that, otherwise it uses the individual sprite images, in this way the game still works, until all the sprites have been turned into spritesheets.<br />
<br />
Through this whole process if it breaks it should only break on the sprite sheets until then it shouldn't break anything exisiting.<br />
<br />
===How This Will Work===<br />
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 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 read at loading into the cache, each grid square will be searched for an image if found it will be loaded into an object that will contain the following information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects in it that give the information about each frame (given above we'll call it a SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its SpriteFrameAddress Objects will be stored in the same cache as the spritesheet itself (so we won't have to refind each frame.<br />
<br />
Current WML modification language will be largely untouched. If feasiable each sheet will be called in WML by someting like:<br />
<br />
image=<Female_Elvish_Archer>,[4.1~4.4]:[75*2,100,130]<br />
<br />
which would translate out to: row 4, columns 1-4, with times of 5ms, 75ms, 100ms, and then 130ms for the images in order. This should take the current markup language and merely extand it to allow for rows and columns be the callers for an image. The <sheetName> will either relate to a memory address of the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
====SpriteSheets Phase One====<br />
would be getting something like:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
to work as a spritesheet with something like:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
When the WML goes for the individual images that create that animation it'll look at the generated SpriteAddressObject for the needed SpriteFrameAddresses This could be extended to so there is a SpriteAnimation object that will read the configs for the unit and have say the Attack Animation instead of calling each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all the Row, Column, and X,Y data for each image might be all that is needed and will work fine.<br />
<br />
====SpriteSheets Phase Two====<br />
At this point, I'll work on getting rid of file path names in the config files, or add it in as an optional short cut way of declaring a spritesheet, something like units/elves-wood/Elvish_Sorceress.png will become Elvish_Sorceress<br />
<br />
====Cache Phase One====<br />
In cache the spritesheets would be loaded at game start and parsed as above using the scenario recruitment lists for all sides, and any recall lists. When an image is needed from a spritesheet it will gotten out of the sheet and then passed into the cache that will using and holding that image such as the scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until the game is exited completely.<br />
<br />
<br />
====Cache Phase Two====<br />
At the end of the scenario one of three things will happen, A) all the spritesheets and accomping addressing data will be dumped. Such as returning to the main menu. B) Each Spritesheet currently loaded will be compared to the next scenario loaded and any that are not needed are dropped. These 2 options should help in loading and playing on devices with limited resources to devote to a cache. C) The sheets will remained cached until the game is exited completely.<br />
<br />
===Testing===<br />
In addition to creating unit tests, I'll try out various hardware to see what sort of performance changes I can detect during the course of getting things working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not 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)<br />
<br />
===Deliverables===<br />
# Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
## dynamic so that low mem devices are not adversely effected. (Likely by implementing option A above).<br />
# Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
# Spritesheets that are flexible and easy for artists and WML users to implement.<br />
## Spritesheets that do not have a fixed size for every frame they hold.<br />
## Nor a Fixed grid size that holds each frame in its borderl.<br />
## Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
# WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
# No negative or negible impact on loading times<br />
<br />
==Packages Required==<br />
SDL: Needed for getting the colour information<br />
Boost: Might be able to provide a performance boost (no pun intended)<br />
<br />
==13 Week Timeline==<br />
March 20 - April 20:<br />
<br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
<br />
April 21 - May 18:<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
<br />
May 19-June 1: <br />
* Add a cache for just the spritesheets <br />
** Here in gl I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant. Ideally, I'd have it keep everything stored that has been stored there already, but perhaps, look at what's on the map and if say orcs are not going to be in this scenario but were in the last dropping the orc spritesheet from the cache. This would help in running wesnoth on such devices as tablets and phones with limited resources.<br />
<br />
June 1-15: <br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
** At this point I'll create the basic get an image out of a spritesheet function. Ideally, at this point we'll know its a spritesheet and just have to send it the sheet and the information about the images in the sheet. This information would be what image we want, and what size the image is. From there the function should grab the right image and send it through the rest of the processes with nothing else having to be done to make it work.<br />
<br />
June 16-29:<br />
* Implement a way to determine if its a sheet or not.<br />
** This will require modifying the existing snytax for the WML or the way it is parsed. <br />
<br />
June 23-27: <br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
<br />
June 30-July 13:<br />
* Modify any existing functions that need to be modified to handle sheets<br />
** Here is where I'd need to update things that I didn't think about during the application process. I'll also use this time to further intergrate the gl::spritesheets cache into the memory management, and hopefully discover any issues at this point and can fix them/address them before the end.<br />
<br />
July 14-27: <br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
<br />
July 28-Aug 10: <br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/pythonn script to convert all the images to spritesheets.<br />
<br />
Aug 3: <br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
<br />
Aug 11-17: <br />
* Documentation and clean up anything that hasn't yet be done.<br />
<br />
Aug 22: <br />
* Final evaluation and send the required code snippets to Google.<br />
<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
<br />
Week 2: May 26 to June 1<br />
<br />
Week 3: June 2 to June 8<br />
<br />
Week 4: June 9 to June 15<br />
<br />
Week 5: June 16 to June 22<br />
<br />
Week 6: June 23 to June 29<br />
<br />
Week 7: June 30 to July 6<br />
<br />
Week 8: July 6 to July 13<br />
<br />
Week 9: July 14 to July 20<br />
<br />
Week 10: July 21 to July 27<br />
<br />
Week 11: July 28 to August 3<br />
<br />
Week 12: August 4 to August 10<br />
<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details that effect you as an user! And only those details, and thank you for helping me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54201SpriteSheetApplicationSAB2014-03-23T19:17:57Z<p>Aishiko: </p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* 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! <br />
* Syntax making sure that its easy to use and understand for the average user<br />
<br />
===First Steps===<br />
At this point I think I would take 1 sprite (character) and create a spritesheet of it, and then test with that one. To allow testing I'd likely have it check for a spritesheet if it finds one it uses that, otherwise it uses the individual sprite images, in this way the game still works, until all the sprites have been turned into spritesheets.<br />
<br />
Through this whole process if it breaks it should only break on the sprite sheets until then it shouldn't break at all.<br />
<br />
===How This Will Work===<br />
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 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 read at loading into the cache, each grid square will be searched for an image if found it will be loaded into an object that will contain the following information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects in it that give the information about each frame (given above we'll call it a SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its SpriteFrameAddress Objects will be stored in the same cache as the spritesheet itself (so we won't have to refind each frame.<br />
<br />
Current WML modification language will be largely untouched. If feasiable each sheet will be called in WML by someting like:<br />
<br />
image=<Female_Elvish_Archer>,[4.1~4.4]:[75*2,100,130]<br />
<br />
which would translate out to: row 4, columns 1-4, with times of 5ms, 75ms, 100ms, and then 130ms for the images in order. This should take the current markup language and merely extand it to allow for rows and columns be the callers for an image. The <sheetName> will either relate to a memory address of the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
====SpriteSheets Phase One====<br />
would be getting something like:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
to work as a spritesheet with something like:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
When the WML goes for the individual images that create that animation it'll look at the generated SpriteAddressObject for the needed SpriteFrameAddresses This could be extended to so there is a SpriteAnimation object that will read the configs for the unit and have say the Attack Animation instead of calling each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all the Row, Column, and X,Y data for each image might be all that is needed and will work fine.<br />
<br />
====SpriteSheets Phase Two====<br />
At this point, I'll work on getting rid of file path names in the config files, or add it in as an optional short cut way of declaring a spritesheet, something like units/elves-wood/Elvish_Sorceress.png will become Elvish_Sorceress<br />
<br />
====Cache Phase One====<br />
In cache the spritesheets would be loaded at game start and parsed as above using the scenario recruitment lists for all sides, and any recall lists. When an image is needed from a spritesheet it will gotten out of the sheet and then passed into the cache that will using and holding that image such as the scaled_to_zoom_ or tod_colored_images_. The sheets will remained cached until the game is exited completely.<br />
<br />
<br />
====Cache Phase Two====<br />
At the end of the scenario one of three things will happen, A) all the spritesheets and accomping addressing data will be dumped. Such as returning to the main menu. B) Each Spritesheet currently loaded will be compared to the next scenario loaded and any that are not needed are dropped. These 2 options should help in loading and playing on devices with limited resources to devote to a cache. C) The sheets will remained cached until the game is exited completely.<br />
<br />
===Testing===<br />
In addition to creating unit tests, I'll try out various hardware to see what sort of performance changes I can detect during the course of getting things working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not 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)<br />
<br />
===Deliverables===<br />
# Properly working Spritesheet cache to speed up loading and elimnate glithy and laging animations do to disk access times.<br />
## dynamic so that low mem devices are not adversely effected. (Likely by implementing option A above).<br />
# Properly parse spritesheets and quickly be able to pass that information on for each frame.<br />
# Spritesheets that are flexible and easy for artists and WML users to implement.<br />
## Spritesheets that do not have a fixed size for every frame they hold.<br />
## Nor a Fixed grid size that holds each frame in its borderl.<br />
## Not require to have the gridlines or the borders be a particular width (optional, could be axed for performance reasons).<br />
# WML syntax for Spritesheets that is not long, complex, hard to understand, or prone to errors.<br />
# No negative or negible impact on loading times<br />
<br />
==Packages Required==<br />
SDL: Needed for getting the colour information<br />
Boost: Might be able to provide a performance boost (no pun intended)<br />
<br />
==13 Week Timeline==<br />
March 20 - April 20:<br />
<br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
<br />
April 21 - May 18:<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
<br />
May 19-June 1: <br />
* Add a cache for just the spritesheets <br />
** Here in gl I'll add a spritesheets cache it will be the cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant. Ideally, I'd have it keep everything stored that has been stored there already, but perhaps, look at what's on the map and if say orcs are not going to be in this scenario but were in the last dropping the orc spritesheet from the cache. This would help in running wesnoth on such devices as tablets and phones with limited resources.<br />
<br />
June 1-15: <br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
** At this point I'll create the basic get an image out of a spritesheet function. Ideally, at this point we'll know its a spritesheet and just have to send it the sheet and the information about the images in the sheet. This information would be what image we want, and what size the image is. From there the function should grab the right image and send it through the rest of the processes with nothing else having to be done to make it work.<br />
<br />
June 16-29:<br />
* Implement a way to determine if its a sheet or not.<br />
** This will require modifying the existing snytax for the WML or the way it is parsed. <br />
<br />
June 23-27: <br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
<br />
June 30-July 13:<br />
* Modify any existing functions that need to be modified to handle sheets<br />
** Here is where I'd need to update things that I didn't think about during the application process. I'll also use this time to further intergrate the gl::spritesheets cache into the memory management, and hopefully discover any issues at this point and can fix them/address them before the end.<br />
<br />
July 14-27: <br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
<br />
July 28-Aug 10: <br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/pythonn script to convert all the images to spritesheets.<br />
<br />
Aug 3: <br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
<br />
Aug 11-17: <br />
* Documentation and clean up anything that hasn't yet be done.<br />
<br />
Aug 22: <br />
* Final evaluation and send the required code snippets to Google.<br />
<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
<br />
Week 2: May 26 to June 1<br />
<br />
Week 3: June 2 to June 8<br />
<br />
Week 4: June 9 to June 15<br />
<br />
Week 5: June 16 to June 22<br />
<br />
Week 6: June 23 to June 29<br />
<br />
Week 7: June 30 to July 6<br />
<br />
Week 8: July 6 to July 13<br />
<br />
Week 9: July 14 to July 20<br />
<br />
Week 10: July 21 to July 27<br />
<br />
Week 11: July 28 to August 3<br />
<br />
Week 12: August 4 to August 10<br />
<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details that effect you as an user! And only those details, and thank you for helping me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54187SpriteSheetApplicationSAB2014-03-23T05:15:14Z<p>Aishiko: </p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* 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! <br />
* Syntax making sure that its easy to use and understand for the average user<br />
<br />
===First Steps===<br />
At this point I think I would take 1 sprite (character) and create a spritesheet of it, and then test with that one. To allow testing I'd likely have it check for a spritesheet if it finds one it uses that, otherwise it uses the individual sprite images, in this way the game still works, until all the sprites have been turned into spritesheets.<br />
<br />
Through this whole process if it breaks it should only break on the sprite sheets until then it shouldn't break at all.<br />
<br />
===How This Will Work===<br />
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 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 read at loading into the cache, each grid square will be searched for an image if found it will be loaded into an object that will contain the following information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects in it that give the information about each frame (given above we'll call it a SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its SpriteFrameAddress Objects will be stored in the same cache as the spritesheet itself (so we won't have to refind each frame.<br />
<br />
Current WML modification language will be largely untouched. If feasiable each sheet will be called in WML by someting like:<br />
<br />
image=<Female_Elvish_Archer>,[4.1~4.4]:[75*2,100,130]<br />
<br />
which would translate out to: row 4, columns 1-4, with times of 5ms, 75ms, 100ms, and then 130ms for the images in order. This should take the current markup language and merely extand it to allow for rows and columns be the callers for an image. The <sheetName> will either relate to a memory address of the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
====SpriteSheets Phase One====<br />
would be getting something like:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
to work as a spritesheet with something like:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
When the WML goes for the individual images that create that animation it'll look at the generated SpriteAddressObject for the needed SpriteFrameAddresses This could be extended to so there is a SpriteAnimation object that will read the configs for the unit and have say the Attack Animation instead of calling each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all the Row, Column, and X,Y data for each image might be all that is needed and will work fine.<br />
<br />
====SpriteSheets Phase Two====<br />
At this point, I'll work on getting rid of file path names in the config files, or add it in as an optional short cut way of declaring a spritesheet, something like units/elves-wood/Elvish_Sorceress.png will become Elvish_Sorceress<br />
<br />
====Cache Phase One====<br />
In cache the spritesheets would be loaded at game start and parsed as above using the scenario recruitment lists for all sides, and any recall lists. At the end of the scenario one of three things will happen, A) all the spritesheets and accomping addressing data will be dumped. Such as returning to the main menu. B) Each Spritesheet currently loaded will be compared to the next scenario loaded and any that are not needed are dropped. These 2 options should help in loading and playing on devices with limited resources to devote to a cache. C) The sheets will remained cached until the game is exited completely.<br />
<br />
When an image is needed from a spritesheet it will gotten out of the sheet and then passed into the cache that will using and holding that image such as the scaled_to_zoom_ or tod_colored_images_.<br />
<br />
===Testing===<br />
In addition to creating unit tests, I'll try out various hardware to see what sort of performance changes I can detect during the course of getting things working. I'll test on a Quad-core with 8 or more GB RAM, a Dual-core with 4GB RAM, and a 32bit single core with 1-4 GB RAM (I don't have any Macs so I can not 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)<br />
<br />
===13 Week Timeline===<br />
March 20 - April 20:<br />
<br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
<br />
April 21 - May 18:<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
<br />
May 19-June 1: <br />
* Add a cache for just the spritesheets <br />
** Here in gl I'll add a gl::spritesheets it will be a cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant. Ideally, I'd have it keep everything stored that has been stored there already, but perhaps, look at what's on the map and if say orcs are not going to be in this scenario but were in the last dropping the orc spritesheet from the cache. This would help in running wesnoth on such devices as tablets and phones with limited resources.<br />
<br />
June 1-15: <br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
** At this point I'll create the basic get an image out of a spritesheet function. Ideally, at this point we'll know its a spritesheet and just have to send it the sheet and the information about the images in the sheet. This information would be what image we want, and what size the image is. From there the function should grab the right image and send it through the rest of the processes with nothing else having to be done to make it work.<br />
<br />
June 16-29:<br />
* Implement a way to determine if its a sheet or not.<br />
** This will require modifying the existing snytax for the WML or the way it is parsed. <br />
<br />
June 23-27: <br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
<br />
June 30-July 13:<br />
* Modify any existing functions that need to be modified to handle sheets<br />
** Here is where I'd need to update things that I didn't think about during the application process. I'll also use this time to further intergrate the gl::spritesheets cache into the memory management, and hopefully discover any issues at this point and can fix them/address them before the end.<br />
<br />
July 14-27: <br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
<br />
July 28-Aug 10: <br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/pythonn script to convert all the images to spritesheets.<br />
<br />
Aug 3: <br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
<br />
Aug 11-17: <br />
* Documentation and clean up anything that hasn't yet be done.<br />
<br />
Aug 22: <br />
* Final evaluation and send the required code snippets to Google.<br />
<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
<br />
Week 2: May 26 to June 1<br />
<br />
Week 3: June 2 to June 8<br />
<br />
Week 4: June 9 to June 15<br />
<br />
Week 5: June 16 to June 22<br />
<br />
Week 6: June 23 to June 29<br />
<br />
Week 7: June 30 to July 6<br />
<br />
Week 8: July 6 to July 13<br />
<br />
Week 9: July 14 to July 20<br />
<br />
Week 10: July 21 to July 27<br />
<br />
Week 11: July 28 to August 3<br />
<br />
Week 12: August 4 to August 10<br />
<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details that effect you as an user! And only those details, and thank you for helping me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54186SpriteSheetApplicationSAB2014-03-23T05:09:11Z<p>Aishiko: /* SpriteSheets Phase Two */</p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* 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! <br />
* Syntax making sure that its easy to use and understand for the average user<br />
<br />
===First Steps===<br />
At this point I think I would take 1 sprite (character) and create a spritesheet of it, and then test with that one. To allow testing I'd likely have it check for a spritesheet if it finds one it uses that, otherwise it uses the individual sprite images, in this way the game still works, until all the sprites have been turned into spritesheets.<br />
<br />
Through this whole process if it breaks it should only break on the sprite sheets until then it shouldn't break at all.<br />
<br />
===How This Will Work===<br />
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 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 read at loading into the cache, each grid square will be searched for an image if found it will be loaded into an object that will contain the following information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects in it that give the information about each frame (given above we'll call it a SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its SpriteFrameAddress Objects will be stored in the same cache as the spritesheet itself (so we won't have to refind each frame.<br />
<br />
Current WML modification language will be largely untouched. If feasiable each sheet will be called in WML by someting like:<br />
<br />
image=<Female_Elvish_Archer>,[4.1~4.4]:[75*2,100,130]<br />
<br />
which would translate out to: row 4, columns 1-4, with times of 5ms, 75ms, 100ms, and then 130ms for the images in order. This should take the current markup language and merely extand it to allow for rows and columns be the callers for an image. The <sheetName> will either relate to a memory address of the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
====SpriteSheets Phase One====<br />
would be getting something like:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
to work as a spritesheet with something like:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
When the WML goes for the individual images that create that animation it'll look at the generated SpriteAddressObject for the needed SpriteFrameAddresses This could be extended to so there is a SpriteAnimation object that will read the configs for the unit and have say the Attack Animation instead of calling each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all the Row, Column, and X,Y data for each image might be all that is needed and will work fine.<br />
<br />
====SpriteSheets Phase Two====<br />
At this point, I'll work on getting rid of file path names in the config files, or add it in as an optional short cut way of declaring a spritesheet, something like units/elves-wood/Elvish_Sorceress.png will become Elvish_Sorceress<br />
<br />
====Cache Phase One====<br />
In cache the spritesheets would be loaded at game start and parsed as above using the scenario recruitment lists for all sides, and any recall lists. At the end of the scenario one of three things will happen, A) all the spritesheets and accomping addressing data will be dumped. Such as returning to the main menu. B) Each Spritesheet currently loaded will be compared to the next scenario loaded and any that are not needed are dropped. These 2 options should help in loading and playing on devices with limited resources to devote to a cache. C) The sheets will remained cached until the game is exited completely.<br />
<br />
When an image is needed from a spritesheet it will gotten out of the sheet and then passed into the cache that will using and holding that image such as the scaled_to_zoom_ or tod_colored_images_.<br />
<br />
<br />
===13 Week Timeline===<br />
March 20 - April 20:<br />
<br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
<br />
April 21 - May 18:<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
<br />
May 19-June 1: <br />
* Add a cache for just the spritesheets <br />
** Here in gl I'll add a gl::spritesheets it will be a cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant. Ideally, I'd have it keep everything stored that has been stored there already, but perhaps, look at what's on the map and if say orcs are not going to be in this scenario but were in the last dropping the orc spritesheet from the cache. This would help in running wesnoth on such devices as tablets and phones with limited resources.<br />
<br />
June 1-15: <br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
** At this point I'll create the basic get an image out of a spritesheet function. Ideally, at this point we'll know its a spritesheet and just have to send it the sheet and the information about the images in the sheet. This information would be what image we want, and what size the image is. From there the function should grab the right image and send it through the rest of the processes with nothing else having to be done to make it work.<br />
<br />
June 16-29:<br />
* Implement a way to determine if its a sheet or not.<br />
** This will require modifying the existing snytax for the WML or the way it is parsed. <br />
<br />
June 23-27: <br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
<br />
June 30-July 13:<br />
* Modify any existing functions that need to be modified to handle sheets<br />
** Here is where I'd need to update things that I didn't think about during the application process. I'll also use this time to further intergrate the gl::spritesheets cache into the memory management, and hopefully discover any issues at this point and can fix them/address them before the end.<br />
<br />
July 14-27: <br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
<br />
July 28-Aug 10: <br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/pythonn script to convert all the images to spritesheets.<br />
<br />
Aug 3: <br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
<br />
Aug 11-17: <br />
* Documentation and clean up anything that hasn't yet be done.<br />
<br />
Aug 22: <br />
* Final evaluation and send the required code snippets to Google.<br />
<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
<br />
Week 2: May 26 to June 1<br />
<br />
Week 3: June 2 to June 8<br />
<br />
Week 4: June 9 to June 15<br />
<br />
Week 5: June 16 to June 22<br />
<br />
Week 6: June 23 to June 29<br />
<br />
Week 7: June 30 to July 6<br />
<br />
Week 8: July 6 to July 13<br />
<br />
Week 9: July 14 to July 20<br />
<br />
Week 10: July 21 to July 27<br />
<br />
Week 11: July 28 to August 3<br />
<br />
Week 12: August 4 to August 10<br />
<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details that effect you as an user! And only those details, and thank you for helping me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54185SpriteSheetApplicationSAB2014-03-23T05:08:52Z<p>Aishiko: /* SpriteSheets Phase Two */</p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* 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! <br />
* Syntax making sure that its easy to use and understand for the average user<br />
<br />
===First Steps===<br />
At this point I think I would take 1 sprite (character) and create a spritesheet of it, and then test with that one. To allow testing I'd likely have it check for a spritesheet if it finds one it uses that, otherwise it uses the individual sprite images, in this way the game still works, until all the sprites have been turned into spritesheets.<br />
<br />
Through this whole process if it breaks it should only break on the sprite sheets until then it shouldn't break at all.<br />
<br />
===How This Will Work===<br />
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 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 read at loading into the cache, each grid square will be searched for an image if found it will be loaded into an object that will contain the following information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects in it that give the information about each frame (given above we'll call it a SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its SpriteFrameAddress Objects will be stored in the same cache as the spritesheet itself (so we won't have to refind each frame.<br />
<br />
Current WML modification language will be largely untouched. If feasiable each sheet will be called in WML by someting like:<br />
<br />
image=<Female_Elvish_Archer>,[4.1~4.4]:[75*2,100,130]<br />
<br />
which would translate out to: row 4, columns 1-4, with times of 5ms, 75ms, 100ms, and then 130ms for the images in order. This should take the current markup language and merely extand it to allow for rows and columns be the callers for an image. The <sheetName> will either relate to a memory address of the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
====SpriteSheets Phase One====<br />
would be getting something like:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
to work as a spritesheet with something like:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
When the WML goes for the individual images that create that animation it'll look at the generated SpriteAddressObject for the needed SpriteFrameAddresses This could be extended to so there is a SpriteAnimation object that will read the configs for the unit and have say the Attack Animation instead of calling each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all the Row, Column, and X,Y data for each image might be all that is needed and will work fine.<br />
<br />
====SpriteSheets Phase Two====<br />
At this point, I'll work on getting rid of file path names in the config files, or add it in as an optional short cut way of declaring a spritesheet, something like units/elves-wood/Elvish_Sorceress.png will be come Elvish_Sorceress<br />
<br />
====Cache Phase One====<br />
In cache the spritesheets would be loaded at game start and parsed as above using the scenario recruitment lists for all sides, and any recall lists. At the end of the scenario one of three things will happen, A) all the spritesheets and accomping addressing data will be dumped. Such as returning to the main menu. B) Each Spritesheet currently loaded will be compared to the next scenario loaded and any that are not needed are dropped. These 2 options should help in loading and playing on devices with limited resources to devote to a cache. C) The sheets will remained cached until the game is exited completely.<br />
<br />
When an image is needed from a spritesheet it will gotten out of the sheet and then passed into the cache that will using and holding that image such as the scaled_to_zoom_ or tod_colored_images_.<br />
<br />
<br />
===13 Week Timeline===<br />
March 20 - April 20:<br />
<br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
<br />
April 21 - May 18:<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
<br />
May 19-June 1: <br />
* Add a cache for just the spritesheets <br />
** Here in gl I'll add a gl::spritesheets it will be a cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant. Ideally, I'd have it keep everything stored that has been stored there already, but perhaps, look at what's on the map and if say orcs are not going to be in this scenario but were in the last dropping the orc spritesheet from the cache. This would help in running wesnoth on such devices as tablets and phones with limited resources.<br />
<br />
June 1-15: <br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
** At this point I'll create the basic get an image out of a spritesheet function. Ideally, at this point we'll know its a spritesheet and just have to send it the sheet and the information about the images in the sheet. This information would be what image we want, and what size the image is. From there the function should grab the right image and send it through the rest of the processes with nothing else having to be done to make it work.<br />
<br />
June 16-29:<br />
* Implement a way to determine if its a sheet or not.<br />
** This will require modifying the existing snytax for the WML or the way it is parsed. <br />
<br />
June 23-27: <br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
<br />
June 30-July 13:<br />
* Modify any existing functions that need to be modified to handle sheets<br />
** Here is where I'd need to update things that I didn't think about during the application process. I'll also use this time to further intergrate the gl::spritesheets cache into the memory management, and hopefully discover any issues at this point and can fix them/address them before the end.<br />
<br />
July 14-27: <br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
<br />
July 28-Aug 10: <br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/pythonn script to convert all the images to spritesheets.<br />
<br />
Aug 3: <br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
<br />
Aug 11-17: <br />
* Documentation and clean up anything that hasn't yet be done.<br />
<br />
Aug 22: <br />
* Final evaluation and send the required code snippets to Google.<br />
<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
<br />
Week 2: May 26 to June 1<br />
<br />
Week 3: June 2 to June 8<br />
<br />
Week 4: June 9 to June 15<br />
<br />
Week 5: June 16 to June 22<br />
<br />
Week 6: June 23 to June 29<br />
<br />
Week 7: June 30 to July 6<br />
<br />
Week 8: July 6 to July 13<br />
<br />
Week 9: July 14 to July 20<br />
<br />
Week 10: July 21 to July 27<br />
<br />
Week 11: July 28 to August 3<br />
<br />
Week 12: August 4 to August 10<br />
<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details that effect you as an user! And only those details, and thank you for helping me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54184SpriteSheetApplicationSAB2014-03-23T05:01:57Z<p>Aishiko: </p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
===Goals===<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
===Problems===<br />
* Not all units and terrain are 72x72<br />
* 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! <br />
* Syntax making sure that its easy to use and understand for the average user<br />
<br />
===First Steps===<br />
At this point I think I would take 1 sprite (character) and create a spritesheet of it, and then test with that one. To allow testing I'd likely have it check for a spritesheet if it finds one it uses that, otherwise it uses the individual sprite images, in this way the game still works, until all the sprites have been turned into spritesheets.<br />
<br />
Through this whole process if it breaks it should only break on the sprite sheets until then it shouldn't break at all.<br />
<br />
===How This Will Work===<br />
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 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 read at loading into the cache, each grid square will be searched for an image if found it will be loaded into an object that will contain the following information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects in it that give the information about each frame (given above we'll call it a SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its SpriteFrameAddress Objects will be stored in the same cache as the spritesheet itself (so we won't have to refind each frame.<br />
<br />
Current WML modification language will be largely untouched. If feasiable each sheet will be called in WML by someting like:<br />
<br />
image=<Female_Elvish_Archer>,[4.1~4.4]:[75*2,100,130]<br />
<br />
which would translate out to: row 4, columns 1-4, with times of 5ms, 75ms, 100ms, and then 130ms for the images in order. This should take the current markup language and merely extand it to allow for rows and columns be the callers for an image. The <sheetName> will either relate to a memory address of the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
====SpriteSheets Phase One====<br />
would be getting something like:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
to work as a spritesheet with something like:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
When the WML goes for the individual images that create that animation it'll look at the generated SpriteAddressObject for the needed SpriteFrameAddresses This could be extended to so there is a SpriteAnimation object that will read the configs for the unit and have say the Attack Animation instead of calling each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all the Row, Column, and X,Y data for each image might be all that is needed and will work fine.<br />
<br />
====SpriteSheets Phase Two====<br />
At this point, I'll work on getting rid of file path names in the config files, or add it in as an optional short cut way of declaring a spritesheet, something like units/elves-wood/Elvish_Sorceress.png will be comes Elvish_Sorceress<br />
<br />
====Cache Phase One====<br />
In cache the spritesheets would be loaded at game start and parsed as above using the scenario recruitment lists for all sides, and any recall lists. At the end of the scenario one of three things will happen, A) all the spritesheets and accomping addressing data will be dumped. Such as returning to the main menu. B) Each Spritesheet currently loaded will be compared to the next scenario loaded and any that are not needed are dropped. These 2 options should help in loading and playing on devices with limited resources to devote to a cache. C) The sheets will remained cached until the game is exited completely.<br />
<br />
When an image is needed from a spritesheet it will gotten out of the sheet and then passed into the cache that will using and holding that image such as the scaled_to_zoom_ or tod_colored_images_.<br />
<br />
<br />
===13 Week Timeline===<br />
March 20 - April 20:<br />
<br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
<br />
April 21 - May 18:<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
<br />
May 19-June 1: <br />
* Add a cache for just the spritesheets <br />
** Here in gl I'll add a gl::spritesheets it will be a cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant. Ideally, I'd have it keep everything stored that has been stored there already, but perhaps, look at what's on the map and if say orcs are not going to be in this scenario but were in the last dropping the orc spritesheet from the cache. This would help in running wesnoth on such devices as tablets and phones with limited resources.<br />
<br />
June 1-15: <br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
** At this point I'll create the basic get an image out of a spritesheet function. Ideally, at this point we'll know its a spritesheet and just have to send it the sheet and the information about the images in the sheet. This information would be what image we want, and what size the image is. From there the function should grab the right image and send it through the rest of the processes with nothing else having to be done to make it work.<br />
<br />
June 16-29:<br />
* Implement a way to determine if its a sheet or not.<br />
** This will require modifying the existing snytax for the WML or the way it is parsed. <br />
<br />
June 23-27: <br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
<br />
June 30-July 13:<br />
* Modify any existing functions that need to be modified to handle sheets<br />
** Here is where I'd need to update things that I didn't think about during the application process. I'll also use this time to further intergrate the gl::spritesheets cache into the memory management, and hopefully discover any issues at this point and can fix them/address them before the end.<br />
<br />
July 14-27: <br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
<br />
July 28-Aug 10: <br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/pythonn script to convert all the images to spritesheets.<br />
<br />
Aug 3: <br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
<br />
Aug 11-17: <br />
* Documentation and clean up anything that hasn't yet be done.<br />
<br />
Aug 22: <br />
* Final evaluation and send the required code snippets to Google.<br />
<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
<br />
Week 2: May 26 to June 1<br />
<br />
Week 3: June 2 to June 8<br />
<br />
Week 4: June 9 to June 15<br />
<br />
Week 5: June 16 to June 22<br />
<br />
Week 6: June 23 to June 29<br />
<br />
Week 7: June 30 to July 6<br />
<br />
Week 8: July 6 to July 13<br />
<br />
Week 9: July 14 to July 20<br />
<br />
Week 10: July 21 to July 27<br />
<br />
Week 11: July 28 to August 3<br />
<br />
Week 12: August 4 to August 10<br />
<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details that effect you as an user! And only those details, and thank you for helping me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54176SpriteSheetApplicationSAB2014-03-23T04:04:34Z<p>Aishiko: </p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
==Goals==<br />
Eliminate as many small single images as possible from the program. <br />
Enable Sprite Sheets to be used in;<br />
# Gameplay<br />
#* Units<br />
#* Terrain<br />
#* etc<br />
# Menus, mouse pointers, etc. Optional Goal I doubt at this point that I'll make it this far.<br />
# Reuse as much as the existing syntax as possible<br />
# Create Unit Tests to make sure that the areas modified are as good as I can make them.<br />
# Make it easy for the artists to add sprites to a sprite sheet: <br />
<br />
==Problems==<br />
* Not all units and terrain are 72x72<br />
* 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! <br />
* Syntax making sure that its easy to use and understand for the average user<br />
<br />
==First Steps==<br />
At this point I think I would take 1 sprite (character) and create a spritesheet of it, and then test with that one. To allow testing I'd likely have it check for a spritesheet if it finds one it uses that, otherwise it uses the individual sprite images, in this way the game still works, until all the sprites have been turned into spritesheets.<br />
<br />
Through this whole process if it breaks it should only break on the sprite sheets until then it shouldn't break at all.<br />
<br />
==How This Will Work==<br />
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 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 read at loading into the cache, each grid square will be searched for an image if found it will be loaded into an object that will contain the following information:<br />
*SpriteSheetName<br />
*Row<br />
*Column<br />
*Upper Y<br />
*Upper X<br />
*Lower Y<br />
*Lower X<br />
<br />
So each Spritesheet will generate a SpriteAddress Object and will have objects in it that give the information about each frame (given above we'll call it a SpriteFrameAddress Object). The Spritesheet and its SpriteAddress and its SpriteFrameAddress Objects will be stored in the same cache as the spritesheet itself (so we won't have to refind each frame.<br />
<br />
Current WML modification language will be largely untouched. If feasiable each sheet will be called in WML by someting like:<br />
<br />
image=<Female_Elvish_Archer>,[4.1~4.4]:[75*2,100,130]<br />
<br />
which would translate out to: row 4, columns 1-4, with times of 5ms, 75ms, 100ms, and then 130ms for the images in order. This should take the current markup language and merely extand it to allow for rows and columns be the callers for an image. The <sheetName> will either relate to a memory address of the sheet or to an image under units/ like units/Elvish_Sorceress.png<br />
<br />
===SpriteSheets Phase One===<br />
would be getting something like:<br />
<br />
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"<br />
<br />
to work as a spritesheet with something like:<br />
<br />
image="units/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]" <br />
<br />
or<br />
<br />
image="units/elves-wood/Elvish_Sorceress[2.1~2.10,2.1~2.2].png:[80*5,100*2,80*5]"<br />
<br />
When the WML goes for the individual images that create that animation it'll look at the generated SpriteAddressObject for the needed SpriteFrameAddresses This could be extended to so there is a SpriteAnimation object that will read the configs for the unit and have say the Attack Animation instead of calling each image seperately (perhaps as a later extention?) <br />
<br />
The ojbects might not be needed and just a config file generated that holds all the Row, Column, and X,Y data for each image might be all that is needed and will work fine.<br />
<br />
===SpriteSheets Phase Two===<br />
At this point, I'll work on getting rid of file path names in the config files, or add it in as an optional short cut way of declaring a spritesheet, something like units/elves-wood/Elvish_Sorceress.png will be comes Elvish_Sorceress<br />
<br />
===Cache Phase One===<br />
In cache the spritesheets would be loaded at game start and parsed as above using the scenario recruitment lists for all sides, and any recall lists. At the end of the scenario one of three things will happen, A) all the spritesheets and accomping addressing data will be dumped. Such as returning to the main menu. B) Each Spritesheet currently loaded will be compared to the next scenario loaded and any that are not needed are dropped. These 2 options should help in loading and playing on devices with limited resources to devote to a cache. C) The sheets will remained cached until the game is exited completely.<br />
<br />
When an image is needed from a spritesheet it will gotten out of the sheet and then passed into the cache that will using and holding that image such as the scaled_to_zoom_ or tod_colored_images_.<br />
<br />
<br />
==13 Week Timeline==<br />
March 20 - April 20:<br />
<br />
* Get more details and further flesh out the details of proposal. Create more patches (at least one every 1-2 weeks that is some bug or feature request, something not trival).<br />
* Get more familiar with Git and GitHub. Be active in the community and encouraging to others that want to create a patch.<br />
<br />
April 21 - May 18:<br />
*More details hammered out and continue doing what I'd been doing during Mar 20 - April 20. Perhaps begin a little pre-coding to test theories.<br />
<br />
May 19-June 1: <br />
* Add a cache for just the spritesheets <br />
** Here in gl I'll add a gl::spritesheets it will be a cache that will hold all the sprite sheets once loaded. It will have to be felxible (in size and what's loaded) and perstant. Ideally, I'd have it keep everything stored that has been stored there already, but perhaps, look at what's on the map and if say orcs are not going to be in this scenario but were in the last dropping the orc spritesheet from the cache. This would help in running wesnoth on such devices as tablets and phones with limited resources.<br />
<br />
June 1-15: <br />
* Add a get_spritesheet_frame function to get the image of the sprite we need right now.<br />
** At this point I'll create the basic get an image out of a spritesheet function. Ideally, at this point we'll know its a spritesheet and just have to send it the sheet and the information about the images in the sheet. This information would be what image we want, and what size the image is. From there the function should grab the right image and send it through the rest of the processes with nothing else having to be done to make it work.<br />
<br />
June 16-29:<br />
* Implement a way to determine if its a sheet or not.<br />
** This will require modifying the existing snytax for the WML or the way it is parsed. <br />
<br />
June 23-27: <br />
* Mid-term evaluation, I would like to receive feedback before this point so that if I'm not performing up to par I can work harder/longer.<br />
<br />
June 30-July 13:<br />
* Modify any existing functions that need to be modified to handle sheets<br />
** Here is where I'd need to update things that I didn't think about during the application process. I'll also use this time to further intergrate the gl::spritesheets cache into the memory management, and hopefully discover any issues at this point and can fix them/address them before the end.<br />
<br />
July 14-27: <br />
* Run tests and see what breaks and fix what broke<br />
** Unit tests would have to be added and commited to keep this up and make sure its as robust as I can make it in the timeframe allotted to make it all work.<br />
<br />
July 28-Aug 10: <br />
* Pad time in case something takes longer then expected<br />
** Something ALWAYS takes longer then expected or breaks in ways that we didn't expect and only a fool doesn't plan for the worst, so that is what this is, this is my, "OH CRAP" time. Where I have some time to address the parts that take longer or where I work on optional extended tasks like writing a shell/pythonn script to convert all the images to spritesheets.<br />
<br />
Aug 3: <br />
* End of all major code additions/changes, begin of code clean-up and Minor fixes begin.<br />
<br />
Aug 11-17: <br />
* Documentation and clean up anything that hasn't yet be done.<br />
<br />
Aug 22: <br />
* Final evaluation and send the required code snippets to Google.<br />
<br />
===The Weeks in the Program===<br />
Week 1: May 19 to May 25<br />
<br />
Week 2: May 26 to June 1<br />
<br />
Week 3: June 2 to June 8<br />
<br />
Week 4: June 9 to June 15<br />
<br />
Week 5: June 16 to June 22<br />
<br />
Week 6: June 23 to June 29<br />
<br />
Week 7: June 30 to July 6<br />
<br />
Week 8: July 6 to July 13<br />
<br />
Week 9: July 14 to July 20<br />
<br />
Week 10: July 21 to July 27<br />
<br />
Week 11: July 28 to August 3<br />
<br />
Week 12: August 4 to August 10<br />
<br />
Week 13: August 11 to August 17<br />
<br />
Optional tasks if everything goes smoother and easier then planed in no particular order:<br />
* Convert all the sprites, update all the .cfg for the base units<br />
* Create script to allow Addon Artists convert their sprites<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details that effect you as an user! And only those details, and thank you for helping me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54100SpriteSheetApplicationSAB2014-03-21T08:07:12Z<p>Aishiko: </p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
<br />
4.4) Include an estimated timeline for your work on the project. Don't forget to<br />
mention special things like "I booked holidays between A and B" and "I got an<br />
exam at ABC and won't be doing much then".<br />
<br />
I'm still working out a timeline but I would most likely do a commit <br />
at least weekly. And break out the commits so that similar changes <br />
are only in that commit. Example, comment changes in one, (assuming <br />
no code changes), a converted set of sprites (aka the spritesheet) as <br />
one, and then code making use of it. After checking to make sure that <br />
the spritesheet works, removal of the converted individual sprite image <br />
files.<br />
<br />
4.5) Include as much technical detail about your implementation as you can<br />
<br />
At this point I think I would take 1 sprite (character) and create a <br />
spritesheet of it, and then test with that one. To allow testing I'd <br />
likely have it check for a spritesheet if it finds one it uses that, <br />
otherwise it uses the individual sprite images, in this way the game <br />
still works, until all the sprites have been turned into spritesheets.<br />
<br />
Once I have completed getting a character spritesheet to work, I'd <br />
then move on to the map sprites to spritesheets, again using the same <br />
methodology of check and if it finds a spritesheet use it otherwise, <br />
use the individual images. Though, on the grouping I'm not sure how <br />
I'd do that mordante and I'd have to discuss grouping, since a map can <br />
have any or all of the different tiles, and they are not chained like <br />
the unit/character sprites are, I'd have to group similar tiles together.<br />
Like the water images, shorelines, docks, and water villages, as one.<br />
The fields, human villages and castles in one. Swamp things together, <br />
and so on.<br />
<br />
I've heard that some devs think that a spritesheet might cause issues <br />
with larger images that don't fit in a hex, I'll intentional create some <br />
sprite sheets just for testing this purpose. I'll also see about creating <br />
some tests to check and see if the performance gains are really showing up.<br />
<br />
==Artists Weigh In== <br />
<br />
OK, not just for artists, go to http://forums.wesnoth.org/viewtopic.php?f=9&t=40191 and weigh in on the details that effect you as an user! And only those details, and thank you for helping me make Wesnoth a little bit better.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54090SpriteSheetApplicationSAB2014-03-21T04:08:35Z<p>Aishiko: </p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
<br />
4.4) Include an estimated timeline for your work on the project. Don't forget to<br />
mention special things like "I booked holidays between A and B" and "I got an<br />
exam at ABC and won't be doing much then".<br />
<br />
I'm still working out a timeline but I would most likely do a commit <br />
at least weekly. And break out the commits so that similar changes <br />
are only in that commit. Example, comment changes in one, (assuming <br />
no code changes), a converted set of sprites (aka the spritesheet) as <br />
one, and then code making use of it. After checking to make sure that <br />
the spritesheet works, removal of the converted individual sprite image <br />
files.<br />
<br />
4.5) Include as much technical detail about your implementation as you can<br />
<br />
At this point I think I would take 1 sprite (character) and create a <br />
spritesheet of it, and then test with that one. To allow testing I'd <br />
likely have it check for a spritesheet if it finds one it uses that, <br />
otherwise it uses the individual sprite images, in this way the game <br />
still works, until all the sprites have been turned into spritesheets.<br />
<br />
Once I have completed getting a character spritesheet to work, I'd <br />
then move on to the map sprites to spritesheets, again using the same <br />
methodology of check and if it finds a spritesheet use it otherwise, <br />
use the individual images. Though, on the grouping I'm not sure how <br />
I'd do that mordante and I'd have to discuss grouping, since a map can <br />
have any or all of the different tiles, and they are not chained like <br />
the unit/character sprites are, I'd have to group similar tiles together.<br />
Like the water images, shorelines, docks, and water villages, as one.<br />
The fields, human villages and castles in one. Swamp things together, <br />
and so on.<br />
<br />
I've heard that some devs think that a spritesheet might cause issues <br />
with larger images that don't fit in a hex, I'll intentional create some <br />
sprite sheets just for testing this purpose. I'll also see about creating <br />
some tests to check and see if the performance gains are really showing up.<br />
<br />
<br />
**************Comments and Suggestions**************<br />
Please place them after this line, all are appreciated and if I can't thank you <br />
personally (IE you don't attach your name to it, Thank you.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54087SpriteSheetApplicationSAB2014-03-21T03:50:40Z<p>Aishiko: </p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Prelim Implementation Ideas==<br />
<br />
4) Project<br />
<br />
4.1) Did you select a project from our list? If that is the case, what project<br />
did you select? What do you want to especially concentrate on?<br />
<br />
I selected one from the list, the implementing the SpriteSheets. <br />
I would like to concentrate on 2 tasks, 1 getting SpriteSheets to just <br />
work in wesnoth, and two, provide a script/tool/utility to allow easy <br />
converting from the old single images to the sheet (assuming certian <br />
naming conventions are followed).<br />
<br />
4.2) If you have invented your own project, please describe the project and the<br />
scope.<br />
<br />
N/A<br />
<br />
4.3) Why did you choose this project?<br />
<br />
I chosse it because I understand the concepts behind it, and felt it <br />
was a task that I could handle. It will also force me to learn and <br />
will provide immediate gains to all users when the version that <br />
includes the change is pushed out.<br />
<br />
4.4) Include an estimated timeline for your work on the project. Don't forget to<br />
mention special things like "I booked holidays between A and B" and "I got an<br />
exam at ABC and won't be doing much then".<br />
<br />
I'm still working out a timeline but I would most likely do a commit <br />
at least weekly. And break out the commits so that similar changes <br />
are only in that commit. Example, comment changes in one, (assuming <br />
no code changes), a converted set of sprites (aka the spritesheet) as <br />
one, and then code making use of it. After checking to make sure that <br />
the spritesheet works, removal of the converted individual sprite image <br />
files.<br />
<br />
4.5) Include as much technical detail about your implementation as you can<br />
<br />
At this point I think I would take 1 sprite (character) and create a <br />
spritesheet of it, and then test with that one. To allow testing I'd <br />
likely have it check for a spritesheet if it finds one it uses that, <br />
otherwise it uses the individual sprite images, in this way the game <br />
still works, until all the sprites have been turned into spritesheets.<br />
<br />
Once I have completed getting a character spritesheet to work, I'd <br />
then move on to the map sprites to spritesheets, again using the same <br />
methodology of check and if it finds a spritesheet use it otherwise, <br />
use the individual images. Though, on the grouping I'm not sure how <br />
I'd do that mordante and I'd have to discuss grouping, since a map can <br />
have any or all of the different tiles, and they are not chained like <br />
the unit/character sprites are, I'd have to group similar tiles together.<br />
Like the water images, shorelines, docks, and water villages, as one.<br />
The fields, human villages and castles in one. Swamp things together, <br />
and so on.<br />
<br />
I've heard that some devs think that a spritesheet might cause issues <br />
with larger images that don't fit in a hex, I'll intentional create some <br />
sprite sheets just for testing this purpose. I'll also see about creating <br />
some tests to check and see if the performance gains are really showing up.<br />
<br />
<br />
4.6) What do you expect to gain from this project?<br />
<br />
Experience, learning to work on a team where most actually pull their <br />
own weight and the success of the project as a whole is not on my <br />
shoulders. This is too big a project for me to even think of that! <br />
and I'd not be able to, not in 3 months.<br />
<br />
4.7) What would make you stay in the Wesnoth community after the conclusion of<br />
SOC?<br />
<br />
Finding that the community is a non-hostile place to contribute, that <br />
individuals are treated with courtsey or the respect they have earned.<br />
That I'm encouraged to help other areas of the code, such as, "Aishi, <br />
the spritesheets work, do you think you could help with the transistion <br />
effects for the map?"<br />
<br />
<br />
<br />
**************Comments and Suggestions**************<br />
Please place them after this line, all are appreciated and if I can't thank you <br />
personally (IE you don't attach your name to it, Thank you.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=54086SpriteSheetApplicationSAB2014-03-21T03:49:46Z<p>Aishiko: </p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_SpriteSheets2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
4) Project<br />
<br />
4.1) Did you select a project from our list? If that is the case, what project<br />
did you select? What do you want to especially concentrate on?<br />
<br />
I selected one from the list, the implementing the SpriteSheets. <br />
I would like to concentrate on 2 tasks, 1 getting SpriteSheets to just <br />
work in wesnoth, and two, provide a script/tool/utility to allow easy <br />
converting from the old single images to the sheet (assuming certian <br />
naming conventions are followed).<br />
<br />
4.2) If you have invented your own project, please describe the project and the<br />
scope.<br />
<br />
N/A<br />
<br />
4.3) Why did you choose this project?<br />
<br />
I chosse it because I understand the concepts behind it, and felt it <br />
was a task that I could handle. It will also force me to learn and <br />
will provide immediate gains to all users when the version that <br />
includes the change is pushed out.<br />
<br />
4.4) Include an estimated timeline for your work on the project. Don't forget to<br />
mention special things like "I booked holidays between A and B" and "I got an<br />
exam at ABC and won't be doing much then".<br />
<br />
I'm still working out a timeline but I would most likely do a commit <br />
at least weekly. And break out the commits so that similar changes <br />
are only in that commit. Example, comment changes in one, (assuming <br />
no code changes), a converted set of sprites (aka the spritesheet) as <br />
one, and then code making use of it. After checking to make sure that <br />
the spritesheet works, removal of the converted individual sprite image <br />
files.<br />
<br />
4.5) Include as much technical detail about your implementation as you can<br />
<br />
At this point I think I would take 1 sprite (character) and create a <br />
spritesheet of it, and then test with that one. To allow testing I'd <br />
likely have it check for a spritesheet if it finds one it uses that, <br />
otherwise it uses the individual sprite images, in this way the game <br />
still works, until all the sprites have been turned into spritesheets.<br />
<br />
Once I have completed getting a character spritesheet to work, I'd <br />
then move on to the map sprites to spritesheets, again using the same <br />
methodology of check and if it finds a spritesheet use it otherwise, <br />
use the individual images. Though, on the grouping I'm not sure how <br />
I'd do that mordante and I'd have to discuss grouping, since a map can <br />
have any or all of the different tiles, and they are not chained like <br />
the unit/character sprites are, I'd have to group similar tiles together.<br />
Like the water images, shorelines, docks, and water villages, as one.<br />
The fields, human villages and castles in one. Swamp things together, <br />
and so on.<br />
<br />
I've heard that some devs think that a spritesheet might cause issues <br />
with larger images that don't fit in a hex, I'll intentional create some <br />
sprite sheets just for testing this purpose. I'll also see about creating <br />
some tests to check and see if the performance gains are really showing up.<br />
<br />
<br />
4.6) What do you expect to gain from this project?<br />
<br />
Experience, learning to work on a team where most actually pull their <br />
own weight and the success of the project as a whole is not on my <br />
shoulders. This is too big a project for me to even think of that! <br />
and I'd not be able to, not in 3 months.<br />
<br />
4.7) What would make you stay in the Wesnoth community after the conclusion of<br />
SOC?<br />
<br />
Finding that the community is a non-hostile place to contribute, that <br />
individuals are treated with courtsey or the respect they have earned.<br />
That I'm encouraged to help other areas of the code, such as, "Aishi, <br />
the spritesheets work, do you think you could help with the transistion <br />
effects for the map?"<br />
<br />
<br />
<br />
**************Comments and Suggestions**************<br />
Please place them after this line, all are appreciated and if I can't thank you <br />
personally (IE you don't attach your name to it, Thank you.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=53487SpriteSheetApplicationSAB2014-03-06T03:41:16Z<p>Aishiko: </p>
<hr />
<div>{{SoC2014Student}}<br />
[[Category:SoC_Ideas_Your_Own_Ideas2014]]<br />
<br />
==Description==<br />
<h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
==IRC==<br />
Aishiko, Aishiko_laptop<br />
<br />
==Questionnaire==<br />
Posted 28 Feb 2014<br />
1) Basics<br />
<br />
1.1) Write a small introduction to yourself.<br />
<br />
1.2) State your preferred email address.<br />
<br />
1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?<br />
<br />
1.4) Why do you want to participate in summer of code?<br />
<br />
I'd like to participate in the summer of code for several reasons, and <br />
yes money is one of them. but experience is the biggest one.<br />
<br />
1.5) What are you studying, subject, level and school?<br />
<br />
I am currently studying computer science (read programming) and networking <br />
technology. I am a Softmore in both, I am a current student at Sandhills <br />
Community College.<br />
<br />
1.6) What country are you from, at what time are you most likely to be able to<br />
join IRC?<br />
<br />
I currently live on the east coast of the US and can be in IRC pretty <br />
much all day, either at home or school, though if at school there will <br />
be a delay if in class and not lab.<br />
<br />
1.7) Do you have other commitments for the summer period ? Do you plan to take<br />
any vacations ? If yes, when.<br />
<br />
I have no current commitments that would impact my ability to give GSOC <br />
40 hours a week of work and attention. But if an emergency comes up <br />
I'll find a way to make up the hours.<br />
<br />
2) Experience<br />
<br />
2.1) What programs/software have you worked on before?<br />
<br />
Mostly personal projects and class projects, in C, C++, C#, PHP, Python, <br />
& the Arduino. One of C++ classes was using DarkGTK (yes I know its <br />
windows only) but we used SpriteSheets, sprite collision, and mouse interaction.<br />
<br />
2.2) Have you developed software in a team environment before? (As opposed to<br />
hacking on something on your own)<br />
<br />
I have in a class environment, but I'm usually the only one left doing <br />
the heavy lifting of coding. Though next year I'll be doing the <br />
programming capstone class where the class of 1-20 students work <br />
together to produce a program for a client, either for the college or <br />
for a community member/business. I'm both looking forward to and <br />
dreading working on a team, wondering if I'll be able to fit in and <br />
create code that is easy to maintain and follow.<br />
<br />
2.3) Have you participated to the Google Summer of Code before? As a mentor or a<br />
student? In what project? Were you successful? If not, why?<br />
<br />
I applied last year, however, I wasn't choosen mostly because I lack <br />
good writing skills for technical documents. At least that is what I <br />
was told.<br />
<br />
2.4) Are you already involved with any open source development projects? If yes,<br />
please describe the project and the scope of your involvement.<br />
<br />
None, I have submitted patches to the linux kernel but, I never <br />
bothered to see if they made it in.<br />
<br />
2.5) Gaming experience - Are you a gamer?<br />
<br />
Sometimes, depends on my mood.<br />
<br />
2.5.1) What type of gamer are you?<br />
<br />
Casual.<br />
<br />
2.5.2) What type of games?<br />
<br />
2.5.3) What type of opponents do you prefer?<br />
<br />
AI oppenents, I'm not really into the whole competetive thing.<br />
<br />
2.5.4) Are you more interested in story or gameplay?<br />
<br />
I think BOTH have to be there for a successful game. <br />
Though to be honest I'm better at critecing story then gameplay.<br />
<br />
2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether<br />
you lean towards single player or multiplayer.<br />
<br />
We do not plan to favor Wesnoth players as such, but some particular projects<br />
require a good feeling for the game which is hard to get without having played<br />
intensively.<br />
<br />
I've played Wesnoth for a year or 2, and I play exclusively single player.<br />
<br />
2.6) If you have contributed any patches to Wesnoth, please list them below. You<br />
can also list patches that have been submitted but not committed yet and patches<br />
that have not been specifically written for GSoC. If you have gained commit<br />
access to our repository (during the evaluation period or earlier) please state<br />
so.<br />
commit 5594aeec32d8c8e59c3f3241fbbb68ce9e862474 2/3/2014<br />
<br />
<br />
3) Communication skills<br />
<br />
3.1) Though most of our developers are not native English speakers, English is<br />
the project's working language. Describe your fluency level in written English.<br />
<br />
3.2) What spoken languages are you fluent in?<br />
<br />
English, I can understand a smattering of other languages but not enough <br />
to do anything deep or programming specific.<br />
<br />
3.3) Are you good at interacting with other players? Our developer community is<br />
friendly, but the player community can be a bit rough.<br />
<br />
3.4) Do you give constructive advice?<br />
<br />
I've been told I do on occasion.<br />
<br />
3.5) Do you receive advice well?<br />
<br />
I do if its construtive and not attacking. If its yelling, screaming, <br />
and insults as well, not so much. How its given usually impacts how well<br />
I receive it.<br />
<br />
3.6) Are you good at sorting useful criticisms from useless ones?<br />
<br />
Given enough time yes, but the painfully obvious ones I usually see <br />
right away.<br />
<br />
3.7) How autonomous are you when developing ? Would you rather discuss<br />
intensively changes and not start coding until you know what you want to do or<br />
would you rather code a proof of concept to "see how it turn out", taking the<br />
risk of having it thrown away if it doesn't match what the project want<br />
<br />
I'm usually fairly autonomous, once the design has been decided, and <br />
if it doesn't work and needs a change I sometimes seek councel on what <br />
way I should go, but sometimes just go ahead and make the change.<br />
Examples:<br />
1) The flow needs changing as it doesn't work right, usually I'll seek<br />
help figuring it how to change the flow so it does work.<br />
2) An array isn't giving the flexablity needed for a function but a <br />
list will, I implement the list instead. And inform whomever needs to <br />
know that I have done that change.<br />
<br />
4) Project<br />
<br />
4.1) Did you select a project from our list? If that is the case, what project<br />
did you select? What do you want to especially concentrate on?<br />
<br />
I selected one from the list, the implementing the SpriteSheets. <br />
I would like to concentrate on 2 tasks, 1 getting SpriteSheets to just <br />
work in wesnoth, and two, provide a script/tool/utility to allow easy <br />
converting from the old single images to the sheet (assuming certian <br />
naming conventions are followed).<br />
<br />
4.2) If you have invented your own project, please describe the project and the<br />
scope.<br />
<br />
N/A<br />
<br />
4.3) Why did you choose this project?<br />
<br />
I chosse it because I understand the concepts behind it, and felt it <br />
was a task that I could handle. It will also force me to learn and <br />
will provide immediate gains to all users when the version that <br />
includes the change is pushed out.<br />
<br />
4.4) Include an estimated timeline for your work on the project. Don't forget to<br />
mention special things like "I booked holidays between A and B" and "I got an<br />
exam at ABC and won't be doing much then".<br />
<br />
I'm still working out a timeline but I would most likely do a commit <br />
at least weekly. And break out the commits so that similar changes <br />
are only in that commit. Example, comment changes in one, (assuming <br />
no code changes), a converted set of sprites (aka the spritesheet) as <br />
one, and then code making use of it. After checking to make sure that <br />
the spritesheet works, removal of the converted individual sprite image <br />
files.<br />
<br />
4.5) Include as much technical detail about your implementation as you can<br />
<br />
At this point I think I would take 1 sprite (character) and create a <br />
spritesheet of it, and then test with that one. To allow testing I'd <br />
likely have it check for a spritesheet if it finds one it uses that, <br />
otherwise it uses the individual sprite images, in this way the game <br />
still works, until all the sprites have been turned into spritesheets.<br />
<br />
Once I have completed getting a character spritesheet to work, I'd <br />
then move on to the map sprites to spritesheets, again using the same <br />
methodology of check and if it finds a spritesheet use it otherwise, <br />
use the individual images. Though, on the grouping I'm not sure how <br />
I'd do that mordante and I'd have to discuss grouping, since a map can <br />
have any or all of the different tiles, and they are not chained like <br />
the unit/character sprites are, I'd have to group similar tiles together.<br />
Like the water images, shorelines, docks, and water villages, as one.<br />
The fields, human villages and castles in one. Swamp things together, <br />
and so on.<br />
<br />
I've heard that some devs think that a spritesheet might cause issues <br />
with larger images that don't fit in a hex, I'll intentional create some <br />
sprite sheets just for testing this purpose. I'll also see about creating <br />
some tests to check and see if the performance gains are really showing up.<br />
<br />
<br />
4.6) What do you expect to gain from this project?<br />
<br />
Experience, learning to work on a team where most actually pull their <br />
own weight and the success of the project as a whole is not on my <br />
shoulders. This is too big a project for me to even think of that! <br />
and I'd not be able to, not in 3 months.<br />
<br />
4.7) What would make you stay in the Wesnoth community after the conclusion of<br />
SOC?<br />
<br />
Finding that the community is a non-hostile place to contribute, that <br />
individuals are treated with courtsey or the respect they have earned.<br />
That I'm encouraged to help other areas of the code, such as, "Aishi, <br />
the spritesheets work, do you think you could help with the transistion <br />
effects for the map?"<br />
<br />
<br />
5) Practical considerations<br />
<br />
5.1) Are you familiar with any of the following tools or languages?<br />
<br />
Git (used for all commits)<br />
I don't get it yet but I'm confident that I can get it.<br />
C++ (language used for all the normal source code)<br />
Its my favourite language and I'm comfortable using the language<br />
and looking up what I don't know and making it work. I'm also not<br />
afraid to ask, for help/documentation if I get stuck.<br />
STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
I've not, YET. Well I might, I never really looked into where a lib or <br />
function comes from when I use, I'll have to pay a bit more attention <br />
now. But they are no on my documentation read list, I'm confident<br />
that by the time coding begins that I'll be able to leverage them to <br />
obtain results, and be more effienent as I go. Even going back and <br />
making a section more effient if I realize that I over looked a better <br />
tool then I orginally used.<br />
Python (optional, mainly used for tools)<br />
I'm familiar enough to use it, follow it (assuming good coding <br />
conventions are followed).<br />
build environments (eg cmake/scons)<br />
I tend to use cmake and the gcc compiler, basically I use which ever <br />
build environment I have available and if its a new one I look up (via <br />
the man page or the internet) how to use it, and if the defaults <br />
settings don't work to add flags/options to get it to compile.<br />
WML (the wesnoth specific scenario language)<br />
Absolutely none before now, again on my read list<br />
Lua (used in combination with WML to create scenarios)<br />
None but I don't create senarios at this point, and if its only used <br />
in that context, it shouldn't have any barring on the project(s) I'm <br />
interested in doing at this point. <br />
<br />
5.2) Which tools do you normally use for development? Why do you use them?<br />
Kate, as its just what I'm used to, I like how it's mimaliztic and <br />
non-intrutsive.<br />
Visual Studio for my C# class because that is what they have to work <br />
in when I turn it in.<br />
<br />
5.3) What programming languages are you fluent in?<br />
I'm not sure what you mean by fluent, if you mean know every builtin <br />
function and every conseviable combination of calls, I doubt very many <br />
could claim to be fluent. However if you mean, comfortable, and able <br />
to figure out things you don't knoe, either by looking it up or by <br />
context then C (and its children, C++, C#, Arduino) python, and PHP. <br />
After being fluent in English doesn't mean you know every word or <br />
special rule for the language.<br />
<br />
5.4) Would you mind talking with your mentor on telephone / internet phone? We<br />
would like to have a backup way for communications for the case that somehow<br />
emails and IRC do fail. If you are willing to do so, please do list a phone<br />
number (including international code) so that we are able to contact you. You<br />
should probably *only* add this number in the application for you submit to<br />
google since the info in the wiki is available in public. We will *not* make any<br />
use of your number unless some case of "there is no way to contact you" does<br />
arise!<br />
<br />
<br />
I wouldn't mind and in some cases prefer it. I'm not the most observant <br />
when it comes to my email, I usually just get notices and spam that can <br />
be ignored (high noise to signal ratio in my mailbox at the moment). <br />
Though when expecting something I check it more often at least once a <br />
day if not more.<br />
<br />
**************Comments and Suggestions**************<br />
Please place them after this line, all are appreciated and if I can't thank you <br />
personally (IE you don't attach your name to it, Thank you.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=EasyCoding&diff=53485EasyCoding2014-03-05T20:52:36Z<p>Aishiko: /* Support variable recall cost in wml */</p>
<hr />
<div>== Foreword ==<br />
<br />
'''We are permanently updating this page. Parts marked by <s>strikeout</s> will likely be deleted shortly.<br />
<br />
This page is here to document easy to do coding tasks. It is not here to double the feature request database, and should only be filled by people that know the code well enough to judge the difficulty of a given task. <br />
<br />
If you are such a person, you should feel free to edit this page.<br />
<br />
If you're not, you should post a feature request and discuss your idea on the forum or IRC. A coder with better knowledge of the code might give you the green light to add your feature here.<br />
<br />
Anybody should feel free to add "clues" to any tasks, that is entry points, traps to avoid, person to contact to discuss and so on.<br />
<br />
If you plan to work on a feature, write your name at the bottom of the feature, with the date. Note that if you are too long at working on a feature I'll "free" it back (that is if you're not working on it. If you have problems implementing it, just tell us....)<br />
<br />
--[[User:Boucman|Boucman]]<br />
<br />
<br />
If none of these are to your liking, feel free to check our [http://gna.org/bugs/?group=wesnoth bug tracker] with a broad spectrum of tasks.<br />
<br />
== MP related features ==<br />
<br />
=== Add possibility to switch off dependency checking ===<br />
MP add-ons can define dependencies. Currently there's no way to force a "broken" configuration, although overzealous use of the system by UMC authors could make this feature useful. Add an option to the MP game creation screen to switch on/off dependency checking. Ask lipk (forum)/lipkab (IRC).<br />
<br />
== WML related features ==<br />
<br />
=== Side-specific results ===<br />
Giving result=defeat or result=victory for specific sides. ([http://gna.org/bugs/index.php?4960 FR #4960]) -- [[User:dlr365|dlr365]] -- patch submitted [https://gna.org/bugs/index.php?4960]<br />
<br />
--[[User:Boucman|Boucman]] 08:58, 28 February 2010 (UTC) Patch seems abandonned, but can be used for further work feel free to take over the FR<br />
<br />
=== Support for leaderless multiplayergames ===<br />
Add support for the WML key victory_when_enemies_defeated= in the scenario tag during multiplayergames. ([https://gna.org/bugs/index.php?8106 FR #8106])<br />
<br />
=== Support variable recall cost in wml ===<br />
see https://gna.org/bugs/?16538<br />
<br />
the syntax needs to be discussed and refined, but the overall idea is good<br />
<br />
make sure to update whiteboard to handle this correctly<br />
<br />
Ask Boucman<br />
<br />
Aishiko 5 Mar 2014<br />
<br />
=== Other Ideas ===<br />
See [[FutureWML]]; some ideas there are easier than others.<br />
<br />
== Improvements to AI ==<br />
<br />
Note: not all of these might be simple tasks. Talk to Crab or mattsc.<br />
<br />
* Add option to take avoided hexes into account in wesnoth.find_path()<br />
<br />
* Make the (old) simple aspect syntax work when the Lua engine is defined for a side. Setting aspects in the [side] tag like this:<br />
[ai]<br />
aggression=0.123<br />
[/ai]<br />
does not work if the Lua engine is defined. You either need to use the [aspect] tag in the [side] tag with 'engine=lua', or use the code above in a [modify_side] tag in an event. Making the above syntax available (as it is with the c++ engine) would be nice. The same also applies to the FAI engine and to aspects set for AI sides in MP games.<br />
<br />
* Add a Lua function ai.get_individual_attacks() that returns all the single attacks the side can do (as opposed to attack combinations). This needs to include an option to recalculate and take the current situation on the map into account (making the function believe that the game state has changed).<br />
<br />
* Set up an option the allows us to exclude units from the move-to-targets phase similar to [filter_own] for the combat phase (other than setting ai_special=guardian, which has a number of other side effects). Actually, having this option for all CA's would be nice.<br />
<br />
* Change the aspects "passive_leader", "passive_leader_shares_keep", "leader_ignores_keep" to work with multiple leaders. The idea is to change the type of those aspects from yes/no to string so both "passive_leader=yes" and "passive_leader=leader_id_1,leader_id_2" is possible.<br />
<br />
* ai.get_new_enemy_dst_src and related functions have several problems:<br />
** They use the current moves of the enemy units, which generally are all zero.<br />
** Hexes occupied by other enemy units count as not reachable.<br />
**Units with zero moves are not listed at all, not even for the hex they are on.<br />
**Working around this with a Lua wrapper makes this actually slower than ai_helper.get_enemy_dst_src, which makes the functions pretty much useless, as speed is the only thing speaking for them.<br />
<br />
* Clean up Micro AI candidate actions code. The Micro AIs were developed over quite a long period while we were trying to figure out how all of this works (and in part also by students participating in the Google Code-in project). As a result, the code in some of them is quite inconsistent, not cleaned up, uncommented (or wrongly commented), etc. '''Important notes:'''<br />
**This is not meant as a single task, but rather as a series of tasks, involving individual MAIs or sets of related MAIs. Please do not submit a pull request in which the code of all MAIs has been modified. <br />
**The Micro AIs are still being worked on pretty constantly, so if you are planning to work on this task, please let mattsc know (either on IRC or via forum PM), so that we can avoid conflicts as much as possible.<br />
<br />
* Add new options (keys or tags) to the Micro AIs. As an example, some (but certainly not all) Micro AIs might benefit from taking some (but certainly not all) of the default AI aspects into account.<br />
<br />
* Write a script that automatically changes WML from the deprecated [ai][target] to the new [ai][goal] syntax. Ideally, this would be part of wmllint.<br />
** There are [http://wiki.wesnoth.org/AiWML#Deprecated_AI_Targeting_Aspects more deprecated AI aspect] which should eventually be added to this, but the [target] -> [goal] change would be a good and important start.<br />
<br />
== GUI related features ==<br />
<br />
Although Mordante developed the new GUI system GUI2, some dialogs still use the older GUI1 and could be improved or transferred. You should contact Mordante on IRC before starting to work on these.<br />
<br />
=== Theme Changes ===<br />
<br />
* hide the hourglass item from the statusbar when there is no timer<br />
<br />
=== Widget Changes ===<br />
* make games sortable in the lobby (open slots, total number of players, era, XP modifier, gold per village, fog/shroud)<br>a GUI2 lobby is currently being developed, ask mordante whether this is still relevant<br />
* input history (chat, commands, ..)<br />
<br />
== GUI2 related features ==<br />
GUI2 is the new gui engine Mordante/SkeletonCrew is working on. <br />
* Information on the wiki can be found here http://www.wesnoth.org/wiki/GUIToolkit<br />
* The source code is under src/gui/<br />
* The configuration config files are under data/gui/default<br />
<br />
Some tasks need the --new-widgets since the code is only shown in the experimental mode. Tasks which need this switch have the * in the title.<br />
<br />
=== Port the random map generator dialog to GUI2 ===<br />
The map generator currently doesn't use the GUI2 framework, but there's no reason why it couldn't. Ask lipk (forum)/lipkab (IRC).<br />
<br />
== Miscellaneous ==<br />
<br />
=== More powerful village naming ===<br />
'''Adding mountain names and other features to village names, having a second random name in village names'''<br />
<br />
Currently the village naming engine has a very good structure that could allow more powerful names to be generated. <br />
Understanding how it works should be quite easy, and a few useful improvements could be added.<br />
<br />
* Currently villages can use lake names and river names, this should be extended to other features like bridges, swamps, mountains etc...<br />
* It would be nice to have a separate list of "first syllabus" and "last syllabus" for naming. That's not really needed in English, but some translations could use it<br />
* Again, it is common to have villages with more than one "random" word in them. having a $name2 variable would be nice<br />
<br />
Turns out this was already done, and should be removed.<br />
<br />
=== Debug Mode ===<br />
* New debug command functionality (setting additional status.variables, possibly terrain)<br />
<br />
=== wesnoth-optipng ===<br />
For lossless png compression we use wesnoth-optipng, a script using an external toolchain (ImageMagick, OptiPNG, Advdef). Perhaps the performance could be improved by using PNGOut instead of advdef. This task includes<br />
* a quick profiling of compression ratio and decompression speed for both tools<br />
* if it provides a higher compression while not significantly slowing down decompression, adapt wesnoth-optipng to use PNGOut<br />
<br />
== Bugs ==<br />
<br />
<br />
<br />
== See Also ==<br />
<br />
[[NotSoEasyCoding]]<br />
<br />
[[Category:Development]]<br />
[[Category:Future]]</div>Aishikohttps://wiki.wesnoth.org/index.php?title=EasyCoding&diff=53473EasyCoding2014-03-04T03:43:42Z<p>Aishiko: /* Support variable recall cost in wml */</p>
<hr />
<div>== Foreword ==<br />
<br />
'''We are permanently updating this page. Parts marked by <s>strikeout</s> will likely be deleted shortly.<br />
<br />
This page is here to document easy to do coding tasks. It is not here to double the feature request database, and should only be filled by people that know the code well enough to judge the difficulty of a given task. <br />
<br />
If you are such a person, you should feel free to edit this page.<br />
<br />
If you're not, you should post a feature request and discuss your idea on the forum or IRC. A coder with better knowledge of the code might give you the green light to add your feature here.<br />
<br />
Anybody should feel free to add "clues" to any tasks, that is entry points, traps to avoid, person to contact to discuss and so on.<br />
<br />
If you plan to work on a feature, write your name at the bottom of the feature, with the date. Note that if you are too long at working on a feature I'll "free" it back (that is if you're not working on it. If you have problems implementing it, just tell us....)<br />
<br />
--[[User:Boucman|Boucman]]<br />
<br />
<br />
If none of these are to your liking, feel free to check our [http://gna.org/bugs/?group=wesnoth bug tracker] with a broad spectrum of tasks.<br />
<br />
== MP related features ==<br />
<br />
=== Add possibility to switch off dependency checking ===<br />
MP add-ons can define dependencies. Currently there's no way to force a "broken" configuration, although overzealous use of the system by UMC authors could make this feature useful. Add an option to the MP game creation screen to switch on/off dependency checking. Ask lipk (forum)/lipkab (IRC).<br />
<br />
== WML related features ==<br />
<br />
=== Side-specific results ===<br />
Giving result=defeat or result=victory for specific sides. ([http://gna.org/bugs/index.php?4960 FR #4960]) -- [[User:dlr365|dlr365]] -- patch submitted [https://gna.org/bugs/index.php?4960]<br />
<br />
--[[User:Boucman|Boucman]] 08:58, 28 February 2010 (UTC) Patch seems abandonned, but can be used for further work feel free to take over the FR<br />
<br />
=== Support for leaderless multiplayergames ===<br />
Add support for the WML key victory_when_enemies_defeated= in the scenario tag during multiplayergames. ([https://gna.org/bugs/index.php?8106 FR #8106])<br />
<br />
=== Support variable recall cost in wml ===<br />
see https://gna.org/bugs/?16538<br />
<br />
the syntax needs to be discussed and refined, but the overall idea is good<br />
<br />
make sure to update whiteboard to handle this correctly<br />
<br />
Ask Boucman<br />
<br />
=== Other Ideas ===<br />
See [[FutureWML]]; some ideas there are easier than others.<br />
<br />
== Improvements to AI ==<br />
<br />
Note: not all of these might be simple tasks. Talk to Crab or mattsc.<br />
<br />
* Add option to take avoided hexes into account in wesnoth.find_path()<br />
<br />
* Make the (old) simple aspect syntax work when the Lua engine is defined for a side. Setting aspects in the [side] tag like this:<br />
[ai]<br />
aggression=0.123<br />
[/ai]<br />
does not work if the Lua engine is defined. You either need to use the [aspect] tag in the [side] tag with 'engine=lua', or use the code above in a [modify_side] tag in an event. Making the above syntax available (as it is with the c++ engine) would be nice. The same also applies to the FAI engine and to aspects set for AI sides in MP games.<br />
<br />
* Add a Lua function ai.get_individual_attacks() that returns all the single attacks the side can do (as opposed to attack combinations). This needs to include an option to recalculate and take the current situation on the map into account (making the function believe that the game state has changed).<br />
<br />
* Set up an option the allows us to exclude units from the move-to-targets phase similar to [filter_own] for the combat phase (other than setting ai_special=guardian, which has a number of other side effects). Actually, having this option for all CA's would be nice.<br />
<br />
* Change the aspects "passive_leader", "passive_leader_shares_keep", "leader_ignores_keep" to work with multiple leaders. The idea is to change the type of those aspects from yes/no to string so both "passive_leader=yes" and "passive_leader=leader_id_1,leader_id_2" is possible.<br />
<br />
* ai.get_new_enemy_dst_src and related functions have several problems:<br />
** They use the current moves of the enemy units, which generally are all zero.<br />
** Hexes occupied by other enemy units count as not reachable.<br />
**Units with zero moves are not listed at all, not even for the hex they are on.<br />
**Working around this with a Lua wrapper makes this actually slower than ai_helper.get_enemy_dst_src, which makes the functions pretty much useless, as speed is the only thing speaking for them.<br />
<br />
* Clean up Micro AI candidate actions code. The Micro AIs were developed over quite a long period while we were trying to figure out how all of this works (and in part also by students participating in the Google Code-in project). As a result, the code in some of them is quite inconsistent, not cleaned up, uncommented (or wrongly commented), etc. '''Important notes:'''<br />
**This is not meant as a single task, but rather as a series of tasks, involving individual MAIs or sets of related MAIs. Please do not submit a pull request in which the code of all MAIs has been modified. <br />
**The Micro AIs are still being worked on pretty constantly, so if you are planning to work on this task, please let mattsc know (either on IRC or via forum PM), so that we can avoid conflicts as much as possible.<br />
<br />
* Add new options (keys or tags) to the Micro AIs. As an example, some (but certainly not all) Micro AIs might benefit from taking some (but certainly not all) of the default AI aspects into account.<br />
<br />
* Write a script that automatically changes WML from the deprecated [ai][target] to the new [ai][goal] syntax. Ideally, this would be part of wmllint.<br />
** There are [http://wiki.wesnoth.org/AiWML#Deprecated_AI_Targeting_Aspects more deprecated AI aspect] which should eventually be added to this, but the [target] -> [goal] change would be a good and important start.<br />
<br />
== GUI related features ==<br />
<br />
Although Mordante developed the new GUI system GUI2, some dialogs still use the older GUI1 and could be improved or transferred. You should contact Mordante on IRC before starting to work on these.<br />
<br />
=== Theme Changes ===<br />
<br />
* hide the hourglass item from the statusbar when there is no timer<br />
<br />
=== Widget Changes ===<br />
* make games sortable in the lobby (open slots, total number of players, era, XP modifier, gold per village, fog/shroud)<br>a GUI2 lobby is currently being developed, ask mordante whether this is still relevant<br />
* input history (chat, commands, ..)<br />
<br />
== GUI2 related features ==<br />
GUI2 is the new gui engine Mordante/SkeletonCrew is working on. <br />
* Information on the wiki can be found here http://www.wesnoth.org/wiki/GUIToolkit<br />
* The source code is under src/gui/<br />
* The configuration config files are under data/gui/default<br />
<br />
Some tasks need the --new-widgets since the code is only shown in the experimental mode. Tasks which need this switch have the * in the title.<br />
<br />
=== Port the random map generator dialog to GUI2 ===<br />
The map generator currently doesn't use the GUI2 framework, but there's no reason why it couldn't. Ask lipk (forum)/lipkab (IRC).<br />
<br />
== Miscellaneous ==<br />
<br />
=== More powerful village naming ===<br />
'''Adding mountain names and other features to village names, having a second random name in village names'''<br />
<br />
Currently the village naming engine has a very good structure that could allow more powerful names to be generated. <br />
Understanding how it works should be quite easy, and a few useful improvements could be added.<br />
<br />
* Currently villages can use lake names and river names, this should be extended to other features like bridges, swamps, mountains etc...<br />
* It would be nice to have a separate list of "first syllabus" and "last syllabus" for naming. That's not really needed in English, but some translations could use it<br />
* Again, it is common to have villages with more than one "random" word in them. having a $name2 variable would be nice<br />
<br />
Turns out this was already done, and should be removed.<br />
<br />
=== Debug Mode ===<br />
* New debug command functionality (setting additional status.variables, possibly terrain)<br />
<br />
=== wesnoth-optipng ===<br />
For lossless png compression we use wesnoth-optipng, a script using an external toolchain (ImageMagick, OptiPNG, Advdef). Perhaps the performance could be improved by using PNGOut instead of advdef. This task includes<br />
* a quick profiling of compression ratio and decompression speed for both tools<br />
* if it provides a higher compression while not significantly slowing down decompression, adapt wesnoth-optipng to use PNGOut<br />
<br />
== Bugs ==<br />
<br />
<br />
<br />
== See Also ==<br />
<br />
[[NotSoEasyCoding]]<br />
<br />
[[Category:Development]]<br />
[[Category:Future]]</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=53422SpriteSheetApplicationSAB2014-03-02T09:04:37Z<p>Aishiko: </p>
<hr />
<div><h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
Posted 28 Feb 2014<br />
1) Basics<br />
<br />
1.1) Write a small introduction to yourself.<br />
<br />
1.2) State your preferred email address.<br />
<br />
1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?<br />
<br />
1.4) Why do you want to participate in summer of code?<br />
<br />
I'd like to participate in the summer of code for several reasons, and <br />
yes money is one of them. but experience is the biggest one.<br />
<br />
1.5) What are you studying, subject, level and school?<br />
<br />
I am currently studying computer science (read programming) and networking <br />
technology. I am a Softmore in both, I am a current student at Sandhills <br />
Community College.<br />
<br />
1.6) What country are you from, at what time are you most likely to be able to<br />
join IRC?<br />
<br />
I currently live on the east coast of the US and can be in IRC pretty <br />
much all day, either at home or school, though if at school there will <br />
be a delay if in class and not lab.<br />
<br />
1.7) Do you have other commitments for the summer period ? Do you plan to take<br />
any vacations ? If yes, when.<br />
<br />
I have no current commitments that would impact my ability to give GSOC <br />
40 hours a week of work and attention. But if an emergency comes up <br />
I'll find a way to make up the hours.<br />
<br />
2) Experience<br />
<br />
2.1) What programs/software have you worked on before?<br />
<br />
Mostly personal projects and class projects, in C, C++, C#, PHP, Python, <br />
& the Arduino. One of C++ classes was using DarkGTK (yes I know its <br />
windows only) but we used SpriteSheets, sprite collision, and mouse interaction.<br />
<br />
2.2) Have you developed software in a team environment before? (As opposed to<br />
hacking on something on your own)<br />
<br />
I have in a class environment, but I'm usually the only one left doing <br />
the heavy lifting of coding. Though next year I'll be doing the <br />
programming capstone class where the class of 1-20 students work <br />
together to produce a program for a client, either for the college or <br />
for a community member/business. I'm both looking forward to and <br />
dreading working on a team, wondering if I'll be able to fit in and <br />
create code that is easy to maintain and follow.<br />
<br />
2.3) Have you participated to the Google Summer of Code before? As a mentor or a<br />
student? In what project? Were you successful? If not, why?<br />
<br />
I applied last year, however, I wasn't choosen mostly because I lack <br />
good writing skills for technical documents. At least that is what I <br />
was told.<br />
<br />
2.4) Are you already involved with any open source development projects? If yes,<br />
please describe the project and the scope of your involvement.<br />
<br />
None, I have submitted patches to the linux kernel but, I never <br />
bothered to see if they made it in.<br />
<br />
2.5) Gaming experience - Are you a gamer?<br />
<br />
Sometimes, depends on my mood.<br />
<br />
2.5.1) What type of gamer are you?<br />
<br />
Casual.<br />
<br />
2.5.2) What type of games?<br />
<br />
2.5.3) What type of opponents do you prefer?<br />
<br />
AI oppenents, I'm not really into the whole competetive thing.<br />
<br />
2.5.4) Are you more interested in story or gameplay?<br />
<br />
I think BOTH have to be there for a successful game. <br />
Though to be honest I'm better at critecing story then gameplay.<br />
<br />
2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether<br />
you lean towards single player or multiplayer.<br />
<br />
We do not plan to favor Wesnoth players as such, but some particular projects<br />
require a good feeling for the game which is hard to get without having played<br />
intensively.<br />
<br />
I've played Wesnoth for a year or 2, and I play exclusively single player.<br />
<br />
2.6) If you have contributed any patches to Wesnoth, please list them below. You<br />
can also list patches that have been submitted but not committed yet and patches<br />
that have not been specifically written for GSoC. If you have gained commit<br />
access to our repository (during the evaluation period or earlier) please state<br />
so.<br />
commit 5594aeec32d8c8e59c3f3241fbbb68ce9e862474 2/3/2014<br />
<br />
<br />
3) Communication skills<br />
<br />
3.1) Though most of our developers are not native English speakers, English is<br />
the project's working language. Describe your fluency level in written English.<br />
<br />
3.2) What spoken languages are you fluent in?<br />
<br />
English, I can understand a smattering of other languages but not enough <br />
to do anything deep or programming specific.<br />
<br />
3.3) Are you good at interacting with other players? Our developer community is<br />
friendly, but the player community can be a bit rough.<br />
<br />
3.4) Do you give constructive advice?<br />
<br />
I've been told I do on occasion.<br />
<br />
3.5) Do you receive advice well?<br />
<br />
I do if its construtive and not attacking. If its yelling, screaming, <br />
and insults as well, not so much. How its given usually impacts how well<br />
I receive it.<br />
<br />
3.6) Are you good at sorting useful criticisms from useless ones?<br />
<br />
Given enough time yes, but the painfully obvious ones I usually see <br />
right away.<br />
<br />
3.7) How autonomous are you when developing ? Would you rather discuss<br />
intensively changes and not start coding until you know what you want to do or<br />
would you rather code a proof of concept to "see how it turn out", taking the<br />
risk of having it thrown away if it doesn't match what the project want<br />
<br />
I'm usually fairly autonomous, once the design has been decided, and <br />
if it doesn't work and needs a change I sometimes seek councel on what <br />
way I should go, but sometimes just go ahead and make the change.<br />
Examples:<br />
1) The flow needs changing as it doesn't work right, usually I'll seek<br />
help figuring it how to change the flow so it does work.<br />
2) An array isn't giving the flexablity needed for a function but a <br />
list will, I implement the list instead. And inform whomever needs to <br />
know that I have done that change.<br />
<br />
4) Project<br />
<br />
4.1) Did you select a project from our list? If that is the case, what project<br />
did you select? What do you want to especially concentrate on?<br />
<br />
I selected one from the list, the implementing the SpriteSheets. <br />
I would like to concentrate on 2 tasks, 1 getting SpriteSheets to just <br />
work in wesnoth, and two, provide a script/tool/utility to allow easy <br />
converting from the old single images to the sheet (assuming certian <br />
naming conventions are followed).<br />
<br />
4.2) If you have invented your own project, please describe the project and the<br />
scope.<br />
<br />
N/A<br />
<br />
4.3) Why did you choose this project?<br />
<br />
I chosse it because I understand the concepts behind it, and felt it <br />
was a task that I could handle. It will also force me to learn and <br />
will provide immediate gains to all users when the version that <br />
includes the change is pushed out.<br />
<br />
4.4) Include an estimated timeline for your work on the project. Don't forget to<br />
mention special things like "I booked holidays between A and B" and "I got an<br />
exam at ABC and won't be doing much then".<br />
<br />
I'm still working out a timeline but I would most likely do a commit <br />
at least weekly. And break out the commits so that similar changes <br />
are only in that commit. Example, comment changes in one, (assuming <br />
no code changes), a converted set of sprites (aka the spritesheet) as <br />
one, and then code making use of it. After checking to make sure that <br />
the spritesheet works, removal of the converted individual sprite image <br />
files.<br />
<br />
4.5) Include as much technical detail about your implementation as you can<br />
<br />
At this point I think I would take 1 sprite (character) and create a <br />
spritesheet of it, and then test with that one. To allow testing I'd <br />
likely have it check for a spritesheet if it finds one it uses that, <br />
otherwise it uses the individual sprite images, in this way the game <br />
still works, until all the sprites have been turned into spritesheets.<br />
<br />
Once I have completed getting a character spritesheet to work, I'd <br />
then move on to the map sprites to spritesheets, again using the same <br />
methodology of check and if it finds a spritesheet use it otherwise, <br />
use the individual images. Though, on the grouping I'm not sure how <br />
I'd do that mordante and I'd have to discuss grouping, since a map can <br />
have any or all of the different tiles, and they are not chained like <br />
the unit/character sprites are, I'd have to group similar tiles together.<br />
Like the water images, shorelines, docks, and water villages, as one.<br />
The fields, human villages and castles in one. Swamp things together, <br />
and so on.<br />
<br />
I've heard that some devs think that a spritesheet might cause issues <br />
with larger images that don't fit in a hex, I'll intentional create some <br />
sprite sheets just for testing this purpose. I'll also see about creating <br />
some tests to check and see if the performance gains are really showing up.<br />
<br />
<br />
4.6) What do you expect to gain from this project?<br />
<br />
Experience, learning to work on a team where most actually pull their <br />
own weight and the success of the project as a whole is not on my <br />
shoulders. This is too big a project for me to even think of that! <br />
and I'd not be able to, not in 3 months.<br />
<br />
4.7) What would make you stay in the Wesnoth community after the conclusion of<br />
SOC?<br />
<br />
Finding that the community is a non-hostile place to contribute, that <br />
individuals are treated with courtsey or the respect they have earned.<br />
That I'm encouraged to help other areas of the code, such as, "Aishi, <br />
the spritesheets work, do you think you could help with the transistion <br />
effects for the map?"<br />
<br />
<br />
5) Practical considerations<br />
<br />
5.1) Are you familiar with any of the following tools or languages?<br />
<br />
Git (used for all commits)<br />
I don't get it yet but I'm confident that I can get it.<br />
C++ (language used for all the normal source code)<br />
Its my favourite language and I'm comfortable using the language<br />
and looking up what I don't know and making it work. I'm also not<br />
afraid to ask, for help/documentation if I get stuck.<br />
STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
I've not, YET. Well I might, I never really looked into where a lib or <br />
function comes from when I use, I'll have to pay a bit more attention <br />
now. But they are no on my documentation read list, I'm confident<br />
that by the time coding begins that I'll be able to leverage them to <br />
obtain results, and be more effienent as I go. Even going back and <br />
making a section more effient if I realize that I over looked a better <br />
tool then I orginally used.<br />
Python (optional, mainly used for tools)<br />
I'm familiar enough to use it, follow it (assuming good coding <br />
conventions are followed).<br />
build environments (eg cmake/scons)<br />
I tend to use cmake and the gcc compiler, basically I use which ever <br />
build environment I have available and if its a new one I look up (via <br />
the man page or the internet) how to use it, and if the defaults <br />
settings don't work to add flags/options to get it to compile.<br />
WML (the wesnoth specific scenario language)<br />
Absolutely none before now, again on my read list<br />
Lua (used in combination with WML to create scenarios)<br />
None but I don't create senarios at this point, and if its only used <br />
in that context, it shouldn't have any barring on the project(s) I'm <br />
interested in doing at this point. <br />
<br />
5.2) Which tools do you normally use for development? Why do you use them?<br />
Kate, as its just what I'm used to, I like how it's mimaliztic and <br />
non-intrutsive.<br />
Visual Studio for my C# class because that is what they have to work <br />
in when I turn it in.<br />
<br />
5.3) What programming languages are you fluent in?<br />
I'm not sure what you mean by fluent, if you mean know every builtin <br />
function and every conseviable combination of calls, I doubt very many <br />
could claim to be fluent. However if you mean, comfortable, and able <br />
to figure out things you don't knoe, either by looking it up or by <br />
context then C (and its children, C++, C#, Arduino) python, and PHP. <br />
After being fluent in English doesn't mean you know every word or <br />
special rule for the language.<br />
<br />
5.4) Would you mind talking with your mentor on telephone / internet phone? We<br />
would like to have a backup way for communications for the case that somehow<br />
emails and IRC do fail. If you are willing to do so, please do list a phone<br />
number (including international code) so that we are able to contact you. You<br />
should probably *only* add this number in the application for you submit to<br />
google since the info in the wiki is available in public. We will *not* make any<br />
use of your number unless some case of "there is no way to contact you" does<br />
arise!<br />
<br />
<br />
I wouldn't mind and in some cases prefer it. I'm not the most observant <br />
when it comes to my email, I usually just get notices and spam that can <br />
be ignored (high noise to signal ratio in my mailbox at the moment). <br />
Though when expecting something I check it more often at least once a <br />
day if not more.<br />
<br />
**************Comments and Suggestions**************<br />
Please place them after this line, all are appreciated and if I can't thank you <br />
personally (IE you don't attach your name to it, Thank you.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=EasyCoding&diff=53363EasyCoding2014-03-01T21:36:30Z<p>Aishiko: /* Support variable recall cost in wml */</p>
<hr />
<div>== Foreword ==<br />
<br />
'''We are permanently updating this page. Parts marked by <s>strikeout</s> will likely be deleted shortly.<br />
<br />
This page is here to document easy to do coding tasks. It is not here to double the feature request database, and should only be filled by people that know the code well enough to judge the difficulty of a given task. <br />
<br />
If you are such a person, you should feel free to edit this page.<br />
<br />
If you're not, you should post a feature request and discuss your idea on the forum or IRC. A coder with better knowledge of the code might give you the green light to add your feature here.<br />
<br />
Anybody should feel free to add "clues" to any tasks, that is entry points, traps to avoid, person to contact to discuss and so on.<br />
<br />
If you plan to work on a feature, write your name at the bottom of the feature, with the date. Note that if you are too long at working on a feature I'll "free" it back (that is if you're not working on it. If you have problems implementing it, just tell us....)<br />
<br />
--[[User:Boucman|Boucman]]<br />
<br />
<br />
If none of these are to your liking, feel free to check our [http://gna.org/bugs/?group=wesnoth bug tracker] with a broad spectrum of tasks.<br />
<br />
== MP related features ==<br />
<br />
=== Add possibility to switch off dependency checking ===<br />
MP add-ons can define dependencies. Currently there's no way to force a "broken" configuration, although overzealous use of the system by UMC authors could make this feature useful. Add an option to the MP game creation screen to switch on/off dependency checking. Ask lipk (forum)/lipkab (IRC).<br />
<br />
== WML related features ==<br />
<br />
=== Side-specific results ===<br />
Giving result=defeat or result=victory for specific sides. ([http://gna.org/bugs/index.php?4960 FR #4960]) -- [[User:dlr365|dlr365]] -- patch submitted [https://gna.org/bugs/index.php?4960]<br />
<br />
--[[User:Boucman|Boucman]] 08:58, 28 February 2010 (UTC) Patch seems abandonned, but can be used for further work feel free to take over the FR<br />
<br />
=== Support for leaderless multiplayergames ===<br />
Add support for the WML key victory_when_enemies_defeated= in the scenario tag during multiplayergames. ([https://gna.org/bugs/index.php?8106 FR #8106])<br />
<br />
=== Support variable recall cost in wml ===<br />
see https://gna.org/bugs/?16538<br />
<br />
the syntax needs to be discussed and refined, but the overall idea is good<br />
<br />
make sure to update whiteboard to handle this correctly<br />
<br />
Ask Boucman<br />
<br />
Aishiko 1 Mar 2014<br />
<br />
=== Other Ideas ===<br />
See [[FutureWML]]; some ideas there are easier than others.<br />
<br />
== Improvements to AI ==<br />
<br />
Note: not all of these might be simple tasks. Talk to Crab or mattsc.<br />
<br />
* Add option to take avoided hexes into account in wesnoth.find_path()<br />
<br />
* Make the (old) simple aspect syntax work when the Lua engine is defined for a side. Setting aspects in the [side] tag like this:<br />
[ai]<br />
aggression=0.123<br />
[/ai]<br />
does not work if the Lua engine is defined. You either need to use the [aspect] tag in the [side] tag with 'engine=lua', or use the code above in a [modify_side] tag in an event. Making the above syntax available (as it is with the c++ engine) would be nice. The same also applies to the FAI engine and to aspects set for AI sides in MP games.<br />
<br />
* Add a Lua function ai.get_individual_attacks() that returns all the single attacks the side can do (as opposed to attack combinations). This needs to include an option to recalculate and take the current situation on the map into account (making the function believe that the game state has changed).<br />
<br />
* Set up an option the allows us to exclude units from the move-to-targets phase similar to [filter_own] for the combat phase (other than setting ai_special=guardian, which has a number of other side effects). Actually, having this option for all CA's would be nice.<br />
<br />
* Change the aspects "passive_leader", "passive_leader_shares_keep", "leader_ignores_keep" to work with multiple leaders. The idea is to change the type of those aspects from yes/no to string so both "passive_leader=yes" and "passive_leader=leader_id_1,leader_id_2" is possible.<br />
<br />
* ai.get_new_enemy_dst_src and related functions have several problems:<br />
** They use the current moves of the enemy units, which generally are all zero.<br />
** Hexes occupied by other enemy units count as not reachable.<br />
**Units with zero moves are not listed at all, not even for the hex they are on.<br />
**Working around this with a Lua wrapper makes this actually slower than ai_helper.get_enemy_dst_src, which makes the functions pretty much useless, as speed is the only thing speaking for them.<br />
<br />
* Clean up Micro AI candidate actions code. The Micro AIs were developed over quite a long period while we were trying to figure out how all of this works (and in part also by students participating in the Google Code-in project). As a result, the code in some of them is quite inconsistent, not cleaned up, uncommented (or wrongly commented), etc. '''Important notes:'''<br />
**This is not meant as a single task, but rather as a series of tasks, involving individual MAIs or sets of related MAIs. Please do not submit a pull request in which the code of all MAIs has been modified. <br />
**The Micro AIs are still being worked on pretty constantly, so if you are planning to work on this task, please let mattsc know (either on IRC or via forum PM), so that we can avoid conflicts as much as possible.<br />
<br />
* Add new options (keys or tags) to the Micro AIs. As an example, some (but certainly not all) Micro AIs might benefit from taking some (but certainly not all) of the default AI aspects into account.<br />
<br />
* Write a script that automatically changes WML from the deprecated [ai][target] to the new [ai][goal] syntax. Ideally, this would be part of wmllint.<br />
** There are [http://wiki.wesnoth.org/AiWML#Deprecated_AI_Targeting_Aspects more deprecated AI aspect] which should eventually be added to this, but the [target] -> [goal] change would be a good and important start.<br />
<br />
== GUI related features ==<br />
<br />
Although Mordante developed the new GUI system GUI2, some dialogs still use the older GUI1 and could be improved or transferred. You should contact Mordante on IRC before starting to work on these.<br />
<br />
=== Theme Changes ===<br />
<br />
* hide the hourglass item from the statusbar when there is no timer<br />
<br />
=== Widget Changes ===<br />
* make games sortable in the lobby (open slots, total number of players, era, XP modifier, gold per village, fog/shroud)<br>a GUI2 lobby is currently being developed, ask mordante whether this is still relevant<br />
* input history (chat, commands, ..)<br />
<br />
== GUI2 related features ==<br />
GUI2 is the new gui engine Mordante/SkeletonCrew is working on. <br />
* Information on the wiki can be found here http://www.wesnoth.org/wiki/GUIToolkit<br />
* The source code is under src/gui/<br />
* The configuration config files are under data/gui/default<br />
<br />
Some tasks need the --new-widgets since the code is only shown in the experimental mode. Tasks which need this switch have the * in the title.<br />
<br />
=== Port the random map generator dialog to GUI2 ===<br />
The map generator currently doesn't use the GUI2 framework, but there's no reason why it couldn't. Ask lipk (forum)/lipkab (IRC).<br />
<br />
== Miscellaneous ==<br />
<br />
=== More powerful village naming ===<br />
'''Adding mountain names and other features to village names, having a second random name in village names'''<br />
<br />
Currently the village naming engine has a very good structure that could allow more powerful names to be generated. <br />
Understanding how it works should be quite easy, and a few useful improvements could be added.<br />
<br />
* Currently villages can use lake names and river names, this should be extended to other features like bridges, swamps, mountains etc...<br />
* It would be nice to have a separate list of "first syllabus" and "last syllabus" for naming. That's not really needed in English, but some translations could use it<br />
* Again, it is common to have villages with more than one "random" word in them. having a $name2 variable would be nice<br />
<br />
Turns out this was already done, and should be removed.<br />
<br />
=== Debug Mode ===<br />
* New debug command functionality (setting additional status.variables, possibly terrain)<br />
<br />
=== wesnoth-optipng ===<br />
For lossless png compression we use wesnoth-optipng, a script using an external toolchain (ImageMagick, OptiPNG, Advdef). Perhaps the performance could be improved by using PNGOut instead of advdef. This task includes<br />
* a quick profiling of compression ratio and decompression speed for both tools<br />
* if it provides a higher compression while not significantly slowing down decompression, adapt wesnoth-optipng to use PNGOut<br />
<br />
== Bugs ==<br />
<br />
<br />
<br />
== See Also ==<br />
<br />
[[NotSoEasyCoding]]<br />
<br />
[[Category:Development]]<br />
[[Category:Future]]</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=53358SpriteSheetApplicationSAB2014-03-01T21:09:28Z<p>Aishiko: </p>
<hr />
<div><h4>Aishiko GSOC 2014 SpriteSheets</h4><br />
My proposal is to take the current functions for drawing sprites and<br />
move it to allow for spritesheets, while hiding any of the changes from<br />
campaign designers. It should allow for the seemless intergration of <br />
spritesheets and allow for a period of conversion from multiple files to <br />
sheets.<br />
<br />
Posted 28 Feb 2014<br />
1) Basics<br />
<br />
1.1) Write a small introduction to yourself.<br />
<br />
1.2) State your preferred email address.<br />
<br />
1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?<br />
<br />
1.4) Why do you want to participate in summer of code?<br />
<br />
I'd like to participate in the summer of code for several reasons, and <br />
yes money is one of them. but experience is the biggest one.<br />
<br />
1.5) What are you studying, subject, level and school?<br />
<br />
I am currently studying computer science (read programming) and networking <br />
technology. I am a Softmore in both, I am a current student at Sandhills <br />
Community College.<br />
<br />
1.6) What country are you from, at what time are you most likely to be able to<br />
join IRC?<br />
<br />
I currently live on the east coast of the US and can be in IRC pretty <br />
much all day, either at home or school, though if at school there will <br />
be a delay if in class and not lab.<br />
<br />
1.7) Do you have other commitments for the summer period ? Do you plan to take<br />
any vacations ? If yes, when.<br />
<br />
I have no current commitments that would impact my ability to give GSOC <br />
40 hours a week of work and attention. But if an emergency comes up <br />
I'll find a way to make up the hours.<br />
<br />
2) Experience<br />
<br />
2.1) What programs/software have you worked on before?<br />
<br />
Mostly personal projects and class projects, in C, C++, C#, PHP, Python, <br />
& the Arduino. One of C++ classes was using DarkGTK (yes I know its <br />
windows only) but we used SpriteSheets, sprite collision, and mouse interaction.<br />
<br />
2.2) Have you developed software in a team environment before? (As opposed to<br />
hacking on something on your own)<br />
<br />
I have in a class environment, but I'm usually the only one left doing <br />
the heavy lifting of coding. Though next year I'll be doing the <br />
programming capstone class where the class of 1-20 students work <br />
together to produce a program for a client, either for the college or <br />
for a community member/business. I'm both looking forward to and <br />
dreading working on a team, wondering if I'll be able to fit in and <br />
create code that is easy to maintain and follow.<br />
<br />
2.3) Have you participated to the Google Summer of Code before? As a mentor or a<br />
student? In what project? Were you successful? If not, why?<br />
<br />
I applied last year, however, I wasn't choosen mostly because I lack <br />
good writing skills for technical documents. At least that is what I <br />
was told.<br />
<br />
2.4) Are you already involved with any open source development projects? If yes,<br />
please describe the project and the scope of your involvement.<br />
<br />
None, I have submitted patches to the linux kernel but, I never <br />
bothered to see if they made it in.<br />
<br />
2.5) Gaming experience - Are you a gamer?<br />
<br />
Sometimes, depends on my mood.<br />
<br />
2.5.1) What type of gamer are you?<br />
<br />
Casual.<br />
<br />
2.5.2) What type of games?<br />
<br />
2.5.3) What type of opponents do you prefer?<br />
<br />
AI oppenents, I'm not really into the whole competetive thing.<br />
<br />
2.5.4) Are you more interested in story or gameplay?<br />
<br />
I think BOTH have to be there for a successful game. <br />
Though to be honest I'm better at critecing story then gameplay.<br />
<br />
2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether<br />
you lean towards single player or multiplayer.<br />
<br />
We do not plan to favor Wesnoth players as such, but some particular projects<br />
require a good feeling for the game which is hard to get without having played<br />
intensively.<br />
<br />
I've played Wesnoth for a year or 2, and I play exclusively single player.<br />
<br />
2.6) If you have contributed any patches to Wesnoth, please list them below. You<br />
can also list patches that have been submitted but not committed yet and patches<br />
that have not been specifically written for GSoC. If you have gained commit<br />
access to our repository (during the evaluation period or earlier) please state<br />
so.<br />
<br />
<br />
3) Communication skills<br />
<br />
3.1) Though most of our developers are not native English speakers, English is<br />
the project's working language. Describe your fluency level in written English.<br />
<br />
3.2) What spoken languages are you fluent in?<br />
<br />
English, I can understand a smattering of other languages but not enough <br />
to do anything deep or programming specific.<br />
<br />
3.3) Are you good at interacting with other players? Our developer community is<br />
friendly, but the player community can be a bit rough.<br />
<br />
3.4) Do you give constructive advice?<br />
<br />
I've been told I do on occasion.<br />
<br />
3.5) Do you receive advice well?<br />
<br />
I do if its construtive and not attacking. If its yelling, screaming, <br />
and insults as well, not so much. How its given usually impacts how well<br />
I receive it.<br />
<br />
3.6) Are you good at sorting useful criticisms from useless ones?<br />
<br />
Given enough time yes, but the painfully obvious ones I usually see <br />
right away.<br />
<br />
3.7) How autonomous are you when developing ? Would you rather discuss<br />
intensively changes and not start coding until you know what you want to do or<br />
would you rather code a proof of concept to "see how it turn out", taking the<br />
risk of having it thrown away if it doesn't match what the project want<br />
<br />
I'm usually fairly autonomous, once the design has been decided, and <br />
if it doesn't work and needs a change I sometimes seek councel on what <br />
way I should go, but sometimes just go ahead and make the change.<br />
Examples:<br />
1) The flow needs changing as it doesn't work right, usually I'll seek<br />
help figuring it how to change the flow so it does work.<br />
2) An array isn't giving the flexablity needed for a function but a <br />
list will, I implement the list instead. And inform whomever needs to <br />
know that I have done that change.<br />
<br />
4) Project<br />
<br />
4.1) Did you select a project from our list? If that is the case, what project<br />
did you select? What do you want to especially concentrate on?<br />
<br />
I selected one from the list, the implementing the SpriteSheets. <br />
I would like to concentrate on 2 tasks, 1 getting SpriteSheets to just <br />
work in wesnoth, and two, provide a script/tool/utility to allow easy <br />
converting from the old single images to the sheet (assuming certian <br />
naming conventions are followed).<br />
<br />
4.2) If you have invented your own project, please describe the project and the<br />
scope.<br />
<br />
N/A<br />
<br />
4.3) Why did you choose this project?<br />
<br />
I chosse it because I understand the concepts behind it, and felt it <br />
was a task that I could handle. It will also force me to learn and <br />
will provide immediate gains to all users when the version that <br />
includes the change is pushed out.<br />
<br />
4.4) Include an estimated timeline for your work on the project. Don't forget to<br />
mention special things like "I booked holidays between A and B" and "I got an<br />
exam at ABC and won't be doing much then".<br />
<br />
I'm still working out a timeline but I would most likely do a commit <br />
at least weekly. And break out the commits so that similar changes <br />
are only in that commit. Example, comment changes in one, (assuming <br />
no code changes), a converted set of sprites (aka the spritesheet) as <br />
one, and then code making use of it. After checking to make sure that <br />
the spritesheet works, removal of the converted individual sprite image <br />
files.<br />
<br />
4.5) Include as much technical detail about your implementation as you can<br />
<br />
At this point I think I would take 1 sprite (character) and create a <br />
spritesheet of it, and then test with that one. To allow testing I'd <br />
likely have it check for a spritesheet if it finds one it uses that, <br />
otherwise it uses the individual sprite images, in this way the game <br />
still works, until all the sprites have been turned into spritesheets.<br />
<br />
Once I have completed getting a character spritesheet to work, I'd <br />
then move on to the map sprites to spritesheets, again using the same <br />
methodology of check and if it finds a spritesheet use it otherwise, <br />
use the individual images. Though, on the grouping I'm not sure how <br />
I'd do that mordante and I'd have to discuss grouping, since a map can <br />
have any or all of the different tiles, and they are not chained like <br />
the unit/character sprites are, I'd have to group similar tiles together.<br />
Like the water images, shorelines, docks, and water villages, as one.<br />
The fields, human villages and castles in one. Swamp things together, <br />
and so on.<br />
<br />
I've heard that some devs think that a spritesheet might cause issues <br />
with larger images that don't fit in a hex, I'll intentional create some <br />
sprite sheets just for testing this purpose. I'll also see about creating <br />
some tests to check and see if the performance gains are really showing up.<br />
<br />
<br />
4.6) What do you expect to gain from this project?<br />
<br />
Experience, learning to work on a team where most actually pull their <br />
own weight and the success of the project as a whole is not on my <br />
shoulders. This is too big a project for me to even think of that! <br />
and I'd not be able to, not in 3 months.<br />
<br />
4.7) What would make you stay in the Wesnoth community after the conclusion of<br />
SOC?<br />
<br />
Finding that the community is a non-hostile place to contribute, that <br />
individuals are treated with courtsey or the respect they have earned.<br />
That I'm encouraged to help other areas of the code, such as, "Aishi, <br />
the spritesheets work, do you think you could help with the transistion <br />
effects for the map?"<br />
<br />
<br />
5) Practical considerations<br />
<br />
5.1) Are you familiar with any of the following tools or languages?<br />
<br />
Git (used for all commits)<br />
I don't get it yet but I'm confident that I can get it.<br />
C++ (language used for all the normal source code)<br />
Its my favourite language and I'm comfortable using the language<br />
and looking up what I don't know and making it work. I'm also not<br />
afraid to ask, for help/documentation if I get stuck.<br />
STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
I've not, YET. Well I might, I never really looked into where a lib or <br />
function comes from when I use, I'll have to pay a bit more attention <br />
now. But they are no on my documentation read list, I'm confident<br />
that by the time coding begins that I'll be able to leverage them to <br />
obtain results, and be more effienent as I go. Even going back and <br />
making a section more effient if I realize that I over looked a better <br />
tool then I orginally used.<br />
Python (optional, mainly used for tools)<br />
I'm familiar enough to use it, follow it (assuming good coding <br />
conventions are followed).<br />
build environments (eg cmake/scons)<br />
I tend to use cmake and the gcc compiler, basically I use which ever <br />
build environment I have available and if its a new one I look up (via <br />
the man page or the internet) how to use it, and if the defaults <br />
settings don't work to add flags/options to get it to compile.<br />
WML (the wesnoth specific scenario language)<br />
Absolutely none before now, again on my read list<br />
Lua (used in combination with WML to create scenarios)<br />
None but I don't create senarios at this point, and if its only used <br />
in that context, it shouldn't have any barring on the project(s) I'm <br />
interested in doing at this point. <br />
<br />
5.2) Which tools do you normally use for development? Why do you use them?<br />
Kate, as its just what I'm used to, I like how it's mimaliztic and <br />
non-intrutsive.<br />
Visual Studio for my C# class because that is what they have to work <br />
in when I turn it in.<br />
<br />
5.3) What programming languages are you fluent in?<br />
I'm not sure what you mean by fluent, if you mean know every builtin <br />
function and every conseviable combination of calls, I doubt very many <br />
could claim to be fluent. However if you mean, comfortable, and able <br />
to figure out things you don't knoe, either by looking it up or by <br />
context then C (and its children, C++, C#, Arduino) python, and PHP. <br />
After being fluent in English doesn't mean you know every word or <br />
special rule for the language.<br />
<br />
5.4) Would you mind talking with your mentor on telephone / internet phone? We<br />
would like to have a backup way for communications for the case that somehow<br />
emails and IRC do fail. If you are willing to do so, please do list a phone<br />
number (including international code) so that we are able to contact you. You<br />
should probably *only* add this number in the application for you submit to<br />
google since the info in the wiki is available in public. We will *not* make any<br />
use of your number unless some case of "there is no way to contact you" does<br />
arise!<br />
<br />
<br />
I wouldn't mind and in some cases prefer it. I'm not the most observant <br />
when it comes to my email, I usually just get notices and spam that can <br />
be ignored (high noise to signal ratio in my mailbox at the moment). <br />
Though when expecting something I check it more often at least once a <br />
day if not more.<br />
<br />
**************Comments and Suggestions**************<br />
Please place them after this line, all are appreciated and if I can't thank you <br />
personally (IE you don't attach your name to it, Thank you.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=53357SpriteSheetApplicationSAB2014-03-01T21:03:57Z<p>Aishiko: </p>
<hr />
<div>Posted 28 Feb 2014<br />
1) Basics<br />
<br />
1.1) Write a small introduction to yourself.<br />
<br />
1.2) State your preferred email address.<br />
<br />
1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?<br />
<br />
1.4) Why do you want to participate in summer of code?<br />
<br />
I'd like to participate in the summer of code for several reasons, and <br />
yes money is one of them. but experience is the biggest one.<br />
<br />
1.5) What are you studying, subject, level and school?<br />
<br />
I am currently studying computer science (read programming) and networking <br />
technology. I am a Softmore in both, I am a current student at Sandhills <br />
Community College.<br />
<br />
1.6) What country are you from, at what time are you most likely to be able to<br />
join IRC?<br />
<br />
I currently live on the east coast of the US and can be in IRC pretty <br />
much all day, either at home or school, though if at school there will <br />
be a delay if in class and not lab.<br />
<br />
1.7) Do you have other commitments for the summer period ? Do you plan to take<br />
any vacations ? If yes, when.<br />
<br />
I have no current commitments that would impact my ability to give GSOC <br />
40 hours a week of work and attention. But if an emergency comes up <br />
I'll find a way to make up the hours.<br />
<br />
2) Experience<br />
<br />
2.1) What programs/software have you worked on before?<br />
<br />
Mostly personal projects and class projects, in C, C++, C#, PHP, Python, <br />
& the Arduino. One of C++ classes was using DarkGTK (yes I know its <br />
windows only) but we used SpriteSheets, sprite collision, and mouse interaction.<br />
<br />
2.2) Have you developed software in a team environment before? (As opposed to<br />
hacking on something on your own)<br />
<br />
I have in a class environment, but I'm usually the only one left doing <br />
the heavy lifting of coding. Though next year I'll be doing the <br />
programming capstone class where the class of 1-20 students work <br />
together to produce a program for a client, either for the college or <br />
for a community member/business. I'm both looking forward to and <br />
dreading working on a team, wondering if I'll be able to fit in and <br />
create code that is easy to maintain and follow.<br />
<br />
2.3) Have you participated to the Google Summer of Code before? As a mentor or a<br />
student? In what project? Were you successful? If not, why?<br />
<br />
I applied last year, however, I wasn't choosen mostly because I lack <br />
good writing skills for technical documents. At least that is what I <br />
was told.<br />
<br />
2.4) Are you already involved with any open source development projects? If yes,<br />
please describe the project and the scope of your involvement.<br />
<br />
None, I have submitted patches to the linux kernel but, I never <br />
bothered to see if they made it in.<br />
<br />
2.5) Gaming experience - Are you a gamer?<br />
<br />
Sometimes, depends on my mood.<br />
<br />
2.5.1) What type of gamer are you?<br />
<br />
Casual.<br />
<br />
2.5.2) What type of games?<br />
<br />
2.5.3) What type of opponents do you prefer?<br />
<br />
AI oppenents, I'm not really into the whole competetive thing.<br />
<br />
2.5.4) Are you more interested in story or gameplay?<br />
<br />
I think BOTH have to be there for a successful game. <br />
Though to be honest I'm better at critecing story then gameplay.<br />
<br />
2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether<br />
you lean towards single player or multiplayer.<br />
<br />
We do not plan to favor Wesnoth players as such, but some particular projects<br />
require a good feeling for the game which is hard to get without having played<br />
intensively.<br />
<br />
I've played Wesnoth for a year or 2, and I play exclusively single player.<br />
<br />
2.6) If you have contributed any patches to Wesnoth, please list them below. You<br />
can also list patches that have been submitted but not committed yet and patches<br />
that have not been specifically written for GSoC. If you have gained commit<br />
access to our repository (during the evaluation period or earlier) please state<br />
so.<br />
<br />
<br />
3) Communication skills<br />
<br />
3.1) Though most of our developers are not native English speakers, English is<br />
the project's working language. Describe your fluency level in written English.<br />
<br />
3.2) What spoken languages are you fluent in?<br />
<br />
English, I can understand a smattering of other languages but not enough <br />
to do anything deep or programming specific.<br />
<br />
3.3) Are you good at interacting with other players? Our developer community is<br />
friendly, but the player community can be a bit rough.<br />
<br />
3.4) Do you give constructive advice?<br />
<br />
I've been told I do on occasion.<br />
<br />
3.5) Do you receive advice well?<br />
<br />
I do if its construtive and not attacking. If its yelling, screaming, <br />
and insults as well, not so much. How its given usually impacts how well<br />
I receive it.<br />
<br />
3.6) Are you good at sorting useful criticisms from useless ones?<br />
<br />
Given enough time yes, but the painfully obvious ones I usually see <br />
right away.<br />
<br />
3.7) How autonomous are you when developing ? Would you rather discuss<br />
intensively changes and not start coding until you know what you want to do or<br />
would you rather code a proof of concept to "see how it turn out", taking the<br />
risk of having it thrown away if it doesn't match what the project want<br />
<br />
I'm usually fairly autonomous, once the design has been decided, and <br />
if it doesn't work and needs a change I sometimes seek councel on what <br />
way I should go, but sometimes just go ahead and make the change.<br />
Examples:<br />
1) The flow needs changing as it doesn't work right, usually I'll seek<br />
help figuring it how to change the flow so it does work.<br />
2) An array isn't giving the flexablity needed for a function but a <br />
list will, I implement the list instead. And inform whomever needs to <br />
know that I have done that change.<br />
<br />
4) Project<br />
<br />
4.1) Did you select a project from our list? If that is the case, what project<br />
did you select? What do you want to especially concentrate on?<br />
<br />
I selected one from the list, the implementing the SpriteSheets. <br />
I would like to concentrate on 2 tasks, 1 getting SpriteSheets to just <br />
work in wesnoth, and two, provide a script/tool/utility to allow easy <br />
converting from the old single images to the sheet (assuming certian <br />
naming conventions are followed).<br />
<br />
4.2) If you have invented your own project, please describe the project and the<br />
scope.<br />
<br />
N/A<br />
<br />
4.3) Why did you choose this project?<br />
<br />
I chosse it because I understand the concepts behind it, and felt it <br />
was a task that I could handle. It will also force me to learn and <br />
will provide immediate gains to all users when the version that <br />
includes the change is pushed out.<br />
<br />
4.4) Include an estimated timeline for your work on the project. Don't forget to<br />
mention special things like "I booked holidays between A and B" and "I got an<br />
exam at ABC and won't be doing much then".<br />
<br />
I'm still working out a timeline but I would most likely do a commit <br />
at least weekly. And break out the commits so that similar changes <br />
are only in that commit. Example, comment changes in one, (assuming <br />
no code changes), a converted set of sprites (aka the spritesheet) as <br />
one, and then code making use of it. After checking to make sure that <br />
the spritesheet works, removal of the converted individual sprite image <br />
files.<br />
<br />
4.5) Include as much technical detail about your implementation as you can<br />
<br />
At this point I think I would take 1 sprite (character) and create a <br />
spritesheet of it, and then test with that one. To allow testing I'd <br />
likely have it check for a spritesheet if it finds one it uses that, <br />
otherwise it uses the individual sprite images, in this way the game <br />
still works, until all the sprites have been turned into spritesheets.<br />
<br />
Once I have completed getting a character spritesheet to work, I'd <br />
then move on to the map sprites to spritesheets, again using the same <br />
methodology of check and if it finds a spritesheet use it otherwise, <br />
use the individual images. Though, on the grouping I'm not sure how <br />
I'd do that mordante and I'd have to discuss grouping, since a map can <br />
have any or all of the different tiles, and they are not chained like <br />
the unit/character sprites are, I'd have to group similar tiles together.<br />
Like the water images, shorelines, docks, and water villages, as one.<br />
The fields, human villages and castles in one. Swamp things together, <br />
and so on.<br />
<br />
I've heard that some devs think that a spritesheet might cause issues <br />
with larger images that don't fit in a hex, I'll intentional create some <br />
sprite sheets just for testing this purpose. I'll also see about creating <br />
some tests to check and see if the performance gains are really showing up.<br />
<br />
<br />
4.6) What do you expect to gain from this project?<br />
<br />
Experience, learning to work on a team where most actually pull their <br />
own weight and the success of the project as a whole is not on my <br />
shoulders. This is too big a project for me to even think of that! <br />
and I'd not be able to, not in 3 months.<br />
<br />
4.7) What would make you stay in the Wesnoth community after the conclusion of<br />
SOC?<br />
<br />
Finding that the community is a non-hostile place to contribute, that <br />
individuals are treated with courtsey or the respect they have earned.<br />
That I'm encouraged to help other areas of the code, such as, "Aishi, <br />
the spritesheets work, do you think you could help with the transistion <br />
effects for the map?"<br />
<br />
<br />
5) Practical considerations<br />
<br />
5.1) Are you familiar with any of the following tools or languages?<br />
<br />
Git (used for all commits)<br />
I don't get it yet but I'm confident that I can get it.<br />
C++ (language used for all the normal source code)<br />
Its my favourite language and I'm comfortable using the language<br />
and looking up what I don't know and making it work. I'm also not<br />
afraid to ask, for help/documentation if I get stuck.<br />
STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
I've not, YET. Well I might, I never really looked into where a lib or <br />
function comes from when I use, I'll have to pay a bit more attention <br />
now. But they are no on my documentation read list, I'm confident<br />
that by the time coding begins that I'll be able to leverage them to <br />
obtain results, and be more effienent as I go. Even going back and <br />
making a section more effient if I realize that I over looked a better <br />
tool then I orginally used.<br />
Python (optional, mainly used for tools)<br />
I'm familiar enough to use it, follow it (assuming good coding <br />
conventions are followed).<br />
build environments (eg cmake/scons)<br />
I tend to use cmake and the gcc compiler, basically I use which ever <br />
build environment I have available and if its a new one I look up (via <br />
the man page or the internet) how to use it, and if the defaults <br />
settings don't work to add flags/options to get it to compile.<br />
WML (the wesnoth specific scenario language)<br />
Absolutely none before now, again on my read list<br />
Lua (used in combination with WML to create scenarios)<br />
None but I don't create senarios at this point, and if its only used <br />
in that context, it shouldn't have any barring on the project(s) I'm <br />
interested in doing at this point. <br />
<br />
5.2) Which tools do you normally use for development? Why do you use them?<br />
Kate, as its just what I'm used to, I like how it's mimaliztic and <br />
non-intrutsive.<br />
Visual Studio for my C# class because that is what they have to work <br />
in when I turn it in.<br />
<br />
5.3) What programming languages are you fluent in?<br />
I'm not sure what you mean by fluent, if you mean know every builtin <br />
function and every conseviable combination of calls, I doubt very many <br />
could claim to be fluent. However if you mean, comfortable, and able <br />
to figure out things you don't knoe, either by looking it up or by <br />
context then C (and its children, C++, C#, Arduino) python, and PHP. <br />
After being fluent in English doesn't mean you know every word or <br />
special rule for the language.<br />
<br />
5.4) Would you mind talking with your mentor on telephone / internet phone? We<br />
would like to have a backup way for communications for the case that somehow<br />
emails and IRC do fail. If you are willing to do so, please do list a phone<br />
number (including international code) so that we are able to contact you. You<br />
should probably *only* add this number in the application for you submit to<br />
google since the info in the wiki is available in public. We will *not* make any<br />
use of your number unless some case of "there is no way to contact you" does<br />
arise!<br />
<br />
<br />
I wouldn't mind and in some cases prefer it. I'm not the most observant <br />
when it comes to my email, I usually just get notices and spam that can <br />
be ignored (high noise to signal ratio in my mailbox at the moment). <br />
Though when expecting something I check it more often at least once a <br />
day if not more.<br />
<br />
**************Comments and Suggestions**************<br />
Please place them after this line, all are appreciated and if I can't thank you <br />
personally (IE you don't attach your name to it, Thank you.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SoC_Ideas_SpriteSheets2014&diff=53356SoC Ideas SpriteSheets20142014-03-01T21:01:44Z<p>Aishiko: /* SpriteSheet */</p>
<hr />
<div>{{SoC2014Idea}}<br />
<br />
==Description==<br />
===SpriteSheet===<br />
Page for the idea: [[SoC_Ideas_SpriteSheets2014]]<br />
<br />
Wesnoth uses thousands of images, each of them stored in separate files.<br />
It would be more efficient to store multiple images in a single file. In order<br />
to make that possible, the Wesnoth engine needs to be adapted to allow this change.<br />
<br />
{{#dpl:<br />
|resultsheader=''There are %PAGES% submitted student proposals for this idea''<br />
|oneresultheader=''There is 1 submitted student proposal for this idea''<br />
|suppresserrors=true<br />
|noresultsheader=''There are no submitted student proposals for this idea''<br />
|category=Summer of Code 2014 Student Page&SoC Ideas IDEA NAME<br />
|notcategory=SoC 2014 Not Submitted To Google<br />
|include=#Description<br />
|nottitlematch=SoC2014_Template_of_Student_page<br />
|mode=userformat<br />
|format=,,<br/>See [[%PAGE%|%TITLE%]] for more information.<br/><br/>,<br />
}}<br />
<br />
==Additional Information==<br />
<br />
Currently, all the Wesnoth unit animations are based on thousands of small png<br />
images, each image representing the unit in a single pose. For terrains the<br />
situation is the same, it has a base image with a lot of transitions to other<br />
terrains, which are now stored as seperate images.<br />
<br />
In a sprite sheet approach, each unit is represented by a single, huge, image<br />
where all the unit images are put on a mosaïc pattern and the game knows where<br />
to look for a given image.<br />
<br />
The advantage of having a large image with all positions is that it's more<br />
efficient in memory. Also one large file is more effecient on the harddisk and<br />
faster to load than a lot of smaller files. So the change to spritesheets will<br />
have a lot of advantages. Also several Wesnoth artists prefer using sprite<br />
sheets over multiple single images.<br />
<br />
This project involves changing the Wesnoth Markup Language (WML)* definition<br />
for images to specify a sub image in a sprite sheet and change the image loading<br />
code of the engine. Creating tools to transform existing images to a sprite sheet<br />
can be an optional objective.<br />
<br />
Regarding the implementation the student is free to come up with his/her own<br />
solution and discuss that with the developers during the application period.<br />
<br />
*) WML is a XML like language, used to describe the data/content of Wesnoth.<br />
<br />
==Whom to ask about this==<br />
<br />
mordante on IRC.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=53355SpriteSheetApplicationSAB2014-03-01T20:59:41Z<p>Aishiko: Blanked the page</p>
<hr />
<div></div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=53312SpriteSheetApplicationSAB2014-03-01T04:48:00Z<p>Aishiko: </p>
<hr />
<div>Posted 28 Feb 2014<br />
1) Basics<br />
<br />
1.1) Write a small introduction to yourself.<br />
<br />
1.2) State your preferred email address.<br />
<br />
1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?<br />
<br />
1.4) Why do you want to participate in summer of code?<br />
<br />
I'd like to participate in the summer of code for several reasons, and <br />
yes money is one of them. but experience is the biggest one.<br />
<br />
1.5) What are you studying, subject, level and school?<br />
<br />
I am currently studying computer science (read programming) and networking <br />
technology. I am a Softmore in both, I am a current student at Sandhills <br />
Community College.<br />
<br />
1.6) What country are you from, at what time are you most likely to be able to<br />
join IRC?<br />
<br />
I currently live on the east coast of the US and can be in IRC pretty <br />
much all day, either at home or school, though if at school there will <br />
be a delay if in class and not lab.<br />
<br />
1.7) Do you have other commitments for the summer period ? Do you plan to take<br />
any vacations ? If yes, when.<br />
<br />
I have no current commitments that would impact my ability to give GSOC <br />
40 hours a week of work and attention. But if an emergency comes up <br />
I'll find a way to make up the hours.<br />
<br />
2) Experience<br />
<br />
2.1) What programs/software have you worked on before?<br />
<br />
Mostly personal projects and class projects, in C, C++, C#, PHP, Python, <br />
& the Arduino. One of C++ classes was using DarkGTK (yes I know its <br />
windows only) but we used SpriteSheets, sprite collision, and mouse interaction.<br />
<br />
2.2) Have you developed software in a team environment before? (As opposed to<br />
hacking on something on your own)<br />
<br />
I have in a class environment, but I'm usually the only one left doing <br />
the heavy lifting of coding. Though next year I'll be doing the <br />
programming capstone class where the class of 1-20 students work <br />
together to produce a program for a client, either for the college or <br />
for a community member/business. I'm both looking forward to and <br />
dreading working on a team, wondering if I'll be able to fit in and <br />
create code that is easy to maintain and follow.<br />
<br />
2.3) Have you participated to the Google Summer of Code before? As a mentor or a<br />
student? In what project? Were you successful? If not, why?<br />
<br />
I applied last year, however, I wasn't choosen mostly because I lack <br />
good writing skills for technical documents. At least that is what I <br />
was told.<br />
<br />
2.4) Are you already involved with any open source development projects? If yes,<br />
please describe the project and the scope of your involvement.<br />
<br />
None, I have submitted patches to the linux kernel but, I never <br />
bothered to see if they made it in.<br />
<br />
2.5) Gaming experience - Are you a gamer?<br />
<br />
Sometimes, depends on my mood.<br />
<br />
2.5.1) What type of gamer are you?<br />
<br />
Casual.<br />
<br />
2.5.2) What type of games?<br />
<br />
2.5.3) What type of opponents do you prefer?<br />
<br />
AI oppenents, I'm not really into the whole competetive thing.<br />
<br />
2.5.4) Are you more interested in story or gameplay?<br />
<br />
I think BOTH have to be there for a successful game. <br />
Though to be honest I'm better at critecing story then gameplay.<br />
<br />
2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether<br />
you lean towards single player or multiplayer.<br />
<br />
We do not plan to favor Wesnoth players as such, but some particular projects<br />
require a good feeling for the game which is hard to get without having played<br />
intensively.<br />
<br />
I've played Wesnoth for a year or 2, and I play exclusively single player.<br />
<br />
2.6) If you have contributed any patches to Wesnoth, please list them below. You<br />
can also list patches that have been submitted but not committed yet and patches<br />
that have not been specifically written for GSoC. If you have gained commit<br />
access to our repository (during the evaluation period or earlier) please state<br />
so.<br />
<br />
<br />
3) Communication skills<br />
<br />
3.1) Though most of our developers are not native English speakers, English is<br />
the project's working language. Describe your fluency level in written English.<br />
<br />
3.2) What spoken languages are you fluent in?<br />
<br />
English, I can understand a smattering of other languages but not enough <br />
to do anything deep or programming specific.<br />
<br />
3.3) Are you good at interacting with other players? Our developer community is<br />
friendly, but the player community can be a bit rough.<br />
<br />
3.4) Do you give constructive advice?<br />
<br />
I've been told I do on occasion.<br />
<br />
3.5) Do you receive advice well?<br />
<br />
I do if its construtive and not attacking. If its yelling, screaming, <br />
and insults as well, not so much. How its given usually impacts how well<br />
I receive it.<br />
<br />
3.6) Are you good at sorting useful criticisms from useless ones?<br />
<br />
Given enough time yes, but the painfully obvious ones I usually see <br />
right away.<br />
<br />
3.7) How autonomous are you when developing ? Would you rather discuss<br />
intensively changes and not start coding until you know what you want to do or<br />
would you rather code a proof of concept to "see how it turn out", taking the<br />
risk of having it thrown away if it doesn't match what the project want<br />
<br />
I'm usually fairly autonomous, once the design has been decided, and <br />
if it doesn't work and needs a change I sometimes seek councel on what <br />
way I should go, but sometimes just go ahead and make the change.<br />
Examples:<br />
1) The flow needs changing as it doesn't work right, usually I'll seek<br />
help figuring it how to change the flow so it does work.<br />
2) An array isn't giving the flexablity needed for a function but a <br />
list will, I implement the list instead. And inform whomever needs to <br />
know that I have done that change.<br />
<br />
4) Project<br />
<br />
4.1) Did you select a project from our list? If that is the case, what project<br />
did you select? What do you want to especially concentrate on?<br />
<br />
I selected one from the list, the implementing the SpriteSheets. <br />
I would like to concentrate on 2 tasks, 1 getting SpriteSheets to just <br />
work in wesnoth, and two, provide a script/tool/utility to allow easy <br />
converting from the old single images to the sheet (assuming certian <br />
naming conventions are followed).<br />
<br />
4.2) If you have invented your own project, please describe the project and the<br />
scope.<br />
<br />
N/A<br />
<br />
4.3) Why did you choose this project?<br />
<br />
I chosse it because I understand the concepts behind it, and felt it <br />
was a task that I could handle. It will also force me to learn and <br />
will provide immediate gains to all users when the version that <br />
includes the change is pushed out.<br />
<br />
4.4) Include an estimated timeline for your work on the project. Don't forget to<br />
mention special things like "I booked holidays between A and B" and "I got an<br />
exam at ABC and won't be doing much then".<br />
<br />
I'm still working out a timeline but I would most likely do a commit <br />
at least weekly. And break out the commits so that similar changes <br />
are only in that commit. Example, comment changes in one, (assuming <br />
no code changes), a converted set of sprites (aka the spritesheet) as <br />
one, and then code making use of it. After checking to make sure that <br />
the spritesheet works, removal of the converted individual sprite image <br />
files.<br />
<br />
4.5) Include as much technical detail about your implementation as you can<br />
<br />
At this point I think I would take 1 sprite (character) and create a <br />
spritesheet of it, and then test with that one. To allow testing I'd <br />
likely have it check for a spritesheet if it finds one it uses that, <br />
otherwise it uses the individual sprite images, in this way the game <br />
still works, until all the sprites have been turned into spritesheets.<br />
<br />
Once I have completed getting a character spritesheet to work, I'd <br />
then move on to the map sprites to spritesheets, again using the same <br />
methodology of check and if it finds a spritesheet use it otherwise, <br />
use the individual images. Though, on the grouping I'm not sure how <br />
I'd do that mordante and I'd have to discuss grouping, since a map can <br />
have any or all of the different tiles, and they are not chained like <br />
the unit/character sprites are, I'd have to group similar tiles together.<br />
Like the water images, shorelines, docks, and water villages, as one.<br />
The fields, human villages and castles in one. Swamp things together, <br />
and so on.<br />
<br />
I've heard that some devs think that a spritesheet might cause issues <br />
with larger images that don't fit in a hex, I'll intentional create some <br />
sprite sheets just for testing this purpose. I'll also see about creating <br />
some tests to check and see if the performance gains are really showing up.<br />
<br />
<br />
4.6) What do you expect to gain from this project?<br />
<br />
Experience, learning to work on a team where most actually pull their <br />
own weight and the success of the project as a whole is not on my <br />
shoulders. This is too big a project for me to even think of that! <br />
and I'd not be able to, not in 3 months.<br />
<br />
4.7) What would make you stay in the Wesnoth community after the conclusion of<br />
SOC?<br />
<br />
Finding that the community is a non-hostile place to contribute, that <br />
individuals are treated with courtsey or the respect they have earned.<br />
That I'm encouraged to help other areas of the code, such as, "Aishi, <br />
the spritesheets work, do you think you could help with the transistion <br />
effects for the map?"<br />
<br />
<br />
5) Practical considerations<br />
<br />
5.1) Are you familiar with any of the following tools or languages?<br />
<br />
Git (used for all commits)<br />
I don't get it yet but I'm confident that I can get it.<br />
C++ (language used for all the normal source code)<br />
Its my favourite language and I'm comfortable using the language<br />
and looking up what I don't know and making it work. I'm also not<br />
afraid to ask, for help/documentation if I get stuck.<br />
STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
I've not, YET. Well I might, I never really looked into where a lib or <br />
function comes from when I use, I'll have to pay a bit more attention <br />
now. But they are no on my documentation read list, I'm confident<br />
that by the time coding begins that I'll be able to leverage them to <br />
obtain results, and be more effienent as I go. Even going back and <br />
making a section more effient if I realize that I over looked a better <br />
tool then I orginally used.<br />
Python (optional, mainly used for tools)<br />
I'm familiar enough to use it, follow it (assuming good coding <br />
conventions are followed).<br />
build environments (eg cmake/scons)<br />
I tend to use cmake and the gcc compiler, basically I use which ever <br />
build environment I have available and if its a new one I look up (via <br />
the man page or the internet) how to use it, and if the defaults <br />
settings don't work to add flags/options to get it to compile.<br />
WML (the wesnoth specific scenario language)<br />
Absolutely none before now, again on my read list<br />
Lua (used in combination with WML to create scenarios)<br />
None but I don't create senarios at this point, and if its only used <br />
in that context, it shouldn't have any barring on the project(s) I'm <br />
interested in doing at this point. <br />
<br />
5.2) Which tools do you normally use for development? Why do you use them?<br />
Kate, as its just what I'm used to, I like how it's mimaliztic and <br />
non-intrutsive.<br />
Visual Studio for my C# class because that is what they have to work <br />
in when I turn it in.<br />
<br />
5.3) What programming languages are you fluent in?<br />
I'm not sure what you mean by fluent, if you mean know every builtin <br />
function and every conseviable combination of calls, I doubt very many <br />
could claim to be fluent. However if you mean, comfortable, and able <br />
to figure out things you don't knoe, either by looking it up or by <br />
context then C (and its children, C++, C#, Arduino) python, and PHP. <br />
After being fluent in English doesn't mean you know every word or <br />
special rule for the language.<br />
<br />
5.4) Would you mind talking with your mentor on telephone / internet phone? We<br />
would like to have a backup way for communications for the case that somehow<br />
emails and IRC do fail. If you are willing to do so, please do list a phone<br />
number (including international code) so that we are able to contact you. You<br />
should probably *only* add this number in the application for you submit to<br />
google since the info in the wiki is available in public. We will *not* make any<br />
use of your number unless some case of "there is no way to contact you" does<br />
arise!<br />
<br />
<br />
I wouldn't mind and in some cases prefer it. I'm not the most observant <br />
when it comes to my email, I usually just get notices and spam that can <br />
be ignored (high noise to signal ratio in my mailbox at the moment). <br />
Though when expecting something I check it more often at least once a <br />
day if not more.<br />
<br />
**************Comments and Suggestions**************<br />
Please place them after this line, all are appreciated and if I can't thank you <br />
personally (IE you don't attach your name to it, Thank you.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=53311SpriteSheetApplicationSAB2014-03-01T04:42:01Z<p>Aishiko: </p>
<hr />
<div>Posted 28 Feb 2014<br />
1) Basics<br />
<br />
1.1) Write a small introduction to yourself.<br />
<br />
1.2) State your preferred email address.<br />
<br />
1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?<br />
<br />
1.4) Why do you want to participate in summer of code?<br />
<br />
I'd like to participate in the summer of code for several reasons, and <br />
yes money is one of them. but experience is the biggest one.<br />
<br />
1.5) What are you studying, subject, level and school?<br />
<br />
I am currently studying computer science (read programming) and networking <br />
technology. I am a Softmore in both, I am a current student at Sandhills <br />
Community College.<br />
<br />
1.6) What country are you from, at what time are you most likely to be able to<br />
join IRC?<br />
<br />
I currently live on the east coast of the US and can be in IRC pretty <br />
much all day, either at home or school, though if at school there will <br />
be a delay if in class and not lab.<br />
<br />
1.7) Do you have other commitments for the summer period ? Do you plan to take<br />
any vacations ? If yes, when.<br />
<br />
I have no current commitments that would impact my ability to give GSOC <br />
40 hours a week of work and attention. But if an emergency comes up <br />
I'll find a way to make up the hours.<br />
<br />
2) Experience<br />
<br />
2.1) What programs/software have you worked on before?<br />
<br />
Mostly personal projects and class projects, in C, C++, C#, PHP, Python, <br />
& the Arduino. One of C++ classes was using DarkGTK (yes I know its <br />
windows only) but we used SpriteSheets, sprite collision, and mouse interaction.<br />
<br />
2.2) Have you developed software in a team environment before? (As opposed to<br />
hacking on something on your own)<br />
<br />
I have in a class environment, but I'm usually the only one left doing <br />
the heavy lifting of coding. Though next year I'll be doing the <br />
programming capstone class where the class of 1-20 students work <br />
together to produce a program for a client, either for the college or <br />
for a community member/business. I'm both looking forward to and <br />
dreading working on a team, wondering if I'll be able to fit in and <br />
create code that is easy to maintain and follow.<br />
<br />
2.3) Have you participated to the Google Summer of Code before? As a mentor or a<br />
student? In what project? Were you successful? If not, why?<br />
<br />
I applied last year, however, I wasn't choosen mostly because I lack <br />
good writing skills for technical documents. At least that is what I <br />
was told.<br />
<br />
2.4) Are you already involved with any open source development projects? If yes,<br />
please describe the project and the scope of your involvement.<br />
<br />
None, I have submitted patches to the linux kernel but, I never <br />
bothered to see if they made it in.<br />
<br />
2.5) Gaming experience - Are you a gamer?<br />
<br />
Sometimes, depends on my mood.<br />
<br />
2.5.1) What type of gamer are you?<br />
<br />
Casual.<br />
<br />
2.5.2) What type of games?<br />
<br />
2.5.3) What type of opponents do you prefer?<br />
<br />
AI oppenents, I'm not really into the whole competetive thing.<br />
<br />
2.5.4) Are you more interested in story or gameplay?<br />
<br />
I think BOTH have to be there for a successful game. <br />
Though to be honest I'm better at critecing story then gameplay.<br />
<br />
2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether<br />
you lean towards single player or multiplayer.<br />
<br />
We do not plan to favor Wesnoth players as such, but some particular projects<br />
require a good feeling for the game which is hard to get without having played<br />
intensively.<br />
<br />
I've played Wesnoth for a year or 2, and I play exclusively single player.<br />
<br />
2.6) If you have contributed any patches to Wesnoth, please list them below. You<br />
can also list patches that have been submitted but not committed yet and patches<br />
that have not been specifically written for GSoC. If you have gained commit<br />
access to our repository (during the evaluation period or earlier) please state<br />
so.<br />
<br />
<br />
3) Communication skills<br />
<br />
3.1) Though most of our developers are not native English speakers, English is<br />
the project's working language. Describe your fluency level in written English.<br />
<br />
3.2) What spoken languages are you fluent in?<br />
<br />
English, I can understand a smattering of other languages but not enough <br />
to do anything deep or programming specific.<br />
<br />
3.3) Are you good at interacting with other players? Our developer community is<br />
friendly, but the player community can be a bit rough.<br />
<br />
3.4) Do you give constructive advice?<br />
<br />
I've been told I do on occasion.<br />
<br />
3.5) Do you receive advice well?<br />
<br />
I do if its construtive and not attacking. If its yelling, screaming, <br />
and insults as well, not so much. How its given usually impacts how well<br />
I receive it.<br />
<br />
3.6) Are you good at sorting useful criticisms from useless ones?<br />
<br />
Given enough time yes, but the painfully obvious ones I usually see <br />
right away.<br />
<br />
3.7) How autonomous are you when developing ? Would you rather discuss<br />
intensively changes and not start coding until you know what you want to do or<br />
would you rather code a proof of concept to "see how it turn out", taking the<br />
risk of having it thrown away if it doesn't match what the project want<br />
<br />
I'm usually fairly autonomous, once the design has been decided, and <br />
if it doesn't work and needs a change I sometimes seek councel on what <br />
way I should go, but sometimes just go ahead and make the change.<br />
Examples:<br />
1) The flow needs changing as it doesn't work right, usually I'll seek<br />
help figuring it how to change the flow so it does work.<br />
2) An array isn't giving the flexablity needed for a function but a <br />
list will, I implement the list instead. And inform whomever needs to <br />
know that I have done that change.<br />
<br />
4) Project<br />
<br />
4.1) Did you select a project from our list? If that is the case, what project<br />
did you select? What do you want to especially concentrate on?<br />
<br />
I selected one from the list, the implementing the SpriteSheets. <br />
I would like to concentrate on 2 tasks, 1 getting SpriteSheets to just <br />
work in wesnoth, and two, provide a script/tool/utility to allow easy <br />
converting from the old single images to the sheet (assuming certian <br />
naming conventions are followed).<br />
<br />
4.2) If you have invented your own project, please describe the project and the<br />
scope.<br />
<br />
N/A<br />
<br />
4.3) Why did you choose this project?<br />
<br />
I chosse it because I understand the concepts behind it, and felt it <br />
was a task that I could handle. It will also force me to learn and <br />
will provide immediate gains to all users when the version that <br />
includes the change is pushed out.<br />
<br />
4.4) Include an estimated timeline for your work on the project. Don't forget to<br />
mention special things like "I booked holidays between A and B" and "I got an<br />
exam at ABC and won't be doing much then".<br />
<br />
I'm still working out a timeline but I would most likely do a commit <br />
at least weekly. And break out the commits so that similar changes <br />
are only in that commit. Example, comment changes in one, (assuming <br />
no code changes), a converted set of sprites (aka the spritesheet) as <br />
one, and then code making use of it. After checking to make sure that <br />
the spritesheet works, removal of the converted individual sprite image <br />
files.<br />
<br />
4.5) Include as much technical detail about your implementation as you can<br />
<br />
At this point I think I would take 1 sprite (character) and create a <br />
spritesheet of it, and then test with that one. To allow testing I'd <br />
likely have it check for a spritesheet if it finds one it uses that, <br />
otherwise it uses the individual sprite images, in this way the game <br />
still works, until all the sprites have been turned into spritesheets.<br />
<br />
Once I have completed getting a character spritesheet to work, I'd <br />
then move on to the map sprites to spritesheets, again using the same <br />
methodology of check and if it finds a spritesheet use it otherwise, <br />
use the individual images. Though, on the grouping I'm not sure how <br />
I'd do that mordante and I'd have to discuss grouping, since a map can <br />
have any or all of the different tiles, and they are not chained like <br />
the unit/character sprites are, I'd have to group simliar tiles together.<br />
Like the water images, shorelines, docks, and water villages, as one.<br />
The feilds, human villages and castles in one. Swamp things together, <br />
and so on.<br />
<br />
4.6) What do you expect to gain from this project?<br />
<br />
Experience, learning to work on a team where most actually pull their <br />
own weight and the success of the project as a whole is not on my <br />
shoulders. This is too big a project for me to even think of that! <br />
and I'd not be able to, not in 3 months.<br />
<br />
4.7) What would make you stay in the Wesnoth community after the conclusion of<br />
SOC?<br />
<br />
Finding that the community is a non-hostile place to contribute, that <br />
individuals are treated with courtsey or the respect they have earned.<br />
That I'm encouraged to help other areas of the code, such as, "Aishi, <br />
the spritesheets work, do you think you could help with the transistion <br />
effects for the map?"<br />
<br />
<br />
5) Practical considerations<br />
<br />
5.1) Are you familiar with any of the following tools or languages?<br />
<br />
Git (used for all commits)<br />
I don't get it yet but I'm confident that I can get it.<br />
C++ (language used for all the normal source code)<br />
Its my favourite language and I'm comfortable using the language<br />
and looking up what I don't know and making it work. I'm also not<br />
afraid to ask, for help/documentation if I get stuck.<br />
STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
I've not, YET. Well I might, I never really looked into where a lib or <br />
function comes from when I use, I'll have to pay a bit more attention <br />
now. But they are no on my documentation read list, I'm confident<br />
that by the time coding begins that I'll be able to leverage them to <br />
obtain results, and be more effienent as I go. Even going back and <br />
making a section more effient if I realize that I over looked a better <br />
tool then I orginally used.<br />
Python (optional, mainly used for tools)<br />
I'm familiar enough to use it, follow it (assuming good coding <br />
conventions are followed).<br />
build environments (eg cmake/scons)<br />
I tend to use cmake and the gcc compiler, basically I use which ever <br />
build environment I have available and if its a new one I look up (via <br />
the man page or the internet) how to use it, and if the defaults <br />
settings don't work to add flags/options to get it to compile.<br />
WML (the wesnoth specific scenario language)<br />
Absolutely none before now, again on my read list<br />
Lua (used in combination with WML to create scenarios)<br />
None but I don't create senarios at this point, and if its only used <br />
in that context, it shouldn't have any barring on the project(s) I'm <br />
interested in doing at this point. <br />
<br />
5.2) Which tools do you normally use for development? Why do you use them?<br />
Kate, as its just what I'm used to, I like how it's mimaliztic and <br />
non-intrutsive.<br />
Visual Studio for my C# class because that is what they have to work <br />
in when I turn it in.<br />
<br />
5.3) What programming languages are you fluent in?<br />
I'm not sure what you mean by fluent, if you mean know every builtin <br />
function and every conseviable combination of calls, I doubt very many <br />
could claim to be fluent. However if you mean, comfortable, and able <br />
to figure out things you don't knoe, either by looking it up or by <br />
context then C (and its children, C++, C#, Arduino) python, and PHP. <br />
After being fluent in English doesn't mean you know every word or <br />
special rule for the language.<br />
<br />
5.4) Would you mind talking with your mentor on telephone / internet phone? We<br />
would like to have a backup way for communications for the case that somehow<br />
emails and IRC do fail. If you are willing to do so, please do list a phone<br />
number (including international code) so that we are able to contact you. You<br />
should probably *only* add this number in the application for you submit to<br />
google since the info in the wiki is available in public. We will *not* make any<br />
use of your number unless some case of "there is no way to contact you" does<br />
arise!<br />
<br />
<br />
I wouldn't mind and in some cases prefer it. I'm not the most observant <br />
when it comes to my email, I usually just get notices and spam that can <br />
be ignored (high noise to signal ratio in my mailbox at the moment). <br />
Though when expecting something I check it more often at least once a <br />
day if not more.<br />
<br />
**************Comments and Suggestions**************<br />
Please place them after this line, all are appreciated and if I can't thank you <br />
personally (IE you don't attach your name to it, Thank you.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=53306SpriteSheetApplicationSAB2014-02-28T21:41:15Z<p>Aishiko: </p>
<hr />
<div>Posted 28 Feb 2014<br />
1) Basics<br />
<br />
1.1) Write a small introduction to yourself.<br />
<br />
1.2) State your preferred email address.<br />
<br />
1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?<br />
<br />
1.4) Why do you want to participate in summer of code?<br />
<br />
I'd like to participate in the summer of code for several reasons, and <br />
yes money is one of them. but experience is the biggest one.<br />
<br />
1.5) What are you studying, subject, level and school?<br />
<br />
I am currently studying computer science (read programming) and networking <br />
technology. I am a Softmore in both, I am a current student at Sandhills <br />
Community College.<br />
<br />
1.6) What country are you from, at what time are you most likely to be able to<br />
join IRC?<br />
<br />
I currently live on the east coast of the US and can be in IRC pretty <br />
much all day, either at home or school, though if at school there will <br />
be a delay if in class and not lab.<br />
<br />
1.7) Do you have other commitments for the summer period ? Do you plan to take<br />
any vacations ? If yes, when.<br />
<br />
I have no current commitments that would impact my ability to give GSOC <br />
40 hours a week of work and attention. But if an emergency comes up <br />
I'll find a way to make up the hours.<br />
<br />
2) Experience<br />
<br />
2.1) What programs/software have you worked on before?<br />
<br />
Mostly personal projects and class projects, in C, C++, C#, PHP, Python, <br />
& the Arduino. One of C++ classes was using DarkGTK (yes I know its <br />
windows only) but we used SpriteSheets, sprite collision, and mouse interaction.<br />
<br />
2.2) Have you developed software in a team environment before? (As opposed to<br />
hacking on something on your own)<br />
<br />
I have in a class environment, but I'm usually the only one left doing <br />
the heavy lifting of coding. Though next year I'll be doing the <br />
programming capstone class where the class of 1-20 students work <br />
together to produce a program for a client, either for the college or <br />
for a community member/business. I'm both looking forward to and <br />
dreading working on a team, wondering if I'll be able to fit in and <br />
create code that is easy to maintain and follow.<br />
<br />
2.3) Have you participated to the Google Summer of Code before? As a mentor or a<br />
student? In what project? Were you successful? If not, why?<br />
<br />
I applied last year, however, I wasn't choosen mostly because I lack <br />
good writing skills for technical documents. At least that is what I <br />
was told.<br />
<br />
2.4) Are you already involved with any open source development projects? If yes,<br />
please describe the project and the scope of your involvement.<br />
<br />
None, I have submitted patches to the linux kernel but, I never <br />
bothered to see if they made it in.<br />
<br />
2.5) Gaming experience - Are you a gamer?<br />
<br />
Sometimes, depends on my mood.<br />
<br />
2.5.1) What type of gamer are you?<br />
<br />
Casual.<br />
<br />
2.5.2) What type of games?<br />
<br />
2.5.3) What type of opponents do you prefer?<br />
<br />
AI oppenents, I'm not really into the whole competetive thing.<br />
<br />
2.5.4) Are you more interested in story or gameplay?<br />
<br />
I think BOTH have to be there for a successful game. <br />
Though to be honest I'm better at critecing story then gameplay.<br />
<br />
2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether<br />
you lean towards single player or multiplayer.<br />
<br />
We do not plan to favor Wesnoth players as such, but some particular projects<br />
require a good feeling for the game which is hard to get without having played<br />
intensively.<br />
<br />
I've played Wesnoth for a year or 2, and I play exclusively single player.<br />
<br />
2.6) If you have contributed any patches to Wesnoth, please list them below. You<br />
can also list patches that have been submitted but not committed yet and patches<br />
that have not been specifically written for GSoC. If you have gained commit<br />
access to our repository (during the evaluation period or earlier) please state<br />
so.<br />
<br />
<br />
3) Communication skills<br />
<br />
3.1) Though most of our developers are not native English speakers, English is<br />
the project's working language. Describe your fluency level in written English.<br />
<br />
3.2) What spoken languages are you fluent in?<br />
<br />
English, I can understand a smattering of other languages but not enough <br />
to do anything deep or programming specific.<br />
<br />
3.3) Are you good at interacting with other players? Our developer community is<br />
friendly, but the player community can be a bit rough.<br />
<br />
3.4) Do you give constructive advice?<br />
<br />
I've been told I do on occasion.<br />
<br />
3.5) Do you receive advice well?<br />
<br />
I do if its construtive and not attacking. If its yelling, screaming, <br />
and insults as well, not so much. How its given usually impacts how well<br />
I receive it.<br />
<br />
3.6) Are you good at sorting useful criticisms from useless ones?<br />
<br />
Given enough time yes, but the painfully obvious ones I usually see <br />
right away.<br />
<br />
3.7) How autonomous are you when developing ? Would you rather discuss<br />
intensively changes and not start coding until you know what you want to do or<br />
would you rather code a proof of concept to "see how it turn out", taking the<br />
risk of having it thrown away if it doesn't match what the project want<br />
<br />
I'm usually fairly autonomous, once the design has been decided, and <br />
if it doesn't work and needs a change I sometimes seek councel on what <br />
way I should go, but sometimes just go ahead and make the change.<br />
Examples:<br />
1) The flow needs changing as it doesn't work right, usually I'll seek<br />
help figuring it how to change the flow so it does work.<br />
2) An array isn't giving the flexablity needed for a function but a <br />
list will, I implement the list instead. And inform whomever needs to <br />
know that I have done that change.<br />
<br />
4) Project<br />
<br />
4.1) Did you select a project from our list? If that is the case, what project<br />
did you select? What do you want to especially concentrate on?<br />
<br />
I selected one from the list, the implementing the SpriteSheets. <br />
I would like to concentrate on 2 tasks, 1 getting SpriteSheets to just <br />
work in wesnoth, and two, provide a script/tool/utility to allow easy <br />
converting from the old single images to the sheet (assuming certian <br />
naming conventions are followed).<br />
<br />
4.2) If you have invented your own project, please describe the project and the<br />
scope.<br />
<br />
N/A<br />
<br />
4.3) Why did you choose this project?<br />
<br />
I chosse it because I understand the concepts behind it, and felt it <br />
was a task that I could handle. It will also force me to learn and <br />
will provide immediate gains to all users when the version that <br />
includes the change is pushed out.<br />
<br />
4.4) Include an estimated timeline for your work on the project. Don't forget to<br />
mention special things like "I booked holidays between A and B" and "I got an<br />
exam at ABC and won't be doing much then".<br />
<br />
I'm still working out a timeline but I would most likely do a commit <br />
at least weekly. And break out the commits so that similar changes <br />
are only in that commit. Example, comment changes in one, (assuming <br />
no code changes), a converted set of sprites (aka the spritesheet) as <br />
one, and then code making use of it. After checking to make sure that <br />
the spritesheet works, removal of the converted individual sprite image <br />
files.<br />
<br />
4.5) Include as much technical detail about your implementation as you can<br />
<br />
At this point I think I would take 1 sprite (character) and create a <br />
spritesheet of it, and then test with that one. To allow testing I'd <br />
likely have it check for a spritesheet if it finds one it uses that, <br />
otherwise it uses the individual sprite images, in this way the game <br />
still works, until all the sprites have been turned into spritesheets.<br />
<br />
Once I have completed getting a character spritesheet to work, I'd <br />
then move on to the map sprites to spritesheets, again using the same <br />
methodology of check and if it finds a spritesheet use it otherwise, <br />
use the individual images. Though, on the grouping I'm not sure how <br />
I'd do that mordante and I'd have to discuss grouping, since a map can <br />
have any or all of the different tiles, and they are not chained like <br />
the unit/character sprites are, I'd have to group simliar tiles together.<br />
Like the water images, shorelines, docks, and water villages, as one.<br />
The feilds, human villages and castles in one. Swamp things together, <br />
and so on.<br />
<br />
4.6) What do you expect to gain from this project?<br />
<br />
Experience, learning to work on a team where most actually pull their <br />
own weight and the success of the project as a whole is not on my <br />
shoulders. This is too big a project for me to even think of that! <br />
and I'd not be able to, not in 3 months.<br />
<br />
4.7) What would make you stay in the Wesnoth community after the conclusion of<br />
SOC?<br />
<br />
Finding that the community is a non-hostile place to contribute, that <br />
individuals are treated with courtsey or the respect they have earned.<br />
That I'm encouraged to help other areas of the code, such as, "Aishi, <br />
the spritesheets work, do you think you could help with the transistion <br />
effects for the map?"<br />
<br />
<br />
5) Practical considerations<br />
<br />
5.1) Are you familiar with any of the following tools or languages?<br />
<br />
Git (used for all commits)<br />
I don't get it yet but I'm confident that I can get it.<br />
C++ (language used for all the normal source code)<br />
Its my favourite language and I'm comfortable using the language<br />
and looking up what I don't know and making it work. I'm also not<br />
afraid to ask, for help/documentation if I get stuck.<br />
STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
I've not, YET. Well I might, I never really looked into where a lib or <br />
function comes from when I use, I'll have to pay a bit more attention <br />
now. But they are no on my documentation read list, I'm confident<br />
that by the time coding begins that I'll be able to leverage them to <br />
obtain results, and be more effienent as I go. Even going back and <br />
making a section more effient if I realize that I over looked a better <br />
tool then I orginally used.<br />
Python (optional, mainly used for tools)<br />
I'm familiar enough to use it, follow it (assuming good coding <br />
conventions are followed).<br />
build environments (eg cmake/scons)<br />
I tend to use cmake and the gcc compiler, basically I use which ever <br />
build environment I have available and if its a new one I look up (via <br />
the man page or the internet) how to use it, and if the defaults <br />
settings don't work to add flags/options to get it to compile.<br />
WML (the wesnoth specific scenario language)<br />
Absolutely none before now, again on my read list<br />
Lua (used in combination with WML to create scenarios)<br />
None but I don't create senarios at this point, and if its only used <br />
in that context, it shouldn't have any barring on the project(s) I'm <br />
interested in doing at this point. <br />
<br />
5.2) Which tools do you normally use for development? Why do you use them?<br />
Kate, as its just what I'm used to, I like how it's mimaliztic and <br />
non-intrutsive.<br />
Visual Studio for my C# class because that is what they have to work <br />
in when I turn it in.<br />
<br />
5.3) What programming languages are you fluent in?<br />
I'm not sure what you mean by fluent, if you mean know every builtin <br />
function and every conseviable combination of calls, I doubt very many <br />
could claim to be fluent. However if you mean, comfortable, and able <br />
to figure out things you don't knoe, either by looking it up or by <br />
context then C (and its children, C++, C#, Arduino) python, and PHP. <br />
After being fluent in English doesn't mean you know every word or <br />
special rule for the language.<br />
<br />
5.4) Would you mind talking with your mentor on telephone / internet phone? We<br />
would like to have a backup way for communications for the case that somehow<br />
emails and IRC do fail. If you are willing to do so, please do list a phone<br />
number (including international code) so that we are able to contact you. You<br />
should probably *only* add this number in the application for you submit to<br />
google since the info in the wiki is available in public. We will *not* make any<br />
use of your number unless some case of "there is no way to contact you" does<br />
arise!<br />
I wouldn't mind and in some cases prefer it. I'm not the most observant <br />
when it comes to my email, I usually just get notices and spam that can <br />
be ignored (high noise to signal ratio in my mailbox at the moment). <br />
Though when expecting something I check it more often at least once a <br />
day if not more.<br />
<br />
Comments and Suggestions Please place them after this line, Thank you.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SoC_Ideas_SpriteSheets2014&diff=53305SoC Ideas SpriteSheets20142014-02-28T21:38:15Z<p>Aishiko: /* SpriteSheet */</p>
<hr />
<div>{{SoC2014Idea}}<br />
<br />
==Description==<br />
===SpriteSheet===<br />
Page for the idea: [[SoC_Ideas_SpriteSheets2014]]<br />
<br />
Wesnoth uses thousands of images, each of them stored in separate files.<br />
It would be more efficient to store multiple images in a single file. In order<br />
to make that possible, the Wesnoth engine needs to be adapted to allow this change.<br />
<br />
{{#dpl:<br />
|resultsheader=''There are %PAGES% submitted student proposals for this idea''<br />
|oneresultheader=''There is 1 submitted student proposal for this idea''<br />
|suppresserrors=true<br />
|noresultsheader=''There are no submitted student proposals for this idea''<br />
|category=Summer of Code 2014 Student Page&SoC Ideas IDEA NAME<br />
|notcategory=SoC 2014 Not Submitted To Google<br />
|include=#Description<br />
|nottitlematch=SoC2014_Template_of_Student_page<br />
|mode=userformat<br />
|format=,,<br/>See [[%PAGE%|%TITLE%]] for more information.<br/><br/>,<br />
}}<br />
<br />
Student Proposal http://wiki.wesnoth.org/SpriteSheetApplicationSAB 2014/02/28<br />
<br />
==Additional Information==<br />
<br />
Currently, all the Wesnoth unit animations are based on thousands of small png<br />
images, each image representing the unit in a single pose. For terrains the<br />
situation is the same, it has a base image with a lot of transitions to other<br />
terrains, which are now stored as seperate images.<br />
<br />
In a sprite sheet approach, each unit is represented by a single, huge, image<br />
where all the unit images are put on a mosaïc pattern and the game knows where<br />
to look for a given image.<br />
<br />
The advantage of having a large image with all positions is that it's more<br />
efficient in memory. Also one large file is more effecient on the harddisk and<br />
faster to load than a lot of smaller files. So the change to spritesheets will<br />
have a lot of advantages. Also several Wesnoth artists prefer using sprite<br />
sheets over multiple single images.<br />
<br />
This project involves changing the Wesnoth Markup Language (WML)* definition<br />
for images to specify a sub image in a sprite sheet and change the image loading<br />
code of the engine. Creating tools to transform existing images to a sprite sheet<br />
can be an optional objective.<br />
<br />
Regarding the implementation the student is free to come up with his/her own<br />
solution and discuss that with the developers during the application period.<br />
<br />
*) WML is a XML like language, used to describe the data/content of Wesnoth.<br />
<br />
==Whom to ask about this==<br />
<br />
mordante on IRC.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=SpriteSheetApplicationSAB&diff=53304SpriteSheetApplicationSAB2014-02-28T21:35:05Z<p>Aishiko: Created page with " 1) Basics 1.1) Write a small introduction to yourself. 1.2) State your preferred email address. 1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it? 1.4..."</p>
<hr />
<div><br />
1) Basics<br />
<br />
1.1) Write a small introduction to yourself.<br />
<br />
1.2) State your preferred email address.<br />
<br />
1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?<br />
<br />
1.4) Why do you want to participate in summer of code?<br />
<br />
I'd like to participate in the summer of code for several reasons, and <br />
yes money is one of them. but experience is the biggest one.<br />
<br />
1.5) What are you studying, subject, level and school?<br />
<br />
I am currently studying computer science (read programming) and networking <br />
technology. I am a Softmore in both, I am a current student at Sandhills <br />
Community College.<br />
<br />
1.6) What country are you from, at what time are you most likely to be able to<br />
join IRC?<br />
<br />
I currently live on the east coast of the US and can be in IRC pretty <br />
much all day, either at home or school, though if at school there will <br />
be a delay if in class and not lab.<br />
<br />
1.7) Do you have other commitments for the summer period ? Do you plan to take<br />
any vacations ? If yes, when.<br />
<br />
I have no current commitments that would impact my ability to give GSOC <br />
40 hours a week of work and attention. But if an emergency comes up <br />
I'll find a way to make up the hours.<br />
<br />
2) Experience<br />
<br />
2.1) What programs/software have you worked on before?<br />
<br />
Mostly personal projects and class projects, in C, C++, C#, PHP, Python, <br />
& the Arduino. One of C++ classes was using DarkGTK (yes I know its <br />
windows only) but we used SpriteSheets, sprite collision, and mouse interaction.<br />
<br />
2.2) Have you developed software in a team environment before? (As opposed to<br />
hacking on something on your own)<br />
<br />
I have in a class environment, but I'm usually the only one left doing <br />
the heavy lifting of coding. Though next year I'll be doing the <br />
programming capstone class where the class of 1-20 students work <br />
together to produce a program for a client, either for the college or <br />
for a community member/business. I'm both looking forward to and <br />
dreading working on a team, wondering if I'll be able to fit in and <br />
create code that is easy to maintain and follow.<br />
<br />
2.3) Have you participated to the Google Summer of Code before? As a mentor or a<br />
student? In what project? Were you successful? If not, why?<br />
<br />
I applied last year, however, I wasn't choosen mostly because I lack <br />
good writing skills for technical documents. At least that is what I <br />
was told.<br />
<br />
2.4) Are you already involved with any open source development projects? If yes,<br />
please describe the project and the scope of your involvement.<br />
<br />
None, I have submitted patches to the linux kernel but, I never <br />
bothered to see if they made it in.<br />
<br />
2.5) Gaming experience - Are you a gamer?<br />
<br />
Sometimes, depends on my mood.<br />
<br />
2.5.1) What type of gamer are you?<br />
<br />
Casual.<br />
<br />
2.5.2) What type of games?<br />
<br />
2.5.3) What type of opponents do you prefer?<br />
<br />
AI oppenents, I'm not really into the whole competetive thing.<br />
<br />
2.5.4) Are you more interested in story or gameplay?<br />
<br />
I think BOTH have to be there for a successful game. <br />
Though to be honest I'm better at critecing story then gameplay.<br />
<br />
2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether<br />
you lean towards single player or multiplayer.<br />
<br />
We do not plan to favor Wesnoth players as such, but some particular projects<br />
require a good feeling for the game which is hard to get without having played<br />
intensively.<br />
<br />
I've played Wesnoth for a year or 2, and I play exclusively single player.<br />
<br />
2.6) If you have contributed any patches to Wesnoth, please list them below. You<br />
can also list patches that have been submitted but not committed yet and patches<br />
that have not been specifically written for GSoC. If you have gained commit<br />
access to our repository (during the evaluation period or earlier) please state<br />
so.<br />
<br />
<br />
3) Communication skills<br />
<br />
3.1) Though most of our developers are not native English speakers, English is<br />
the project's working language. Describe your fluency level in written English.<br />
<br />
3.2) What spoken languages are you fluent in?<br />
<br />
English, I can understand a smattering of other languages but not enough <br />
to do anything deep or programming specific.<br />
<br />
3.3) Are you good at interacting with other players? Our developer community is<br />
friendly, but the player community can be a bit rough.<br />
<br />
3.4) Do you give constructive advice?<br />
<br />
I've been told I do on occasion.<br />
<br />
3.5) Do you receive advice well?<br />
<br />
I do if its construtive and not attacking. If its yelling, screaming, <br />
and insults as well, not so much. How its given usually impacts how well<br />
I receive it.<br />
<br />
3.6) Are you good at sorting useful criticisms from useless ones?<br />
<br />
Given enough time yes, but the painfully obvious ones I usually see <br />
right away.<br />
<br />
3.7) How autonomous are you when developing ? Would you rather discuss<br />
intensively changes and not start coding until you know what you want to do or<br />
would you rather code a proof of concept to "see how it turn out", taking the<br />
risk of having it thrown away if it doesn't match what the project want<br />
<br />
I'm usually fairly autonomous, once the design has been decided, and <br />
if it doesn't work and needs a change I sometimes seek councel on what <br />
way I should go, but sometimes just go ahead and make the change.<br />
Examples:<br />
1) The flow needs changing as it doesn't work right, usually I'll seek<br />
help figuring it how to change the flow so it does work.<br />
2) An array isn't giving the flexablity needed for a function but a <br />
list will, I implement the list instead. And inform whomever needs to <br />
know that I have done that change.<br />
<br />
4) Project<br />
<br />
4.1) Did you select a project from our list? If that is the case, what project<br />
did you select? What do you want to especially concentrate on?<br />
<br />
I selected one from the list, the implementing the SpriteSheets. <br />
I would like to concentrate on 2 tasks, 1 getting SpriteSheets to just <br />
work in wesnoth, and two, provide a script/tool/utility to allow easy <br />
converting from the old single images to the sheet (assuming certian <br />
naming conventions are followed).<br />
<br />
4.2) If you have invented your own project, please describe the project and the<br />
scope.<br />
<br />
N/A<br />
<br />
4.3) Why did you choose this project?<br />
<br />
I chosse it because I understand the concepts behind it, and felt it <br />
was a task that I could handle. It will also force me to learn and <br />
will provide immediate gains to all users when the version that <br />
includes the change is pushed out.<br />
<br />
4.4) Include an estimated timeline for your work on the project. Don't forget to<br />
mention special things like "I booked holidays between A and B" and "I got an<br />
exam at ABC and won't be doing much then".<br />
<br />
I'm still working out a timeline but I would most likely do a commit <br />
at least weekly. And break out the commits so that similar changes <br />
are only in that commit. Example, comment changes in one, (assuming <br />
no code changes), a converted set of sprites (aka the spritesheet) as <br />
one, and then code making use of it. After checking to make sure that <br />
the spritesheet works, removal of the converted individual sprite image <br />
files.<br />
<br />
4.5) Include as much technical detail about your implementation as you can<br />
<br />
At this point I think I would take 1 sprite (character) and create a <br />
spritesheet of it, and then test with that one. To allow testing I'd <br />
likely have it check for a spritesheet if it finds one it uses that, <br />
otherwise it uses the individual sprite images, in this way the game <br />
still works, until all the sprites have been turned into spritesheets.<br />
<br />
Once I have completed getting a character spritesheet to work, I'd <br />
then move on to the map sprites to spritesheets, again using the same <br />
methodology of check and if it finds a spritesheet use it otherwise, <br />
use the individual images. Though, on the grouping I'm not sure how <br />
I'd do that mordante and I'd have to discuss grouping, since a map can <br />
have any or all of the different tiles, and they are not chained like <br />
the unit/character sprites are, I'd have to group simliar tiles together.<br />
Like the water images, shorelines, docks, and water villages, as one.<br />
The feilds, human villages and castles in one. Swamp things together, <br />
and so on.<br />
<br />
4.6) What do you expect to gain from this project?<br />
<br />
Experience, learning to work on a team where most actually pull their <br />
own weight and the success of the project as a whole is not on my <br />
shoulders. This is too big a project for me to even think of that! <br />
and I'd not be able to, not in 3 months.<br />
<br />
4.7) What would make you stay in the Wesnoth community after the conclusion of<br />
SOC?<br />
<br />
Finding that the community is a non-hostile place to contribute, that <br />
individuals are treated with courtsey or the respect they have earned.<br />
That I'm encouraged to help other areas of the code, such as, "Aishi, <br />
the spritesheets work, do you think you could help with the transistion <br />
effects for the map?"<br />
<br />
<br />
5) Practical considerations<br />
<br />
5.1) Are you familiar with any of the following tools or languages?<br />
<br />
Git (used for all commits)<br />
Enough to realize I don't like it and find it hard to use, but<br />
if I can get some help working out how to do it a few times<br />
I'm confident that I can get it.<br />
C++ (language used for all the normal source code)<br />
Its my favourite language and I'm comfortable using the language<br />
and looking up what I don't know and making it work. I'm also not<br />
afraid to ask, for help/documentation if I get stuck.<br />
STL, Boost, Sdl (C++ libraries used by Wesnoth)<br />
I've not, YET. Well I might, I never really looked into where a lib or <br />
function comes from when I use, I'll have to pay a bit more attention <br />
now. But they are no on my documentation read list, I'm confident<br />
that by the time coding begins that I'll be able to leverage them to <br />
obtain results, and be more effienent as I go. Even going back and <br />
making a section more effient if I realize that I over looked a better <br />
tool then I orginally used.<br />
Python (optional, mainly used for tools)<br />
I'm familiar enough to use it, follow it (assuming good coding <br />
conventions are followed).<br />
build environments (eg cmake/scons)<br />
I tend to use cmake and the gcc compiler, basically I use which ever <br />
build environment I have available and if its a new one I look up (via <br />
the man page or the internet) how to use it, and if the defaults <br />
settings don't work to add flags/options to get it to compile.<br />
WML (the wesnoth specific scenario language)<br />
Absolutely none before now, again on my read list<br />
Lua (used in combination with WML to create scenarios)<br />
None but I don't create senarios at this point, and if its only used <br />
in that context, it shouldn't have any barring on the project(s) I'm <br />
interested in doing at this point. <br />
<br />
5.2) Which tools do you normally use for development? Why do you use them?<br />
Kate, as its just what I'm used to, I like how it's mimaliztic and <br />
non-intrutsive.<br />
Visual Studio for my C# class because that is what they have to work <br />
in when I turn it in.<br />
<br />
5.3) What programming languages are you fluent in?<br />
I'm not sure what you mean by fluent, if you mean know every builtin <br />
function and every conseviable combination of calls, I doubt very many <br />
could claim to be fluent. However if you mean, comfortable, and able <br />
to figure out things you don't knoe, either by looking it up or by <br />
context then C (and its children, C++, C#, Arduino) python, and PHP. <br />
After being fluent in English doesn't mean you know every word or <br />
special rule for the language.<br />
<br />
5.4) Would you mind talking with your mentor on telephone / internet phone? We<br />
would like to have a backup way for communications for the case that somehow<br />
emails and IRC do fail. If you are willing to do so, please do list a phone<br />
number (including international code) so that we are able to contact you. You<br />
should probably *only* add this number in the application for you submit to<br />
google since the info in the wiki is available in public. We will *not* make any<br />
use of your number unless some case of "there is no way to contact you" does<br />
arise!<br />
I wouldn't mind and in some cases prefer it. I'm not the most observant <br />
when it comes to my email, I usually just get notices and spam that can <br />
be ignored (high noise to signal ratio in my mailbox at the moment). <br />
Though when expecting something I check it more often at least once a <br />
day if not more.<br />
<br />
Comments and Suggestions Please place them after this line, Thank you.</div>Aishikohttps://wiki.wesnoth.org/index.php?title=EasyCoding&diff=53303EasyCoding2014-02-28T21:32:32Z<p>Aishiko: /* More powerful village naming */</p>
<hr />
<div>== Foreword ==<br />
<br />
'''We are permanently updating this page. Parts marked by <s>strikeout</s> will likely be deleted shortly.<br />
<br />
This page is here to document easy to do coding tasks. It is not here to double the feature request database, and should only be filled by people that know the code well enough to judge the difficulty of a given task. <br />
<br />
If you are such a person, you should feel free to edit this page.<br />
<br />
If you're not, you should post a feature request and discuss your idea on the forum or IRC. A coder with better knowledge of the code might give you the green light to add your feature here.<br />
<br />
Anybody should feel free to add "clues" to any tasks, that is entry points, traps to avoid, person to contact to discuss and so on.<br />
<br />
If you plan to work on a feature, write your name at the bottom of the feature, with the date. Note that if you are too long at working on a feature I'll "free" it back (that is if you're not working on it. If you have problems implementing it, just tell us....)<br />
<br />
--[[User:Boucman|Boucman]]<br />
<br />
<br />
If none of these are to your liking, feel free to check our [http://gna.org/bugs/?group=wesnoth bug tracker] with a broad spectrum of tasks.<br />
<br />
== MP related features ==<br />
<br />
=== Add possibility to switch off dependency checking ===<br />
MP add-ons can define dependencies. Currently there's no way to force a "broken" configuration, although overzealous use of the system by UMC authors could make this feature useful. Add an option to the MP game creation screen to switch on/off dependency checking. Ask lipk (forum)/lipkab (IRC).<br />
<br />
== WML related features ==<br />
<br />
=== Side-specific results ===<br />
Giving result=defeat or result=victory for specific sides. ([http://gna.org/bugs/index.php?4960 FR #4960]) -- [[User:dlr365|dlr365]] -- patch submitted [https://gna.org/bugs/index.php?4960]<br />
<br />
--[[User:Boucman|Boucman]] 08:58, 28 February 2010 (UTC) Patch seems abandonned, but can be used for further work feel free to take over the FR<br />
<br />
=== Support for leaderless multiplayergames ===<br />
Add support for the WML key victory_when_enemies_defeated= in the scenario tag during multiplayergames. ([https://gna.org/bugs/index.php?8106 FR #8106])<br />
<br />
=== Support variable recall cost in wml ===<br />
see https://gna.org/bugs/?16538<br />
<br />
the syntax needs to be discussed and refined, but the overall idea is good<br />
<br />
make sure to update whiteboard to handle this correctly<br />
<br />
Ask Boucman<br />
<br />
=== Other Ideas ===<br />
See [[FutureWML]]; some ideas there are easier than others.<br />
<br />
== Improvements to AI ==<br />
<br />
Note: not all of these might be simple tasks. Talk to Crab or mattsc.<br />
<br />
* Add option to take avoided hexes into account in wesnoth.find_path()<br />
<br />
* Make the (old) simple aspect syntax work when the Lua engine is defined for a side. Setting aspects in the [side] tag like this:<br />
[ai]<br />
aggression=0.123<br />
[/ai]<br />
does not work if the Lua engine is defined. You either need to use the [aspect] tag in the [side] tag with 'engine=lua', or use the code above in a [modify_side] tag in an event. Making the above syntax available (as it is with the c++ engine) would be nice. The same also applies to the FAI engine and to aspects set for AI sides in MP games.<br />
<br />
* Add a Lua function ai.get_individual_attacks() that returns all the single attacks the side can do (as opposed to attack combinations). This needs to include an option to recalculate and take the current situation on the map into account (making the function believe that the game state has changed).<br />
<br />
* Set up an option the allows us to exclude units from the move-to-targets phase similar to [filter_own] for the combat phase (other than setting ai_special=guardian, which has a number of other side effects). Actually, having this option for all CA's would be nice.<br />
<br />
* Change the aspects "passive_leader", "passive_leader_shares_keep", "leader_ignores_keep" to work with multiple leaders. The idea is to change the type of those aspects from yes/no to string so both "passive_leader=yes" and "passive_leader=leader_id_1,leader_id_2" is possible.<br />
<br />
* ai.get_new_enemy_dst_src and related functions have several problems:<br />
** They use the current moves of the enemy units, which generally are all zero.<br />
** Hexes occupied by other enemy units count as not reachable.<br />
**Units with zero moves are not listed at all, not even for the hex they are on.<br />
**Working around this with a Lua wrapper makes this actually slower than ai_helper.get_enemy_dst_src, which makes the functions pretty much useless, as speed is the only thing speaking for them.<br />
<br />
* Clean up Micro AI candidate actions code. The Micro AIs were developed over quite a long period while we were trying to figure out how all of this works (and in part also by students participating in the Google Code-in project). As a result, the code in some of them is quite inconsistent, not cleaned up, uncommented (or wrongly commented), etc. '''Important notes:'''<br />
**This is not meant as a single task, but rather as a series of tasks, involving individual MAIs or sets of related MAIs. Please do not submit a pull request in which the code of all MAIs has been modified. <br />
**The Micro AIs are still being worked on pretty constantly, so if you are planning to work on this task, please let mattsc know (either on IRC or via forum PM), so that we can avoid conflicts as much as possible.<br />
<br />
* Add new options (keys or tags) to the Micro AIs. As an example, some (but certainly not all) Micro AIs might benefit from taking some (but certainly not all) of the default AI aspects into account.<br />
<br />
* Write a script that automatically changes WML from the deprecated [ai][target] to the new [ai][goal] syntax. Ideally, this would be part of wmllint.<br />
** There are [http://wiki.wesnoth.org/AiWML#Deprecated_AI_Targeting_Aspects more deprecated AI aspect] which should eventually be added to this, but the [target] -> [goal] change would be a good and important start.<br />
<br />
== GUI related features ==<br />
<br />
Although Mordante developed the new GUI system GUI2, some dialogs still use the older GUI1 and could be improved or transferred. You should contact Mordante on IRC before starting to work on these.<br />
<br />
=== Theme Changes ===<br />
<br />
* hide the hourglass item from the statusbar when there is no timer<br />
<br />
=== Widget Changes ===<br />
* make games sortable in the lobby (open slots, total number of players, era, XP modifier, gold per village, fog/shroud)<br>a GUI2 lobby is currently being developed, ask mordante whether this is still relevant<br />
* input history (chat, commands, ..)<br />
<br />
== GUI2 related features ==<br />
GUI2 is the new gui engine Mordante/SkeletonCrew is working on. <br />
* Information on the wiki can be found here http://www.wesnoth.org/wiki/GUIToolkit<br />
* The source code is under src/gui/<br />
* The configuration config files are under data/gui/default<br />
<br />
Some tasks need the --new-widgets since the code is only shown in the experimental mode. Tasks which need this switch have the * in the title.<br />
<br />
=== Port the random map generator dialog to GUI2 ===<br />
The map generator currently doesn't use the GUI2 framework, but there's no reason why it couldn't. Ask lipk (forum)/lipkab (IRC).<br />
<br />
== Miscellaneous ==<br />
<br />
=== More powerful village naming ===<br />
'''Adding mountain names and other features to village names, having a second random name in village names'''<br />
<br />
Currently the village naming engine has a very good structure that could allow more powerful names to be generated. <br />
Understanding how it works should be quite easy, and a few useful improvements could be added.<br />
<br />
* Currently villages can use lake names and river names, this should be extended to other features like bridges, swamps, mountains etc...<br />
* It would be nice to have a separate list of "first syllabus" and "last syllabus" for naming. That's not really needed in English, but some translations could use it<br />
* Again, it is common to have villages with more than one "random" word in them. having a $name2 variable would be nice<br />
<br />
Turns out this was already done, and should be removed.<br />
<br />
=== Debug Mode ===<br />
* New debug command functionality (setting additional status.variables, possibly terrain)<br />
<br />
=== wesnoth-optipng ===<br />
For lossless png compression we use wesnoth-optipng, a script using an external toolchain (ImageMagick, OptiPNG, Advdef). Perhaps the performance could be improved by using PNGOut instead of advdef. This task includes<br />
* a quick profiling of compression ratio and decompression speed for both tools<br />
* if it provides a higher compression while not significantly slowing down decompression, adapt wesnoth-optipng to use PNGOut<br />
<br />
== Bugs ==<br />
<br />
<br />
<br />
== See Also ==<br />
<br />
[[NotSoEasyCoding]]<br />
<br />
[[Category:Development]]<br />
[[Category:Future]]</div>Aishikohttps://wiki.wesnoth.org/index.php?title=EasyCoding&diff=53292EasyCoding2014-02-27T16:40:58Z<p>Aishiko: /* More powerful village naming */</p>
<hr />
<div>== Foreword ==<br />
<br />
'''We are permanently updating this page. Parts marked by <s>strikeout</s> will likely be deleted shortly.<br />
<br />
This page is here to document easy to do coding tasks. It is not here to double the feature request database, and should only be filled by people that know the code well enough to judge the difficulty of a given task. <br />
<br />
If you are such a person, you should feel free to edit this page.<br />
<br />
If you're not, you should post a feature request and discuss your idea on the forum or IRC. A coder with better knowledge of the code might give you the green light to add your feature here.<br />
<br />
Anybody should feel free to add "clues" to any tasks, that is entry points, traps to avoid, person to contact to discuss and so on.<br />
<br />
If you plan to work on a feature, write your name at the bottom of the feature, with the date. Note that if you are too long at working on a feature I'll "free" it back (that is if you're not working on it. If you have problems implementing it, just tell us....)<br />
<br />
--[[User:Boucman|Boucman]]<br />
<br />
<br />
If none of these are to your liking, feel free to check our [http://gna.org/bugs/?group=wesnoth bug tracker] with a broad spectrum of tasks.<br />
<br />
== MP related features ==<br />
<br />
=== Add possibility to switch off dependency checking ===<br />
MP add-ons can define dependencies. Currently there's no way to force a "broken" configuration, although overzealous use of the system by UMC authors could make this feature useful. Add an option to the MP game creation screen to switch on/off dependency checking. Ask lipk (forum)/lipkab (IRC).<br />
<br />
== WML related features ==<br />
<br />
=== Side-specific results ===<br />
Giving result=defeat or result=victory for specific sides. ([http://gna.org/bugs/index.php?4960 FR #4960]) -- [[User:dlr365|dlr365]] -- patch submitted [https://gna.org/bugs/index.php?4960]<br />
<br />
--[[User:Boucman|Boucman]] 08:58, 28 February 2010 (UTC) Patch seems abandonned, but can be used for further work feel free to take over the FR<br />
<br />
=== Support for leaderless multiplayergames ===<br />
Add support for the WML key victory_when_enemies_defeated= in the scenario tag during multiplayergames. ([https://gna.org/bugs/index.php?8106 FR #8106])<br />
<br />
=== Support variable recall cost in wml ===<br />
see https://gna.org/bugs/?16538<br />
<br />
the syntax needs to be discussed and refined, but the overall idea is good<br />
<br />
make sure to update whiteboard to handle this correctly<br />
<br />
Ask Boucman<br />
<br />
=== Other Ideas ===<br />
See [[FutureWML]]; some ideas there are easier than others.<br />
<br />
== Improvements to AI ==<br />
<br />
Note: not all of these might be simple tasks. Talk to Crab or mattsc.<br />
<br />
* Add option to take avoided hexes into account in wesnoth.find_path()<br />
<br />
* Make the (old) simple aspect syntax work when the Lua engine is defined for a side. Setting aspects in the [side] tag like this:<br />
[ai]<br />
aggression=0.123<br />
[/ai]<br />
does not work if the Lua engine is defined. You either need to use the [aspect] tag in the [side] tag with 'engine=lua', or use the code above in a [modify_side] tag in an event. Making the above syntax available (as it is with the c++ engine) would be nice. The same also applies to the FAI engine and to aspects set for AI sides in MP games.<br />
<br />
* Add a Lua function ai.get_individual_attacks() that returns all the single attacks the side can do (as opposed to attack combinations). This needs to include an option to recalculate and take the current situation on the map into account (making the function believe that the game state has changed).<br />
<br />
* Set up an option the allows us to exclude units from the move-to-targets phase similar to [filter_own] for the combat phase (other than setting ai_special=guardian, which has a number of other side effects). Actually, having this option for all CA's would be nice.<br />
<br />
* Change the aspects "passive_leader", "passive_leader_shares_keep", "leader_ignores_keep" to work with multiple leaders. The idea is to change the type of those aspects from yes/no to string so both "passive_leader=yes" and "passive_leader=leader_id_1,leader_id_2" is possible.<br />
<br />
* ai.get_new_enemy_dst_src and related functions have several problems:<br />
** They use the current moves of the enemy units, which generally are all zero.<br />
** Hexes occupied by other enemy units count as not reachable.<br />
**Units with zero moves are not listed at all, not even for the hex they are on.<br />
**Working around this with a Lua wrapper makes this actually slower than ai_helper.get_enemy_dst_src, which makes the functions pretty much useless, as speed is the only thing speaking for them.<br />
<br />
* Clean up Micro AI candidate actions code. The Micro AIs were developed over quite a long period while we were trying to figure out how all of this works (and in part also by students participating in the Google Code-in project). As a result, the code in some of them is quite inconsistent, not cleaned up, uncommented (or wrongly commented), etc. '''Important notes:'''<br />
**This is not meant as a single task, but rather as a series of tasks, involving individual MAIs or sets of related MAIs. Please do not submit a pull request in which the code of all MAIs has been modified. <br />
**The Micro AIs are still being worked on pretty constantly, so if you are planning to work on this task, please let mattsc know (either on IRC or via forum PM), so that we can avoid conflicts as much as possible.<br />
<br />
* Add new options (keys or tags) to the Micro AIs. As an example, some (but certainly not all) Micro AIs might benefit from taking some (but certainly not all) of the default AI aspects into account.<br />
<br />
* Write a script that automatically changes WML from the deprecated [ai][target] to the new [ai][goal] syntax. Ideally, this would be part of wmllint.<br />
** There are [http://wiki.wesnoth.org/AiWML#Deprecated_AI_Targeting_Aspects more deprecated AI aspect] which should eventually be added to this, but the [target] -> [goal] change would be a good and important start.<br />
<br />
== GUI related features ==<br />
<br />
Although Mordante developed the new GUI system GUI2, some dialogs still use the older GUI1 and could be improved or transferred. You should contact Mordante on IRC before starting to work on these.<br />
<br />
=== Theme Changes ===<br />
<br />
* hide the hourglass item from the statusbar when there is no timer<br />
<br />
=== Widget Changes ===<br />
* make games sortable in the lobby (open slots, total number of players, era, XP modifier, gold per village, fog/shroud)<br>a GUI2 lobby is currently being developed, ask mordante whether this is still relevant<br />
* input history (chat, commands, ..)<br />
<br />
== GUI2 related features ==<br />
GUI2 is the new gui engine Mordante/SkeletonCrew is working on. <br />
* Information on the wiki can be found here http://www.wesnoth.org/wiki/GUIToolkit<br />
* The source code is under src/gui/<br />
* The configuration config files are under data/gui/default<br />
<br />
Some tasks need the --new-widgets since the code is only shown in the experimental mode. Tasks which need this switch have the * in the title.<br />
<br />
=== Port the random map generator dialog to GUI2 ===<br />
The map generator currently doesn't use the GUI2 framework, but there's no reason why it couldn't. Ask lipk (forum)/lipkab (IRC).<br />
<br />
== Miscellaneous ==<br />
<br />
=== More powerful village naming ===<br />
'''Adding mountain names and other features to village names, having a second random name in village names'''<br />
<br />
Currently the village naming engine has a very good structure that could allow more powerful names to be generated. <br />
Understanding how it works should be quite easy, and a few useful improvements could be added.<br />
<br />
* Currently villages can use lake names and river names, this should be extended to other features like bridges, swamps, mountains etc...<br />
* It would be nice to have a separate list of "first syllabus" and "last syllabus" for naming. That's not really needed in English, but some translations could use it<br />
* Again, it is common to have villages with more than one "random" word in them. having a $name2 variable would be nice<br />
<br />
<br />
Aishiko 27/02/2014<br />
<br />
=== Debug Mode ===<br />
* New debug command functionality (setting additional status.variables, possibly terrain)<br />
<br />
=== wesnoth-optipng ===<br />
For lossless png compression we use wesnoth-optipng, a script using an external toolchain (ImageMagick, OptiPNG, Advdef). Perhaps the performance could be improved by using PNGOut instead of advdef. This task includes<br />
* a quick profiling of compression ratio and decompression speed for both tools<br />
* if it provides a higher compression while not significantly slowing down decompression, adapt wesnoth-optipng to use PNGOut<br />
<br />
== Bugs ==<br />
<br />
<br />
<br />
== See Also ==<br />
<br />
[[NotSoEasyCoding]]<br />
<br />
[[Category:Development]]<br />
[[Category:Future]]</div>Aishiko