As you probably noticed all of omkommersind's runs have been removed, so i will make a little backstory about this:
1 month ago the russian runner Omkommersind submitted a new WR in the any% difficult category. I verified it after watching carefully, and i didn't apparently notice anything sketchy, apart from the fact that it had some suboptimal strats and some mistakes / missed skips (example: webby skip). Still was beating my previous run by two seconds. I verified it because my 9:19 still has some time to save due to some outdated strats.
Next he submitted a WR for the good ending category. Even that run didn't seem to have anything bad, and had a lot of time to save due to various reasons (basically RNG related).
Yesterday i noticed he claimed to have gotten a very high 9:11, which was re-timed by swordsmankirby to a 9:12.01. I watched the run very carefully, and still it seemed strange he could tie a good WR like that with so many mistakes (iron grips here and there, missed webby skip, 4 cycle egypt boss). Then i noticed a specific thing (will post videos): when going over the last falling bridge in Niagara Falls he kills the bird and gets no lag. Well, every DT2 runner knows that killing the bird there is a big no no, because its sprite + the falling bridge = a lot of lag. So we just release the dpad for a couple of frames as soon as the bird appears to pass underneath it and go through with almost no lag. at first i thought he had found a way to manipulate it, so i tried to replicate it on console. No way. As soon as you start pogoing you get the lag. So i asked which emu he was using, and he answered me he was using Retroarch frontend with FCEUX core. Retroarch is a frontend that allows playing multiple emulators with different core. He said he was using it because his PC can't handle regular FCEUX.
I decided to do some comparison on the aforementioned bridge and here's my results. For the emulator i used the EXACT SAME rom file i use on console. Plus i used the real japanese cart, but still had the same results as the everdrive, so i didn't record anything.
This is Console vs His run: https://streamable.com/nyke0
This is regular FCEUX vs His run: https://streamable.com/puk3o
Way faster.
I also received some informations about retroarch, which has many features and tweaks to basically delete any kind of lag / input lag if you know how to use it. Pretty advanced stuff. Since he said he's using retroarch because his PC can't handle regular FCEUX i decided to try it, assuming he was using the default settings (FCEUX core of course because that's what he mentioned).
Here's the comparison: https://streamable.com/3x8ad
Still faster. So i don't really know what happened here but i had more informations that with the right tweaks is possible to achieve those results on retroarch. And keep in mind this, with an i7 Intel Core it took me about 30 seconds to just load Ducktales 2, vs the instant load from FCEUX. How is it possible that a frontend+FCEUX is faster than just using the emulator alone? If you have a slow PC just go with Nestopia, best choice.
Anyway i'm not able to tell if this was intentional or not. I'm just saying these runs unfortunately can't be accepted for obvious reason. For emulator i highly suggest to apply these rules:
-
You have to specify the emulator you're using in the submission comments (of course in some cases it's pretty obvious).
-
Retroarch is now officially banned with any core. Those possible tweaks and features are too risky to just let them pass.
Thanks a lot and sorry for the wall of text
PS: In one video i have a suit because it was during lunch break and i had to go back to work. Sorry :D :D
Well it is a pity this became obvious only when I got under WR times, as I started submitting runs on retroarch more than year ago and they were verified by honored people here. I gonna retry all the runs on nestopia, hope it will lag enough. P.S. some more risky places while we are talking about it: we cant check which rom is used by speedrunned, no matter if he uses flash cartrigde or emulator; you can totally remove lag from dt2 just by optimizing the game code inside the rom, you can just speed up Scrooge's walk speed just a lil bit or whatever you want.
I would suggest before ruling Retroarch as the issue, eliminate that it isn't a core issue with fceux as well. There's Ludo https://ludo.libretro.com/ which is minimalist emulator that interfaces with the cores, it has none of the options that Retroarch has for reducing lag etc. So is a great test to see if the core is at fault instead. If you get the same issue in Ludo, then it's certainly an issue with the core, rather than Retroarch.
PS: I have no vested interest in running this game, but I do run other games on Retroarch, and have done a lot of research in the Genesis (mainly Sonic) community with the emulators available.
@Omkommersind yes usually WR submissions are more carefully examinated. It's pretty normal. Especially in High optimized games. Thanks for your suggestion about the used rom. It's definitely something we Will keep an Eye on, but like i said i tried It on the original cart and had the same results.
Anyway it's not a matter of getting enough lag, it's a matter of running the same way as the original cart, otherwise It would be an unfair advantage.
@Mannix86 There it is. Bizhawk vs Omkommersind's run https://streamable.com/80q27
Keep in mind this. It's not a retroarch problem, because as you can see in one of my comparisons, regular retroarch with FCEUX core just runs the same as the other emus and as the console version, the problem here is that the version used in the rejected runs was (intentionally?) obviously tweaked to run like that. I even tried Retroarch both with mesen and bsnes cores with default settings and they still runs slower than omkommersind's. So the thing here is, were all these tweaks intentional or it's just a bad core used to run smoother (for slow pc reasons)?
@garadas for sure it was intentional I tried a lot of settings changes to get rid of freezes, sound lags and ugly lines on screen redraw, not sure which of them made it "even faster that console" but I dont think anything was wrong with the core
Keep in mind this is not a personal attack, i would be happy to accept any legit WR submission, but those runs aren't acceptable.
Download Retroarch, download FCEUX (core) and do the same test and you'll have the same result (pretty sure, promise you) as FCEUX run through Bizhawk. Retroarch does nothing as a frontend and there should be no difference using FCEUX as a core compared to FCEUX as a standalone emulator unless you adjust various settings from within Retroarch's menu itself.
Retroarch, if anything is incredibly good at reproducing stuff like lag frames, etc. I used to use it to run TMNT2 sometimes, also using the FCEUX core. Half of my submitted runs on that game are on a RetroUSB AVS, the other half on Retroarch via FCEUX core as Nestopia ironically doesn't run it (and emulator runs were marked as emulator). Anyway, everywhere the game lagged on console, also lagged on emulator via Retroarch & FCEUX. It was the only game I sometimes ran on emulator despite having a console setup because at the time the brick controller + that game in particular was uncomfortable.
Also, don't mean to make this sound bad at you or anything @Omkommersind, but this should be a truthful response.
that's what i meant, i tried the same part with Retroarch + FCEUX core and got the same result as regular FCEUX (well, apart from the slower loading times). 2nd and 3rd comparisons are exactly these two.
Yeah, there's literally no difference, and should be no difference, so I'm glad you checked. Retroarch isn't some undiscovered cheating tool or anything like that. It has many, many options to reduce things like lag frames, or adding extra sprites that could be used in the wrong way, among other things, but default, out of the box, it's just basically an emulator that is like MAME that supports many different emulators ("cores") / consoles and is more convenient than downloading 20 different standalone emulators. If you download a core, and touch nothing for settings, it's exactly the same as using the standalone emulator variant.
I think need update the rules for this game. Add milliseconds. Why not add in any% and good ending subcategories, if the second category does not add hard then it seems to me there is no point in the any% difficult category.
@NeGAtiv4k that's something i wanted as well. Any% difficult can be deleted but that's something we're gonna discuss later.
@PresJPolk agreed. Retroarch Is perfect for casual retro enthusiasts, not for speedrunners unfortunately
@garadas21 maybe add a subcategory for a separate complexity, whereas for me everyone can choose the complexity for themselves. Sorry for my google translator) in English I'm not strong.
Just adding my 2 cents here. Retroarch has been banned from many Game Boy boards for a while. We had tested it to lengths with different cores (e.g., the supposedly accurate Gambatte core), but we could not find any setting that produced satisfactory results - which resulted in the exclusion of the emulator. One major issue seemed to be vsync, as we could not find any setting that resulted in the correct frame rate - even in completely static sequences without any lag or loads. I have no idea if this applies to NES emulation in any shape or form so please just treat this as additional information for further research. Another setting THAT SHOULD VERY OBVIOUSLY ALWAYS BE TURNED OFF is the runahead feature. ( https://www.libretro.com/index.php/retroarch-1-7-2%E2%80%8A-%E2%80%8Aachieving-better-latency-than-original-hardware-through-new-runahead-method/ )
Edit: Testing had been done about 1 to 2 years ago and I have no knowledge about any updates since then.
[quote]Another setting THAT SHOULD VERY OBVIOUSLY ALWAYS BE TURNED OFF is the runahead feature.[/quote]
This isn't always the case. One of our console runners did a bunch of testing (for Genesis), and runahead of 1 came close to console but due to other factors as well, it still had more input lag than console. However, I should say that if runahead is used, it should be dealt with on a case by case basis with each game and/or platform, and an experienced console runner should be doing the testing.
It's a bit strange that you couldn't find settings that get the correct frame rate. I run GPGX using the sync to exact content framerate setting (on a GSync monitor), which means the core is always in control of the framerate rather than retroarch trying to get a sync up with the monitor. Before getting a GSync monitor I would have the normal issue of occasional duplicate frames every so often due to the fps mismatch between montior and the GPGX core.
Actually, @garadas21 checking the streamable links again, (looks to be 30fps so not 100% accurate). This is almost certainly from using runahead with a value that is set too high where it is set above of the amount of input lag frames for the game/platform (obviously requires testing, but I would hazard a guess that it's set to at least 2 in this instance).
But you can see if you go frame by frame, there are animation frames missing in the jumps etc. These could be from the 30fps encode, but it looks unlikely that you see more in your video.
We have a similar thing in S3K if Runahead is set to 2, which you can see here: it misses of the first animation frame (where Sonic is in a ball at the lowest height).
This is something that mods can fairly easily check for to reject runs as well because the expected animation frames are always missing from an input change - and there's no real reason for not having 60fps encodes for 8/16 bit consoles in retroarch anyway.
EDIT: just for clarification, skipping animation frames in this fashion, also means if those frames are lag frames, they will be skipped as well.
I recorded my video in 30fps to have a reliable comparison. So thanks for the heads up.
