Performance

Subforum for discussion and help with ScummVM's PocketPC/HandheldPC port

Moderator: ScummVM Team

Post Reply
adiro69
Posts: 19
Joined: Sat Nov 05, 2005 9:12 am

Performance

Post by adiro69 »

Hi all,

I am using ScummVM for Pocket PC starting with the 0.7 version on a Win2003 SE PPC (Toshiba e800). At the moment I have installed 4 versions on my machine: 0.7.1, 0.8.0, 0.8.1 and 0.9.0. Because of the battery I prefer to set my PPC to 100MHz in order to save power and to be able to play longer.
I have realized that on the newer versions the application is slower than the older. Not only the launcher but also the engines are performing slower. For example the Monkey Island 2 is performing very well on the 0.7.1 but very slow on the 0.9.0. For the Simon 1 the difference is more visible.
Is this a problem of the new compiler? Can we expect that the code will be opimized in a future version or adding new engines and features will further impact the performance?



Regards
Adi
User avatar
frank_m24
Posts: 97
Joined: Sun Oct 30, 2005 4:10 pm
Location: Germany

Post by frank_m24 »

Hello,

maybe you are using different settings, e.g. different sound settings?

At least for me there is no noticeable difference for Monkey Island 2 between the versions, I am using a Dell Axim X50v. And the Simon games are "feeling" much faster with 0.9.0 than with the previous versions.

kind regards

Frank
adiro69
Posts: 19
Joined: Sat Nov 05, 2005 9:12 am

Post by adiro69 »

Hi
At least for me there is no noticeable difference for Monkey Island 2 between the versions, I am using a Dell Axim X50v. And the Simon games are "feeling" much faster with 0.9.0 than with the previous versions.
Are you using your processor at maximum speed? As I already explained I am using it any time at the slowest speed, in my case 100MHz and I have deactivated the sound and music. Testing it with the 400MHz there is no problem. But also the battery is down in 1 hour...... :(

Regards
Adi
User avatar
frank_m24
Posts: 97
Joined: Sun Oct 30, 2005 4:10 pm
Location: Germany

Post by frank_m24 »

Hello,

I'm using the Auto Mode - no idea which clock fequency is used in this case - something between 104 and 624 MHz

kind regards

Frank
adiro69
Posts: 19
Joined: Sat Nov 05, 2005 9:12 am

Post by adiro69 »

Hi,
I'm using the Auto Mode -
When I am using the auto mode, my processor is running at 400MHz and the battery is down in about 1 hour. A little bit to fast for an adventure game.... :)

Regards
Adi
User avatar
knakos
ScummVM Porter
Posts: 423
Joined: Wed Nov 02, 2005 2:35 pm
Location: Athens, Greece

Re: Performance

Post by knakos »

adiro69 wrote: I have realized that on the newer versions the application is slower than the older. Not only the launcher but also the engines are performing slower. For example the Monkey Island 2 is performing very well on the 0.7.1 but very slow on the 0.9.0. For the Simon 1 the difference is more visible.
I can only describe this as normal code evolution. The codebase in scummvm is getting increasingly complex with each version, so you can expect such things. In particular with 0.9.0a, the mp3 interfacing part of the core had to be built without optimisations which might incur some performance loss.
adiro69
Posts: 19
Joined: Sat Nov 05, 2005 9:12 am

Post by adiro69 »

I can only describe this as normal code evolution. The codebase in scummvm is getting increasingly complex with each version, so you can expect such things.
First of all I wold like to thank you for your precious work! ScummVM is the best application for a Pocket PC!

I know now what is the performance problem. I have a VGA device with Windows 2003 SE, standard, without any VGA enabling hacks (Toshiba e800). Until the version 0.9.x I was able to use the 1x filter on lanscape mode. This filter was working on a virtual 320x240 screen with a real resolution of 640x480. The OS was responsible to scale the video output to the 640x480 resolution, and it is very good at doing it. PocketScumm was working on a 320x240 screen, which is fast even with a slow main processor (100Mhz). In the newest version, the 1x filter is not there any more and the normal one is rendering the output only on 1/4 of the screen (top-left corner if PocketScumm is started on potrait mode) so I am forced to use the 2x one. This uses a virtual resolution of 640x480, and PocketScumm is forced to scale everything itself. This is the reason for my performance problem. I can imagine that on a PPC with QVGA resolution (320x240) it is working ok.
But this is not the only problem with this filter. The new feature to drive the mouse pointer using the directional buttons is working only on about 1/4 of the screen (top-left on landscape orientation).

Do you think that it will be possible to reenable the 1x filter from the previous versions? Also with the orientation button?

Thank you and regards
Adi
User avatar
knakos
ScummVM Porter
Posts: 423
Joined: Wed Nov 02, 2005 2:35 pm
Location: Athens, Greece

Post by knakos »

Letting the os (gapi) stretch 240x320 to 480x640 is bad thing on the average, considering the multitude of devices out there. In fact, on some models there is a severe slowdown when relying on gapi to stretch stuff.

Further, using the true 480x640 resolution of your device allows you to experience the goodness of the 640x480 :)

So I do not think we will go back to the way things were, in this respect. For the mouse emulation using dpad, this looks like a bug and I would appreciate if you fill out a bug report.

Kostas
adiro69
Posts: 19
Joined: Sat Nov 05, 2005 9:12 am

Post by adiro69 »

