Broken Sword performance and a couple of other questions

Subforum for discussion and help with ScummVM's PSP (PlayStation Portable) port

Moderator: ScummVM Team

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

Post by fingolfin »

sev wrote:Imagine this. You have 2 complex and independent expressions to calculate, each one, say, in 3 steps. Will it ease claculation if you will mix those stages, i.e. instead of calucalting A A A B B B you do A B A B A B. No, amount of computations will be exactly the same. So no performance gain will be here. Only one different thing is that you will have only 1 file to open, nothing else.
That's not strictly true (although in this case it probably is): If your memory is not RAM (*random access* memory), if it maybe even has a big penalty for accesssing different places in it (the so-called "seek time"; esp. bad for CD/DVD), then it does help if your data stream is interleaved, in fact it can make a substantial difference. Stress on *can*, however.

Alas, Eugene is of course still right in this case, since the PSP doesn't use a CD drive, but rather flash RAM, where this is indeed a useless technique :-)
User avatar
ScummVM Lead
Posts: 2091
Joined: Wed Sep 21, 2005 1:06 pm

Post by sev »

fingolfin wrote: That's not strictly true
Oh, yes, I knew you will say that :). Don't mess with matematicians! ;) I thought about writing "in this particular case", especially since my first eample featured 20 subexpressions, but wanted to stay focused.

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

Post by fingolfin »

Yeah, sorry, just can't resists nitpicking ;-).
Posts: 1
Joined: Mon Jan 02, 2006 7:39 am

Broken Sword performance and a couple of other questions

Post by reibax »

What about making a mp4-ready scummvm version for the psp so that it can take full advantage of the psp's decompression system?That way we coud re-encode the movies to mp4...
User avatar
ScummVM Developer
Posts: 91
Joined: Wed Nov 02, 2005 9:22 pm
Location: Dortmund, Germany

Post by lavosspawn »

or maybe the PSP's GPU has a function for YUV->RGB conversion that could be used to speed the mpeg2 decoding up?
But I have to admit... I'm not sure how much CPU power that conversion actually takes.
ScummVM Porter
Posts: 5
Joined: Thu Jan 12, 2006 2:24 pm

Post by TMM »

I have done some testing, and made a stand-alone mp2/ogg player for PSP, code is available somewhere, please reply if you think it'll be useful for you (doubtful, but still)

anyway, the performance trouble of the MP2's on PSP seems to be three fold.

first, there is scummvm's overlay system, which gives quite a bit of overhead, it is, however, required because they are 16bit, and, osystem apparantly only supports up to 8 bits of colour.

Second, there is the sound upsampeling. The cutscenes have a samplerate of 11.5 khz, while psp's native sampling rate is 44.1 khz. Also note that the PSP does not support hardware resampling. Resampling of audio is very float intensive, and is ,thus, rather expensive on PSP. Also, in scummvm the sound gets upsampled twice. once in the animation code (to 22.5 khz) and later in the psp backend up to 44.1.

Another problem appears to be that scummvm does its own YUV>RGB conversion, while there is nothing wrong with that in itself, it appears that the code in mp2convert (also from libmpeg2) is much tighter. I think scummvm does the conversion itself due to the fact that scummvm tries to support both the 0.3.x and 0.4.x branches of libmpeg2. (mp2convert is available since 0.4.x)

I am working on the following solution:
1) stop using overlays in the PSP backend for video, but start a native psp display, and render to that.
2) expand the #ifdefs for 0.3.0 a bit to make scummvm use mp2convert if 0.4.0 is used
3) reencode video 320x200 and have the hardware do the upscaling for free
4) reencode the oggs to 44.1khz so upsampling is eliminated.

(obviously, the 'new' cutscenes should be made available in a different pack, this might also help the other 'small system' ports of scummvm, such as wince/pocketpc)
Post Reply