Faster Melee

Home About Archive Guides Subscribe Discord

NEW! Major Lag Reductions Discovered for Melee

This discovery opens up the possibly to play Melee online without input lag if your ping is 50ms or lower. In theory, this lag reduction saves up to 1.5 frames compared to a standard console and 60Hz TV. This involves either using the new 120FPS build of Dolphin or using the new Gecko Code that tries to do the same thing in-game without Dolphin doing the work (more on this later). If you have a 60Hz monitor, you will still save about ~1 frame total from either of these hacks. If you have a 120Hz monitor, that extends to ~1.5 frames from the transmission time being reduced by half a frame. Currently this in-game version does not yet work on console - in theory it can work though so we still have hope.

Melee HD Reddit

Over a year ago, I wrote the first Melee HD post describing how for the first-time-ever: we can finally play Melee on Dolphin without any input lag locally. Which was a huge deal. Everyone knew about Dolphin but everyone discredited it until that point because the lag situation was a joke. Since then we've been able to enjoy high quality Melee and play online with the only lag being from the connection itself and not from adapters or monitors if you have the right setup. And now, for the first-time-ever: we can finally play Melee ONLINE without any input lag when your ping is 50ms and below!

20XX Multiplier

So here's the story. A little over a week ago I was messing around in 20XX and noticed in the first menu there's an option to adjust the speed at which the game runs at - everyone may know about "Slow-Mo Melee" found in the Special Melee modes, but this does not slow the game down by exactly 50%; so it wasn't until the new 20XX came out with this option that I thought to try this. (I also totally forgot about training mode as I almost never use it)

Dolphin Speed Limit

So this is what I realized. See, in Dolphin, you can adjust the game speed. You can force a game to run at 200% 120FPS - but the catch is that while it runs at 120FPS, that makes everything run twice as fast; so there wasn't any real benefit to ever using this and it was just something fun to mess around with at best. But then that morning it hit me. Why don't I put Dolphin at 200% 120FPS on my 120Hz CRT monitor - THEN adjust the game speed multiplier in 20XX to 0.50x? That way you have one thing doubling the speed and the other halving the speed so it evens out. The video smoothness was the first thing I noticed. You get major benefits in terms of reduced tearing, stutter, and any motion artifacts from using 120FPS @ 120Hz - even on a 60Hz monitor it should still have an effect.

The thing with console is that there is roughly ~3 frames of input lag. I was even reminded of this on Twitter from Tai here:

Tai Twitter Reminder

One of those frames is from display lag. Even our precious CRTs lag 16.67ms before they completely render a frame top to bottom. You can read more about this in my write-ups here and here. The other two frames are from the game itself. Yep, it's true - we've basically been playing on buffer 2 for the last 15 years with most of us not having a clue. Our standard console play has a whole frame of extra lag. Well the good news is, we can actually change it now if we choose to. Obviously this won't happen anytime soon, but it's an option for the future. For now, let's focus on where we can actually use this: Netplay.

Timeline Animated

It's important to note that this is simply the working theory based on what we think the code is doing. We still need to test it more to verify that this is what's actually happening. As far as what a human is capable of feeling in terms of input lag - I can say all ~15 testers so far agreed there was a significant improvement based on testing over netplay. So I think we're off to a good start. I should also emphasize that you do not need a 120Hz monitor to feel the effect. Regardless of the monitor, the game lag itself is being reduced by a frame. The 120Hz monitor is saving an additional half frame. So for a 60Hz user, they can play up to buffer 2 with console lag (33ms ping). A 120Hz user can play up to buffer 3 with console lag (50ms ping). This also allows you to play people much farther away than you normally would. I was testing with people on the west coast (from Chicago) getting pings at 107ms buffer 7 and it was totally playable. Felt like buffer 4.

Desktop Screenshot

Let's talk about the problems I encountered getting this thing to work. When you change the speed of emulation, you change the pitch and speed of the audio. This was by far the biggest problem. And when I first encountered it, modifying Dolphin wasn't even on the table. My whole game plan was to literally edit every piece of audio manually and put them back into the game at 0.5x speed to balance it out. If you click the thumbnail above, you can actually see a screenshot of what my desktop looked like during this process.

It was a nightmare. You had to do 15 things just to get one thing done. To my surprise, I actually was able to get all of the relevant music in the game converted. At first you might think it's not that difficult but when you have to deal with the loops in the music and setting those perfect and right on the block, it gets pretty tedious. Not to mention everything had to be converted from .hps to .wav and then into LEFT and RIGHT .dsp tracks and THEN back to .hps and you better hope to god you got the loops right. But the even more tedious job was the character and menu sounds.

