#3366 closed defect (outdated)
PSP: Stuttering video on all Smush SAN files in COMI
| Reported by: | SF/avatar1976 | Owned by: | joostp |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Monkey Island 3 |
Description
I have tried both uncompressed and compressing the SAN files (audio both in MP3 and OGG). Current version 0.10 produces stuttering and pauses where it misses several frames of video (audio is not affected as badly and video stays in sync aside from while pausing or stuttering).
The 333Mhz 0.9 version created by Joostp does not experience stuttering, however video does go out of sync during SAN (Smush Anination) playback. Sync issues in SAN has been fixed in 0.10 but a 333Mhz version has not been made available due to Joostp wanting issues logged. Request 333Mhz to be available from the downloads section also on ScummVM website (at least for testing if sheer Mhz will resolve problems).
Ticket imported from: #1766695. Ticket imported from: bugs/3366.
Attachments (1)
Change History (15)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
| Owner: | set to |
|---|---|
| Summary: | PSP Port: Stuttering video on all Smush SAN files in COMI → PSP: Stuttering video on all Smush SAN files in COMI |
comment:3 by , 17 years ago
Yes, he is right! A 333 Mhz 0.10 would be very welcome. As today, most of PSP owners set it at 333 Mhz... I'm certain more Mhz and the addtional 32 MB of Ram from PSP Slim could solve these COMI performance issues.
comment:4 by , 16 years ago
I added an experimental patch which tries to rearrange the code in SMUSH codec 47 to make it possible for compilers to optimize it better.
Caveat: It might not run properly (or might be super-slow) depending on what the alignment rules for reads are on the PSP: The code used to read stuff bytewise on the PSP, I changed it to read 16bit words, which might not be OK on the PSP. If that's so, I could add some hacks to mitigate that effect (though a hand-written ASM version of this will always be better).
I wonder if you could give this a try, joost / anybody?
comment:6 by , 16 years ago
| Status: | new → pending |
|---|
comment:8 by , 16 years ago
| Status: | pending → closed |
|---|
comment:9 by , 16 years ago
This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).
comment:10 by , 16 years ago
| Status: | closed → new |
|---|
comment:11 by , 16 years ago
Unfortunately this patch causes it to crash a few seconds in, presumably due to an unaligned read. At present I don't have a comprehensive debugging environment set up, so can't tell you exactly where the problem lies. :-/
comment:13 by , 13 years ago
Closing this as it seems to work well for me in a current build.
A lot has changed since this bug was filed (over 4 years ago!)
comment:14 by , 13 years ago
| Resolution: | → outdated |
|---|---|
| Status: | new → closed |
Joostp, any idea where the bottleneck is, precisely? Would it help if we found a MIPS coder who writes an ASM version of the relevant SMUSH codec (like Robin did for ARM systems) ? Or is it taking up the time somewhere else? Can you even do reasonable profiling on the PSP? :)