SpriteSheets Aishiko 2014 GSOC feedback Editted 23 Mar 14

Contribute art for mainline Wesnoth.

Moderator: Forum Moderators

Forum rules
Before posting critique in this forum, you must read the following thread:

What do you think of this proposal?

Poll ended at April 20th, 2014, 6:20 am

Perfect
0
No votes
Sounds Good
1
11%
Needs Tweaking
4
44%
Needs Lots of Work
3
33%
Horrible
1
11%
 
Total votes: 9

Aishiko
Inactive Developer
Posts: 4
Joined: February 27th, 2014, 5:26 pm

SpriteSheets Aishiko 2014 GSOC feedback Editted 23 Mar 14

Post by Aishiko »

23 Mar 14 Edit

After a little more research and a bit of luck I think I've come up with a way to make most people happy.

Since its not clear this is to add spritesheets to be able to convert the exisiting images as well as for new content or addon content. The other Goals are to speed up loading, reduce diskspace requirements, decrease access times, and give the artists another tool in their toolkit.

Taking doofus-01's suggestion about a grid square to hold each image and then have each image in a second box within (see further down this page for his suggestion unedited). I think I've found a way to do that without a massive performance hit. So
image="units/elves-wood/sorceress-melee-attack-[1~10,1,2].png:[80*5,100*2,80*5]"
could become: image="units/elves-wood/sorceress.png[2.1~10,2.1,2.2]:[80*5,100*2,80*5]"
which would bascially say Elvish Sorceress, Row 2, Columns 1-10 and then Row 2 column 1, and finally Row 2 column 2

We need to tell it which row and column, because if we don't know how many rows/columns we are dealing with we need both declared so we can find that one image, second if we didn't anded an image to row 1 at the end then you'd have to update all the affected places where any image is called from the following rows as it would increase the image number associcated with those images by one.

Which if the Grid is consistant like 150x200 pixels the outer grid would only have to be found once and then math takes over and that can speed up locating the actual images, this will also allow for easier extending to all sprites displayed from units to attacks to terrian. I'll not bore you with the complicated backend, does this seem like a better method that will meet your needs which I now read to be:
flexiability in placement and size of images for just about type of image
Simple easy to use WML code
Unlimited rows and columns OR no upper maxes you have to worry about hitting when creating and placing within a spritesheet


Original Post

I've been hearing that the artists want spritesheets and have for a while now. Since that is my GSOC proposal is about, I want to know your concerns/wishes for them. My plan (and hope) is to make it very easy for you to use them so easy you don't have to be concerned with any implementation, beyond including 3 small pieces of information. And since your all visual types, I spent some time and make a mock up sprite sheet out of the Female Elvish Archer!

Yes I know it might not actually work, that's the sort of thing you're good at and I appreciate that you do it. However it lets you see where I'm going with this. You'll see that each image is surrounded by a border exactly 3 pixels wide. It helps you (at least it helped me!) position each sprite properly, without having to worry about what pixel is in the top corner, I could see when it was right and when it was wrong.
A mock up of the Elvish Archer Female spritesheet!
A mock up of the Elvish Archer Female spritesheet!
forumExample.png (25.85 KiB) Viewed 10158 times
Just so you know which image is which:
1 archer+female
2 archer+female-bow-attack1
3 archer+female-bow-attack2
4 archer+female-bow-attack3
5 archer+female-bow-attack4

6 archer+female-sword
7 archer+female-sword-1
8 archer+female-sword-2
9 archer+female-sword-3
10 archer+female-sword-4

11 archer+female-sword-defend
12 archer+female-bow
13 blank (oops my mistake!)
14 archer+female-die1
15 archer+female-die2

16 archer+female-die3
17 archer+female-die4
18 blank
19 blank
20 blank

21 blank
22 blank
23 blank
24 blank
25 blank

They are numbered from right to left starting with 1 (yes coders I know 0 is a perfectly fine number but not intuitive for the those used to counting starting at 1). I actually didn't count the number of images and accidentally included an extra row... just think of that as a template that can be added to the repo to aid you in the creation of new sheets or appending to current ones when you run out of room on a current one.

So now we have a spritesheet how do you tell the program it is and what images to take out for a particular animation? Its so simple, you just send [1,72,72] on the end of image listing. The first 1 says "I'm a spritesheet!", the second says "I'm 72 pixels high.", and the third says "I'm 72 pixels wide." Other then changing the file name... that's it!

