It looks like you're new here. If you want to get involved, click one of these buttons!

- 7.5K All Categories
- 10 Help with translations
- 4.1K General questions
- 101 Roadmap
- 344 Game & application design
- 299 Plugins
- 68 User experience
- 74 Marketplace
- 284 Code snippets
- 33 Building a team?
- 261 Suggestions & requests
- 347 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 624 Bugs and issues
- 194 Introduce yourself
- 204 Announcements
- 99 Forum talk
- 395 Relax cafe

bowerandy
Guru

Hi @ar2rsawseen,

I've been trying to implement scaling and rotation about arbitrary points using matrices and I've been using the matrix maths that you so kindly included in GiderosCodingEasy. However, I don't understand your implementation of Matrix:multiply(). The current library has this:

and I think it should be:

Am I just missing something obvious?

best regards

I've been trying to implement scaling and rotation about arbitrary points using matrices and I've been using the matrix maths that you so kindly included in GiderosCodingEasy. However, I don't understand your implementation of Matrix:multiply(). The current library has this:

function Matrix:multiply(matrix) local m11 = matrix:getM11()*self:getM11() + matrix:getM12()*self:getM21() local m12 = matrix:getM11()*self:getM12() + matrix:getM12()*self:getM22() local m21 = matrix:getM21()*self:getM11() + matrix:getM22()*self:getM21() local m22 = matrix:getM21()*self:getM12() + matrix:getM22()*self:getM22() *** local tx = self:getTx() + matrix:getTx() *** local ty = self:getTy() + matrix:getTy() return self:setElements(m11, m12, m21, m22, tx, ty) end |

function Matrix:multiply(matrix) local m11 = matrix:getM11()*self:getM11() + matrix:getM12()*self:getM21() local m12 = matrix:getM11()*self:getM12() + matrix:getM12()*self:getM22() local m21 = matrix:getM21()*self:getM11() + matrix:getM22()*self:getM21() local m22 = matrix:getM21()*self:getM12() + matrix:getM22()*self:getM22() *** local tx = matrix:getM11()*self:getTx() + matrix:getM12()*self:getTy() + matrix:getTx() *** local ty = matrix:getM21()*self:getTx() + matrix:getM22()*self:getTy() + matrix:getTy() return self:setElements(m11, m12, m21, m22, tx, ty) end |

best regards

Likes: Niicodemus

tweets: @ insidebowerhaus blog: http://bowerhaus.eu/blog/blog.html

+1 -1 (+1 / -0 )Share on Facebook

## Comments

Let me fix that

best regards

Likes: ar2rsawseen

But you are completely right, it should behave as expected and thus I've updated GiderosCodingEasy

Additionally I've separated physics extension as Box2Easy.lua as you've suggested before

I might try separate components by logic in similar way, so user could include and require inside init only modules he or she feels are needed

Likes: hgvyas123

First, multiply(). I came up with the exact same fix as @bowerandy for fixing the tx and ty fields. However, I also flipped the order of the multiplication. Matrix multiplication is not communicative, so A*B != B*A. With the way your function is currently written, if you do A:multiply(B) then it results in B*A, which is backwards to me. This is probably a preference thing, but in my mind, I always assumed that the given matrix (self) was being multiplied by the passed in variable (matrix). So that A:multiply(B) results in A*B. So here is my modified multiply().

I've posted my version and an example project at https://github.com/nshafer/Matrix

Thanks,

Nathan Shafer

My original Matrix class was created for easier porting of a game from another JavaScript framework I had before, thus there were difference, sorry if it confused anyone

function Sprite:setScaleXYAboutAnchor(scaleX, scaleY, ax, ay)

..

end

which will scale about an arbitrary anchor point. I've tried the translate(x, y) * scale(sx, sy) * translate(-x, -y) idea but I can't get it to work. Note that the sx, sy are absolute scale values and not relative to the current scale.

Any help greatly appreciated.

@ar2rsawsenn, will you update GiderosCodingEasy with the suggested changes. I'd just like to know which version to rely on.

