I had the same problem as you at 0.9.0v. Now at 0.9.1 on my Dell Axim X51v (WM5, 624Mhz, 30mb prog. mem.) scumm play movies, but they are very slow.. I think it's about.. 5fps...
In my opinion the problem is that the movie and voice are played at the same time from two other files.
What do U think about that?
PS. sorry for my english...
Broken Sword 1 startup problem
Moderator: ScummVM Team
I agree with you. But pda can handle with very big video files(700mb and bigger), and many programs in the same time, so why it can`t work properly with short cut scenes..? I think that the problem is still not enough optimized code. (no offence,I'm glad to watch even 5fps scenes;) )No, it's that the processor cannot cope with the (computational) load and/or the code is not optimized enough.
Not exactly. The bitrate of the video (not the size ) matters: This affects the time your device spends fetching data from the "drive". Also, since this is an encoded bitstream, for larger bitrates the processor has to spend more time more time decoding the stream. Even more, the data have to be converted from different colorspace into rgb and finally blit onto the screen.
Now, scummvm is not meant to be used as an optimized movie player, although obviously it has to perform that as well for some games. What we prioritize here is that the scummvm core can run data from a multitude of adventure engines and also especially in the ce port case, be able to do so for various screen resolutions and input configurations.
This does not mean that we like parts of scummvm to be suboptimal - on the contrary - but the other factors come first. Of course, if anyone is willing to help along by providing optimizations and/or bugfixes is very welcome.
Now, scummvm is not meant to be used as an optimized movie player, although obviously it has to perform that as well for some games. What we prioritize here is that the scummvm core can run data from a multitude of adventure engines and also especially in the ce port case, be able to do so for various screen resolutions and input configurations.
This does not mean that we like parts of scummvm to be suboptimal - on the contrary - but the other factors come first. Of course, if anyone is willing to help along by providing optimizations and/or bugfixes is very welcome.