so in our example:
image="units/elves-wood/archer+female.png"
becomes
image="units/elves-wood/archer+female.png[1,72,72,1]"
In this you can see that it says its a sprite sheet of images 72x72, and we want the first image.
and an animation sequence goes from:
image="units/elves-wood/archer+female-bow-attack[1~4].png:[75*2,100,130]"
to:
image="units/elves-wood/archer+female.png[75*2,100,130][1,72,72,2~5]"
or:
image="units/elves-wood/archer+female.png[1,72,72,2~5][75*2,100,130]"
In these you can see that it says its a sprite sheet of images 72x72, and we want images 2-5.
Not a big difference and easy for you to write, the code then takes all that and parses it leaving you free to not worry about how it works it's magic to work. This is a work in progress and your feedback can change the course of how things are done. As you can see I have no plans to change the timing block it works and you're familiar with it.

Almost done, a final concern I'd like to address is that this will not mean that you'll have to convert everything right away, standard sprite image files WILL be able to continue to be used (until such time as the powers that be decide to change that).

Finally it is my hope that I'll be able to cook up a python script to make converting easier for you, however that is secondary to getting spritesheets to "just work in Wesnoth". And if it happens that I'm not able to create a utility to convert the images during the summer of code, well I'll just have to make it after the summer.

Finally, there is a poll that will run from now to roughly the announcement of the accepted students and their proposals. Please vote and if you think it could or needs to be improved upon please share, and if practical implement or address them. Feel free to express any concerns you might have I'll do my best to try and address them as well.

Thank you for taking the time to read this and any comments you might give in the spirit of making Wesnoth better.

*edited for grammar and spelling*
Last edited by Aishiko on March 23rd, 2014, 4:47 am, edited 3 times in total.
Wussel
Posts: 624
Joined: July 28th, 2012, 5:58 am

Re: SpriteSheets Aishiko 2014 GSOC feedback request to Artis

Post by Wussel »

How would you deal with oversize units or animations?

Personally I do use gridlines of 12 pixel for positioning. Thus the border should be 12 pixel wide in my opinion.

Could you use oversize like 96 times 96 Spritesheets?
Aishiko
Inactive Developer
Posts: 4
Joined: February 27th, 2014, 5:26 pm

Re: SpriteSheets Aishiko 2014 GSOC feedback request to Artis

Post by Aishiko »

Wussel, thank you for sharing, as for the size no, for this to be workable on my end (the code) I need to know either how many images it has wide (in this version which makes more sense then a vertical layout for most people I think though I could be wrong.) Now I choose 5 and a 5x5 grid for an example there is literally nothing saying it could can't be 100 imagee wide or 10, whatever is easy for you, the artist to work with. Its not limited to a square too, it could be 5 wide and 10 rows tall or 10 colums wide and 5 rows high. I also choose 5 as most animations use 5 or less frames (that I've looked at) and so you put each row a different set of animations like attack or defend. But either the number of columns or rows has to be some set standard.

Oversized images and animations are sent the same way that is why the hieght and width are sent, all the images in the sprite sheet would share the same dimentions so for example the arbiter (drake) would all have images of 150x150 or the white missile projectile would all have 100x100. This I realize might require some images to be resized so all the images in a unit set would be the same size, but those are more exceptions then the rule. The converting might seem like a pain, but it eases the burden of implentation and use, easier to implement, easier to maintain, and eaiser for the non-coding community to use, because if its too hard to use, we, the devs get to deal with complaints and upset users. So I'm trying to strike that middle ground. Back to the oversized units/sprites, we could have a unit with a size of say 150x670 (the light-beam found in data/core/images/halo/holy) as long as the images are all the same size and they are in a sheet and its numbered correctly it'll work. so in the example if you made it 2x2 and its expecting 5 wide, then you'd have images 1, 2, 6, & 7 not 1-4.
User avatar
beetlenaut
Developer
Posts: 2814
Joined: December 8th, 2007, 3:21 am
Location: Washington State
Contact:

Re: SpriteSheets Aishiko 2014 GSOC feedback request to Artis

Post by beetlenaut »

I propose using an "S" instead of a "1" to indicate a sprite sheet. It would make it easier to read.

Starting the counting with zero allows you to count the rows by by fives, allowing you to determine the number of a sprite much more easily I think.

