• Dear Cerberus X User!

    As we prepare to transition the forum ownership from Mike to Phil (TripleHead GmbH), we need your explicit consent to transfer your user data in accordance with our amended Terms and Rules in order to be compliant with data protection laws.

    Important: If you accept the amended Terms and Rules, you agree to the transfer of your user data to the future forum owner!

    Please read the new Terms and Rules below, check the box to agree, and click "Accept" to continue enjoying your Cerberus X Forum experience. The deadline for consent is April 5, 2024.

    Do not accept the amended Terms and Rules if you do not wish your personal data to be transferred to the future forum owner!

    Accepting ensures:

    - Continued access to your account with a short break for the actual transfer.

    - Retention of your data under the same terms.

    Without consent:

    - You don't have further access to your forum user account.

    - Your account and personal data will be deleted after April 5, 2024.

    - Public posts remain, but usernames indicating real identity will be anonymized. If you disagree with a fictitious name you have the option to contact us so we can find a name that is acceptable to you.

    We hope to keep you in our community and see you on the forum soon!

    All the best

    Your Cerberus X Team

Mouse optimization

SLotman

Active member
3rd Party Module Dev
Tutorial Author
Joined
Jul 3, 2017
Messages
261
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 ;)
 
I hope you recovered from your moment of horror :cool:
Good job.

EDIT: I have updated Github with your contribution. Thank you.
 
Last edited:
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:
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 :(
 
Its mouseX that seems to be effected. mouseY is fine here. At least with the RockOut example.
 
Last edited:
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.
 
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
 
The input, audio and app stuff in mojo and mojo2 are the same. Only the graphics stuff differs.
 
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
 
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!)
 
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.
 
Back
Top Bottom