Opened 13 years ago
Closed 6 years ago
#5759 closed defect (fixed)
PSP: Urban Runner: Loading of Savegames does not work
| Reported by: | SF/mcknallski | Owned by: | bluddy |
|---|---|---|---|
| Priority: | normal | Component: | Engine: Gob |
| Version: | Keywords: | ||
| Cc: | Game: | Urban Runner |
Description
ScummVM version: 1.4.0git1086-g38c9988 (Jun 15 2011 06:30:10) Language of game: German Platform: PSP
I found a critical (PSP specific) Bug in Urban Runner.
When I Save the Game, the PSP writes the Savefiles (into the correct Directory) but don´t show up in the Load Screen.
When I import the Savefiles into the Windows Version of ScummVM, they show up and load correctly. The whole Problem does not occur in the Windows Version.
And I´ve found something interesting. The Gamefiles are the following:
CD1.ITK CD1.STK CD2.ITK CD3.ITK CD4.ITK INTRO.STK OBJET1.ITK
Now when I delete only one of the CD?.ITK, the loading of Savegames works again. No matter, which of the CD.ITK Files I delete.
When I create a 0 Byte File to replace the deleted File, the Bug occurs too.
Ticket imported from: #3317306. Ticket imported from: bugs/5759.
Attachments (2)
Change History (23)
comment:1 by , 13 years ago
| Summary: | Urban Runner on PSP: Loading of Savegames does not work → PSP: Urban Runner: Loading of Savegames does not work |
|---|
comment:2 by , 13 years ago
| Owner: | set to |
|---|
comment:3 by , 13 years ago
comment:4 by , 13 years ago
At my prompting, DrMcCoy (Gob) and joostp (PSP) discussed this in the development IRC channel: http://logs.scummvm.org/log.php?log=scummvm.log.13Sep2011&format=html
The probable cause is exhaustion of the file handles in the PSP backend which is limited to 16 files open concurrently. When all the ITK files are present, Gob runs in NO_CD mode and opens all 8 datafiles simultaneously currently. If one is missing, it assumes it is running from CD and thus opens the current file and asks for the next CD when necessary i.e. only 1-2 datafiles are open concurrently. Since ScummVM also has a number of other files open i.e. config file, translation dat and now logfile, this is likely to exhaust the 16 handles.
To fix this: 1. The PSP backend should be modified to report file handle exhaustion in a warning dialog i.e. When the open fails, a warning dialog is shown on the screen. 2. The Gob engine should be modified to not open all the datafiles concurrently. This should be possible, but is not trivial as this is partly under the control of the game scripts. See the IRC discussions for various solutions.
comment:5 by , 13 years ago
One additional note: The 16 concurrent file handles in the PSP backend is a limitation of the PSP firmware and can't be increased, so the warning dialog and testing to establish if any other games are opening too many files simultaneously is the only solution.
A modification to the desktop (SDL) backend to print a warning to the log/console window if more than 16 file handles are opened simultaneously would also be a good idea for testing.
comment:6 by , 13 years ago
I don't have any time to deal with this, but another idea is to emulate having an unlimited number of open files, based on the idea that even if many files are open, only a few are used at any time.
We put every open file in a set, with a certain maximum count of open files. When the maximum count is exceeded and a new file is opened, we remove an old file from the set by using an LRU scheme. When a file is removed from the set, it is closed, and its position is saved. If that file is read from again, it's re-added to the set.
There's already something a little similar in the PSP backend for suspend/resume, though this would better be implemented as a wrapper layer for the FS.
comment:7 by , 13 years ago
FD sharing used for all backends is something we really do not want. It has for example the following negative impact:
Performance issues, due to FS code using read buffers to allow fast access, these would need to be restored everytime we change an FD (File Descriptor). If that ever happens to a FD used in audio stream playback this is probably not so nice for systems with slow I/O.
Next it's overhead we do not need for most backends. The NDS backend never had any problems due to its max FD cout, thus it will only increase the binary size for no gain.
So if we want something like this FD sharing we should do it like this: - Write some generic implementation - Deploy it in the FS code of the backends which need it
Anyway a more odd point about the bug report is that saving seems to work fine and loading doesn't. So it seems there is some FD left for saving, but oddly not some for loading. Any idea about this? As I understand DrMcCoy the GOB engine keeps the same number of FDs open for all the game. So it's odd that we have an FD available for writing but not for reading.
comment:8 by , 13 years ago
FWIW, 16 is the theoretical limit, in practice it seems to be about 9. (see also: http://forums.ps2dev.org/viewtopic.php?p=52918 )
comment:9 by , 13 years ago
DrMcCoy has committed a fix for the Gob side of this: 16bbc07690a48603e080699305d417379bc18cee
GOB: Don't explicitly open CD1.ITK for Urban Runner
CD1.ITK is the one CD archive file the Urban Runner scripts open themselves in NO_CD mode. Since the PSP has extremely limited file handles, having that archive opened twice makes the load code fail on that device.
Hopefully, the scripts don't decide to close and not reopend CD1.ITK in places where it's needed. A full playthrough with loading/saving between screens (especially across CD content borders, and during death screens) would probably be prudent.
As indicated, this will require a playtest to confirm.. and this doesn't deal with the PSP backend issue with FDs which still remains.
comment:10 by , 13 years ago
Ok. Saving and loading works good for now. But Now I found an Crash/Freeze in this Game. It occurs only on the PSP not in the Windows Build. I,ve Attached the Savegame File for the Scene, where it crashes.
by , 13 years ago
| Attachment: | Crash Savegame.zip added |
|---|
Use the first Savegame called " Speicherplatz 1". Savegame in the Office Building, while the Player hides in the Cabinet. The Game crashes when the Guard shows up in the PIcture-in-Picture-Screen.
comment:11 by , 13 years ago
mcknallski: Have loaded attached savegame with Urban (US) under Linux x86_32. The savegame loads and as you have described, I see the correct scene with the guard video and no crash. Running with valgrind also shows no issues.
Running memory profiling, ScummVM running at this point is using around 13MB of memory, but with PSP having 32MB of memory, this is unlikely to be an OOM issue unless there is a problem here.
Since we can't replicate this on a desktop build, without more debug information from the PSP, we are unlikely to be able to fix this.
comment:12 by , 13 years ago
mcknallski: I have looked at the code in backends/platform/psp especially trace.* and logMessage. I think the PSP daily builds should be configured to log messages to a file on the memory card called SCUMMTRACE.TXT or possibly a file in "logs". If you can find these files after a crash and attach them zipped, this might help.
comment:13 by , 13 years ago
There is a SCUMMTRACE.TXT. But it is Empty (0 Byte). Maybe because the whole PSP System, crashes/freezes.
comment:14 by , 13 years ago
The fact that there's nothing in the log file would seem to suggest that the PSP runs out of memory. 13 MB is a lot for the PSP -- you have to add in the size of the executable as well as the space that's made in memory for the biggest plugin found. Also, the available memory is only 24MB.
Mcknallski, try deleting all the plugins except for the gob engine and see if it makes any difference.
comment:15 by , 13 years ago
No. It does not make any Difference. I also deleted the SCUMMTRACE.TXT.
By reproducing the Crash it deos not even create the empty SCUMMTRACE.TXT. The empty File was existing even before the Crash appears. Until that (savegane) point there were no crash in the Game even in other Picture-in-Picture Scenes (e.g. in the Beginning).
I played through that scene on the PC and imported the Savegame back to the PSP System and i´ve played till 58% of the Game and it was till now the first and only Crash/Freeze.
comment:16 by , 13 years ago
The current point at issue is that the PSP crashes when a specific video is played.
By running .scummvm -d 5 --debugflags=video on my linux x86_32 build with the attached savegame, the video in question on my Urban Runner (US) is "GARDARIV"
mcknallski: Could you run the same on your desktop build and confirm that the Urban Runner (de) uses the same video name?
by , 13 years ago
| Attachment: | Crash Savegame 2.zip added |
|---|
Use the last Savegame called "Büro". Savegame in the Research Facility. PSP freezes, when the Guards are showing up in an Picture-in-Picture Video. Just wait 10~20 Seconds and the Video appears.
comment:17 by , 13 years ago
Right. It is the same Name (GARDARIV). I forgot to say, that the first Frame of the Video is shown.
I made some further testings and found out, that all the Picture-in-Picture Videos in the Office are crashing/freezing.
Now I encountered the same situation at another Scene in the Game. At 88% of the Game the exactly same happens. I uploaded an Archive with the Savegame for that Scene.
Use the last Savegame called "Büro". Savegame in the Research Facility. PSP freezes, when the Guards are showing up in an Picture-in-Picture Video. Just wait 10~20 Seconds and the Video appears. As befor only the first Frame is shown and the PSP freezes.
comment:18 by , 11 years ago
mcknallski: I would like to test this out too, but sadly I haven't got a German version of Urban Runner in my possession. If it's not too much trouble, I'd urge you to take a look and see if this occurs with the latest build.
comment:19 by , 11 years ago
The loading of Savegames has been fixed a long Time ago. But the later mentioned Issue with some Crashes at some places (see the attached Savegame-Files) is still unresolved. I´ve tested it with the latest Build of today with the German Version of the Game.
comment:20 by , 11 years ago
mcknallski: Thank you for retesting this. I think the only way this will be resolved will be if nitrus provides you with instructions for building a toolchain and psplink/gdb serial debugging on the PSP to allow you to provide more detailed and exact backtrace allowing us to locate the likely cause of the problem. I suggest you talk to nitrus outside of the bug tracker either by e-mail, forum or IRC to discuss this. Hopefully in time, the updated instructions from nitrus will be merged to the relevant PSP wiki pages and other users can do similar work to provide debugging traces.
comment:21 by , 6 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Since the original issue of save games missing on PSP was resolved, I am closing this ticket. Any other outstanding issues that still exist today should be opened in a new ticket.
Checked the Git history and this should still be occuring with the latest v1.4.0 daily i.e. no relevant changes in Gob, but is this a PSP backend file access issue or a Gob engine loading issue.
bluddy: Could you take a look at this and see if this looks like a PSP backend issue? If not, then I think this should be assigned to DrMcCoy so he can take a look and see if the Gob saveload / resource loading code contains the issue here.
McKnallski: It would be very useful if you could replicate this on a desktop platform, or if you could run the latest Development build on your PSP in debug mode and get a logfile of any debug output/warnings which are emitted.
bluddy: Is it possible currently to get debug output from the PSP build? Serial Cable console? Logfile on Memory Stick?