Can you tell us where you got your FreeDOS image from? Its ID doesn't match with the imported image that came with the JPC source (yours is 45c3f118cbca79f176307142c73f780c, the imported one from the JPC source is f334bc4d5dc5f393feb0ca2d1e1cdc25 (which you have used in the past, mind you)). In fact, it doesn't even match with the imported 1.2 image (b47e30f0d3574d8be004742104ada494).
1. In fact, Burb's testrun on Bizhawk 2.2.2 doesn't feature such heavy graphical corruption either. I don't know exactly what caused those lines to appear in my run, but my best guess is that this is because I entered the glitch world during day time since I skipped the day-night transition, while all those RTA runs enter the glitch world during the horrible night.
I can at the very least confirm that bit from my testing (on BizHawk 2.3). However, I seem to be completely unable to replicate the glitched world after leaving the glitch white town (and I also sometimes soft-lock in the town). Maybe it's because I don't perform a certain glitch with the whip (where you phase through the floor, shown at around 3:32 in the temp encode). What happens when I leave the glitch town the intended way (without any glitches): The game loads the area normally.
Further testing will be needed.
FWIW, there are RTA runs that perform the same death warp, but 1) the graphics aren't corrupt post-death warp (no lines everywhere). 2) They all load from an Everdrive. 3) None of the runs show the save slots.
The only difference between the difficulties in this game is the points you get in the final score tally of each level. It doesn't change the time limits on the levels, enemy behavior, or the points you get for doing any actions in the stages.
Actually, it seems the time limit ticks down a wee bit faster on Hard than on Normal (judging from the comparison encode).
It seems like this TAS was initially started with a version of the Nintendo FDS BIOS that was converted to the iNES format. However, the TAS syncs just fine on the actual (raw) Nintendo FDS BIOS and the Twin Famicom FDS Bios (cf. temp encode).
This submission's 'ROM' is a unique cartridge image file that I created. As it was created from the same disk image that adelikat used in his run, I assume anyone else using Disk2EasyFlash on that disk image should be able to create an equivalent cartridge format image to verify this submission.
Yeah....no. For one, the game was never released on a cartridge. So, we're limited to either the tape version (and deal with absurdly long load times) or the disk version (which is often a cracked release, which adelikat used in his TAS), not a cartridge image you created yourself with some tool.
FWIW, there's a thread on Reddit that's talking about this issue.
BTW, some of the videos that I very distinctly remember uploading at 720p60 are no longer 60 FPS.
Just as a note: We do not allow usage of that build for our encodes, as it causes more graphical bugs to happen when upscaled (maybe not necessarily in Super Monkey Ball: Touch & Roll, but in other games, it causes graphical bugs to happen that normally don't occur on a vanilla DeSmuME build). See feos's post.
Not to mention its release was likely past 0.9.11, and since most NDS TASes are on 0.9.9, they will very likely desync on that build anyway.
Skipping World 6 by having a specific powerup at the end of World 5 is not "Warpless" to me. Not voting.
World 4 also gets skipped, because of what Patashu said in his post (and also requires the Mini-Mushroom if you want to access World 4). Not to mention the published run does the same.
Use an official emulator version
Every officially supported TAS emulator has a repository to host official releases obtainable as a package (like binaries). These official releases are supported by TASVideos. Using custom or interim builds compiled from emulator source code (from e.g. svn or git repositories) is not officially supported. Always make sure your movie syncs on the official releases; use interim builds at your own risk. If a movie syncs on some interim build, but doesn't sync on any official release, it will be rejected.
Note that some emulators require interims because their official releases are infrequent and/or often outdated (including Dolphin and VBA-rr); for these emulators, interim versions are accepted on a case-by-case basis. If you are considering using such an emulator version, ask a judge if it is justified in your case. If it is clear that there is no other way to TAS your game, permission will be granted.
You didn't actually use BizHawk 2.0.0 (since it seems you looked at the movie version instead of the emulator version), but an interim release (specifically, this one). However, the TAS syncs on BizHawk 2.3 (an official release).
Notes for the publisher/encoder:
The TAS desyncs around 30k frames in with GlideN64 (roughly the second map after the intermission text). However, it's also the only plugin that emulates the "melt" effect when you reach the exit of a stage or when you die. I currently don't know which setting in Glide64mk2 (which was used here) restores that effect, but I do know that the "Framebuffer read every frame" setting in Glide64mk2 restores the fade-outs (after selecting the difficulty and after pressing any button on the results screen after each map).
Actually, considering the fact that he (and also EZGames69) have copied my exact rating for MrWint's run, it takes more than a few efforts since he chose to make it personal.
How's about you heed Warp's advice and stop once and for all. It's getting really tiring at this point.
As for the encodes being broken, they have been fixed (in fact, the compatibility encode was never broken to begin with, as both feos and I confirmed it was fine).
It would be really nice if you actually posted the improvement in this thread instead of leaving it as an edit to your submission, because it can be easily missed if just left as an edit.
(by the way, the reported time on Microstorage is wrong, it is in fact 11:25.49 long)
The whole site, speedrun.com, did not even exist when this submission was created.
Does it matter?
On Speed Demos Archive, the speedruns are timed from when you gain control of the character (in this game, you gain control of Batman after "Stage 1-1" vanishes) until the loss of control (in this game, when the screen starts to fade after approaching Joker). Obviously, our (current) timing starts from console power-on and ends when the credits are reached without further interaction (so no manual input needed to reach the ending).
I'd really appreciate if you replied to the other points I made in my previous post.
Checking over how the input is placed it seems intentional that the input ends after the final hit, but what occurs after such as going straight to the credit sequence without additional input is unknown.
Without submitting a statement concerning what happened with this submission, I will add for the record, that it used to be a practice in the early days of TASVideos — and this submission certainly qualifies — that movies do not need to supply all input to advance the ending.
Are you absolutely sure it used to be a practice? Because we checked certain games that require extra input after the final boss is defeated to actually reach the ending, and as it turns out, only two movies did not perform the extra input necessary to actually reach it, this being one of them. The second one, incidentally, is also one of yours.
This was possible as long as the necessary input would be trivial, such as in Rygar where you just press a button at any time of your choosing, to flip the page in the ending scene.
Here's the thing: In Rygar, you still reach the ending, requiring just one button press to advance in it. In this game, for instance, you have to get to Joker after he's been defeated to actually get to the ending. Needless to say that by today's standards, this movie would be rejected for not completing the game proper and thus should've been replaced with an extended file that actually reaches the ending.
BTW, the SRC rules for this game are also pretty clear:
Timer ends when you loose control after Jokers deathanimation and the screen starts to fade.
The screen never starts to fade with the movie file alone, unless manual input is provided.
At the beginning of this work, I just wanted to use area 1 and area 4's glitch. Because I thought that cell glitch belongs to "game end glitch" branch. Since mtvf1 suggested me to give it an "any%" name, I agree with him.
And I don't agree with him, since all any% TASes on this site do not have a branch at all or have a branch that's not just "any%".
Per the Publisher Guidelines:
We don't have a concept of "default goal", therefore we don't use labels like "any%" as a branch label. Instead we identify what is unique in every branch or set of branches, something that the other branches of the same game don't represent.
I myself wonder what the (seemingly, as I don't know the game) missed hit opportunities at the fight against Innova are about, though. Like, it seems you could hit him after he's done with just one dash, but instead, you're often waiting until after he's done with the second or third dash before attacking.
I'd really like to see this addressed, since it seemingly went by unnoticed (and because I'm genuinely curious).
I liked this run until about the 16-minute mark which is when the reality of fighting end-game bosses at extremely low levels kicks in.
Yeah, I especially felt the fight against Innova was dragging on, and on, and on, and on, and on, and on, to the point where I started speeding up (but only got 10 extra FPS, so it was effectively 1.17x speed).
I myself wonder what the (seemingly, as I don't know the game) missed hit opportunities at the fight against Innova are about, though. Like, it seems you could hit him after he's done with just one dash, but instead, you're often waiting until after he's done with the second or third dash before attacking.
Even then, considering the later boss fights drag on for so long (especially Innova, because holy cow, there's next to no variety), I'd give this a Meh for entertainment, but leaning towards No.
Check if you're using the mGBA core. Open the game in BizHawk, then go in GBA > Core. If mGBA is checked, then you should report the issue here: https://github.com/mgba-emu/mgba/issues
Edit: oh and by the way, before report the issue, make sure it wasn't already fixed in the latest version of mGBA: https://mgba.io/downloads.html
This is an N64 game he's talking about, not a GBA game...
