Add a more "standard" spritesheet format

[melonjs]

Zwoptex, TexturePacker or any other stuff with an easy and popular format !

[jarruda]

+1

[melonjs]

hehe :)
any suggestions ?

[jarruda]

Cocos2D implements the zwoptex format, which both TexturePacker and (obviously) zwoptex implement. It seems to have become somewhat of a standard. I'm not really a fan of using XML for that sort of thing, but plists are natively supported on iOS, so I guess that's why they chose it. JSON would have been more compact and easier to parse.

Rotation is part of the standard, however; so you would be blocked on this until you implement rotation in your sprite classes.

[Chuckeltard]

I was also hoping to use Texture Packer, has anyone worked on this? Or found a good way to use better sprite sheets?

[nvlbg]

Well yeah, I'm using it, although it might be improved a lot.

In TP you can tweak the settings, so each of your sprites will be the same size as the others, and with different padding space (so it's the same size as the others, right?), and update the colRect for each entity.

In the game I'm developing I use this approach, although I really want to use some better format, so I can strip those empty pixels from my spritesheet.

[melonjs]

Hi guys, now that ticket #15 is done (will make it easier to add additional format) and that I just finished JSON parsing (which means it's easy to add for this as well) my next step is to look at adding Texturepacker support.

I however have a few questions as I don't really know how to start this.

basically, the idea of Texturepacker is obviously to pack all sprite in a single image and build out of it a texture atlas, kind of dictionnary that contains position and setting for all single image.

In melonJS is working today, the most simple renderable element is the spriteObject, and then AnimationSheet that takes in input a sprite sheet with fixed cell size.

with Texture Packer how would this work, knowing that all image can have different size ? I'm trying to see how it could then be used (programmatically) when adding a renderable element to an entity that would be using TexturePacker, but I cannot see it....

I was initially thinking that a texturePacker "object" could define a function that would returns a specific sprite(s), but then if it;s about creating an additional image in memory all benefit of texture packer is lost !

[parasyte]

My understanding is that these texture atlases contain information about positioning each frame, relative to an object's "center point" maybe. Without at least that, supporting different sizes for each animation frame would be a complete headache to manage. Likewise, the atlas should contain information about frame ordering and durations.

[melonjs]

Yep actually from what I saw so far (in other implementation) this can be seen as 2 different objects :

• a first Atlas Object that basically contains the dictionnary
• a texture sprite, that takes as parameter the texture itself and "part" of the atlas linked to the object we want to display. (At the end it ends up being like the current AnimationSheet)

[melonjs]

This is also linked to ticket #15, but since I'm having these questions when implementing this, here they are,

How is a sprite supposed to be displayed corresponding to an entity ?
for sure the position should be relative to the entity itself (which is what I've done when displaying the renderable), but with sprite size and entity size not being aligned aligned anymore (as entity does not inherit anynmore from sprite), it might/will cause some noticeable differences (specially with texturepacker where individual png in the texture file can be trimmed/cropped, and have different size).

• So do we take the basic assumption that the anchor point for renderable is (0,0), or the center (.5, .5), or (1,1) ?
• Do we need a way to change that (like ensuring that they are bottom aligned), and how to properly managed that ?

If anyone passing by here, some light/idea would be appreciated :)

[parasyte]

@obiot, my recommendation here is anchoring to the center (0.5, 0.5). This is also inline with physics engines (box2d/chipmunk) which describe object positions relative to their center, and polygons are defined by vectors around the center, rotation around the center, etc.

I'm looking at the ticket-8 branch now, but I don't see any information about sprite anchor points. :( https://github.com/obiot/melonJS/blob/d73a489f3a9b90abe06f58d3abb5262ff6ca0136/examples/platformer/data/gfx/texture.json I guess this info has to be added outside of texturepacker? Or maybe it's a matter of the source images you used to create that atlas?

As I understand it (reading forum posts) the TexturePacker "trim" feature will remove the transparent pixels, and store some information about the original image size in the meta data. That's probably what these spriteSourceSize/sourceSize properties are for. So as long as each animation frame from the source images are the same size, this method should work correctly, allowing the use of center point as the anchor.

[melonjs]

@parasyte thank you for the feedback as always :)

But do we say here that both the entity (than inherit from rect) and the sprite anchor points should be aligned ?

Else, ticket #8 is still pretty draft, but for the trim function yes, that’s the idea.
Position is wrong as well when rotated (but that should be fixed if we default the position to (.5, .5)

[parasyte]

@obiot I think it would be very useful to transition all anchor points to default to object center, including position vector. It will be really odd for upgrading the lib in existing games. But it will make a log of things much easier for us when we have multiple renderables, and when we decide to integrate a physics engine. :)

[melonjs]

@parasyte
I’m not sure I’m really following you when you say including position vector… as how can both the object anchor point and position vector aligned to the same point ? (other one center)

Would you mind explaining me with some example ?  like compared to what I did in ticket#8 (entity draw function)

Else I completely agree about any breaking changes, and if we want melonJS to go to the next level some are anyway required !

[parasyte]

@obiot Currently, position vectors are "anchored" to (0,0) on the object. The coordinate of the left side is given by pos.x, and the coordinate for the right side by pos.x + width. My proposal is changing the "anchor" to the middle, e.g. (0.5,0.5), so the object's left side coordinate is pos.x - halfWidth, and the right side is pos.x + halfWidth. Same for the the vertical position.

[melonjs]

http://www.qcmat.com/understanding-anchorpoint-in-cocos2d/

[melonjs]

@parasyte

I ended up having very little free time during this weekend, but I finally implemented the changes we discussed for the renderable positioning :

Here is what I did :

• Entity Objects now also have a anchorPoint which is used to position renderables
• Default position is (around) the center of the entity (0.5, 0.5)
• Anchor point (0,0) is the top left corner of the object, anchor point (1,1) is the bottom right : I don’t know if there is any standard regarding this, I’ve been goggling it but could not find anything, so I just followed what we did so far (the anchor point in sprite object uses the same)
• Renderable are bounds to the rect size of the entity, which means that when specifying (0.5, 1.0), the renderable will be bottom aligned with the entity rect. I think that this makes sense when dealing with sprite and entity (and is the behavior you can find in the above link), and will help with defining later several entities that might all share the same collision box.
• The anchoring computation code might need some optimization, though I didn’t figure out how to perform less operation at each time (maybe using some function caching?)

And that should be all I think ?

I think that if this thing works well, I will commit back a first version of ticket #8 in the master branch (while keep working on ticket #8 to add SpriteAnimation), I know that this is not yet finished, but at least we have a first version with a sprite object that can be extracted from textureapacker and most of all the new object positioning (the sooner we expose it, the sooner people will use it).

What do you think ? would you see any other “must” change stuff if we do so ?

[melonjs]

I was just thinking that it's nice to see that when things are well thought they all come together quite nicely :)

[parasyte]

@obiot OoooOOOoooo! :D

TBH, I don't know of any other engines/frameworks that use unit vectors for anchor point, but it really simplifies the math involved when used with the Vector2D class. I like it. (Chipmunk uses unitless vectors for the center point; the numbers don't necessarily correlate to any specific length. Typically though, it's easiest to treat the vectors in Chipmunk as pixel lengths. At least, in my experience.)

However, Chipmunk is a bit different still: It uses (0,0) as the center, and negative numbers for left/down, and positive numbers for right/up. (Remember: it assumes the Y-axis is reversed!) So in Chipmunk, the upper-left corner of a 10x10 rectangle is (-5,5) and the lower-right corner is (5,-5)! This is done so the position of an object in world coordinates is equivalent to position (0,0) relative to the object, and makes specifying anchors for joints/constraints super easy.

I haven't looked at the code for this yet, but it sounds cool!

[melonjs]

@parasyte

note that it's still time to align it to what chipmunk is doing, so far almost nobody used this in melonJS , so it's just a matter of deciding what is the "best", knowing that ultimately being closer from what is chipmunk is doing will for sure ease our life when integrating it (either as plugin or not)

though to be honest, while i can understand that the y axis can be reversed, having (0,0) as center point looks however strange to me )

