Emulator

Ah, The pika STILL hasn't stopped falling.

Saves me a download. Will someone figure out why that Pikachu can't stop falling, before a Skitty or a Meowth uses the fact to catch it quicker?

sheng.long, Dolphin-emu does not approve of anyone illegally downloading Wii games.

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.

i really wanna play this game can someone fix this issue already

Me too, I want to be able to play-test the game for Dolphin.
I can't imagine this loading issue would be too difficult to fix, I think it's mostly related to the 38mb of temporary files it creates.

well if its that simple i guess it shouldn't take them long to fix i just hope they finally fix this issue soon coz i'm growing restless

Have you tried it with LLE? I know that it won't be playable, but it would be an interesting experiment.

The issue persists with the LLE plugin, and I don't believe the issue is related to the sound emulation in any way.

The plugin seems to work well, aside from the video on the title screen.

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.

hmm i was thinking since you could just extract the necessary files from the game with dolphin via game properties could you most likely get dolphin to read the needed files from a directory i dunno something like that....

The issue has advanced with r6164
The game now attempts to get past the loading screen and then crashes.

Unknown pointed address prefix 62, report this to the devs: 0x62875A20

Issue 3506 has been merged into this issue.

so has anyone figured it out yet?

The issue has changed, giving a different error message.
On Dolphin r6746, the game gives two error messages at the same point, "DSI exception in stmw", and then "DSI exception in lmw" or possibly "Imw"
That's when using JIT.

Issue 4170 has been merged into this issue.

Can you please provide some information about the background and complexity of this to fix?
Is it only a bug in existing code or is functionality missing in order to make the game run?

I am mainly an user but willing to help to fix this bug.

Thanks to the help of the people in the IRC channel we were able to analyze the problem a bit:
http://pastebin.com/Kr7PbM3J

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:
http://img6.imagebanana.com/img/pxyv87eu/Auswahl_007.png

Usually a game would go into an infinite loop if it has spun off another thread (which is meant to do the work) or if it has detected an error condition.

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.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2

#7 0x00007f866b164040 in ?? () from /lib64/ld-linux-x86-64.so.2

if you load a save from after the intro.... it works

where did you get that save?

Isaac, which version of Dolphin is the game working in for you?
I have a completed save loaded from my wii and the game still crashes when trying to load the playable game, regardless of the intro video.

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

Issue 5073 has been merged into this issue.

Poképark 2 reportedly has the same loading issues as the first game did, going by forum activity.
http://forums.dolphin-emulator.com/showthread.php?tid=5581&page=3

This issue was closed by revision 095b9de85e41.

This issue was closed by revision 53d2d9718fe3.