Sprite data - Seperate text file or built into sprite image?

[Shaun Dreclin]

So my sprites are all going to have information attached to them like for animated sprites, how big is each frame and how long should they last, or for layered sprites where part of it will be rendered before the user, then the other part of it after.

Question is, do I put all that data in a plain text file, or do I encode it directly into the image itself? Having it in the image improves portability and makes sure stuff is kept in one place, but there may be a performance hit reading that data from the image.

Does anyone have experience with this? One method of pixel reading I've seen has you render the image to a canvas then get the pixel data out of the canvas. Is that optimized, or will it hurt performance? Can you even use canvas in node.js (my server side)?

[tips4design]

Why don't you use a texture atlas? http://phaser.io/examples/v2/loader/load-texture-atlas It was created exactly for this, have a JSON file which describes your image spritesheet.

PS: I thought this was for Phaser, but you should be able to do something similar in Pixi.js too.

[ivan.popelyshev]

Plain text file, of course. Pixel data has many disadvantages: for example, if alpha channel is not 1.0, RGB channels will be screwed because of pre-multiplied alpha.

var loader = new PIXI.loaders.Loader();
loader.add('mytextfile', 'textfile.txt');
loader.load(function(loader, resources) {
    // data will be text if ajax grabbed text file, and JSON if it was json file
    resources['mytextfile'].data; 
    //parse it!
});

You can also look at https://github.com/pixijs/pixi.js/blob/master/src/loaders/spritesheetParser.js , and make your own parser, "loader.use(myLoader())". That way you'll be able to load images that are specified in your textfile.

[Shaun Dreclin]

Ah yeah I had a feeling saving in pixel data wouldn't be the best way to do it.

I guess now I decide if I use a master file or have a file for every sprite haha

doing my_sprite.png and my_sprite.json would probably be best from a development standpoint, so I don't have to fiddle with a huge file any time I want to move things around or change things, what are your thoughts?

[ivan.popelyshev]

My thoughts are that you have to use atlases too. PIXI cant optimize rendering process if you are using different texture per every object.

[Shaun Dreclin]

Well its not different per every object, it's different for every type of object.

Like I have a tree with an animation where a bird pops out, I want that to be in a single image rather than many images. But then I need to tell pixi "Frame one is from 0-100 pixels, frame two is from 100-200 pixels" etc. Then I have a chair with no animation but it has two layers because it has an arm rest that needs to render over the user. I need pixi to make two sprites out of that image, one for the behind the user part and another for the in front part.

 

Also this is pixi only, not phaser. Not sure if texture atlas is a pixi or phaser feature

 

 

Edit: Ah I found the thing on texture atlas. There will be way too many items to put into a massive sprite sheet, but I guess I could use a texture atlas for every item?

[ivan.popelyshev]

Texture atlas is pixi feature, you can use http://renderhjs.net/shoebox/ and export to json(hash). If you want some extra data, load one more text file and parse it like i said. You even can specify which atlases must be loaded in that text file

[Shaun Dreclin]

Ooh, shoebox looks excellent! Will try that out.

On a similar topic, I'm kind of stumped with how exactly I want to put all the data for an item together. There are 8 possible directions it can face, it can have two layers (behind and in front of the user), any number of "states" (like on and off for a lamp) and each state/direction combination can have any number of animation frames.

Would shoebox be able to handle that kind of thing for me or will I need to use another tool?

[ivan.popelyshev]

Shoebox algorithm:

1) input is a number of images

2) output is one big image and file with specification, which rectangle corresponds to which original file.

It doesnt care about your logic or states. You'll have a big number of PIXI.Texture from that atlas, and you'll have to create Sprites, Movieclips or whatever do you need out of them.

[Shaun Dreclin]

Ahh alright so it just builds me a sprite sheet and I'll have to work out the logic myself.

At some point I'm going to have potentially hundreds if not thousands of different items, and you'll only see a small portion of those in most sessions. That's why I'm pretty iffy on putting everything into one massive sprite sheet

[ivan.popelyshev]

If you have some kind of "themes", or "packs" or "levels", then you can arrange different packs to separate atlases. I have a number of 2048x2048 textures in almost every game I write  Of course if there are thousands of items then its better to dynamically load them WHICH IS COMPLETELY DIFFERENT TOPIC. Pixi does not have dynamic loading, you have to create your own architecture that uses PIXI loaders for that.

Also, atlases are useful even if they have only one item, because that item can have a number frames  You dont have to specify frame coordinates in metadata, because atlas already has them and there's parsing code that created PIXI.Texture for every frame.

If you need some bonus data, make your own atlas format which contains metadata for frames, I told you how to parse it already. And you can use both formats: your metadata contains stuff that specifies which atlases/images need to be loaded for the item.

[Shaun Dreclin]

Yeah I'm only loading an item the first time the user actually sees one, to avoid wasting tons of memory and bandwidth.

There isn't really any predictable pattern of when things will need to be loaded though, since the areas are all user-generated.

Is the performance increase significant enough to waste bandwidth loading textures for items that aren't being used?

[ivan.popelyshev]

I dont know your texture sizes and how many items you have, I cant answer that. Also some of items will already exists in browser cache. Also, its possible that you'll eat all the memory with those items if player enters some very heavy room

[Shaun Dreclin]

Textures are usually up to 300 pixels wide and tall, (but no actual limit on them) and there will be a *lot* of them. A single item could have 100 textures or more (generally less though, a static non-interactive non-animated item would only have 8 textures, one for each direction)

I'm thinking one sprite sheet per item is probably the best way of handling it, it also means if I want to edit an item its easy to find the files for it and I don't have to pull it out of a larger sheet

[ivan.popelyshev]

First look how atlases work, try to load atlas for one item instead of multiple images.

[Shaun Dreclin]

Yeah I'll try that out, for developing I've just been loading a single texture by url and putting that into the sprite.

[mattstyles]

I use spritesheet-js to create an atlas. Bit easier than farting around with a gui, but, well, its an alternative.

[Exca]

I use texturepacker. https://www.codeandweb.com/texturepacker
 

It's not free but it has a lot of nice features.