GSoC: Sprite Sheets

[gabba]

I'm interested in working on sprite sheets for the summer of code, and other GSoC students are too. This is a thread to discuss various proposals, and to allow some input from artists since they frequent the forums more than irc or the mailing list.

I'll start by posting a link to my proposal: I think it's pretty complete, but I'm curious to know if I interpreted well the current needs regarding sprite sheets.
http://wiki.wesnoth.org/GSoC-SpriteSheets_Gabba

Let the flaming bashing harmonious and friendly discussion start!

[thespaceinvader]

The one major, MAJOR question I have: will we still be able to load individual pngs into compiled copies of the game, and have them work as they do now?

I don't have any other way of testing animations...

[Boucman]

good point, we have many artists that don't compile wesnoth but rely only on WML and prepacked distributions...

if it was possible to combine both approch that would be great indeed

[gabba]

The one major, MAJOR question I have: will we still be able to load individual pngs into compiled copies of the game, and have them work as they do now?
I don't have any other way of testing animations...

My idea (which you'll see if you read the proposal, it's short) is to keep the current WML animation system as is. You'll still test and define animations the usual way, using individual .png, if you want. You can keep doing that with compiled copies of the game, too.

If you do work from svn sources, you'll have an option at build time to generate sprite sheets from those, and if you do that it'll automatically generate modified copies of the WML that references the "pieces" of sprite sheets instead of original .png (keeping original images and WML intact in separate folders). This said as an artist you can completely ignore the existence of this system if you want. Actually I don't think it's of much interest to artists, as it's more a disk space / memory optimization issue.

Edit: Concrete example from the drake glider (Glider.cfg):
What it'll look like on svn (i.e., same as now):

Code: Select all

[attack_anim]
       (...)
        [frame]
            duration=100
            image="units/drakes/glider-kick-1.png"
        [/frame]
       (...)
[/attack_anim]

What it'll look like after processing through my system, and therefore in your packaged copy of the game:

Code: Select all

[attack_anim]
       (...)
        [frame]
            duration=100
            image="units/drakes/drakes_sprite_sheet.png~CROP(0,0,20,20)"
        [/frame]
       (...)
[/attack_anim]

What you can change it to in either the svn or compiled version in order to test a new image:

Code: Select all

[attack_anim]
       (...)
        [frame]
            duration=100
            image="units/drakes/My_New_Fancy_Glider_Kick_1.png"
        [/frame]
       (...)
[/attack_anim]

[Fou_Fou]

I don't see why there would be any problem generating a sprite sheet using individual .png files. I completely understand thespaceinvader concern regarding testing animation - I've done some animation work in the past for projects, and it's a lot easier to make sure if stuff is lined up correctly then when you're looking at everything on a sprite sheet.

Maybe have it so you when you originally upload the individual .png files, it automatically generates the spritesheet then?

[thespaceinvader]

That's reassuring. Thanks.

The other concern that I have is that this might make animation and coding less accessible for beginners - but I couldn't be certain. I can't say I've ever worked with sprite sheets, myself.

Purely out of interest, what would be the likely download size advantage from doing this?

[Fou_Fou]

