3
\$\begingroup\$

I am currently working on an iPhone project, but most of my work has been in Flash. Flash has a feature where you can place a bitmap into a MovieClip, set its registration point with the mouse and it's automatically adopted. It's one of the lovelier Flash features.

Now I'm doing iPhone stuff, using TexturePacker for importing the graphics, and I'm having to write code like this:

if(graphic == "spikes1") setAnchorPoint(ccp(1, 0));
if(graphic == "spikes2") setAnchorPoint(ccp(.5f, 0));
if(graphic == "spikes3") setAnchorPoint(ccp(.5f, 0));
if(graphic == "spikes4") setAnchorPoint(ccp(.5f, 0));

if(graphic == "bush-a") setAnchorPoint(ccp(.5f, .25f));
if(graphic == "bush-b") setAnchorPoint(ccp(.5f, .25f));

if(graphic == "tree1") setAnchorPoint(ccp((float)134/209, (float)34/202));
if(graphic == "tree2") setAnchorPoint(ccp((float)96/236, (float)31/184));

I can obviously use macros or functions to shorten this a little, but is there a more intelligent way to go about this?

How do professional platformer games (on consoles and PC) handle this?

\$\endgroup\$

3 Answers 3

2
\$\begingroup\$

If you're referring about not having to hardcode all of of those anchor points, you could move them to an external file, and after loading all of the images, just read and iterate through your anchor file and set the values. The file could look like:

spikes1 1 0
spikes2 0.5 0
spikes3 0.5 0
spikes4 0.5 0
bush-a 0.5 0.25
bush-b 0.5 0.25

And for easier access, after loading the images you cold store them in some hashtable or dictionary using the name of the graphic as a key. Then to assign the anchor points it would be something like (in pseudocode because I'm not familiar with Objective-C):

foreach(entry in anchorFile)
{
    string[] data = entry.split(' ');
    string name = data[0];
    float x = parseFloat(data[1]);
    float y = parseFloat(data[2]);
    imageDictionary[name].setAnchorPoint(cpp(x, y));
}

To help you generate the file, you could also create a simple offline tool where you'd load all of your images, click once on each of them, and then it would generate the data file for you with all the anchor points recorded. Should be fairly trivial to implement.

\$\endgroup\$
0
\$\begingroup\$

While you could create some meta-data file that contains the anchor points for all your sprites, you should generally avoid having different anchor points for different sprites.

There are some reasons for this:

  • You might create a collision shape in another editor, after changing the anchor-point, the shape will suddenly no longer match the sprite.
  • Maybe you use a level-editor that doesn't support anchor-point offsets. So while your level looks fine in the editor, it will no longer work in your game (where you use offsets).

Things like this can cause strange issues that can become hard to debug. I strongly suggest you don't alter the anchor points at all, unless there's a very good reason to do so.

\$\endgroup\$
4
  • \$\begingroup\$ A generic, shared anchor point would not work for this situation. The art is too varied and the anchor point needs to match the visuals. My level editor is written specifically for this game and definitely handles this ok. \$\endgroup\$ Jan 3, 2012 at 11:16
  • \$\begingroup\$ @ChrisBurt-Brown But why does it have to match the visuals? Do you plan to rotate the sprites? In any case: If you have your own level-editor, why not make the anchor-point editable there and output it with your other level data? \$\endgroup\$
    – bummzack
    Jan 3, 2012 at 11:27
  • \$\begingroup\$ It has to match the visuals -- um, imagine a Box2D polygon breaking up into bits, with sprites attached to the polygon, they have to follow the right "chunks". So they need to know the point they are attached at. As for the level editor, I don't want to put the burden on the level designer to place the anchor point correctly. I want that to all be sorted out before level design begins. \$\endgroup\$ Jan 3, 2012 at 11:36
  • \$\begingroup\$ @ChrisBurt-Brown If you're using Box2D, then you might consider PhysicsEditor. It also allows you to set the anchor point and provides helper classes that will allow you to parse and apply the anchor point from the meta-data. \$\endgroup\$
    – bummzack
    Jan 3, 2012 at 12:03
0
\$\begingroup\$

Usually artists manage their assets folder where they create their graphics in .psd format or something else with layers. By convention a specific layer named anchor is created which contains a single opaque pixel (other pixels are ignored), and the artists define that pixel as the rotation point for the sprite. Then, in your conversion process from .psd to your own formats you split the layers and convert the coordinate to a text file which you can later load like David Gouveia mentioned.

If you are dealing with a layer-less art pipeline, you can then use the convention of storing several files for the same graphic, like sprite1.png and sprite1_anchor.png, where the anchor point has already been split by the artist into a separate graphic. This puts pressure on the artists to remember to update the anchor files, though anchors don't tend to change that much.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .