Broken Sword performance and a couple of other questions

fingolfin · Post by **fingolfin** » Sat Dec 31, 2005 2:17 pm

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

Post by **sev** » Sat Dec 31, 2005 2:51 pm

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.

Eugene

fingolfin · Post by **fingolfin** » Sun Jan 01, 2006 2:35 am

Yeah, sorry, just can't resists nitpicking

.

reibax · Post by **reibax** » Mon Jan 02, 2006 7:45 am

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

lavosspawn · Post by **lavosspawn** » Mon Jan 02, 2006 9:09 am

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.

TMM · Post by **TMM** » Thu Jan 12, 2006 10:31 pm

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)