Mouse optimization

SLotman

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jul 3, 2017
Messages
223
I was trying to implement something here (CrazyGames SDK), when I ran into a series of problems. Long story short, MouseX() and MouseY() were not working with their SDK implementation, mostly due to Monkey/Cerberus just using canvas.onmousemove, canvas.onmouseup and etc, instead of using canvas.addEventListener('mousemove', ...) and so on.

After I began to get mouse coords again, they were all over the place. So I went into the html5 target and to my horror I see this:

HTML:
    function mouseX( e ){
        var x=e.clientX+document.body.scrollLeft;
        var c=canvas;
        while( c ){
            x-=c.offsetLeft;
            c=c.offsetParent;
        }
        return x*xscale;
    }  

    function mouseY( e ){
        var y=e.clientY+document.body.scrollTop;
        var c=canvas;

        while( c ){
            y-=c.offsetTop;
            c=c.offsetParent;
        }
        return y*yscale;
    }

Every time you move your mouse, those two functions are called. If your canvas is deep into several elements, its clear this is highly inneficient!

So I took code from my games in PixiJS and rewrote those functions to something much simpler:

HTML:
    function mouseX( e ){
        var x = 0;
        if (canvas) {
            var   rect =  canvas.getBoundingClientRect(),
                    root = document.documentElement;

            // relative mouse position
            x = e.clientX - rect.left - root.scrollLeft;
        }
        return x*xscale;
    }
  
    function mouseY( e ){
      var y = 0;
      if (canvas) {
            var   rect =  canvas.getBoundingClientRect(),
                    root = document.documentElement;
            // relative mouse position
            y = e.clientY - rect.top - root.scrollTop;
        }
        return y*yscale;
    }

You can remove the "if (canvas) {" part if you want, looking at it now as I write I see it as unnecessary, but I'll leave it just in case ;)

I haven't tested this extensively on Cerberus/Monkey - but it seems to work fine (including in the CrazyGamesSDK), so I decided to post it here, maybe hoping this could improve the target a bit ;)
 

MikeHart

Administrator
3rd Party Module Dev
3rd Party Target Dev
3rd Party Tool Dev
Joined
Jun 19, 2017
Messages
3,390
I hope you recovered from your moment of horror :cool:
Good job.

EDIT: I have updated Github with your contribution. Thank you.
 
Last edited:

SLotman

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jul 3, 2017
Messages
223
Hmmm. Better hold out on that.

When going fullscreen, something is breaking here - the coordinates seems off somehow.

Yeah, just confirmed: if you set the CANVAS_RESIZE_MODE in MonkeyGame.html to '1' stretch and go fullscreen, the coordinates are going crazy :(
 
Last edited:

SLotman

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jul 3, 2017
Messages
223
Update: OUCH! This is definitively a bug - even with the old functions this happens as well. Going fullscreen (by dragging the debug splitter to the bottom of the window) breaks the mouse coordinates somehow - so not exactly fault of the code I posted.

Don't have a clue how to fix it though. For now, just avoid CANVAS_RESIZE_MODE = 1 :(
 

MikeHart

Administrator
3rd Party Module Dev
3rd Party Target Dev
3rd Party Tool Dev
Joined
Jun 19, 2017
Messages
3,390
Its mouseX that seems to be effected. mouseY is fine here. At least with the RockOut example.
 
Last edited:

Wingnut

Well-known member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
1,229
I'm using Cerberus V2022-01-24 and mouse is perfect in windowed and fullscreen mode with HTML5_CANVAS_RESIZE_MODE=1

Sidenote: I'm doing something else right now with the html5 mouse events I'm trying to get windows 10/11 touch to work bc they are special events in windows they are not like android and ios browsers. two different standards.
 

Wingnut

Well-known member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
1,229
Okay i got the same in mojo1 e.g. Rockout .

i I think there was a bug with like this with mojo2 before and it was fixed .
When you put a #HTML5_CONSOLE_SHOW = False both x and y will map again
 

MikeHart

Administrator
3rd Party Module Dev
3rd Party Target Dev
3rd Party Tool Dev
Joined
Jun 19, 2017
Messages
3,390
The input, audio and app stuff in mojo and mojo2 are the same. Only the graphics stuff differs.
 

Wingnut

Well-known member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
1,229
You are right. I had to try some mojo2 examples to see it myself and i was surprised. I went through everything and I ended finding the reason why it "worked" for me. I had the directives to set my html5 width & height to match my screen ratio. It doesn't matter what resolution but the ratio needs to match the screen.

e.g. a 16:10 display would work with something like
#HTML5_CANVAS_WIDTH = 640
#HTML5_CANVAS_HEIGHT = 400
 

SLotman

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jul 3, 2017
Messages
223
I'm thinking the problem isn't even with the mouse functions, but the screen scaling. Stretch should literally stretch the screen to fill the whole available area (specially on fullscreen), but I'm seeing borders - and the mouse coords are definitively taking the borders into account.

(The mouse coords MouseX / MouseY are actually clipped, so if you draw your own mouse pointer instead of using the system's you won't see anything wrong with it - the crosshair into rockout is a perfect example of this!)
 

Wingnut

Well-known member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
1,229
I can't remember but I was trying to explain this as a bug a year ago or so but it's not really a bug, it behaves differently bc of the browser. Desktop is fine. One of the big browsers stood out in how it does fullscreen. It's actually a html browser resolution thing.
 
Top Bottom