For one thing, they don't exist on their own. They exist in a bigger container file that has all of the sounds for that character. This is called a .ssm file. And sounds featured completely different rates. Some were 8k, 12.5k, 22.5k, 32k, 44.1k, 48k, etc. Not to mention some were mono and some were stereo. So even though I had a good method of converting the .ssm files to .dsp files and .wav files, it was hard to batch process anything because the rates and channels were all different. Then, even when you finish doing all this. Just for one sound, you had to manually insert this puppy back into the original .ssm file via hex editing.

So this was the point where I started to realize I need to recheck if there were any other options. Throughout the process I was talking to various tech people in the community like JMC, SleepyK, ShortFuse, CeLL, etc. And ShortFuse remembered seeing an article on the Dolphin Blog talking about 60FPS Hacks. This had to do with making 30FPS games like Super Mario Sunshine run at 60FPS. The idea was to make Dolphin do the audio work instead of the manually editing the files in the game.

Visual Studio

The code was not hard at all to modify. The trouble was figuring out where this was. In the article, JMC talks about modifying the SystemTimers.cpp. I did try this and it actually adjusted the speed just fine - but the pitch was still too high. We thought maybe we needed to adjust something in Mixer.cpp to maybe adjust the audio stretching. But this wasn't it either. The solution turned out to be in the AudioInterface.cpp. It was simple - reduce the amount of samples by half because the game is running at 2x. It worked! phire super helped me out finding this so shoutouts to him.

Another problem was figuring out what the hell the Gecko Code needed to be EXACTLY to slow-down the game perfectly for 120FPS. On Smashboards there's a thread from a while back where people were trying to do this very thing! But it was back in the day when Dolphin sucked. They were trying to see if the code would let Melee interpolate the rest of the frames and it didn't work. The input lag back then was pretty bad so it wasn't really about that. Remember, they were on a build that had no Native Support, Exclusive Fullscreen, or proper Netplay.

So it turns out Dan Salvato wrote a 30FPS code that DoctorKirby ended up using to figure out what any FPS you want should be. There was actually a lot of confusion though within the thread because DoctorKirby didn't exactly explain how they got their 1 FPS code and they actually believed Dan's original 30FPS code was wrong. So I thought maybe DoctorKirby was right, so I tweaked their 60FPS code by converting their hex code into decimal code, multiplying it by 2, and then converting that number back into hex. This did the job but how could I know if it was really right? There also was a concern that maybe it needs to be divided by 1.001 (60/59.94) to properly account for the fact that NTSC is really 59.94 FPS and not exactly 60.

Dolphin Dev Mode

I ended up messaging Dan to get to the bottom of it and he explained how he got his original 30FPS value and how it works.

Dan Salvato: All you have to do to perfect it is see what the variable is when the game is at 100% speed and then cut the variable in half.

Truck: How can we get the value?
Truck: Is there a way we could dump the memory from Dolphin or something?

Dan Salvato: Start Dolphin with the /d flag to get the debugger interface and you can just browse to the memory address.

So that's exactly what I did. And was able to pull the value right from Dolphin. I took that value and multiplied it by 2 after converting it from hex to decimal like before. It was the same code from the 120FPS thread - So we could put to rest any doubt that the 120FPS code deriven from Dan was wrong. So I switched the Gecko Code in my build back to the original.

Besides all of the 120FPS stuff though, there is another issue that needed to be fixed outside of that. First mentioned in the January Progress Report on Dolphin's blog, there was actually a significant polling issue.

"Dolphin was actually polling for input at the wrong part of the frame, so, the game would check for if a button was being held, and Dolphin wasn't actually checking for input at that exact moment. This bug also applies to other games; you may notice games like Super Smash Bros. Melee feeling a bit more like console. Any game that relies on very specific or subframe inputs should be noticeably affected; assuming both the user and game are precise enough!"

And even though that was 5 months ago, the current netplay build we've been using on SmashLadder does not have the fix for this. What happened though is while the Dolphin Devs fixed the bug, it caused desyncs and other issues in netplay. So it worked offline just fine, but not over netplay. Coincidentally though, as I was making my build, a fix came out for it and I added it to my build. There was another issue with Rumble that was also fixed that I added to my build.