Also, specifying the size of the sprites in every animation call seems a little redundant--especially since it will be 72*72 90% of the time. In order to reduce this clutter and make animation code easier to read, couldn't the program determine the size of the sprites in the sheet pretty easily? The width of a sprite is simply the sheet's width divided by 5 minus 18 for the borders. The height is harder, but if the color used in the border was disallowed in the sprites themselves, determining the height could be done by sampling the colors in the first sprite. (Actually, figuring out the size of the sprite grid and the width of the borders could be done about the same way, which would eliminate Wussel's concerns.) Would this be too slow?
Campaigns: Dead Water,
The Founding of Borstep,
Secrets of the Ancients,
and WML Guide
User avatar
lipk
Posts: 637
Joined: July 18th, 2011, 1:42 pm

Re: SpriteSheets Aishiko 2014 GSOC feedback request to Artis

Post by lipk »

I don't like that you need to specify the sheet's dimensions every time you want to get an image. IMO it would be better to keep the spritesheet's parameters hidden from the animation code.

Some code to illustrate my point:

Code: Select all

[spritesheet]
    sprite_width=72
    sprite_height=72
    border_size=3 #do we really need borders, by the way?
    image_file=units/elves-wood/archer+female.png
    id=elf-archer-female
[/spritesheet]
...
image="elf-archer-female[1]"
...
It'd require some thought, however, how much overhead an additional layer costs here.

EDIT: ninja'd
User avatar
doofus-01
Art Director
Posts: 4122
Joined: January 6th, 2008, 9:27 pm
Location: USA

Re: SpriteSheets Aishiko 2014 GSOC feedback request to Artis

Post by doofus-01 »

lipk wrote:#do we really need borders, by the way?
It would make alignment easier when pasting a frame in, I believe, as Aishiko said.


The exact form this takes should probably be determined by whether this is about new content or converting old content. If this is really about converting existing content into sprite sheets, then of course thought should really go into the WML side. If I were trying to use this for new content though, I'd prefer to have something with clunky WML, but that didn't lock me into a certain frame-size or frame-count. For example, using reserved colors for automatic detection (red & black, in the example) have an available cell with a reasonable available area that is larger than expected frames, then another border for the actual frames.
ss_example.png
ss_example.png (11.7 KiB) Viewed 10015 times
Probably doesn't look like an improvement, but if I was drawing an animation in layers (which is how it's usually done, as far as I know), and had to redraw the sprite sheet when I found I needed larger cells, I'd be cursing this sprite sheet business after a while.

Of course, if the old separate-image mechanism is still available, then maybe it doesn't matter. Or if you got the python script written to handle creating the sprite sheet.

Shorter version: Is this to make an easy template for new images/animations, or is this to have better image loading & file browsing & whatever-else-it-is-that-makes-sprite-sheets-better?
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
User avatar
Dugi
Posts: 4961
Joined: July 22nd, 2010, 10:29 am
Location: Carpathian Mountains
Contact:

Re: SpriteSheets Aishiko 2014 GSOC feedback request to Artis

Post by Dugi »

Wondering what would you guys say about this alternative I made up when I read this idea a few days ago.
User avatar
zookeeper
WML Wizard
Posts: 9742
Joined: September 11th, 2004, 10:40 pm
Location: Finland

Re: SpriteSheets Aishiko 2014 GSOC feedback request to Artis

Post by zookeeper »

Maybe for once I should write down my suggestion... this is mostly for reference since a lot of this stuff comes up in IRC discussion:

Basic idea: in image paths, you index the sheet by specifying the row and column. The sheet itself will have the frames outlined with a magic color, and the game automatically finds the individual frame coordinates based on them. Nothing else needs to be done to tell the game that it's a spritesheet and no metadata needs to be provided.

Usage example: if I want the second frame from the fourth row, I'd index the sheet with something like image="units/elves-wood/archer+female.png<4,2>. I haven't pondered that much on the exact syntax, there's probably plenty of ideas that'd work.

Sheet specifications: top left pixel of the image denotes the magic color used for the outlines. Based on the outlines, the game figures out the exact coordinates of each frame row by row and stores them internally. Each row can contain a different number of frames, which can all be of different sizes and positioned freely, as long as frames within a row don't overlap each other horizontally, and rows don't overlap each other vertically.

Pros: no need to provide and maintain metadata, sheets can be organized very freely and loosely and frames don't need to be of the same size.

Cons: needs code to figure out the frame coordinates based on the outlines, which shouldn't be hard as such, but providing meaningful error messages for malformed sheets might be tricky. On the other hand, magic color outlines should make mistakes pretty obvious for the artist anyway. Also, if the operation is very slow, it could cause a more noticeable delay when the sheet is first accessed.
User avatar
doofus-01
Art Director
Posts: 4122
Joined: January 6th, 2008, 9:27 pm
Location: USA

