Shaun Dreclin

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

Recommended Posts

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)?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 :P

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.