Opened 16 years ago

Closed 16 years ago

Last modified 12 months ago

#1099 closed defect (fixed)

ALL: jerky cursor movement regression

Reported by: SF/logicdeluxe Owned by: fingolfin
Priority: normal Component: Ports
Keywords: Cc:
Game:

Description

ScummVM 0.5.3cvs (Aug 2 2003 17:21:15)
Windows.
In game, the cursor movement is at an anoying low rate.
(It is faster with CTRL-f usage.)
This is not the case while in GUI or a message pops up,
where the cursor movement is as smothly as the ps2
mouse refresh is set. In pause mode for example.
This worked fine in ScummVM 0.5.0pre-cvs (Aug 2 2003
02:02:46) and in ScummVM 0.5.0 (Aug 2 2003 02:52:38),
where the movement also is smothly in game.
I encountered this with all my SCUMM games. It might
apply to the others, as well.

Ticket imported from: #781903. Ticket imported from: bugs/1099.

Change History (8)

comment:1 by eriktorbjorn, 16 years ago

Owner: set to fingolfin

comment:2 by eriktorbjorn, 16 years ago

This is probably related to Fingolfin's recent cursor
changes. We no longer call update_screen() on mouse move
events, it seems.

comment:3 by fingolfin, 16 years ago

Probably because I removed the call to update_screen() from the
EVENT_MOUSEMOVE case in Scumm::parseEvents. However, I
removed it because all other event loops (including those in
NewGUI, Simon, Sky, Sword2...) do *not* have such a call.

The mouse doesn't really "lag", it's exactly at the right spot, it's
just not redrawn as often anymore, causing the impression of
"lag".

The problem probably is that we are having longer delays between
regular update_screen calls in the Scumm main loop than in the
other loops. I could fix that by inserting an update_screen call into
waitForTimer(). But IMHO better would be to fix the mouse cursor
drawin code in the SDL backend, to redraw the mouse
immediately when it's moved. I'll look into it.

comment:4 by eriktorbjorn, 16 years ago

Would it be enough to simply call draw_mouse() and
update_screen() in set_mouse_pos()? (It already calls
undraw_mouse().)

Most of the time there would only be two dirty rects - the
ones from drawing/undrawing the mouse cursor - and we need
to redraw those anyway.

Possible optimizations would be to limit the redrawing
frequency (might be worth it) or to change the two dirty
rects into one since they probably overlap already (probably
not worth it).

But maybe I'm missing something obvious...

comment:5 by SF/logicdeluxe, 16 years ago

I think there is no need to limit the frequency. A typically
mouse refresh is somewhere between 30 Hz and 100 Hz (usually
bellow the screen refresh). The GUI has no Problem, so the
game shouldn't either. Redrawing just some mouse pixels
takes not much CPU time anyway.

comment:6 by fingolfin, 16 years ago

Resolution: fixed
Status: newclosed

comment:7 by fingolfin, 16 years ago

Fixed based on erik's suggestion.

comment:8 by digitall, 12 months ago

Component: --Unset--Ports
Note: See TracTickets for help on using tickets.