Opened 17 years ago

Closed 17 years ago

Last modified 2 years 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, 17 years ago

Owner: set to fingolfin

comment:2 by eriktorbjorn, 17 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, 17 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, 17 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, 17 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, 17 years ago

Resolution: fixed
Status: newclosed

comment:7 by fingolfin, 17 years ago

Fixed based on erik's suggestion.

comment:8 by digitall, 2 years ago

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