Difference between CanvasToLayerX / Y and Mouse.X / Mouse.Y

What is the difference between these expressions:

CanvasToLayerX("Layer 0", Mouse.AbsoluteX, Mouse.AbsoluteY)

and

Mouse.X("Layer 0")

?

I was using these in a large (like 10,000 x 10,000 px field) zoom and pan, and they behave much differently, despite the fact that they seem conceptually the same.

Nobody knows how either of these work?

To be totally honest, I'm also waiting for someone who understands what the mouse.absolute(x/y) expression does in practice to answer this!

I use it in practice, and as far as I can determine it gives the mouse coordinate in a local layer. For instance, I have a 10,000 x 10,000 (roughly) pixel canvas that I zoom in on. The Mouse.absoluteX and Mouse.absoluteY give you the mouse coordinates with respect to the screen. Mouse.X("layer") and Mouse.Y("layer") gives me the mouse coordinates with respect to my 10,000 x 10,000 px grid.

I am not really certain at all how the other expression works or what canvas it is mapping from. I assume it is mapping from the c2canvas to whatever layer I specify, but I don't see why it needs both x and y coordinates to do that.

It should be the same as far as I can tell. Have you got an example where they give different values?

Is this what you try to do?

https://www.scirra.com/tutorials/1167/layertocanvascanvastolayer-example

Sort of. I am actually using it for a mouse-wheel-based zoom and pan (like Google maps) sort of thing.

I mostly want to know how that particular function works on the inside.

I think they are identical. When you give a layer name to Mouse.X/Y, it does the same math as canvastolayer.

What math is that though?

Why does it require a y-component for the X layer and an x-component for the Y layer though? That seems intuitively odd.

Either way, using the CanvasToLayerX/Y fixed (or at least markedly improved) our spastic zoom and pan problem over using the Mouse.X and Mouse.Y.

I suppose it would be nice to have more precise and thorough documentation, although I would much prefer Scirra improving Construct into the website design arena over improved documentation.

My guess is x and y are needed if The layout or layer is rotated. If you really want to see the math you can look at the js files in the exporter directory of the C2 install.

The manual covers what the mouse expressions do pretty well imo:

https://www.scirra.com/manual/114/mouse

[quote:2u6007p7]Mouse expressions

AbsoluteX

AbsoluteY

Return the position of the mouse cursor over the canvas area in the HTML page. This is (0, 0) at the top left of the canvas and goes up to the window size. It is not affected by any scrolling or scaling in the game.

X

Y

Return the position of the mouse cursor in game co-ordinates. This is (0, 0) at the top left of the layout. It changes to reflect scrolling and scaling. However, if an individual layer has been scrolled, scaled or rotated, these expressions do not take that in to account - for that case, use the layer versions below.

X("layer")

Y("layer")

Return the position of the mouse cursor in game co-ordinates, with scrolling, scaling and rotation taken in to account for the given layer. The layer can be identified either by a string of its name or its zero-based index (e.g. Mouse.X(0)).

https://www.scirra.com/manual/126/system-expressions

[quote:2u6007p7]Layers

In expressions where a layer is required, either its name (as a string) or index (as a number, zero-based) can be entered.

CanvasToLayerX(layer, x, y)

CanvasToLayerY(layer, x, y)

Calculate the layout co-ordinates underneath a position in canvas co-ordinates for a given layer.

LayerToCanvasX(layer, x, y)

LayerToCanvasY(layer, x, y)

Calculate the canvas co-ordinates above a position in layout co-ordinates for a given layer.

I'm curious in what ways you'd like it to be improved?

I bet you are right on R0J0, that would make sense, if you rotate the frame of reference.

I guess just the specific equations that are doing the translations. From those descriptions they seem like they would be identical, but I do not believe that they are. I am really a Java programmer who got whisked into the JavaScript realm somewhat unwillingly, so I am extremely grateful for Construct. I am just used to documentation that allows me to follow the number trail when it comes to mathematical manipulations. I could take the time to work out an approximation for what is in the black box, but I think that my time is better spent pressing our game development further.

Either way, it works for us for now, so I can't complain too much.

I'd like to see either an improved or new version of CanvasToLayerX/Y so that it can be used in games that use dynamic displays (such as fullscreen or varying window sizes) because it isn't useful when the canvas changes size/scale. This would be useful for converting coordinates of an object on a layer that scrolls to a HUD layer for instance. Maybe a LayerToLayerX/Y expression.

We have managed to use CanvasToLayerX/Y for our UI layer to resize all of our UI to fit the user's screen. A randomly funny side effect of this block is that it effectively disables the browser's ctrl-mouse-wheel zoom functions, since the UI automatically resizes itself to what we specified.

This method works well beyond my expectations though, which is nice.

Another nice side effect is that you can rearrange your UI based on the user screen's aspect ratio to have a different display for smart phones etc.

[attachment=0:1awaa0ls][/attachment:1awaa0ls]