Absolute Mouse

0 favourites
From the Asset Store
Total customisation of the input! You can combine inputs from all peripherals. Make your game accessible for everyone!
  • R0J0hound ah that's a good idea. Not sure why I didn't think to use absolute to see if it moved and the regular X for position. For some reason I was thinking I needed to use one or the other.

    That fixes the wake up problem. Although I still have the problem of when the mouse is awake and I slide to the next screen you see the mouse moving - which isn't a terrible thing, I just wanted it to stay in place and not "hover" over things as it moves across the screen.

    In general if you set a sprite to mouse.x/y there is a tiny little lag - a player wouldn't notice, but because I swipe screens and move pretty fast with easing (meaning the screen swipe is not instant) you see the mouse move. So when I saw the absolute values, I was thinking those are the ones I want.

    I tried viewport expression, but those seem to be pre-upscaling. I didn't see any 'screen' values in the Browser obj in c3 - maybe they removed that.

    if I shut off Fullscreen mode in Properties the absolute value works perfect.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Funky Koval I don't think pointer lock will help me here. I am positioning a sprite to wherever the mouse currently is on my layout and I lerp the screen position when "swiping" to the next screen. So its not an instant move... if it was I would have no issue. The main problem is I'm trying to be "stylish" and swipe right ..haha! If I shut off Fullscreen mode and use Absolute values it all works perfectly.

    what I need to do is:

    Set mouse_point_sprite to mouse.absolute x/y - upscale

    but upscale has to be calculated. but I guess if I use absolute for the hiding, I could use the calculation for position which doesn't have to be exact (is this what you meant R0J0hound?)

  • That’s kinda what I meant with calculating. You’d effectively be just doing all the math that mouse.x/y does behind the scene. Which would work but I don’t think it provides much benefit.

    As for the lagging of the sprite behind the actual mouse cursor. I thought that was just because of latency between code and the drawn frames or 1/60th of a second.

    An alternative is the to set the mouse cursor from a sprite, which doesn’t lag behind but it’s on top of everything as it’s not truly a sprite then. That reason that doesn’t lag is the operating system is drawing it then which is more input event based instead of frame based.

    Anyways unless the lag you’re seeing is something different. In which case I’m all for tightening it up if possible.

    Edit:

    It just occurred to me that when you scroll some stuff doesn’t get recalculated till the end of the tick. For example viewportLeft(). It possibly could be the same for the mouse(layer).x expression. That could be lag you’re getting which is different than the other one I mentioned.

    You’ll have to test it but assuming that that setting the scroll position causes mouse.x to update till the next tick you can order your events like this.

    Basically before scrolling, save the scroll position to variables. Then after the scroll correct the position.

    Set sprite x to mouse.x

    Set oldScrollx to scrollx

    Set scroll position

    Set sprite x to self.x-oldScrollx+scrollx

  • R0J0hound I elected to not "set cursor from sprite" since it's updates are not that reliable. If I change mouse pointers it doesn't always work which is why I started to use my own sprites instead. It was always wonky.

    You’d effectively be just doing all the math that mouse.x/y does behind the scene. Which would work but I don’t think it provides much benefit.

    Well if the mouse is showing it would not race across the screen as the camera moved. What happens is that sometimes depending on where the mouse was when the camera moves it travels over buttons that make clicking sounds and effects... it happens really fast as the camera moves. It's noticeable. It's sort of a polish nitpicky thing. I'm just trying to tighten up things. When I look at absolute values they never move when the camera moves. It still may happen since the hover buttons could move under the mouse, it would just be less so without it trailing like it currently does. I only know because if I run the game with Fullscreen mode OFF and use absolute for the mouse pos it pretty much fixes it.

    Set sprite x to mouse.x

    Set oldScrollx to scrollx

    Set scroll position

    Set sprite x to self.x-oldScrollx+scrollx

    aha! I will poke around with this.. however I have my mouse code in an #include (included on all event sheets) and the scroll happens in the layout's event sheet, so I have to find a way to do it... but that is a good suggestion to just make sure, thanks!

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