Jump to content
Sign in to follow this  
sonder

Flipping not working

Recommended Posts

I suspect that the code in scmlreference does not support flipping because setting either scale parameter negative in characterinfo only flips each piece individually rather than the entire model. I'm just confirming if this is the case and looking for suggestions or possible workarounds. Or if I'm missing something.

Edit: Anyway I don't think we want to flip the images, the shading (side-lit) gets flipped too which looks bad. What we need is a way to flip the bones...

Share this post


Link to post
Share on other sites

Unfortunately I can't test this myself, so I could be missing something running through it in my head, but if you want to create a special method for your implementation -

I think flipping using characterinfo method as you described, and then if the item is a sprite (not a bone) flipping it back (*-1) - I believe should do exactly what you're saying. Just make sure it's a separate case so that you don't do that when just attempting a regular flip.

Edit: Just reread your original post, and noticed the bug with the collar in the image. To be clear the characterinfo flip should accurately flip the entire character correctly, creating a perfect mirror image. If it doesn't it's either a bug in your code, or the reference:

This code here:

            if(currentRef.parent>=0)
{
parentInfo=transformBoneKeys[currentRef.parent].info;
}
else
{
parentInfo=characterInfo;
}

under updateCharacter()

should use the CharacterInfo as the parent data for everything without a parent. This means that top level bones, and sprites that have no parent bone should all be flipped as you'd expect, which in turn would propagate down through all child bones flipping/scaling/rotating/moving the entire character, whether or not the character uses bones and sprites, just sprites, or a mix of unparented sprites, and bones

Share this post


Link to post
Share on other sites

Yeah, about the conditional parenting I believe that's what the code is doing, but I'll double check that.

Strangely I think that vertical flipping (via scalex, so actually horizontal rotated) is working but not horizontal (via scaley). Maybe it could be an issue with unmapfromparent? You've tried flipping in both directions?

This code here:

            if(currentRef.parent>=0)
{
parentInfo=transformBoneKeys[currentRef.parent].info;
}
else
{
parentInfo=characterInfo;
}

under updateCharacter()

should use the CharacterInfo as the parent data for everything without a parent. This means that top level bones, and sprites that have no parent bone should all be flipped as you'd expect, which in turn would propagate down through all child bones flipping/scaling/rotating/moving the entire character, whether or not the character uses bones and sprites, just sprites, or a mix of unparented sprites, and bones

Share this post


Link to post
Share on other sites

hi Sonder. Sorry about the delay in response.

Can you see if this fixes your problem?:

