Emulator

This is reproducible in other games? What older versions have you tried?

Fog wrote:

This is reproducible in other games?

I just tested Pokemon XD, and it does not seem to exhibit this behaviour. However, it is difficult to tell with most games because you often don't have control of the game fast enough to see the initial behaviour. In Melee, if you enable the Gecko Code 'Melee Netplay Community Settings', you boot directly to the character select screen and bypass almost all loading. If there is another game that has a code that gives the user immediate control, then that's a good candidate to check the bug's behaviour.

Also, I did not explain this in the bug report, but an additional dead frame shows up later on (3-5 minutes after game start, roughly), meaning that all inputs are delayed by 2 frames from then on. I did not see additional input delay in Pokemon XD after 10 minutes, which leads me to believe that it is not affected by the glitch.

Fog wrote:

What older versions have you tried?

4.0-5400 had the same behaviour as 4.0-7161. I was told that a version from 'two or three years ago' (ie, 3.x) had additional delay, but also that there was a bug fix addressing that issue.

Tried anything newer? Lots have changed since 7161, considering we're well on our way to 8000.

theincrediblemastere wrote:

Tried anything newer? Lots have changed since 7161, considering we're well on our way to 8000.

Just tested right now, 7960 shows the same behavior.

Hey, just a note, I've tested this in 4.0-8586, which claims to have made some polling improvements to the emulator that benefit Melee, but this behavior is still exhibited in that version of Dolphin.

Practical_TAS wrote:

Hey, just a note, I've tested this in 4.0-8586, which claims to have made some polling improvements to the emulator that benefit Melee, but this behavior is still exhibited in that version of Dolphin.

Can you provide a DTM file which exhibits this behaviour?

Oh, I can't see the "note" section of the files, which is where I originally put the exact dead frames. In 7161.dtm, the dead frame is frame 783; in 8586.dtm, it's frame 712.

Could you try it without the cheat to see what happens?

Practical_TAS wrote:

This file displaying the bug with no cheats. Dead frame is 525.

Looked at the DTM file, it does capture one lag frame and records it in the header of the DTM file.

If you stop moving the stick and move the stick again after a little bit, does it resume normal behaviour?

Hmm, looking at the other two DTM files, they don't exhibit the lag frame in the DTM header.

I'll have to look at this further.

So doing some initial testing, there are actually three frames of lag being introduced. So if you go left right left stop, once you stop (the fourth frame), the inputs from the prior three frames will play out.

It's hard to tell if this is issue happens on console or not.

Before the "dead frame", you have two frames of lag. So it introduces another frame of lag later on.

If you stop moving the stick and move the stick again after a little bit, does it resume normal behaviour?

No, I've never seen it revert to normal behaviour.

So doing some initial testing, there are actually three frames of lag being introduced. So if you go left right left stop, once you stop (the fourth frame), the inputs from the prior three frames will play out.

Before the "dead frame", you have two frames of lag. So it introduces another frame of lag later on.

Wow, that hasn't happened to me. I know Dolphin sometimes ignores the very first input performed, but I've never had three frames of lag on 7161+.

Practical_TAS wrote:

If you stop moving the stick and move the stick again after a little bit, does it resume normal behaviour?

No, I've never seen it revert to normal behaviour.

So doing some initial testing, there are actually three frames of lag being introduced. So if you go left right left stop, once you stop (the fourth frame), the inputs from the prior three frames will play out.

Before the "dead frame", you have two frames of lag. So it introduces another frame of lag later on.

Wow, that hasn't happened to me. I know Dolphin sometimes ignores the very first input performed, but I've never had three frames of lag on 7161+.

It should match up with what you're experiencing where it reverses after a bit. However, I still don't know for sure if it's an issue that happens specifically with Melee in Dolphin or just happens in Melee in general.

I have recently become aware of Ishiiruka, a fork of Dolphin.

Ishiiruka has an option not present in Dolphin called "Double Video Rate Hack", which appears to double the rate at which inputs are polled without changing the frame rate of the output video. The bug present here is NOT present in recent builds of Ishiiruka, as explained in this link (Scroll down to the heading "Dead Frame Input Lag")

This leads me to believe that the issue is in fact a problem in Dolphin and not in Melee.

Last time I checked, the point of Double Video Rate Hack was specifically to change the framerate. That you don't get the input delay when using it doesn't prove that this problem doesn't happen on console, since the hack makes Ishiiruka act in a way that's impossible for real consoles. Thanks for letting us know, though.

JosJuice wrote:

Last time I checked, the point of Double Video Rate Hack was specifically to change the framerate. That you don't get the input delay when using it doesn't prove that this problem doesn't happen on console, since the hack makes Ishiiruka act in a way that's impossible for real consoles. Thanks for letting us know, though.

You're right, that's my mistake. I jumped the gun upon finding that there's a Dolphin fork that doesn't come with the dead frame issue.

I should clarify, however, that Ishiiruka doesn't suffer the dead frame issue at all, whether or not Double Video Rate Hack is enabled. Without the hack, it has a consistent 1 frame delay when TASing, from the start of emulation; with the hack, there's no delay at all. In both cases, the dead frame as described in this bug report does not appear.

Ishiiruka should be identical in regards to the lag. I wonder if it's just something stupid like framelag due to shader generation.

This can be closed. As per https://youtu.be/x2hu5ZEuzcc?t=4m8s, Dan Salvato has done some research on Melee and in the process discovered that this issue stems from a bug in Melee itself.