Re: SpriteSheets Aishiko 2014 GSOC feedback Editted 23 Mar 1

Post by doofus-01 »

OK, I think the problem is this: Making an animation into several images is trivial, from the "artist" perspective, all that a sprite sheet does is facilitate palette swapping, which can be done easily with something like [acronym="-fill #FFFF00 -opaque #999999" where #999999 is what you want to replace with #FFFF00]Image Magick,[/acronym] even for a billion PNG files (one of the reasons to use Pixel Art). There may be reasons to move to sprite sheets, but they have little to do with image creation/animation. So what is the least painful to adapt to? I hope the move to sprite sheets does not cause any sacrifice in what is currently supported.

@Dugi: It makes sense to organize the sprite directory structure, so that the units get their own folders. I think that's already being done. If there is some significant file-size savings in shipping them in compressed archives then cheers, it doesn't sound like too big a pain to unpack that.

@zookeeper: I think we proposed similar things (maybe? not sure why outline-finding would be needed), so I guess I agree, but this:
zookeeper wrote:Also, if the operation is very slow, it could cause a more noticeable delay when the sheet is first accessed.
If this causes glitchy animations, as we currently have, then what's the point? If it is only a delay/hiccup when the sprite sheet is first accessed, then that is so much better than the status quo, it's hardly worth mentioning as a "con".
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
Aishiko
Inactive Developer
Posts: 4
Joined: February 27th, 2014, 5:26 pm

Re: SpriteSheets Aishiko 2014 GSOC feedback Editted 23 Mar 1

Post by Aishiko »

@doofus-01: The plan is to make things smoother durng gameplay, by having 1 file for that unit held in a seperate cache (that doesn't get cleared until after the game). This will hopefully reduce or elimnate glitchy animations. The sheet will be parsed at the start up of the game hopefully not impacting loading times. IE: what we gain from loading the 1 file isn't more then we lose by having to search for the frames. As I have stated before, single image sprite files will NOT be impacted, you'll still be able to have one sprite per file, for the forseeable future. The reasons being, my project will not give me the time to convert them all and update every unit_tye's cfg file, Every current addon would need to changed as well. Both are beyond the scope of project, its only to extend the flexibility of image subsection that deals with sprites. I can not make any sort of guarntee about what will be decided in the future (my magic 8-ball is in the shop). Spritesheets when done right speed up the loading and accessing of images, that is what we/I'm trying to do, at the sametime, making sure that the artists and WML people can easily create and use spritesheets.
User avatar
zookeeper
WML Wizard
Posts: 9742
Joined: September 11th, 2004, 10:40 pm
Location: Finland

Re: SpriteSheets Aishiko 2014 GSOC feedback Editted 23 Mar 1

Post by zookeeper »

Aishiko wrote:@doofus-01: The plan is to make things smoother durng gameplay, by having 1 file for that unit held in a seperate cache (that doesn't get cleared until after the game). This will hopefully reduce or elimnate glitchy animations. The sheet will be parsed at the start up of the game hopefully not impacting loading times. IE: what we gain from loading the 1 file isn't more then we lose by having to search for the frames.
How do you decide which sheets to parse at startup, though? Parse the sheet of every 200+ unit types the game recognizes, or every... I dunno, potentially 500+ unit types if in MP? Doesn't sound like a good idea.

I think it's worth remembering that even if the sheet is parsed when first accessed, that first access would happen when you first see the unit (when drawing the main map for the first time, when opening a recruit/recall dialog, etc; usually situations where there is already a delay of some sort), not for example when starting an attack. Unless, of course, the base frame of the unit is not part of the sheet, but that's not much of a concern. As for halo fx animations for instance, sure, perhaps the sheet would be parsed only when an attack utilizing that animation is already running, but still that'd only be a one-time short delay. And there's plenty of room for later adding some sort of smart pre-loading by simply loading all images referenced by an unit type when a unit of that type is first created, although that's got nothing to do with spritesheets as such, and it's kinda weird how that's not been done already.
Aishiko wrote:As I have stated before, single image sprite files will NOT be impacted, you'll still be able to have one sprite per file, for the forseeable future.
Well, I think it'd be absurd if support for single images was actually ever dropped even for unit animations. Whatever the implementation, it's just an addition which doesn't in any way conflict with the current way, just like IPF's... as far as I've understood all the proposals, anyway.
aquileia
Inactive Developer
Posts: 120
Joined: August 25th, 2012, 5:13 pm

Re: SpriteSheets Aishiko 2014 GSOC feedback Editted 23 Mar 1

Post by aquileia »

Oh... doofus' comment brought me an idea... possibly bad, but hey, it's worth sharing at least.

How hard would it be to store them as .gif (without the differential compression of course)? This would obsolete cutting out frames and it could even take the frame durations if we wanted. Then both frames and durations could be extracted (or a sequence from the gif could be played directly if SDL supports that).

I don't know whether GIMP can handle gif, this could be a problem as artists should be able to use their current tools.


As to border colors in sprite sheets: The more colors we nee for borders the less we have for the image itself, and red seems too prominent in this case.
User avatar
Dugi
Posts: 4961
Joined: July 22nd, 2010, 10:29 am
Location: Carpathian Mountains
Contact:

Re: SpriteSheets Aishiko 2014 GSOC feedback Editted 23 Mar 1

Post by Dugi »

GIMP can handle gif, it can open it as an image in layers. The frames have to be of the same resolution (Doofus' Death Knight problem), but it should not cause problems and take only very little extra space as long as all of them are centred. The problem I fear is that .gif can't handle transparency, so if you try to make a .gif from an animation (to show it on the forums for example), the unit's shadow is either non-transparent or absent.
User avatar
zookeeper
WML Wizard
Posts: 9742
Joined: September 11th, 2004, 10:40 pm
Location: Finland

Re: SpriteSheets Aishiko 2014 GSOC feedback Editted 23 Mar 1

Post by zookeeper »

Well gif doesn't support more than 1-bit alpha nor more than 8-bit color so that's out of the question.
Aishiko
Inactive Developer
Posts: 4
Joined: February 27th, 2014, 5:26 pm

Re: SpriteSheets Aishiko 2014 GSOC feedback Editted 23 Mar 1

Post by Aishiko »

zookeeper wrote:How do you decide which sheets to parse at startup, though? Parse the sheet of every 200+ unit types the game recognizes, or every... I dunno, potentially 500+ unit types if in MP? Doesn't sound like a good idea.

I think it's worth remembering that even if the sheet is parsed when first accessed, that first access would happen when you first see the unit (when drawing the main map for the first time, when opening a recruit/recall dialog, etc; usually situations where there is already a delay of some sort), not for example when starting an attack. Unless, of course, the base frame of the unit is not part of the sheet, but that's not much of a concern. As for halo fx animations for instance, sure, perhaps the sheet would be parsed only when an attack utilizing that animation is already running, but still that'd only be a one-time short delay. And there's plenty of room for later adding some sort of smart pre-loading by simply loading all images referenced by an unit type when a unit of that type is first created, although that's got nothing to do with spritesheets as such, and it's kinda weird how that's not been done already.
Actually, my idea is to parse them when loaded into memory, at the scenario start which will grab all the sheets used for that scenario only and prepare them, which I would hope would eliminate any image access lag or glitchy animations.
zookeeper wrote:
Aishiko wrote:As I have stated before, single image sprite files will NOT be impacted, you'll still be able to have one sprite per file, for the forseeable future.
Well, I think it'd be absurd if support for single images was actually ever dropped even for unit animations. Whatever the implementation, it's just an addition which doesn't in any way conflict with the current way, just like IPF's... as far as I've understood all the proposals, anyway.
I don't have any control over that and agree I'd not remove single image capabilities for the simple fact that unit portriats will still depend on that capability being there unless we turn that into a spritesheet of 1, and I don't think adding and processing it as a sprite sheet with a single image is a good idea from a performance stand point, there wouldn't be gains in performance at that point, only losses. My comment about the forseeable future, was me saying, "The Powers That Be Control What Comes In And What Goes Out" of mainline, and I am not one of those powers that be. I'll not one of those "Powers That Be".

However there is nothing to stop a scenario designer from taking the various portriats and turning them into a spritesheet, such as the Konrad portriats in Heir to the Throne.
doofus-01 wrote:As to border colors in sprite sheets: The more colors we nee for borders the less we have for the image itself, and red seems too prominent in this case.
I just grabed a colour for the example, it could be any colour. The colour chosen will be one that is not used in sprites Though in theory it wouldn't matter as we'd find the border before we ever parsed the sprite, and never should parse the sprite, if its formatted and bordered properly.
Post Reply