I have been playing with ScummVM 8.2 on OpenBSD and it works pretty well especially when SDL and scummvm are built with xscale optimisations.
I would, however, have liked to have the video support working well on Broken Sword 2 and have had this built into various test attempts on PDAXROM, Cacko and OpenBSD in the past and all have yielded extremely poor performance. I assumed that this was due to video bitrate of the provided mpeg2 files so when I found instructions yesterday (on the pocketscumm site) on how to re-encode these files I did so and found... it was still darned slow.
I then took a good look at libmpeg2 (also built with xscale optimisation) to see if there was any floating point stuff that could be optimised and I found that it actually comes with a player.
Running the player against these files produces perfect video, however, when run through ScummVM you get about 1 frame every 2 seconds.
Finally I took a look at ScummVM and found that ScummVM calls the render code from libmpeg2 and renders it internally to a buffer that it draws with a routine called drawYUV. It also attempts to time music playback against the frames that it emits to the display and introduces frame skip to attempt to synchronise music against video (in Sword2 the sound and video come from seperate files). This isn't a great way of doing this for a few reasons.
i. The libmpeg2 library still has to render all the frames anyway because mpeg2 uses a key frame and incremental update mechanism for rendering individual frames - non key frames therefore require incremental changes from the last key frame. So the hard work of mpeg2 rendering has been done already, all ScummVM is skipping is its output of the frames.
ii. In most X server implementations on the Zaurus the display is handled by a Shadow Frame buffer since the natural screen orientation is portrait. This means that libmpeg2 is rendering a frame to a buffer, the drawYUV command is rendering to shadow buffer and finally the X server renders the shadow frame buffer to the display.. this is a lot of information to pump out frame by frame (many buffer copies here per frame)
So unless somebody fancies rejigging ScummVM radically in the area of video playback don't expect to get these video cutscenes at a reasonable frame rate.
-Andy
