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
Performance
Moderator: ScummVM Team
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
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
Hi
Regards
Adi
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......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.
Regards
Adi
Re: Performance
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 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.
First of all I wold like to thank you for your precious work! ScummVM is the best application for a Pocket PC!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.
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
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
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
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.Further, using the true 480x640 resolution of your device allows you to experience the goodness of the 640x480 Smile
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
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
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
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?
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?
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.knakos wrote:but it is highly likely that device-specific optimisations will not make it into the scummvm trunk
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
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.
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.
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.
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.