best regards

@bowerandy: This should be as simple as this:

Thanks,

Nathan Shafer

best regards

https://github.com/nshafer/AnchorSprite

Thanks,

Nathan Shafer

Honestly, it's a testament to the solidity of Gideros that this stuff just works, and works well. And the ability to extend and modify this stuff in Lua is why I'm loving Gideros.

Thanks,

Nathan Shafer

Unfortunately, something in your new matrix stuff has broken some of my existing code to do with SVG loading. I'm using a modified version of Gideros Illustrator, which is an add-on by @Jack888. Basically, I am getting the SVG transform and applying it to a text field but now the y origin of the field is at the top left of the text rather than the baseline. I'm not sure what the problem is but it may, or may not, be related to this:

BTW, if you put my tag (@bowerandy) in any reply I should get an e-mail to say you've replied.

@Niicodemus, the problem with setAnchor() not working for TextFields still remains, I think.

best regards

It was done for many reasons, first because of the improper anchor points for textfield because of baseline fix.

Second @moopf stated that it was difficult to align the texts without proper baseline.

Additionally when implementing setting shadows for TextField, I've had to wrap them in Sprite element, which also fixed the baseline problem in most cases (at least it seemed to fix it for anchor points), as it wrapped the TextField bounds.

And even more additionally there is (or there was supposed to be) kerning option, which would allow to fix the baseline by user themselves if they wanted it too.

It appears to be "somewhere near" top left, is that right? Given a particular text field and font, how can I now calculate where the old origin used to be?

Previously, the matrix transforms that Gideros uses were directly compatible with those in an SVG file. Now, for text fields, they are not because of this origin issue.

Basically, I have a matrix (loaded from SVG) containing a translation to the old origin. I now need to modify this matrix so that it accounts for the changes in GiderosCodingEasy. Currently it appears to set the text offset down by about the M height and offset left by a few pixels. I am not using anchor points.

best regards

best regards

The solution could be to override not with Sprite but empty TextField maybe?

Unfortunately don't have much time to think about it now, I'll try to get back to it

best regards

I updated my text project and you can see that the anchor is getting applied to the teal text. https://github.com/nshafer/AnchorSprite.

Thanks,

Nathan Shafer

best regards

@atilim, would it be possible to integrate this into the base of Gideros so that these calculations don't have to happen in Lua? That would decrease overhead and also make it so that MovieClip worked with this.

Thanks,

Nathan Shafer

While waiting for @atilim to consider adding this to the base, one thing you could do is to only install the extra methods on demand by using a method called like enableAnchors() to install them on a sprite by sprite basis. This would avoid the performance hit when it's not needed.

best regards

Thanks,

Nathan Shafer

best regards

That said, I just changed a couple internal variable and function names so that it will get along nicer with GCE. Now, whichever one gets executed last will determine which one is overwriting the Sprite class. Both create the function Sprite:setAnchorPoint(). If you want to use AnchorSprite's implementation, then make AnchorSprite.lua depend on GiderosCodingEasy.lua, which will make Gideros call AnchorSprite after GCE, and thus AnchorSprite will overwrite GCE's Sprite:setAnchorPoint(). However, that also means that you'll lose any other part of GCE's functionality when it comes to other things it does to Sprite. Mainly because AnchorSprite's Sprite:set() function will overwrite GCE's version. And there's a LOT of stuff that GCE is doing. So honestly, if you're using GCE, you probably want to keep doing that. If you just want anchor support that only applies to sprites you want it to, and don't want any of the other things that GCE provides, then AnchorSprite will probably fit the bill a little better. I wouldn't suggest mixing the two, unless you ripped out the Anchor support from GCE first.

I myself have not included GCE in my projects, but rather I just cut out pieces that I want, and only after I understand exactly what they're doing. It's also been invaluable for learning Gideros. So, that said, @ar2rsawseen, I'm not sure AnchorSprite should be rolled into GCE or not, but you're more than welcome to.

Thanks,

Nathan Shafer