either localToGlobal or hitTestPoint is wrong when considering a Shape with a texture transformation matrix

[miellaby]

The last release of Gideros (september) fixed up the rendition of a shape with a rotated texture via a transformation matrix (3d parameter setFillStyle).

However my hand-made 2d physics engine doesn't work yet for such shapes. My collision routing is all buggy.

According to me, either hitTestPoint or localToGlobal is broken in such a combination Shape+texture transformation matrix (also the shape itself is a horizontal rectangle rotated with setRotation). I can't exactly tell what's wrong, I'm a bit lazy here.

Also there is a possibility the API changed, if so, feel free to reject this bug.

[ar2rsawseen]

Just FYI hitTestPoint always tested against max boundaries (a rectangle in which you can put the shape it) it does not test against shape border, but only against the dimensions you get in getBounds() method

[miellaby]

Good point. thanks. But I'm already aware of that. FYI these shapes are used to draw the platforms of my game Renabomb ( http://giderosmobile.com/apps/renabomb-vengeance ).

Every shape is actually a rectangle (why I used a shape to begin with? because how it can crop the texture the way I want when the platform is smaller than the picture).

On a side note, I've just noticed that I'm not forced anymore to set up my transformation matrix to additionally rotate the texture by +/-90° when the shape is rotated with setRotation. I don't know when this bug was fixed.

[miellaby]

@ar2rsawseen, your remark made me wonder if something changed since version 2014.01.

So I modified the demo project Button.gproj to demonstrate the API change.

In main.lua, I rotate the button.

button:seRotation(45) -- diagonal !!!!
button:setPosition(50, 100)
stage:addChild(button)

and it works very well in release 2014.01 and not in the last release. As you more or less predicted, hitTestPoint now matches an horizontal boundary rectangle an not an inclined rectangle by taking into account the rotation angle as it used to. Is it normal? Should I forget the hope to package my game with a more recent Gideros version?

[hgy29]

@miellaby, this is definitely a bug, and I am afraid I introduced it in one of the latests releases (2015.8 or 2015.9). I wonder how I can have missed it.

Let me explain: hittestPoint works by checking if a given point is within the Sprite's bounds, those bounds being the minimum square that enclose the shape. Previously the screen coordinate (mouse) was transformed into the sprite's local coordiniates by reversing all transform matrices used for display, then the check was made in sprite's local coordiniates (i.e. unrotated in your example).
This caused various issues (untransformable matrices, clipping strangeness, 3D perspective issue,..) so I thought it was a good idea to check the coordinates in screen space directly (forward transforms only).

However for a rotated shape, the bounding box as seen in screen space changes, and this is what you see... So I'll have to find another way: either reverting (and reintroducing bugs), or maybe carry more geometrical information during transforms (vectors ?), or even make it be a polygon hitTest...

[ar2rsawseen]

Well problem is that previously provided x,y coordinates were transformed to transformed Sprites coordinates, but now Sprites are untransformed back to global coordinates.
https://github.com/gideros/gideros/blob/master/2dsg/sprite.cpp#L708

My guess is, it was done to handle clipped children and parents relations.

@hgy29 is it possible to take transformation in consideration when determining hitTestPoint as it used to be, while keeping still handle clips in Sprite hierarchy? Maybe transforming x, y coordinate to whole children stack, rather than untransforming Sprites back?

[ar2rsawseen]

@hgy29 ninjajed me :)

[ar2rsawseen]

Maybe, at least for quick solution, it is possible to determine in which case to use which approach? If any of parents are clipped then you most probably need a bounding rectangle either way, if not then transform coordinates to Sprite.

[hgy29]

I've had a lot of thinking about this, and got an idea: instead of using axis-aligned bounding boxes (i.e minx,miny,maxx,maxy), we could consider the bounding box as an arbitrary four point polygon, and transform those four points across hierarchy. The only tricky part (and it should be fairly simple) is to determine the best bouding polygon out of each child own bounding polygon.

[AnthonyBall1966]

Maybe have that as a different function so you can specify x1..xn and y1..yn (not just 4 points) and make the existing function a helper into the other function?
On 2 Oct 2015 08:24, Nicolas Bouquet notifications@github.com wrote:I've had a lot of thinking about this, and got an idea: instead of using axis-aligned bounding boxes (i.e minx,miny,maxx,maxy), we could consider the bounding box as an arbitrary four point polygon, and transform those four points across hierarchy. The only tricky part (and it should be fairly simple) is to determine the best bouding polygon out of each child own bounding polygon.

—Reply to this email directly or view it on GitHub.

[AnthonyBall1966]

That way you could add a function available in Lua to redefine the collision shape for a particular sprite?
On 2 Oct 2015 08:24, Nicolas Bouquet notifications@github.com wrote:I've had a lot of thinking about this, and got an idea: instead of using axis-aligned bounding boxes (i.e minx,miny,maxx,maxy), we could consider the bounding box as an arbitrary four point polygon, and transform those four points across hierarchy. The only tricky part (and it should be fairly simple) is to determine the best bouding polygon out of each child own bounding polygon.

—Reply to this email directly or view it on GitHub.

[ar2rsawseen]

Was this one fixed already?

[hgy29]

Not yet, I am afraid. But it is still on my mind...

[ar2rsawseen]

Ok, no problem, just checking :)