sonder Posted December 8, 2013 Report Share Posted December 8, 2013 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... Quote Link to comment Share on other sites More sharing options...
sonder Posted December 8, 2013 Author Report Share Posted December 8, 2013 So you can see what I'm talking about, here's unflipped https://www.dropbox.com/s/sn3v0rvvsoord ... .43.40.png and flipped (negative y scale ... it would be x but the model is animated "on its side" for reasons I don't really understand but the animator said this was best) https://www.dropbox.com/s/47eibgk81voud ... .43.09.png Quote Link to comment Share on other sites More sharing options...
lucid Posted December 9, 2013 Report Share Posted December 9, 2013 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 Quote Link to comment Share on other sites More sharing options...
sonder Posted December 9, 2013 Author Report Share Posted December 9, 2013 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 Quote Link to comment Share on other sites More sharing options...
sonder Posted December 18, 2013 Author Report Share Posted December 18, 2013 Bump Quote Link to comment Share on other sites More sharing options...
lucid Posted December 18, 2013 Report Share Posted December 18, 2013 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. Quote Link to comment Share on other sites More sharing options...
sonder Posted December 19, 2013 Author Report Share Posted December 19, 2013 [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. Quote Link to comment Share on other sites More sharing options...
Mick Posted February 17, 2014 Report Share Posted February 17, 2014 I made a C++ implementation and got the same bug with axis flipping. Your fix solved the problem. Thanks! Quote Link to comment Share on other sites More sharing options...
8DashP Posted March 21, 2014 Report Share Posted March 21, 2014 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. Quote Link to comment Share on other sites More sharing options...
8DashP Posted March 21, 2014 Report Share Posted March 21, 2014 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. *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); Quote Link to comment Share on other sites More sharing options...
8DashP Posted March 22, 2014 Report Share Posted March 22, 2014 *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. Quote Link to comment Share on other sites More sharing options...
southbird Posted June 8, 2014 Report Share Posted June 8, 2014 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. Quote Link to comment Share on other sites More sharing options...
Dredok Posted July 20, 2014 Report Share Posted July 20, 2014 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! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.