ScummVM logo Forum Index - ScummVM website - Contact us - Buy Supported Games: GOG.com Rules - Search - Register - Login curved edge
Folder Forum Index > PocketPC/WinCE Port > Performance
Performance
  Author    Thread Reply to topic
adiro69



Joined: 05 Nov 2005
Posts: 19
Performance 

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

 Reply with quote  
Post Fri Jul 07, 2006 8:18 am 
 View user's profile Send private message
frank_m24



Joined: 30 Oct 2005
Posts: 97
Location: Germany
 

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

 Reply with quote  
Post Fri Jul 07, 2006 8:34 am 
 View user's profile Send private message
adiro69



Joined: 05 Nov 2005
Posts: 19
 

Hi


quote:

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...... Sad

Regards
Adi
 Reply with quote  
Post Fri Jul 07, 2006 8:42 am 
 View user's profile Send private message
frank_m24



Joined: 30 Oct 2005
Posts: 97
Location: Germany
 

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

 Reply with quote  
Post Fri Jul 07, 2006 8:54 am 
 View user's profile Send private message
adiro69



Joined: 05 Nov 2005
Posts: 19
 

Hi,


quote:
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.... Smile

Regards
Adi
 Reply with quote  
Post Fri Jul 07, 2006 9:14 am 
 View user's profile Send private message
knakos
ScummVM Porter


Joined: 02 Nov 2005
Posts: 424
Location: Athens, Greece
Re: Performance 

quote:
Originally posted by adiro69

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.
 Reply with quote  
Post Fri Jul 07, 2006 6:52 pm 
 View user's profile Send private message
adiro69



Joined: 05 Nov 2005
Posts: 19
 


quote:
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
 Reply with quote  
Post Thu Jul 13, 2006 8:18 am 
 View user's profile Send private message
knakos
ScummVM Porter


Joined: 02 Nov 2005
Posts: 424
Location: Athens, Greece
 

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 Smile

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

 Reply with quote  
Post Thu Jul 13, 2006 9:49 am 
 View user's profile Send private message
adiro69



Joined: 05 Nov 2005
Posts: 19
 


quote:
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....
Sad

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
 Reply with quote  
Post Thu Jul 13, 2006 10:50 am 
 View user's profile Send private message
knakos
ScummVM Porter


Joined: 02 Nov 2005
Posts: 424
Location: Athens, Greece
 

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

 Reply with quote  
Post Thu Jul 13, 2006 11:43 am 
 View user's profile Send private message
korDen



Joined: 22 Dec 2006
Posts: 3
 

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?

 Reply with quote  
Post Fri Dec 22, 2006 5:08 pm 
 View user's profile Send private message
knakos
ScummVM Porter


Joined: 02 Nov 2005
Posts: 424
Location: Athens, Greece
 

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).

 Reply with quote  
Post Sat Dec 23, 2006 10:21 am 
 View user's profile Send private message
sev
ScummVM Lead


Joined: 21 Sep 2005
Posts: 1949
 

quote:
Originally posted by knakos
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
 Reply with quote  
Post Sat Dec 23, 2006 12:36 pm 
 View user's profile Send private message Visit poster's website
fingolfin
Retired


Joined: 21 Sep 2005
Posts: 1466
 

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 Smile

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.

 Reply with quote  
Post Sat Dec 23, 2006 5:09 pm 
 View user's profile Send private message
knakos
ScummVM Porter


Joined: 02 Nov 2005
Posts: 424
Location: Athens, Greece
 

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.

 Reply with quote  
Post Sat Dec 23, 2006 5:47 pm 
 View user's profile Send private message
  Display posts from previous:      
Reply to topic

Forum Jump:
 



Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Powered by phpBB © 2001, 2006 phpBB Group
Forum design by ScummVM team, icons by raina
curved edge   curved edge