[parasyte]

I think that's pretty common when defining polygons. When I was learning OpenGL, the same convention was used. For example, about 1/3 down the page: http://openglbook.com/the-book/chapter-2-vertices-and-shapes/ there's a diagram of a triangle defined in 3-dimensional space which uses (0,0,0) as the center point. (Also note the reversed Y-axis in OpenGL, too! This actually matches the Cartesian coordinate system, and geometry in general.)

[melonjs]

@parasyte
so what do we do ?

note that if we keep (0,5, 0.5) as the reference center point (which furthermore really ease with the corresponding math), it's probably better to keep what I did as well (maybe less confusing to understand as well), or set (0,0) as bottom-left and (1, -1) as top right ?

[melonjs]

@parasyte

Animation is there ! it still need further testing and tweaks (as right now when using rotation option or non trimmed sprites, final position can be a bit off), but else it works just as I wanted :)

if you want to try, make sure you disable rotation, and enable trim !

[melonjs]

@parasyte thank you for the last code review, I effectively forgot the one when creating sprites ;)

I did not do much today (I was the whole day to some exhibition for my company), but I will merge this baby tomorrow in the main branch. it's late now here, i'm tired, and I'm lazy then to update the wiki and write a post in the forum with the changes, and seek for our usual beta-testers :)

[obiot]

I'm closing this one, as the point was to add a more generic/flexible texture format, which we did, and so far so good (i don't believe it being100% bug free, but at least it's mature enough tho consider this one done).

if more format are to be added they can be managed through specific ticket/request.