Zwoptex: 1.0.2 Generic Coordinate Format

On July 26, 2010, in Zwoptex App, by robertjpayne

With Zwoptex 1.0.2 I’ve introduced a new coordinate format ‘XML Generic’.

By default Zwoptex 1.0.2 will NOT use this new format. It will instead use ‘XML cocos2d’ which is supported in the develop branch of cocos2d.

The generic format contains a bit more information and re-organizes the key’s to make the coordinate list a bit more readable. We now have the following available in each frame:

  • aliases – This will be used in Zwoptex 1.1 for the aliasing feature
  • spriteColorRect – The {{x, y},{width, height}} that is the non-empty pixels in relation to the source sprite size
  • spriteOffset – The {x, y} offset the sprite needs to be moved from to line up with the source sprite due to trimming
  • spriteSize – The {width, height} of sprite with trimming calculated
  • spriteSourceSize – The {width, height} of the sprite before trimming
  • spriteTrimmed – Whether or not the sprite is trimmed
  • textureRect – The {{x, y}, {width, height}} of the sprite in the texture image
  • textureRotated – Whether or not the texture is rotated

spriteOffset Notes:

The spriteOffset value is calculated for sprites that are drawn with a center origin. That is if you have a 100×100 pixel sprite the draw rect would be {-50,-50,50,50}. If you’re drawing with a bottom-left origin {0,0,100,100} use {spriteColorRect.x,spriteSourceSize.height -spriteColorRect.y}.

The main purpose of this is to make the keys a bit more verbose as to what they relate to and provide complete information about the sprite and it’s texture coordinates without the user having to manipulate anything due to trimming or rotation.

This new format is supported via the develop branch of the official cocos2d repository.

-Robert

 

3 Responses to Zwoptex: 1.0.2 Generic Coordinate Format

  1. Roger says:

    I’m using Zwoptex to produce sprite sheets for my game. I do not use Cocco2D, so I need to interpret the data coming in myself and I’m a little confused.

    What exactly is spriteOffset, because it doen’t seem to do what I think it would based on your description? I would assume that adding this offset to the draw position of the sprite would cause it to be draw at it’s original location.

    In my situation, I am importing a small image that sits on a 1024×768 transparent canvas (iPad). The sprite only occupies the top right of the image.

    Here is the xml:

    Object-14.png

    aliases

    spriteColorRect
    {{528, 0}, {496, 426}}
    spriteOffset
    {264, 171}
    spriteSize
    {496, 426}
    spriteSourceSize
    {1024, 768}
    spriteTrimmed

    textureRect
    {{2, 2}, {496, 426}}
    textureRotated

    Why is offset only {264, 171}? I would assume it would be {528, 0}. Clearly I am not understanding what these values are.

    Assuming I wanted to render this sprite relative to it’s location in the 1024,768 canvas, what values should I be using? I can use the first x,y value in spriteColorRect, but it seems like that is what spriteOffset should be.

    As you can probably figure out, I have a bunch of images that are laid out (PS layers) where they need to be drawn on the iPad’s screen and I want to render them all in the right place.

    Thanks

  2. Robert Payne says:

    Hi Roger,

    Sorry for the response delay.

    The spriteColorRect is the rectangle Zwoptex crops out of the original image during trimming. It trims down each edge until it hits a row/column with a pixel that has greater than 0.0 alpha.

    If you were to take your image and starting at pixel 528×0 and draw a rect that is 496×426 it would cover all your non-transparent pixels.

    To answer the second question. The spriteOffset is calculated from the center point of the sprite. It is also calculated in a coordinate system in which 0,0 is the bottom left corner and increases to the top and right.

    So in conclusion the {528,0}, and {264,171} , are actually identical just in different coordinate spaces. Remember if you do use the sourceColorRect values that the Y is top-bottom not bottom-top so you will need to flip it manually if you’re not flipping the coordinate system on the iPad since it defaults to 0,0 bottom left.

    -Robert

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="">