Change in RegionAttachment C

Emblazed · 11 जून 2013

A bit ago I had Spine-c up and running just fine with our internal engine. Today i updated and found a few changes that puzzled me as well as messed with our rendering of spine animations. So my question is..

Previous code for RegionAttachment.c

void RegionAttachment_updateVertices (RegionAttachment* self, Slot* slot) {
	float* offset = self->offset;
	Bone* bone = slot->bone;
	self->vertices[VERTEX_X1] = offset[VERTEX_X1] * bone->m00 + offset[VERTEX_Y1] * bone->m01 + bone->worldX;
	self->vertices[VERTEX_Y1] = offset[VERTEX_X1] * bone->m10 + offset[VERTEX_Y1] * bone->m11 + bone->worldY;
	self->vertices[VERTEX_X2] = offset[VERTEX_X2] * bone->m00 + offset[VERTEX_Y2] * bone->m01 + bone->worldX;
	self->vertices[VERTEX_Y2] = offset[VERTEX_X2] * bone->m10 + offset[VERTEX_Y2] * bone->m11 + bone->worldY;
	self->vertices[VERTEX_X3] = offset[VERTEX_X3] * bone->m00 + offset[VERTEX_Y3] * bone->m01 + bone->worldX;
	self->vertices[VERTEX_Y3] = offset[VERTEX_X3] * bone->m10 + offset[VERTEX_Y3] * bone->m11 + bone->worldY;
	self->vertices[VERTEX_X4] = offset[VERTEX_X4] * bone->m00 + offset[VERTEX_Y4] * bone->m01 + bone->worldX;
	self->vertices[VERTEX_Y4] = offset[VERTEX_X4] * bone->m10 + offset[VERTEX_Y4] * bone->m11 + bone->worldY;
}

Current RegionAttachment.c

void RegionAttachment_computeVertices (RegionAttachment* self, float x, float y, Bone* bone, float* vertices) {
	float* offset = self->offset;
	x += bone->worldX;
	y += bone->worldY;
	vertices[VERTEX_X1] = offset[VERTEX_X1] * bone->m00 + offset[VERTEX_Y1] * bone->m01 + x;
	vertices[VERTEX_Y1] = offset[VERTEX_X1] * bone->m10 + offset[VERTEX_Y1] * bone->m11 + y;
	vertices[VERTEX_X2] = offset[VERTEX_X2] * bone->m00 + offset[VERTEX_Y2] * bone->m01 + x;
	vertices[VERTEX_Y2] = offset[VERTEX_X2] * bone->m10 + offset[VERTEX_Y2] * bone->m11 + y;
	vertices[VERTEX_X3] = offset[VERTEX_X3] * bone->m00 + offset[VERTEX_Y3] * bone->m01 + x;
	vertices[VERTEX_Y3] = offset[VERTEX_X3] * bone->m10 + offset[VERTEX_Y3] * bone->m11 + y;
	vertices[VERTEX_X4] = offset[VERTEX_X4] * bone->m00 + offset[VERTEX_Y4] * bone->m01 + x;
	vertices[VERTEX_Y4] = offset[VERTEX_X4] * bone->m10 + offset[VERTEX_Y4] * bone->m11 + y;
}

The main part that I'm looking at with the change is why x and y are incremented by the bone->worldXY .. this messed our rendering up in a big way..

I have a work around ( pass zero for both x and y ) but what i wanted to know was why is it coded in this way.. is it to support a certain form on atlas sheets or something.. or am i missing something with the code base that i should conform to so that I keep my compatibility with the spine system as a whole.

Thanks for you time and responses.

emblazed

Nate · 11 जून 2013

We had a discussion here:
viewtopic.php?f=3&t=624
The result was that a skeleton should be positioned by using an x and y field on skeleton, not by setting the root bone position. This means in Spine 0,0 should be used as a reference point. When you position the skeleton at runtime, that point becomes 0,0. This enables you to use the root bone as part of your skeleton. Previously you had to leave the root bone unkeyed at 0,0 solely to position the skeleton at runtime.

As a result of that, computeVertices changed to take x and y, which are the skeleton position. All vertices are offset by the skeleton position. Passing 0,0 is perfectly fine if you want the old behavior.

Emblazed · 11 जून 2013

Thanks for he reply.. but just to make things ok going forward. If I just pass zero zero for x and y into this compute function will I be able to use all current functionality correctly as well as things moving forward? Or should i refactor to conform to this change?

Nate · 11 जून 2013

It doesn't make much difference. If you don't want to use the new way to position your skeleton and you want to continue to use the root bone, passing 0,0 is fine. The downside is very minor: you will have the root bone (which has to update its world transform) just to position the skeleton. Focus on making your game work and don't worry about that.