Game in fixed fit projection while cursor in stretched projection. Working with collision boxes

[PaStef]

Hi all,
I’ve made an android game, that I run with the default renderer using a fixed fit projection so that aspect ratios are kept, with a game.project resolution of 640x1136.
It works fine for everything but the cursor/finger (I use defold-input). When I try the game on a longer phone, I thus have black bars and for the cursor the coordinates are as if the game was stretched. As you can see below, reproduced on pc, the cursor has to be higher than the heart to trigger a collision, but the coordinates are right in order to spawn the animation (slash and blood) at the right place on the heart. Same with the swords if the screen is stretched horizontally.

I first thought the collision objects were going off screen, but from what I’ve read in the forum, I understand this is normal behaviour for fixed fit to have the input not included in the fit. However, since I only work with collision objects and messages (the cursor itself has a collision shape) and not coordinates calculations, how can I trick the system about the cursor position, so that it acts and creates collisions where it actually visually is ?
Thank you

[ross.grams]

There’s a brief mention of how to do this in the defold-input readme here, and an example using Orthographic to do the coordinate conversion here.

So the math to convert the coordinates is the tricky bit. I can’t tell you off the top of my head, but it shouldn’t be too hard to figure out. There will be a scale factor (the camera zoom) and probably an offset. I’ve always found it easier to convert from action.screen_x and action.screen_y instead of the already-stretched action.x and action.y, but that’s just a preference.

You might want to edit the render script to make some things (like the zoom) accessible to your input script, either with a module or global variables, just so you don’t have to calculate them twice in different places.

[PaStef]

It worked, I used the orthographic camera and the code shown here.
No math required and only basic configuration, using the camera included render script.
So thanks @ross.grams for pointing me in the right direction, and thanks @britzl for the camera!