I've worked with spritesheets before, in my spare time I've been working on coding up a little javascript/canvas game (I suggest viewing with firefox - if it doesn't show up immediately, just refresh once and it typically works) where the background was made using just a tiny spritesheet I made.

I'm not exactly sure about download size advantages, but it does help the system during runtime, since it takes less effort for the computer to draw multiple sprites from one image, than multiple sprites from many images. Basically, it's more efficient.

I know that the Torque 2D game engine had a nice way of making sprite sheets easy to deal with. When you loaded the sprite sheet, you indicated the width/height of an individual tile (providing that all tiles have the same dimension), and then the program cut up the sprite sheet for you so you could easily select what tiles you wanted.

[gabba]

The other concern that I have is that this might make animation and coding less accessible for beginners - but I couldn't be certain. I can't say I've ever worked with sprite sheets, myself.

See my edit above: people would use exactly the same workflow.
Or if they'd rather use hand-made strips or sheets of images, I'd allow them to use that too... it's not really more complicated.

[thespaceinvader]

Ah cool, OK.

fou fou: the issue with that approach is that our sprites do not have a defined frame size. They vary a great deal.

[gabba]

One inconvenient of sprite sheets might be that if the game is packaged with them, less artists will be drawn to modify the game? Do the individual pngs make it more interesting for artists to look inside the game folders and start tweaking some images and replacing stuff?

In any case, one solution to this would be to have the regular Wesnoth dowload, and then the Artists' Download, which has exactly the same executable, but comes with the images (and WML animation files) straight from svn, instead of the automatically generated sprite sheets. This would be very easy to do with the system I described.

Artists could experiment with their own individual images in both distributions, but with the second, they'd have the originals in a more accessible format to play with.

[Zarel]

(Posted by Jetrel since I don't have access to Developers' Discussion)

Purely out of interest, what would be the likely download size advantage from doing this?

It would save 40%-60% of the sprite size. Of course, most of Wesnoth's download size is due to the bundled music, so it shouldn't affect total size too much. The main advantages of sprite sheets are memory usage and performance (and easier on the filesystem once installed).

One inconvenient of sprite sheets might be that if the game is packaged with them, less artists will be drawn to modify the game?

Editing existing frames will be as easy as it always is.

Adding/removing frames will involve messing with WML, and we can add a note in the WML so anyone who modifies it can see instructions on how to find the un-sprite-sheeted version for editing.

Most artists don't want to mess with WML either way; they usually post frames and wait for coders to commit them, so the addition of sprite sheets wouldn't make much of a difference in that respect either way.

[tsr]

One inconvenient of sprite sheets might be that if the game is packaged with them, less artists will be drawn to modify the game? Do the individual pngs make it more interesting for artists to look inside the game folders and start tweaking some images and replacing stuff?

In any case, one solution to this would be to have the regular Wesnoth dowload, and then the Artists' Download, which has exactly the same executable, but comes with the images (and WML animation files) straight from svn, instead of the automatically generated sprite sheets. This would be very easy to do with the system I described.

Artists could experiment with their own individual images in both distributions, but with the second, they'd have the originals in a more accessible format to play with.

From what I can tell in your proposal you have no intention whatsoever to mix and match the individual pngs in any way so couldn't the sprite sheets be generated at cache-time? Like this all the folders would stay like now with two additions (so no confusion for artists while gaining cpu/gpu cycles for players):
- a generated spritesheet
- a definition file where the game can look up sprites at run-time
(the definition-file "units/drakes/glider.cfg" would look something like)

Code: Select all

    [spritesheet]
        sheet_image=units/drakes/glider.png
        [frame]
            animation=kick
            sequence=1
            area=0,0,72,72
        [/frame]
        [frame]
            animation=kick
            sequence=2
            area=0,72,72,144
        [/frame]
    [/spritesheet]

So then when the engine wants to find the image "glider-kick-1.png" it looks for:
- has the file changed on the filesystem since the last cahe?
---if-- yes: generate a new cache (if not --no-cache then always load the image from file)
- find a cfg in "units/drakes/" for "glider" and in that get the "area" of the frame with the "animation=kick" and "sequence=1"
- use that area on the image "glider.png"

How does that sound? (or maybe the above defies the purpose completely?)

/tsr

[Edit] Having time in the morning and skimming through #wesnoth-dev I saw that a similar approach was already discussed there

[Jetrel]

What you'll get out of just adding spritesheets to wesnoth, is two things:
1] dramatic on-disk space savings. In a test, I concatenated all the drake sprites into one PNG. They went from appx 3 mb down to 300kb.
2] less awkwardness in dealing with individual files. There will generally be only one image per unit, and for most people, working with more than a few windows open gets really awkward really fast. In fact, MSPaint (which unfortunately gets used a lot) only supports having one document open at a time, so anyone working on wesnoth sprites with it would quickly get frustrated by having to constantly open and close stuff.



If I had to make a long-shot wish, my opinion would be that we should do what Frogatto does, because the improvements over there holistically offer many more benefits (Frogatto is a side project of mine right now which has GPL code, but does not have GPL content). An additional concern which frogatto mitigates is memory usage; frogatto is OpenGL, so we don't need to cache any large images like this for simple operations like TC shifting or rotation/mirroring. Unfortunately, it is almost certainly far beyond the scope of GSOC to do a conversion like this, I'm merely stating this for informational purposes.