Let's go over the purpose of my build real quick because it's important. You have to understand this manipulation of Dolphin is not at all well received with the Developers. It was not recommended to do things this way. However, it is way too important to simply "wait until we do it the right way". So what is the right way? Well, we're supposed to actually reverse engineer the game and find some sort of Gecko Code that automatically fixes the sound issue in-game. Yeah...doesn't sound like that's happening any time soon. Understand that the only reason we even have the 120FPS Gecko Code working is because Melee HAPPENED to HAVE a speed multiplier built into the game! That made it wayyy easier to find and it was just one line of code. So that being said, this build will serve the purpose of having the bleeding edge enhancements (like the latest bug fixes and features) while continuing to remain as a TESTING build and not as a final product. If players want to use it though - they have that choice. But I cannot promote it as a finished product.

Another thing I'm doing with my build is I'm configuring all the settings each time I compile it so all the player has to do is add their Games Directory that their Melee iso is in. The game speed, adapter, mem card, gecko codes, graphics, and netcode settings should all already be adjusted ahead of time. This is what SmashLadder should have done in my opinion. You prevent a lot of dumb questions in chat too from people who don't like to read instructions.

TruckJitsu: in terms of visuals, it seems like there's smoothness just in terms reducing tearing / stuttering and those kinds of artifacts

JMC47: yes
JMC47: that's absolutely true
JMC47: you'll be seeing more frames and stuff
JMC47: it'll be rendering more
JMC47: you'll be seeing double the frames
JMC47: if you got the Computer for it, then it'll be "better" visually

If you got this far in this thread, understand that this is not making Melee render NEW interpolated frames in between the normal 60 frames per second - it is still just 60fps in terms of animation. In the future though, because the game does use interpolation, we can modify it potentially to literally render new in-between frames and get true 120fps. But even though the game is only 60fps with frames being doubled - that in itself enhances the visual quality. And it does it without compromising input lag unlike using something like buffered vsync.

In the beginning of the write-up I mentioned that there was another way to reduce input lag without using Dolphin's 200% - a way to speed up the game by using the game itself through Gecko Codes. This is something we're still testing and I will make a separate post for this once we verify the results. So far it seems promising so just know that it exists and will probably be the new standard for netplay considering it doesn't require a separate build of Dolphin to work - I still am going to push for 120FPS Melee using 200% emulation though because it is still the superior method because of the better visual quality - even for 60Hz monitors I still think running the 120FPS mod runs smoother than the 60Hz mod. In terms of input lag though, they might be the same. I'll keep you updated. The in-game version of this trick was discovered by Dan Salvato by the way. When we were talking about the 120FPS code he randomly messaged me back with this new code to test out. I guess this idea gave him a spark to try out another idea and we think it worked. But like I said, I'm going to make a separate post specifically for Dans new code he found and how it can change the standard in which we play Netplay. If you want to test this stuff out with us, join the Discord!

Reducing the input lag in Melee was always a pursuit of mine. But my focus was always on display lag. I was thinking hey, what if we get 1000hz monitors using OLED technology in the future? I never thought to emulate the game faster or modify the game itself. So it's amazing that we're getting less lag using this technique than if we had 1000Hz monitors. Pretty insane. There are limitations to how far this can go. I did make a build for 400% 240fps that did work - but it's hard to say if it's worth it because you need a 240Hz monitor. Which there are some legitimate ones out there. One is the Nokia 445Pro CRT - which can go up to like 350Hz or something because the manufacturer did not put a hardware limit on that monitor. You don't see the typical "out of range error". This is talked about on the Blur Busters forum here. On overstock.com, they were around $280 though so it might not be worth the investment. Another newer method is to overclock compatible gaming monitors to 240Hz - you can read about this method here. These true 240Hz solutions would allow us save another half frame of latency. However, we run into a problem of diminishing returns because the wii-u adapters have limits on their refresh rate. We'd need to get a new adapter that could support 240Hz or more. This is possible and I will make a separate write-up for that. Just know that there's more improvement possible in the future.

Wrapping up, I have to say thanks to all the Dolphin Devs and Melee Tech people that helped me along the way and I hope all of you join the Discord and test this baby out. The instructions will be provided on the Guides page. Special thanks to JMC, phire, Dan Salvato, ShortFuse, CeLL, and SleepyK. Thanks for reading.

I'll be posting more frequent updates in the Discord while keeping the bigger write-ups on the website. You can also follow me on Twitter @TruckJitsu.


Share this on Reddit here!


Posted on 5/4/2016 by: TruckJitsu