In 9 simple events.

https://www.dropbox.com/s/8nemgd09q8jcu ... .capx?dl=0

I cant answer does questions.

But let me suggest another way to tackle this.

https://www.dropbox.com/s/y7cbazqk1ouvfwc/1012.c3p?dl=0

Is this what you want to do ?

LOS works flawless.

https://www.dropbox.com/s/xbkyej0szutnf ... .capx?dl=0

You must have a logical flaw in your events.

https://www.dropbox.com/s/bcdjvcyyj8m9m ... s.c3p?dl=0

Read that comment here ?

This is the most accurate version i can make with my simple talents.

https://www.dropbox.com/s/52ic3swmbkd27 ... .capx?dl=0

The angle is always calculated with the same, non outgrowing, distances.

When doing this on the parallaxing layer the little errors get bigger when it gets far away from the layout origin.

The centre of mass is not used. I just can not get it done when using the centre of mass.

ID in XForID is a number assigned by the system. You can not change its value to anything you want to.

You can of course change that value by touching screen.

The expression Touch.TouchID is holding the value of it.

Write Touch.TouchID to a textbox under a 'On any touch start' event. Watch it evolve to understand it.

Now i understand the problem. I apologize for not getting it earlier.

The reason for this is that the force is pushes from the center of mass and the rotation takes the origin.

But lets first go the path that you started. starting from the collision polygon.

Lets explore the center of mass, see if it drifts.

https://www.dropbox.com/s/6s7ay6vwoxtqb ... .capx?dl=0

It does not. It is pretty stable. But it is a little of do inevitable floating point calculations.

Is that enough to cause a torque when applying a force ?

https://www.dropbox.com/s/s2kl9qpgilaoo ... .capx?dl=0

Darn it, yes it does. So in some way, your guts are right.

Same problem when we use an exact imagepoint ?

https://www.dropbox.com/s/92uz1kof9rsp7 ... .capx?dl=0

Nope, not at all. So it kinda a butterfly effect, a little mathematical error that cause big changes.

I have no idea if it possible to do this better. In real life it is not possible, just less noticeable do the proportions of mass, forces, gravity ..... and so on.

Question remains, is this the cause of the problem we face.

https://www.dropbox.com/s/tb85vpfaawclh ... .capx?dl=0

No, no, i still notice drifting. An that is because the rotation gripes on the origin and the force gripes on an imagepoint that is not the origin. Those forces do not balance out.

But, we can not rotate an object with the center of mass as origin. Well, in a way we can, just set a torque towards the mouse coordinates on that layer. But then i dont know how to avoid the wobbling, the torque will always overshoot a little.

So, we have no other chance (but i am not the smartest in here, maybe someone knows how to stop the wobble) then taking the two system apart. The 'system that rotates in tick steps' and the 'physics system'.

Here goes:

https://www.dropbox.com/s/8tmehuf4r61tc ... .capx?dl=0

Hope this explanation satisfies you.

I do not see a collisions setup in that capx. So i do not understand the initial question, still.

About this capx.

Besides a few weird things that you do, i see nothing wrong, or i miss something.

Weird things ? ....

1 In the physics world there is no such thing as an immediately movement, like you rotate that sprite. That will mess things up, got to do things smoothly. (with respect to time).

2 You compare to mouse coordinates that are not on the layer that you are moving, due the parallax. Run it in debug, en click 'mouse', watch the coordinates for the layers, you will understand.

So, if i do those things in a better way .....

https://www.dropbox.com/s/4sqbnd0bjioqe ... .capx?dl=0

..... Do we still have problems ? Do i miss something ?

LevelArray.Clear() sets every element to zero.

Pointless to use push after that.

Or the array had the size (0,1,1), then push will work as expect, but the clear is pointless

Or the array has elements (10,1,1) then the push will make a 11th X index, clear and push are pointless.

Instead of clear, set the size to (0,1,1). That is a truly empty array.

The AsJSON does not contain the graphics. An array with the AsJSON strings is not enough.

Creating an member from a family creates a random member.

So, the family needs an instance variable identifying the member.

That variable needs to be stored in the array too.

After loading the array, while running trough it

you will have to create/destroy a family member (in a while loop) until it matches that variable. That is not easy, and can eat time. Then set it to the AsJSON string.

Or.

Create the correct sprite (not family) depending on that variable.

That is just a lot of events, 1 creation event for each possible sprite.

Compared to that, Newt's solution is a breeze.

That is what the LOS does already. (had that covered)

There is no distance calculation faster and less resource demanding than the LOS.

1. Graphics issue, got to draw in right proportions.

2. You do not zoom proportional.

3. A scale factor is a number which scales, or multiplies, some quantity.

Why point sampling ? Are you making pixel art ?

Are you scaling each object individually ?

I am getting the idea that you are doing something totally not standard.

Gonna humble back off, might be better if you share a .capx.