Difference between revisions of "SpriteSheetApplicationSAB"
Line 14: | Line 14: | ||
==Prelim Implementation Ideas== | ==Prelim Implementation Ideas== | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
4.4) Include an estimated timeline for your work on the project. Don't forget to | 4.4) Include an estimated timeline for your work on the project. Don't forget to | ||
Line 74: | Line 51: | ||
some tests to check and see if the performance gains are really showing up. | some tests to check and see if the performance gains are really showing up. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
**************Comments and Suggestions************** | **************Comments and Suggestions************** | ||
Please place them after this line, all are appreciated and if I can't thank you | Please place them after this line, all are appreciated and if I can't thank you | ||
personally (IE you don't attach your name to it, Thank you. | personally (IE you don't attach your name to it, Thank you. |
Revision as of 04:08, 21 March 2014
This page is related to Summer of Code 2014 |
See the list of Summer of Code 2014 Ideas |
This is a Summer of Code 2014 student page |
Description
Aishiko GSOC 2014 SpriteSheets
My proposal is to take the current functions for drawing sprites and move it to allow for spritesheets, while hiding any of the changes from campaign designers. It should allow for the seemless intergration of spritesheets and allow for a period of conversion from multiple files to sheets.
IRC
Aishiko, Aishiko_laptop
Prelim Implementation Ideas
4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".
I'm still working out a timeline but I would most likely do a commit at least weekly. And break out the commits so that similar changes are only in that commit. Example, comment changes in one, (assuming no code changes), a converted set of sprites (aka the spritesheet) as one, and then code making use of it. After checking to make sure that the spritesheet works, removal of the converted individual sprite image files.
4.5) Include as much technical detail about your implementation as you can
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.
Once I have completed getting a character spritesheet to work, I'd then move on to the map sprites to spritesheets, again using the same methodology of check and if it finds a spritesheet use it otherwise, use the individual images. Though, on the grouping I'm not sure how I'd do that mordante and I'd have to discuss grouping, since a map can have any or all of the different tiles, and they are not chained like the unit/character sprites are, I'd have to group similar tiles together. Like the water images, shorelines, docks, and water villages, as one. The fields, human villages and castles in one. Swamp things together, and so on.
I've heard that some devs think that a spritesheet might cause issues with larger images that don't fit in a hex, I'll intentional create some sprite sheets just for testing this purpose. I'll also see about creating some tests to check and see if the performance gains are really showing up.
**************Comments and Suggestions************** Please place them after this line, all are appreciated and if I can't thank you
personally (IE you don't attach your name to it, Thank you.