Further, using the true 480x640 resolution of your device allows you to experience the goodness of the 640x480 Smile
Thank you for your response. I understand that there is a jungle in the PPC hardware world and it is very complicated to find a universal solution.
I am very happy with the 640x480 resolution for reading ebooks or other more static things, but for playing an adventure it is not an advantage. For example the animation of "Legend of Kyrandia" on the new PocketScumm is slower than playing it with the PocketDOS PC emulator with the same processor speed. Even when I increase the processor speed to max it still seems to be to slow. I was happy to be able to play this game with PocketScumm because on the PocketDOS there are still some graphic glitches but now I prefer to finish it on the DOS emulator....
:(

Why it is not possible to create a new 1x filter using the code from the 0.7/0.8? I think that many users will prefer to have it. For example some users will prefer to play on the portrait orientation. At the moment this is only possible with the normal filter but for the VGA devices it will be rendered only on the top left 1/4 area of the screen.

Please consider this only as feedback. Thank you again for your effort!

Regards
Adi
User avatar
knakos
ScummVM Porter
Posts: 423
Joined: Wed Nov 02, 2005 2:35 pm
Location: Athens, Greece

Post by knakos »

What is say is true for kyra, but what about broken sword which is an 640x480 game? Further, to my knowledge, it is not possible to switch at runtime between gapi compatibility (240x320) and raw framebuffer (480x640), following the guidelines of microsoft (hence you'll need two different binaries). Finally, as I said, the gapi compatibility mode may be ok for your device but wreaks havoc on others (some other devices are known not to stretch QVGA to VGA, but simply center it on screen).

Some part of the system has to push 4 times the volume of data when dealing QVGA games which need to be displayed in VGA resolution. This can be either the system or scummvm directly. Given all my previous comments, I do support that scummvm needs native access to the framebuffer, at the expense of being a bit slower. Leaving the increased resolution offered by VGA unsupported is the wrong way to go.

Thanks,
Kostas
korDen
Posts: 3
Joined: Fri Dec 22, 2006 3:11 pm

Post by korDen »

Maybe I'm wrong but AFAIK some devices like Dell Axim x51v have internal optimization of GAPI to use their 3D accelerators and thus letting GAPI handle image scaling might be worth. Am I right?

A better way though is to introduce an optimization for newest graphic adapters. For ex, Quake Mobile and Quake 3 port to WinCE have been designed for x51v (and their 3d accelerators). PocketSNES, PocketGBA, TCPMP also added otimizations for 2700g capable devices. Could onyone look into their source code and apply similar optimizations to ScummVM?
User avatar
knakos
ScummVM Porter
Posts: 423
Joined: Wed Nov 02, 2005 2:35 pm
Location: Athens, Greece

Post by knakos »

If someone likes to give this a go that's fine, but it is highly likely that device-specific optimisations will not make it into the scummvm trunk, even if they are submitted as a patch (this doesn't mean that the patch should not be submitted).
User avatar
sev
ScummVM Lead
Posts: 2273
Joined: Wed Sep 21, 2005 1:06 pm
Contact:

Post by sev »

knakos wrote:but it is highly likely that device-specific optimisations will not make it into the scummvm trunk
Well, why not? Especially if the patch will be clean, properly #ifdef'ed, i.e. could be excluded at compilation stage, and the main thing, maintained when future changes will require it.

Consider NDS port, it has tons of device specifications. Consider our scalers code, it has MMX/SSE optimizations, so it MT-32 code, etc.


Eugene
fingolfin
Retired
Posts: 1452
Joined: Wed Sep 21, 2005 4:12 pm

Post by fingolfin »

Disclaimer: This post is not arguing pro/con device specific optimizations; but rather I want to set some facts straight, as a proper discussion is not possible if one uses skewed comparisions/facts :-)

That said, sev, I disagree with your comparisions. For example, while NDS optimizations are "device specific", that hardly is a limitation, since there is only one NDS out there - so the distinction between "device specific" and "generic" is moot.

And x86 / MMX optimizations are hardly device specific either -- there are gazillions of different devices out which all benefit from that optimization.

Finally, the MT32 code in ScummVM mainly results from the fact that many games used to explicitly make use of that device (i.e. the games already contained "device specific optimizations". So while that code is "device specific", it's IMHO in a very different league and not directly comparable to the current situation.

A better example would be to compare this with adding ATI video card specific changes to ScummVM, or even changes specific to one particular graphics card.
User avatar
knakos
ScummVM Porter
Posts: 423
Joined: Wed Nov 02, 2005 2:35 pm
Location: Athens, Greece

Post by knakos »

Fingolfin is indeed closer to the 'spirit' of these device specific optimisations with the $brand gfx card.

Thinking through this issue, it is more likely these changes (and notice we're arguing about changes whose impact and actual code has not even remotely been evaluated) will belong better in the SDL port, which we can, almost, clutter as much we want in order to get more efficiency and speedup. If any of these has to be done inside the scummvm trunk, I would initially oppose it.

To give a little insight on what might be the case here, some devices have specific APIs to access non-standard stuff such as external displays and whatever. Switching code paths in the video part might be tricky due to missing and/or incomplete API docs and, more importantly, will be hard to maintain. Even Microsoft is currently supporting a semi-official way to get to the framebuffer on a large number of devices which, needless to say, turns my guts inside out.

That said, I do evaluate each patch with no prejudice and value the contribution.
Post Reply