#1789 closed defect
COMI: cannon shooting uses a lot of performance
| Reported by: | SF/noscript | Owned by: | |
|---|---|---|---|
| Priority: | low | Component: | Engine: SCUMM |
| Version: | 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 , 20 years ago
| Priority: | normal → low |
|---|---|
| Summary: | cannon shooting uses a lot of performance → COMI: cannon shooting uses a lot of performance |
comment:2 by , 20 years ago
comment:3 by , 20 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 , 20 years ago
| Status: | new → pending |
|---|
comment:6 by , 20 years ago
| Status: | pending → new |
|---|
comment:7 by , 19 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 , 19 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 , 19 years ago
its a lot better no but it hangs sometimes for a half second :)
sry for late posting
comment:10 by , 19 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 , 19 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:13 by , 19 years ago
| Status: | new → closed |
|---|
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.