What frogatto does, most importantly, is it completely changes the animation WML, moving away from specifying single frames in a node, to specifying an entire animation with one node - this works if you can make certain assumptions which, I've found in practice, to all be just fine; being forced to follow these rules really doesn't hurt a game:
1] all the frames are the same size (they almost always are, and the smaller ones can be increased in size if they're not).
2] You also need all the frames to be arranged in a rectangular grid in the spritesheet, but in practice that's no harder than managing separate images.
3] all the frames have the same duration. If you need a radically different duration (such as a long pause for an idle animation), you chain a few different animations together.
4] Frogatto also uses "magic colors" to do binary transparency; this eliminates a major maintenance task in wesnoth of hunting down errant alpha values in sprite. A second 'magic color' could easily work for our shadows. All these are is just a quick compare on image load to construct an alpha channel, if the image doesn't come with one.

So in frogatto, you can specify an entire animation with something like this:

Code: Select all

		[animation]
		id=stand
		image=characters/frogatto-spritesheet1.png
		pad=3   #gap between frames in both x AND y directions, no provision for making it different between the two.
		rect=2,2,33,34
		frames=3
		frames_per_row=1   #defaults to 1, normally I wouldn't specify this, but doing it for exposition here
		duration=6   #per frame, and 1 unit=20msec in frogatto
		[/animation]

And that code would operate with this image (nonGPL), specifically, the 3 frames in the upper-left.

[gabba]

Ok, let's see.

@tsr: I'm not sure of what you mean exactly when you say "mix and match" the individual pngs?
Anyways, without getting into the details of your proposal, of course, these sheets could be generated at cache time. I suppose it would increase initial loading time, but as a one-time or unfrequent thing it's acceptable. I also had a slightly different take on the WML appearance (actually I want to avoid introducing anything new there), but that's not important.
The problem is that there doesn't seem to be a consensus of what people actually want from sprite sheets. If reducing disk usage is a priority, your idea wouldn't cut it...

@Jetryl: you seem to find sprite sheets more convenient, but thespaceinvader above seemed very attached to the idea of using individual .png files. I guess it depends on several factors; I imagine that stuff like overlaying several frames of an animation in GIMP so you can see the previous ones by transparency is made easier if they're individual images.

If an animation system like that of frogatto is really what's wanted (I know you're not asking for it, I'm just stating facts), I don't think it would be hard to implement over the course of the summer of code. It might actually boost this task to something more in proportion with the allocated time. But you'd end up with two animations systems in parallel, and it would take at least two Wesnoth major releases (so, by 1.12?) for people to move over completely to the new one... if they actually like it.

Maybe something more reasonable is to add some features from Frogatto:
- the magic color transparency may be interesting, but I'm a big fan of doing things "the right way" (if there is such a thing), so I prefer the alpha channel system as it is now -- but hey, it's not my call. Again, you'd end up with two transparency systems in parallel for a while, with some WML attribute to tell when you're using the new one.

- what I find much more interesting is the ability to specify several frames in a single rectangle: it's an "auto-crop" mechanism of sorts. And does look like it could simplify life a lot for someone like you that works directly with handmade sprite sheets. I think this could easily be integrated into wesnoth's current animation system by adding a [frame_group] tag that you could use as an alternative to [frame]. Something like:

Code: Select all

[attack_anim]
       (...)
        [frame_group]
            id="drakeB"
            image="units/drakes/drake_spritesheet.png"
            pad=3   #gap between frames in both x AND y directions
            rect=2,2,33,34
            frames=3
            frames_per_row=1
            duration=100 #or for individual durations: duration={100,200,150}
        [/frame_group]
       (...)
[/attack_anim]

I put an ID there 'cause while we are at it, referencing specific frames from that frame group elsewhere would be handy, by doing for instance drakeB/2 for the second frame of the group. I'm just throwing ideas around of course.

By the way, to make a sprite sheet like you described, you don't really need a specialized tool. Or if you do, there's an imagemagick command ("montage") that does it according to your specifications, there's a link to it on my proposal page.

Lastly, depending on the importance of the disk space aspect, large sprite sheets including various image sizes (from several animations/units) can include waaaay more images than you can with a fixed rectangular grid. See the clanlib tool screenshot on my proposal and also the shots from the C#/XNA tool I linked to to see what I mean. Edit: Right now my proposal allows for fixed grid sprite sheets as input and optimized and reorganized sprite sheets as output, so having the best of both worlds is possible.

Edit: oops, missed the code tags.

[thespaceinvader]

gabba: it's probably because I'm used to the way Wesnoth does it. I find it easy to work this way, but I'm sure I could get used to a different method.

This makes a lot more sense in terms of size and streamlining, though.