Opened 10 years ago

Closed 10 years ago

Last modified 12 months ago

#9063 closed patch

Allow suspend/resume for PSP

Reported by: bluddy Owned by: joostp
Priority: normal Component: Port: PSP
Keywords: Cc:


Added suspend/resume feature. Built against the trunk version. Tested on multiple games.
Description: List of open file descriptors is iterated through. Fds are shut on suspend and restored on resume. Mutex and SDL condition variables used to prevent threads from accessing while suspend/resume is in progress.


Ticket imported from: #2831248. Ticket imported from: patches/1168.

Attachments (3)

suspend.patch (24.4 KB ) - added by bluddy 10 years ago.
Patch to allow suspend/resume on PSP
psp_suspend_cleaned.diff (22.8 KB ) - added by joostp 10 years ago.
Slightly cleaned up (mostly formatting) version of the patch against trunk
suspend.2.patch (30.9 KB ) - added by bluddy 10 years ago.
Worked out some bugs. Good to go hopefully.

Download all attachments as: .zip

Change History (21)

by bluddy, 10 years ago

Attachment: suspend.patch added

Patch to allow suspend/resume on PSP

comment:1 by joostp, 10 years ago

Owner: set to joostp

comment:2 by joostp, 10 years ago


Could you please post this patch as a unified diff? (or simply: svn diff > suspend.patch)

comment:3 by joostp, 10 years ago

Actually, don't bother. I'll just apply it here and svn diff on my end. :)

comment:4 by bluddy, 10 years ago

Ohhhh - so svn has a diff call built in? Man I had so much trouble making the darn patch using regular diff. OK thanks for doing it for me - I'll remember for next time.

comment:5 by joostp, 10 years ago

Nice work on this patch! Unfortunately, it doesn't seem to fully work here.

On Monkey Island 1 (VGA version) I suspend the PSP during the intro, resume, and a few seconds later press ESC (L trigger) to skip to the game, at which point I get; "ERROR: (0:1:0x795): Cannot read resource!", which of course is the classical "can't read from file" error. Can you reproduce this?

comment:6 by bluddy, 10 years ago

Hmm... I don't have MI1 VGA installed on my PSP right now, but I'll tell you what I tried it on: MI1 CD, DOTT, Simon2, MI2 and IHNM. All seemed to work fine. I did the most testing on DOTT, so perhaps test it there to see if the EBOOT was built correctly. When I get home, I'll try MI1 VGA too.

comment:7 by joostp, 10 years ago

OK, I tried it on my 5.00 FW PSP and it seems to work fine on that. It's on FW 1.00 that it doesn't work... any ideas?

Of course it's not a huge deal, since hardly anyone runs 1.00 anymore, and it didn't work there to begin with.

comment:8 by bluddy, 10 years ago

Wow you have 2 psps... cool :)

I'm not so sure exactly what kind of differences there are between 1.00 and 5.00 that would affect my implementation. If I had to guess, it would be that the needed Sony SDK libraries weren't implemented properly yet for supporting SDL's mutex and condition variables, which I use to block any thread trying to read from files. Alternatively, the power callbacks may be different (or not fully functional) in the earlier Sony SDK and therefore the PowerManager class's suspend/resume functions are never called to tell the streams to close/reopen their files.

comment:9 by joostp, 10 years ago

Yes that sounds plausible. :)

There is another, more serious, issue though. During playing (MI1VGA, but also in the launcher itself) I get some screen corruption every 15-30 seconds or so. It flashes black for a frame or so... for a minute I thought this was just general brokenness of the trunk, but without your patch this does not occur.

comment:10 by bluddy, 10 years ago

Interesting. Well I'm going to be gone on a trip for a week, so I don't have time to look at the code. I will be using my psp on the plane though, so I'll check out this problem from my end. I don't remember seeing this issue when I developed on the 0.13.1 release (the trunk was too unstable) and I played for a while. Also I haven't seen it yet in the new release, and I can't really figure out how my patch would cause a periodic corruption. It really would make more sense to me that it's something in the trunk.

