Touch Devices: unintended offset on area() Clickable comps when the Kaboom canvas is positioned absolutely

replit / kaboom

💥 JavaScript game library

https://kaboomjs.com

MIT License

2.66k stars 228 forks source link

Touch Devices: unintended offset on area() Clickable comps when the Kaboom canvas is positioned absolutely #587

Closed MeowcaTheoRange closed 1 year ago

MeowcaTheoRange commented 2 years ago

In my Kaboom game, JellyBean's Mid-Sim, this problem has been solved. Simply use <canvaselement>.pageTop and <canvaselement>.pageLeft to calculate a position offset on the canvas, and then offset any areas that are intended to be clicked. This will fix any offset... if the screen does not get rotated, changing the position of the canvas.

So, I am posting this issue, to bring awareness to this Kaboom bug.

How to reproduce

Partake in mating. Preferably with a member in your same species class.

How to reproduce... this issue

<!DOCTYPE html>
<html>
    <head>
        [<Import Kaboom Lol>]
        <style>
            #kaboom {
                position: absolute;
                left: 900px;
                top: 900px;
            }
        </style>
    </head>
    <body>
        <canvas id="kaboom" />
        <script>
            kaboom({
                width: 100,
                height: 100,
                canvas: document.querySelector("#kaboom")
            });
            loadBean();

            var bean = add([
                sprite("bean"),
                area(),
                pos(40, 80)
            ]);

            debug.inspect = true;
            bean.onClick(() => {
                debug.log("clicked");
                shake();
            })
        </script>
    </body>
<html>

a-a-GiTHuB-a-a commented 2 years ago

Good pun. :>

glantucan commented 2 years ago

Is there a fix for this coming any soon? It is happening to me no matter what the position css property is for the canvas. It seems I could make the workarond proposed by the OP work. But we'd have to change a lot of code when the fix is implemented.

I'm loving kaboom, by the way. I'm actually thinking on migrating most of our games at rockalingua from phaser to this. Using phaser for them is kind of an overkill. And kaboom provides more than enough for what we need.

[EDIT]: Actually, I just realized this is happening only when I resize the canvas to make it responsive, which a must for us.

MeowcaTheoRange commented 2 years ago

[EDIT]: Actually, I just realized this is happening only when I resize the canvas to make it responsive, which a must for us.

yeah i'd say try not to do that

glantucan commented 2 years ago

yeah, but we need to XD

We are making educational games (to teach Spanish) and the whole idea is that kids use them anywhere, in school, at home, on the go with their parents phone, ... and that means we need the games to adapt to many different screen sizes.

I actually think this is a must on any web game.

This is a priority for us, but I understand that it may not be for you, just wanted to know whether it is or not.

In any case, keep up with the great work!!! :)

MeowcaTheoRange commented 2 years ago

Ah, OK, well, here's some tips I can give you:

If you want Kaboom to be adaptive to screen size, to fill the screen all of the time, then I recommend:

removing "height" and "width" properties from Kaboom setup, then it will always stretch to fill the screen
using things like center() to center things to the screen and using width() * [decimal number] or height() * [decimal number] here to get "adaptivity" when it comes to adjusting screen width

What Kaboom won't do is change its' size during runtime. That is currently impossible unless -

you first create a Kaboom game that is at least 3840 x 2160 in size
make a "width/height limit" that adapts to the user's screen size
use that "width/height limit" instead of the width() or height() function for calculating screen width

MeowcaTheoRange commented 1 year ago

Issue has been solved in Kaboom 3000, it seems.