United KingdomLocking as we now have https://www.speedrun.com/s3 (and https://www.speedrun.com/sandk )
Basically for the slope glitch to work objects need to be in a specific order in memory. Making the top big ring disappear (by collecting it) messes with that order.
Originally we were under the impression that entering the 2nd big ring fixed the order as the stage reloaded, which gave you 1 attempt to retry it.
However, since that stream, we had a discussion on the discord, and Chrezm did some science with it, that meant that you only need to enter the room where the 2nd big ring was to correct the order of the objects in memory. So on the 2nd run through, Ctrl could have entered the room where the 2nd big ring was, leave, and be able to still get slope glitch.
Have you checked out pho's video guide for the whole game? It has inputs shown too and
As a runner and glitch hunter for Sonic 3 & Knuckles. I can say that the 16bit Sonics still have some untapped potential for glitch hunting. There are a number of tools that we use (which have a lot of crossover with the TASes), to aid you as well.
Feel free to pop into the Sonic Speedrunning discord (invite links are on the left hand side of any of the main-line Sonic game pages) as that's where most of us hang out (including a couple of the TASers) to discuss glitches and strats.
Pretty sure https://www.speedrun.com/johnsmith101/allposts is going to edit the post at some point to include links.
Registers, then posts thanks to a response about a moderation option in a game (so it wouldn't have helped them as they're not a mod). Then so far hasn't returned. Rather fishy.
https://www.speedrun.com/Redgomes/allposts copy of https://www.speedrun.com/Speedrunning/thread/t50rt/
Also, there's these two which kinda seem suspect with text from Reddit questions that already have answers etc: https://www.speedrun.com/GilbertJobs/allposts copy of https://www.reddit.com/r/speedrun/comments/d5ag0v/what_are_some_good_glitch_exhibition_channels/ And https://www.speedrun.com/AksarBhai/allposts copy of https://www.reddit.com/r/speedrun/comments/d5qvo0/super_mario_64_speedrun_question/
Whilst nothing inherently wrong with cross-posting; it seems rather odd that they have cross-posted it days later after having received responses there, so figure they warrant further scrutiny.
Damn, 3 in a row 🤣 https://www.speedrun.com/iosman123/allposts Copy of:
https://www.speedrun.com/moltoviaxx/allposts Links look dodgy for first post.
In my opinion, it's pretty much cut and dry. Unless it gets really popular with speedrunners and gets its own platform (which I'm doubting as it has both input and audio lag). Then as it's an SoC emulator it should just be classed as Genesis with the Emulator checkbox ticked and handled like any other non-FPGA emulator.
https://www.speedrun.com/Riogomes/allposts Forum thread is a copy+paste of: https://www.speedrun.com/The_Site/thread/wnx7k
Ultra-minor one, page title (and twitter description) for runs duplicate the runners names e.g.:
https://www.speedrun.com/Nigan/allposts earlier posts seem to have some shady links (maybe edited in afterwards?).
Also Copy/Paste of other posts: e.g. https://www.speedrun.com/The_Site/thread/rz6w1 is a copy of https://www.speedrun.com/The_Site/thread/qt1zk
https://www.speedrun.com/Streaming_Recording_Equipment/thread/h86pd is a copy of https://www.speedrun.com/Streaming_Recording_Equipment/thread/9wzvz/1
I'm not sure why you are talking about FPS with regards to RunAhead, RunAhead has zero impact on fps, if RunAhead causes a lag frame to be jumped over, it is still classed as a frame, so the fps remains unchanged.
Also, there are only 2 ways of being able to get RetroArch to run at exactly 60.099fps, turn vsync off and audio sync on, and get tearing (or dupe frame if sub-60fps core). With vsync turned off you also lose the ability for frame delay (since it uses vsync to time the delay). With vsync on; retroarch will deviate from 60.099fps dependant on other settings to ensure vsync is hit (or attempted to). The other option is "Sync to exact content frame rate" which can only be used with GSync/FreeSync monitors, where it will run at what fps the core has stipulated.
Showing the FPS display in Retroarch is a fairly pointless endeavour as well, as when you have exact content framerate on and audio sync off, it's a static figure (the core's desired fps, which in the case for fceu with an NTSC game is 1008307711.0/16777215.0 i.e. 60.0998265207, but obviously retroarch truncates/rounds the figure for the display). And when exact content frame rate isn't used, it's based on an average of Retroarch's attempts to try to get vsync/DRC/audio sync etc at a consistent point. There is very little you can deliberately do to get the FPS higher without it being noticeable, there are some things that will have a minor effect on it, like a monitor refresh rate that isn't 60hz or 120hz.
Frame Delay is no more resource intensive than it set to 0. It just gives the core less time to generate the frame, if it doesn't generate it in time then the frame is skipped, the core still processes it in the same time regardless.
I'll say again; a few of our (apparently "non-serious") speedrunners did like for like testing for input lag between real console and retroarch with different runahead settings to come to the conclusion that RunAhead of 1 for genesis provided the closest match for input delay between the two, and even then it still didn't provide an advantage to emulator.
Also, I should point out that Hardcore mode in Retroarch which disables emulator advantage features, like save states, rewind, fast foward, etc, does not disable RunAhead.
So I stand by my point, it should be dealt with in a case by case basis, with investigation being done (preferably by console runners, who are acustomed to the lag on console).
But what do I know? I'm not a serious speedrunner apparently.
@screevo Just curious if anyone (speedrunning related) has done any direct comparisons with runahead using a high FPS camera recording the input and screen etc and when it shows on screen between console and retroarch with runahead? Not with the target of being ahead of console, but matching it.
Bottom line (for me) is there are multiple factors that affect input latency on an emulator, which can even be down to which controller or monitor you choose to use, for controllers, bluetooth adds more than USB, and USB still isn't perfect unless you use something like a blissbox to remove that,.
We did have a console runner who used a blissbox with retroarch as well and deemed that 1 frame runahead was close to actual console but still not quite as responsive. Not 100% sure of their tests, but others in the community who have done frame perfect tricks on both console and with retroarch and 1 frame runahead and have come to the same conclusion. Not scientific by any means, but hasn't caused any reason for concern thus far.
Given that this appears to be down to an FCEU overclocking option, it's clear that Retroarch's options were not the cause of the speed difference anyway, so hopefully this matter can be considered resolved :)
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.
[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.
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.
Yup, that's fine... some top runners use custom made fight sticks for speedrunning Sonic games on a genesis.
As long as you don't take advantage of features like macros or turbo, you're good to go with 3rd party controllers.
As I mentioned previously, Winauth and browser extensions also are available that can generate the codes. Not as secure for the individual as having a separate device. But still protects the site from shared passwords and still not a big inconvenience either.
