Resizing Preview Window Affects Mouse.AbsoluteX Event Checks

0 favourites
  • 2 posts
From the Asset Store
Save hours of work by resizing items on your game screens.
  • GOAL

    Using the Absolute X value of the Mouse to determine when to rotate the Player's angle (and thus the 3D camera with it).

    If Mouse.AbsoluteX is less than 1/3 the width of the viewport (layer "HUD", set with a 0x0 parallax and 2D layer rendering) then rotate counter-clockwise.

    If Mouse.AbsoluteX is greater than 2/3 of the viewport, rotate clockwise.

    (In the screenshot, I had this backwards by accident.)

    Now, this WORKS...but with a small catch


    When doing a preview play of the game, resizing the preview window affects the viewport width (default 1500 pixels). Even though I tell it to check for 1/3 or 2/3 of the viewport width, regardless the current width of the window/viewport.

    Yet, when I resize it bigger or smaller than what the preview window started at, the two condition lines I highlighted in the first pic still calculate things at 1500 pixels even though, as my second pic points out, the viewport is more than 1500 pixels.

    (When the preview window is resized smaller, thus the viewport is less than 1500 pixels wide, I can't even begin to made it rotate clockwise.)

    In this second image, the preview window is enlarged to fix my monitor's full size. As a result the viewport width is greater than 1600 pixels. This isn't necessarily a problem because the event lines are not looking for specific values but a fraction of a value, whatever that value is at the time.

    The actual problem is that as the viewport, itself, is resized, that new viewport width value does not seem to be taken into account. For example, if I resize the preview window significantly smaller and try to move the Mouse to the far right of the viewport, it will not cause the Player to rotate whatsoever because the viewport is much smaller than 1500.

    When the preview window is close to 1500 pixels (the default value I set in the project parameters), 1/3 of that is 500 and 2/3 of that is 1000. But these values do not register. It's actually at values just a bit less than 500 and 1000 before the appropriate actions take place.

    In the image above, there is a rainbow-colored bar that I was using originally. On it are two small tick marks to denote where the 1/3 and 2/3 portions of the bar are at. These were supposed to be the visual cues (for testing) to let me know where the Player/camera should start rotating clockwise or counterclockwise. However, I discovered that ultimately even the object when used as a reference produced the same problem as using the viewport width as a reference.

    Is this a bug or is there a detail I'm missing?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • The mouse absolute position is not directly related to the viewport size, so you probably don't actually want to compare them.

    The mouse absolute position is basically the offset from the top-left of the canvas in CSS co-ordinates. The absolute position of the bottom-right corner depends on the window size, as a bigger canvas means a bigger absolute position. The viewport is how much of the layout content you see. Think of a 2D game: the viewport size stays the same even if you resize the window smaller or larger. It just means the same viewport sized content is displayed bigger or smaller.

    You probably want to either compare the mouse absolute position to the canvas CSS size (from PlatformInfo), or compare the mouse position on a 2D layer to the viewport size.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)