...Haven't I made it clear enough?
(for the record, the SHA1 given in the movie is actually the MD5 checksum)
And I just checked with the online MD5 checker you mentioned, and guess what? The hashes still match with yours (from onlinemd5).
So my only guess is that you uploaded the wrong BK2.
So the synchronization is finally over. In fact, we had to TAS the whole game again. We discovered new tactics and improved some battles. As a result, our new TAS is over 14 seconds faster comparing to IGT of our old Gens run.
Though, Bizhawk's Genesis core is more laggy accurate, it's even faster in the real time condition.
Please, replace our current movie with this one: User movie #51156051777459736
It desyncs for me on the very last fight (Sub-Zero gets hit, then misses his freeze attack)...
ROM hash and BizHawk version match.
Just some quick pre-requisites on getting it to sync (specifically the memory card part):
On the memory card manager, open a memory card that doesn't exist yet. This will prompt the following question:
Click "Yes".
Then, immediately after, you'll get asked a second question:
Here, you have to click "No". This will trigger the memory card format in the game when playing back the movie (see the temp encode).
As a side note, the GC system language has to be set to German (obviously) and the DSP audio engine has to be set to LLE recompiler (but using Dolphin's internal DSP ROMs instead of the proprietary DSP ROMs).
EDIT: The MD5 hash of the disc is identical to the one found on Redump.
I'd rather see this improvement done on BizHawk (and its more accurate Genplus-GX core) instead of Gens... Nevermind the fact that Gens is a very inaccurate emulator, and the re-record versions are based on a version that's sixteen years old.
BTW: Yes, you do get desyncs when directly importing a Gens movie to BizHawk. That's to be expected, so you have to re-sync it in BizHawk (preferably using TAStudio, to save you some headache).
For what it's worth, I could get it to sync with the patch mentioned in the annotations. So it's at least theoretically possible to get it to sync in vanilla libTAS.
EDIT: I managed to get it to sync on libTAS 1.3.1 (stable release) by manually pausing at the specific frames (plus one frame) provided in the code!
NOTE: MAKE SURE YOU USE VBA-NEXT WITH THIS MOVIE! mGBA has an unresolved issue emulating this game which will prevent you from advancing past the title screen!
Then why wasn't it reported in the bug tracker? That's literally step one when you encounter such an issue.
I've acquired a New3DS XL with an integrated capture board recently...mainly to record footage of what's possibly my favourite mode in WarioWare Gold:
Link to video
The pacing gets really frantic later on, meaning you have to stay focused at all times in order to not fail at the microgames.
On another note, I've also improved my PB in DuckTales by around one second:
Link to video
On my Windows 10 host, if I disable vsync in-game, TowerFall runs at 2000 FPS on average, but it doesn't actually run any faster. Since the LTM forces it to run at 1000 FPS, it will effectively dump 1000 frames per second to AVI.
Here's a GIF of Twilight Spire II, slowed down to 15 FPS (no way am I embedding that, it's over 10 MB!). As you can see, since libTAS forces it to run at 1000 FPS, it will effectively dump 1000 frames per second to AVI. If you look closely at the timer, you'll notice that every millisecond is present, due to the AVI dump being at 1000 FPS.
Hello and welcome to TASVideos, TommyeAsY.
Just so you know, PAL releases of PS1 games run at ~50 FPS, while NTSC(-U/J) releases of PS1 games run at ~60 FPS.
Are the glitches used in this TAS not present in the American release of the game? If not, then the American release is preferred, due to it running at 60 FPS instead of 50 FPS.
BTW, you mis-interpreted the ROM filename field. You're meant to put the filename of the ROM/ISO you used, not the filename of the BIOS. This has been fixed.
Just as a note: Additional input is required after the credits (to clear some additional text boxes) before "The End" shows up. The other two campaigns (Shovel of Hope and Plague of Shadows) do not have any additional text boxes after the credits, so they're fine.
Technically, this submission breaks the Movie Rules:
No tampering with the files the game is composed of
Some systems, such as DOS, exposes the separate parts of the operating system and/or the game to the user. You are not allowed to manipulate these files except as is normally necessary to play the game, such as "installing" it.
That means no renaming/copying/deleting/replacing/editing files that affect game-play.
We do not allow save-anchored movies
We want a standard starting point for movies (power-on). Saves introduce an infinite amount of possible variation that may cause the game to behave differently compared to starting from power-on. They also can be hacked, allowing nearly transparent cheating.
However, there are certain games with unlockable modes, second quests, or other things of interest that can only be accessed if a save file (or an otherwise "dirty" SRAM) is present. If you really wish to submit a movie made on such a mode, you will need a verification movie made and provided alongside it. Any input file that starts from power-on (for example, a previously submitted movie for that game) and creates the exact circumstances for your submission to sync will generally do.
Note that you don't have to optimize the verification movie: it only serves as a save or SRAM generator that makes it possible to claim the legitimacy of your effort. This submission is a good example.
In any case, ensure a run of your unlocked mode provides meaningful content over a fresh game. For example, if the unlocked mode features all new bosses, but your run triggers the endgame sequence before meeting any of them, and this same glitch exists in a fresh game as well, then there is no benefit to unlocking this mode.
As there's no verification movie present, this sadly puts this submission in a bad state as of now.
I can safely confirm it syncs on my 32-bit Kubuntu VM with the latest Linux kernel (4.15.0-34-generic as of this writing) with the instructions provided in the movie annotations.
Nice, finally the Shovel Knight TASes have been submitted.
Note to other encoders/publishers: I will encode and publish all of them once they get accepted.
Hey. Isn't the "castle" part in the game name supposed to have an uppercase C?
I personally consider that "castle" have to have a lower case 'c' because it's not a proper noun, so no real reason to capitalize it there.
Then by that logic, "Luigi's Mansion" should be "Luigi's mansion" and "Oddworld: Abe's Oddysee" should be "Oddworld: Abe's oddysee", just to name two examples.
Per the Publisher Guidelines:
Capitalize game names according to the rules of English language, even if official game names contradict them, unless the way they are named traditionally is against the rules.
And here's what Wikipedia has to say:
English usage is not consistent, but generally prepositions and articles are not capitalized: "the Forest of Dean", "Gone with the Wind", "University of Southampton". With some publications "The" forms part of the title: "reading The Times". For a more detailed explanation see Capitalization § Titles.
In conclusion: The game title should be written as "Smurf: Rescue in Gargamel's Castle".
I apologize if using the different FreeDOS and BIOS images made/make things difficult.
It's fine (at least from my perspective). I found the BIOS image in the source for the latest stable Bochs release (2.6.9). As for the modified FreeDOS image, I believe it's legal to post it, since the only thing that changed from the stock FreeDOS image is autoexec.bat, with everything else intact (and FreeDOS itself is available for free).
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).
The only thing I can think of is that my FreeDOS is a slightly modified version of the one with the JPC source. I edited the autoexec.bat to automatically load the mouse into linear mode instead of accelerated (this makes TASing mouse based games much easier). I then extracted the resulting drive to a new image.
I see....but that's now moot, since you have an updated movie file that syncs on the stock FreeDOS image. I also noticed you used the BIOS from the latest stable Bochs release (2.6.9 as of this writing) instead of the one included with JPC-RR.
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.
(for the record, the SHA1 given in the movie is actually the MD5 checksum)
And I just checked with the online MD5 checker you mentioned, and guess what? The hashes still match with yours (from onlinemd5).
So my only guess is that you uploaded the wrong BK2.
Click "Yes".
Then, immediately after, you'll get asked a second question:
Here, you have to click "No". This will trigger the memory card format in the game when playing back the movie (see the temp encode).
As a side note, the GC system language has to be set to German (obviously) and the DSP audio engine has to be set to LLE recompiler (but using Dolphin's internal DSP ROMs instead of the proprietary DSP ROMs).
EDIT: The MD5 hash of the disc is identical to the one found on Redump.
