Emulator Issues #2917
Poképark Wii - Perpetual loading (ingame)
What steps will reproduce the problem?
1. Load Poképark Wii, create a gamesave and start a new game
2. The intro video plays
3. The game displays a loading screen
What is the expected output? What do you see instead?
The game should load and gameplay should begin. The first thing you should see is an introductory dialogue from Mew.
Instead, the loading screen never progresses, with an animation of Pikachu falling perpetually.
Dolphin version with the problem? Other Dolphin version without the
32-bit or 64-bit and any other build parameters?
OS version and versions of tools/libraries used?
Windows 7 32bit
Please provide any additional information below.
This is tested using a European copy of the game, extracted from a retail disc.
Issue persists in JIT and JITIL recompilers.
#3 Updated by Rupeeclock over 9 years ago
Okay, I'm mostly just an end-user, but I decided to take a look at the log files for Dolphin.
Attached is my log file, the conditions being:
- Brand new Log File
- Brand new Gamesave on poképark Wii
- Starting a new game, playing intro video, watching loading screen, stopping emulation.
In particular, there's some interesting lines I want to take note of:
Line 63: 45:15:015 .\Src\IPC_HLE\WII_IPC_HLE_Device_FileIO.cpp:115 W[WII_IPC_FILEIO]: FileIO: Open failed - File doesn't exist ./User/Wii/title/00010000/52384150/data/GWD
Lines 63 through 72 are similar, all starting that these save files don't exist. However, they do, they are in the folder.
Even more curious is this line.
Line 53: 45:02:866 .\Src\IPC_HLE\WII_IPC_HLE_Device_FileIO.cpp:115 W[WII_IPC_FILEIO]: FileIO: Open failed - File doesn't exist ./User/Wii/tmp/Pokemon/Res00.dan
Lines 53 through 58 indicate the presence of temporary files created on the Wii's memory, these 5 files take up 38mb. I have emulated many Wii games and not seen any others create temporary files like this before.
When opening one of these Temporary files (Res03.dan) in Notepad++, there are many references to .efb and .brres files, including: EfPigeon.efb, EfPikachu.efb, EfSamehader.efb, Pigeon.brres, Pikachu.brres, and other things.
I'm not a programmer, but as an end-user I would have to guess that on real hardware, Poképark Wii for whatever reason stores temporary files on the Wii, and then accesses these temporary files for EFB access and sound effects.
If it is of any help to the programmers I have also attached a one of the temporary files, Res03.Dan.
#9 Updated by Rupeeclock over 9 years ago
I've something to add to the issue.
Using a gamesave that has an attraction unlocked, thus playable in the arcade without loading a saveslot, trying to play one of these attractions results in a black screen.
On the black screen you can still access the Home menu.
I can't however provide a gamesave as it is 12mb.
#17 Updated by christoph.korn about 9 years ago
Thanks to the help of the people in the IRC channel we were able to analyze the problem a bit:
This is the backtrace I got with the "core" file of the crash.
On Ubuntu I had the libc6-dbg package for debugging symbols installed.
With the interpreter the screen just was black at the time when normally the crash occured.
It looks like it was trapped in an infinite loop:
#19 Updated by christoph.korn about 9 years ago
Well I ran the game in the debugger and got to the point where the game normally crashed. But this time Pikachu just keeps falling forever without crashing the game. The game seems to be in some different infinite loop than on my screenshot because when this (from comment #18) loop happened there was just a black screen.
However after stopping the game and trying again the game also crashed now. So it is not behaving always the same. To be honest I have no idea what to look at in the debugger anyway.
Seems without proper debugging skills or code knowledge I won't get far with this bug.
But with the source code I have the same problem that I do not know where to start looking at.
Could someone give me a tip about in which module this bug might occur from ?
I also don't understand why I don't get a good backtrace from gdb although debugging symbols of a required library have been loaded:
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.12.1.so...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
#7 0x00007f866b164040 in ?? () from /lib64/ld-linux-x86-64.so.2
#23 Updated by Anonymous over 8 years ago
so far I've narrowed it down to:
801D16D4 lwz r10, 0(r5) # becomes 0
this occurs in what appears to be the processing of WAV (and other?) assets in MEM2. After the nullpointer is seen, some garbage processing occurs, and eventually a read from a bad address happens, causing a DSI exception. The game dies in the unhandled exception handler. Removing the DSI here doesn't help, since the real problem is whatever causes the value at 0(r5)(8049a394) to be 0. :<
osreport is at 802098E0
#25 Updated by Rupeeclock about 8 years ago
Poképark 2 reportedly has the same loading issues as the first game did, going by forum activity.
#26 Updated by parlane about 8 years ago
- Status changed from New to Fixed