comment:11 by bluddy, 10 years ago

After having played for a while, I haven't found the bug you're talking about, joost. I've found 2 other problems though:

1. If I suspend at just the right moment, the resume won't work. This is because I didn't protect the fopen() calls, which were being done outside the PSPIoStream class. Should be easy to fix.

2. Problems with long sound files, which restart from the beginning when you resume. I found this in MI1, where it's not a big deal -- the music for the area just restarts. It's a big problem for Loom though, since the audio becomes out of sync. (However, Loom seems to have serious syncing issues in the regular 0.13.1 version in any case). I assume this will also be an issue with any later game that streams music (Full Throttle, Dig, MI3).

I think the problem is that even though I block the file streams, the mp3/ogg decoders need data for their buffers and when they don't get that data, they try to reopen the stream, causing the issue. My idea to resolve the problem right now is to try to pause the engine if there is one. However, my attempt has run into some weird problems (granted I haven't had much time to play with it).

Joost, how close are we to exhausting the memory on the PSP? My 0.13.1 build is at roughly 7.9MB. Is it possible I'm running out of memory when I try to add a mutex?

comment:12 by joostp, 10 years ago

Are you testing with 0.13.1 or trunk? I've attached a cleaned up version (so it follows the ScummVM code formatting conventions, updates psp.spec, etc) of the patch against trunk. Would be worth testing with that, since 0.13.1 is already quite old at this point.

As for the available memory, there should be enough for most games. Only the 640x480 games (COMI, DW2, BS1&2) would possibly struggle. I've been using MI1VGA as a primary test case.

by joostp, 10 years ago

Attachment: psp_suspend_cleaned.diff added

Slightly cleaned up (mostly formatting) version of the patch against trunk

comment:13 by bluddy, 10 years ago

I tested against both trunk and 0.13.1, but I usually develop on 0.13.1 since developing on the trunk has been such a pain -- I'll encounter problems and eventually find out they were trunk problems. For example, last time I checked the trunk, AGI games were so slow they were unplayable on the psp. Also sometimes the https:// svn is deactivated and tells me to use http://, which usually doesn't work for me.

Thanks for cleaning up the code -- I'll download it when I get home.

I've managed to solve problem 2 by pausing the current engine, then waiting until I'm paused before I do anything else. Had a little trouble figuring out why it didn't work at first, but now it works great. Problem 1 should be much easier.

As to the memory issue, I think we may be very borderline, but I'll have to check that on the trunk. In any case, we should switch to prx plugins asap. Maybe that'll be the next thing I do, unless you want to do it.

comment:14 by joostp, 10 years ago

Nice! Do all engines support pausing?

As for the PRX plugins, it's been on my TODO for a long time, but I'm just not getting around to it. I wouldn't mind if you want to pick it up. :)

by bluddy, 10 years ago

Attachment: suspend.2.patch added

Worked out some bugs. Good to go hopefully.

comment:15 by bluddy, 10 years ago

Worked out some bugs with regard to directory access. Checked with trunk and 0.13.1.

Note that currently the trunk has issued with MI1 CD causing slowdown. It didn't seem to be connected to my patch. Also, on 0.13.1 MI1CD works very well with my patch. DOTT works nicely with the patch in both branches.

I changed my mind about pausing the engine. It causes timing headaches since we don't know when the engine is polling and when it isn't -- we're in low level after all. After patching up the problems with directory access and changing the way the thread blocking works to a cleaner and more classic design, I noticed that engine pausing wasn't necessary anymore for games with long sound files anyway.

comment:16 by joostp, 10 years ago

Status: newclosed

comment:17 by joostp, 10 years ago

After some extensive testing I've not run into any issues, nor the one that I saw previously (wonder what caused it?!). I've committed a modified version of this to trunk, and will commit to branch-1-0-0 after some more testing.

Thanks a lot for this excellent patch!

comment:18 by digitall, 12 months ago

Component: Port: PSP
Note: See TracTickets for help on using tickets.