Opened 16 years ago

Closed 16 years ago

Last modified 16 years ago

#1789 closed defect

COMI: cannon shooting uses a lot of performance

Reported by: SF/noscript Owned by:
Priority: low Component: Engine: SCUMM
Keywords: Cc:
Game: Monkey Island 3


The Canon shooting on LeChucks Ship uses a lot of performance. Dont know why, there is no error or such. In earlier builds this wasnt so extreme

Sys: WinXP, 512 DDR RAM, 2,6Ghz CVS: 2004.09.27

Ticket imported from: #1035690. Ticket imported from: bugs/1789.

Change History (13)

comment:1 by fingolfin, 16 years ago

Priority: normallow
Summary: cannon shooting uses a lot of performanceCOMI: cannon shooting uses a lot of performance

comment:2 by eriktorbjorn, 16 years ago

Does it still happen? I ran that scene with the current CVS on my 450 MHz PIII, and I didn't notice much difference in CPU usage compared to the past few stable releases.

comment:3 by fingolfin, 16 years ago

When you say that it "uses a lot of performance", how do you measure that? Using a system usage level meter? Some other utility? By "feel", i.e. how responsive the mouse is? Voodoo? ;-)

comment:4 by fingolfin, 16 years ago

Status: newpending

comment:5 by SF/noscript, 16 years ago

i didnt test again, but i will tomorrow

comment:6 by SF/noscript, 16 years ago

Status: pendingnew

comment:7 by eriktorbjorn, 16 years ago

Any news on this?

One reason I made my first comment was back in September was that the bug was filed around a time where we had a bug which I think made ScummVM redraw more of the screen than necessary, but I don't know if that made any noticeable change in CPU usage or not.

comment:8 by SF/mnbv, 16 years ago

I've just got the game and I have to say that I noticed that the scene felt sluggish, i.e. screen updates didn't keep up with the mouse very well.

I don't know if that's what the OP meant but that's what I observed when I played.

I'm using ScummVM 0.7.0CVS (Nov 13 2004 15:29:08)

Sys: Debian unstable, 1.5GB DDR RAM, 1.6GHz

IIRC (back when I used to use windows) when I tried the demo of CoMI (not with scummvm) that scene was very sluggish but I put that down to my CPU, only a 450MHz at the time.

comment:9 by SF/noscript, 16 years ago

its a lot better no but it hangs sometimes for a half second :)

sry for late posting

comment:10 by eriktorbjorn, 16 years ago

The hangs could be a script busy-waiting for something. I think I saw a script like that, waiting for a sound to finish, in the room where Guybrush meets Murray for the first time. (This used to cause Digital iMUSE to hang.)

If it's something like that, it might be possible to add a workaround for it. Of course, this is just guessing.

comment:11 by fingolfin, 16 years ago

So I run this scene through Shark (kind of a run-time profiler). Once with my regular build, once with an optimized one.

In the first case, we spent about 18% of our time in AkosRenderer:: codec1_genericDecode -- not a surprise, the scene is cramped with actors. More surprising: 17% spent in IMuseDigital::flushTracks. Another 12% spent in drawStripToScreen. Ouch.

With -O, things changed somewhat: 21% spent in flushTracks! 13% spent in SDL, busy blitting our stuff to screen (to be expected), and only 12% in the AKOS renderer.

In total, ScummVM was using about 75% of my system, pretty bad.

So, flushTracks looks strange, and I checked it. Turns out the code was busy waiting on the result of another thread, ugh. I put a fix for that into CVS. It now calls _vm->parseEvents() sometimes.

Result: flushTracks now only takes about 0.4% of our time in an optimized build. In the -O build, SDL dominates now, followed by the AKOS 1 renderer.

I hope that this change helps at least a bit...

comment:12 by fingolfin, 16 years ago

What is the status of this item?

comment:13 by fingolfin, 16 years ago

Status: newclosed
Note: See TracTickets for help on using tickets.