Emulator

https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds

Can you use this bisect tool to find the exact version where this breaks?

Fog wrote:

https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds

Can you use this bisect tool to find the exact version where this breaks?

According to the program, the exact version where this breaks is 4.0-8612. Thanks for the link, I didn't know that such a tool existed.

I did few more testing, and apparently the app made a mistake. Here is the actual version that started the issue: https://dolphin-emu.org/download/dev/master/4.0-8610/

In short, 4.0-8608 works, 4.0-8610 doesn't.

Never mind. It turns out that the skip EFB Access from CPU is responsible for this issue. If it's on, the issue exists. I'm going to add this to the wiki.

I seriously wish that you can actually edit posts. Anyway, allowing EFB Access from CPU causes massive slow-down. That should be checked before the issue is closed.

EFB Access being a massive slowdown is expected: it requires syncing between CPU/GPU

I'm a bit curious though to know why this game specifically needs EFB access, while Pikmin 2 (at least GCN) doesn't.

A lot of Wii games use EFB Access to tell things about the Wiimote IR and what its hovering over.

Yeah, but this game doesn't. The wiimote works perfectly with and without EFB access. The camera just refuses to be behind Olimar when EFB access is skipped for some obscure reasons.

It should be noted that in the game properties, the option synchronize GPU and CPU doesn't affect the issue. I really hope that there is an alternative way to deal with this issue, the EFB access causes really noticeable slow-downs compared to other games. Super Mario Galaxy doesn't suffer from such issues. Why? Maybe there is a specific part of the EFB that is important, in that case, It could be added as a hack instead or something.

Last thing I would like to mention is that the slow-down is not consistent and very odd.

So, while EFB access is skipped. Above land, or in water (in the distant spring, for example), my fps reaches 100-108. That value doesn't change when the camera 'angle' is changed. But when zoomed out, the fps naturally decreases to around 85-90. Which is understandable.

However when EFB access is not skipped. The fps goes down to ~20 during the top-down view (which is the only available option when EFB is skipped) going in water decreases the fps to ~14 fps.

When the 3/4 view is activated. The fps reaches ~45 no matter the zoom (in other words, 3/4 view, even when showing more stuff than the top-down view gives out less slow-down). However going to the water actually decreases fps back to ~14 fps. Now that's really odd.

Bottom line, something really fishy is going with the EFB, if it is skipped. The emulator follows the common sense in that the fps kinda decreases when more stuff is shown. And water does not do anything weird. However with EFB access enabled, the amount of stuff shown does not matter. The angle of the camera does however make a big difference. Also water causes slowdowns.

Can someone please investigate further in the situation? It's not the matter of the wiimote anymore.

The game is looking for stuff on the screen.

It doesn't sound like anything is really fishy, it just sounds like the game is using the hardware differently in different situations.

Can you explain a bit further, what does that have to do with camera angles, and what are those stuff. Is it looking for them using the EFB? if that's the case then why? The game works fine when EFB is skipped. Why does the game refuse to go in 3/4 view when it can't find those stuff or something?

It's probably using EFB Access to see various things on screen, perhaps Olimar, the number of pikmin, etc.

EFB Access to CPU basically means "I'm looking for something on the screen" and it gets that information and uses it for something. Super Mario Sunshine uses EFB Access to determine the turning radius of Mario based on if he's on screen or not, for instance. So, this is really just typical Nintendo game shenanigans.

So the game is trying to access something "urgent". And because it failed it prevents the 3/4 camera angle (even though it doesn't make much difference). Then in Pikmin 2, the developers decided, nah we don't need that?

Your speculation is not making much sense.

What I'm thinking is, based on playing the game. When Skip EFB Access is enabled, it's outright failing check, and thus falling back to whatever the default is.

I'm still a bit curious to what it is actually testing and if there is an alternative way to do this. You tested the game? Did you notice slowdowns?

Interestingly, the gamecube version doesn't seem to suffer that much, or at least the bug is not there: https://www.youtube.com/watch?v=W8U9H-lFDIY

now if someone has Pikmin 2 Wii, it's time to test this.

Fixed in 4.0-9426: https://dolphin-emu.org/download/dev/a9931e609fa3c4ca0abaf58d395a7555114ab4a4/

Fixed by 4.0-9426 -> https://dolphin-emu.org/download/dev/a9931e609fa3c4ca0abaf58d395a7555114ab4a4/

Feel free to keep investigating the behavior. I'm guessing that in the Wii port there were a lot of changes to the code to account for the fact that the Wiimote InfraRed now was used for the control scheme. In doing so, they had to make sure that stuff wasn't blocking the screen; if it was, you wouldn't be able to select/use Pikmin.

It could be something else, but EFB Access to CPU is an integral feature of the GameCube/Wii. Skipping it could cause all kinds of weird behaviors, from missing distortions, missing Bloom, various bits of the game not working (Pull Stars in Super Mario Galaxy 1/2), etc.

If you're looking for a way to fix it without the option, that probably won't happen. Sometimes the games do stuff that are costly to emulate.

Yeah, sadly I think this is the current only way to do it. The only other idea is to force the camera using action replay, a skilled hacker could do it, and in that case, I think adding that as a patch to the wiki would be the best solution.