on_mouse_move

Started by Gurok, Sat 01/11/2014 08:29:21

Previous topic - Next topic

Gurok

I'm just going to propose this. If it gets shot down in flames, that's fine.

We have a few modules to handle two-click interfaces. Some of them automatically change the cursor based on what you're currently hovering over. Extended ALARCOST is one that comes to mind.

They all seem to suffer from the same flaw I pointed out in this thread: http://www.adventuregamestudio.co.uk/forums/index.php?topic=51211.0. That is, due to the structure of the game loop, there's a one frame delay before cursors get updated when the cursors change. I got no responses from the thread and my source diving has led me to believe it's not currently possible to avoid this delay.

Note: If you have trouble seeing the problem, you can try lowering the FPS of a game to 10 and moving the mouse cursor rapidly. You should see flashes of the previous cursor in places where it shouldn't be.

I have a patch for an on_mouse_move callback, but I don't know whether it's right. Here's the commit:

https://github.com/gurok/ags/commit/1bb68aa0b127506765b2e284fc59b6e1c40da5b7

I need opinions though:

Is this generic enough to go in mainline AGS or does it seem silly? It makes sense to me. We have a global on_mouse_click. We should have a global on_mouse_move.

This could quite easily be repeatedly_execute_always_before_render. (Whew! That's a mouthful.) Should I remove the checks for mouse position changes and just run it on every loop? Would that be more generic/useful?

To be clear, I'm proposing to insert it here in the game loop:
1. Update mouse x/y position
--> Run on_mouse_move callback <--
2. Render screen + mouse cursor
3. Process events (and run repeatedly_execute_always)


Please ignore this. I've found a better solution and it was doing weird things with blocking functions anyway.
[img]http://7d4iqnx.gif;rWRLUuw.gi

Snarky

I would suspect that the flickering of moving characters when manually scrolling the screen is somehow related to this. It seems as if certain built-in engine actions (updating mouse coordinates, updating coordinates/frame for walking characters, ...) happens before the frame is rendered, while scripted events such as changing the mouse cursor or moving the viewframe happen after (and only take effect on the next frame).

This feels to me like an engine bug: surely the game state and scripts should be updated and run together, before the frame is rendered?

Gurok

I've experienced this bug too. The workaround exists, I know. Also, as long as the camera position isn't tied directly to player.x, it's fine. I don't think it's exactly the same problem though. I tried putting SetViewport(player.x - 160, 0) in an on_mouse_move just to test it and the player sprite was still jumpy.

And holy cow, Mouse.Update worked. Thanks, Snarky! I think we can scrap this now. It felt really wrong anyway.
[img]http://7d4iqnx.gif;rWRLUuw.gi

SMF spam blocked by CleanTalk