Some systems may take longer to process the game loop
than others so we delay by a variable amount so faster
and slower system execute the game loop the same number
of times per second (the fps is capped at 100).
Slower systems that take longer than 10ms to process the game
loop won't have any delay.
In some cases a mouse moved event could be handled between the moment
the xtakeit script was queued and the moment it is executed (on the same
frame), causing the mouse position no longer to be over a marble
rectangle.
Fixes#10647.
Fixes Trac#10642.
The original engine will move the dome sliders whenever the player is
dragging a dome slider to the left or right regardless of y position.
In ScummVM the dome slider position would only change to the players x
mouse position when the y value was also in the slider hotspot. This
change removes the y check by making the point to be checked always
have a y value in the hotspot rect.
The x values are also bound to the max and min value that any of the
slider hotspots can have. This allows the slider to go all the way to
the left and right even if the user has gone past the slider area
to the left or right while still holding the slider.
Fixes Trac#10575.
When stepping away or pressing the buttom for the mechanical age fortress
rotator after setting it west it would be south. This is because some variables
used for a workaround were being reset everytime the rotator puzzle
was being reinitalized (in o_fortressRotation_int). Which happens when
the player steps back up to the rotator controls.
This change simply removes the variables being reset so they retain
the variables they had before. Those variables are already initalized
in the Mechanical constructor.
The direction that the fortress is pointing is calculated when
the user locks on using the left throttle (after the gears have
stopped). It also happens when the user hits the button.
There is only a difference in the two behaviors when the user has
changed the direction, but not locked on.
The 2nd case can lead to the direction be different than
what the last locked on direction was. Since the user
can lock the direction to say north, turn it to west, not
lock on and hit the button, which will set the direction
to west. This can lead to confusion since a direction sound
isn't played in this case.
This change removes code, to prevent the recalculation
of the direction when the button is pressed so that direction
is always what it was last locked onto.
This way all the other actions are blocked while the card load scripts
are executed. Expecially, it's not possible anymore to open the main
menu while the scripts for returning from the main menu are still
executing.
Fixes Trac#10628.
Eugene Sandulenko
David Fioramonti
Bastien Bouclet
D G Turner