if(parentInfo.scaleX*parentInfo.scaleY{
unmappedInfo.angle=(360-angle)+parentInfo.angle;
}
else
{
unmappedInfo.angle=angle+parentInfo.angle;
}

If this works, I'll add it to the next update of the documentation.

Share this post


Link to post
Share on other sites

[strikethru]Thanks Lucid, unfortunately that didn't work.[/strikethru]

I know that characterinfo is being used on the "root" bone for sure - a debugging sessions showed that all the other bones have the -1.0 scaley propagated.

I think it has to be a problem in the bone transformation stage but I'm not sure if it's a problem with my code or the psuedocode.

This is some Forth code. I know it's unlikely, but see if you can make some sense of it. (mini cheatsheet: keywords and symbols are executed from left to right with no exception, ( ) just means a comment, ! means =, @ means "fetch value", and p is short for fixed-point)


: unmapFromParent ( struct = spacialinfo ; parentinfo destinfo -- )
locals| dest parent |

angle @
scale 2@ p* 0< if 360.0 swap - then
parent >angle @ + dest >angle !

scale 2@ parent >scale 2@ 2p* dest >scale 2!

( a @ parent >a @ p* dest >a ! )

parent >px 2@
px 2@ or if
px 2@ parent >scale 2@ 2p*
parent >angle @ 2rotate 2+
then
dest >px 2!

pivot 2@ dest >pivot 2!
;

I'd show you the bone transform code but it bears pretty much no resemblance to the pseudocode.

edit: oh, oops! I was supposed to check the parent scale wasn't I. standby.

edit2: OK this is what happened when i fixed that. ScaleY=1: https://www.dropbox.com/s/mmvutqlf1xbwi ... .13.04.png ScaleY=-1: https://www.dropbox.com/s/zjrq9zhuiat06 ... .13.06.png

I'm starting to wonder if I'm supposed to be using ScaleY ... shouldn't ScaleX be the one? I only did that because the source animations are "rotated" and I can't even remember what my logic was there.

edit3: Success. https://www.dropbox.com/s/3506il73pt613 ... .18.24.png

Indeed I was supposed to be using ScaleX all along and your fix seems to have worked.

Share this post


Link to post
Share on other sites

OK I seem to be having trouble flipping the Grey Guy, and I'm not sure I'm following what's happening above. I've tried every variation I can think of with no luck.

My guy looks perfectly fine with characterInfo values of x,y, = 0,0 and scaleX, scaleY = 1,1. If I change scaleY to be -1, to try and flip him the other direction, things become very messed up. scaleX at -1, is just as messy. Both at -1 produces a clean image, just flipped on both axes.

Where does the code Lucid suggested go? I tried it in the unmapFromParent() code, separately before that in the bone and object key loading, after the keyFromRef() call.

Also, I had to add a transform before painting of the pivot points, to get my code to draw correctly. So I'm guessing an adjustment may need to be made there, but I'm not sure how.

Here's my addition pivot transform code, where k is the current object key being processed.

		float offsetX = (pivotX - 0.5f) * img_dims.first; // image width
float offsetY = (pivotY - 0.5f) * img_dims.second; // image height
float sprite_x = -offsetX*k.info.scaleX;
float sprite_y = -offsetY*k.info.scaleY;

bool flipped = ((k.info.scaleX < 0) != (k.info.scaleY < 0));
float angle = k.info.angle;

if (flipped)
angle = -angle;

float s = (float)sin (angle * SCM::DEG_TO_RAD);
float c = (float)cos (angle * SCM::DEG_TO_RAD);
float xnew = (sprite_x * c) - (sprite_y * s);
float ynew = (sprite_x * s) + (sprite_y * c);
xnew += k.info.x;
ynew += k.info.y;

sprite_x = xnew;
sprite_y = ynew;

// Let the renderer draw it
sprites[parentSprite].paint (k.spriteKey.folder , k.spriteKey.file , sprite_x , sprite_y , flipped ? -k.info.angle : k.info.angle , k.info.scaleX , k.info.scaleY , k.z_order);

Any ideas where I've gone wrong?

Thanks. Russell.

Share this post


Link to post
Share on other sites

Been trying all sorts of combo's. This is the closest I've got with using the absolute of the scale values when calculating sprite_x and sprite_y, but I can't figure out where the final alignment issues are. Nothing I try to adjust the pivot offsets gets any closer to a final image. Given my non-pivot code seems to be the same as what is recommended elsewhere, I can only think the issue is in my pivot adjustments.

Jg6Zrjs.png

*EDIT*

Actually I can get a slightly closer image in some components, by changing the new x value sin/cos line to a + instead of a -, which has some consistency with flipping. Here's the bits of code changed from what i posted above, and the final image I have.

		float sprite_x = offsetX * std::abs(k.info.scaleX) * -1;
float sprite_y = offsetY * std::abs (k.info.scaleY) * -1;

float s = (float)sin (angle * SCM::DEG_TO_RAD);
float c = (float)cos (angle * SCM::DEG_TO_RAD);
float xnew = (sprite_x * c) + (sprite_y * s);
float ynew = (sprite_x * s) + (sprite_y * c);

0WpnCuB.png

Share this post


Link to post
Share on other sites

*EDIT*

OK, finally got it all figured out. I was trying to do the pivot adjustment on the spriter data all this time, when i should have just been doing it on my Shiva images, using the spriter data. So yeah, in the end, I threw out all my pivot code changes, and just had to change the paint method to accept the pivot value, and then subtract that from the final image location. The one trick with all that, was that the final pivot adjustment is in local coordinate space, not global.

Hope my wild rambling will be of use to some future implementers.

Thanks.

Russell.

Share this post


Link to post
Share on other sites
hi Sonder. Sorry about the delay in response.

Can you see if this fixes your problem?:

if(parentInfo.scaleX*parentInfo.scaleY<0)
{
unmappedInfo.angle=(360-angle)+parentInfo.angle;
}
else
{
unmappedInfo.angle=angle+parentInfo.angle;
}

If this works, I'll add it to the next update of the documentation.

I just wanted to confirm as someone who is working to adopt the Spriter format, after spending hours trying to figure out why my flipping also wasn't working as it seemed it magically should, following the reference as much as applicable etc... yes, I needed this block of code! So I can definitely say this should be put into the SCML reference.

Share this post


Link to post
Share on other sites
hi Sonder. Sorry about the delay in response.

Can you see if this fixes your problem?:

if(parentInfo.scaleX*parentInfo.scaleY<0)
{
unmappedInfo.angle=(360-angle)+parentInfo.angle;
}
else
{
unmappedInfo.angle=angle+parentInfo.angle;
}

If this works, I'll add it to the next update of the documentation.

I just wanted to confirm as someone who is working to adopt the Spriter format, after spending hours trying to figure out why my flipping also wasn't working as it seemed it magically should, following the reference as much as applicable etc... yes, I needed this block of code! So I can definitely say this should be put into the SCML reference.

Yep, I was wondering why my flipping wasn't working. This did the trick for me too!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...