Opened 15 years ago

Closed 15 years ago

Last modified 15 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

Description

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, 15 years ago

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

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

Status: newpending

comment:5 by SF/noscript, 15 years ago

i didnt test again, but i will tomorrow

comment:6 by SF/noscript, 15 years ago

Status: pendingnew

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

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

sry for late posting

comment:10 by eriktorbjorn, 15 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, 15 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, 15 years ago

What is the status of this item?

comment:13 by fingolfin, 15 years ago

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