TASVideos

Tool-assisted game movies
When human skills are just not enough

Submission #7214: CasualPokePlayer's SGB Gamera: Daikaijuu Kuuchuu Kessen in 19:29.9

Console: Super Game Boy
Game name: Gamera: Daikaijuu Kuuchuu Kessen
Game version: JPN
ROM filename: Gamera - Daikaijuu Kuuchuu Kessen (Japan) (SGB Enhanced).gb
Branch:
Emulator: BizHawk 2.6.3 dev
Movie length: 19:29.9
FrameCount: 69901
Re-record count: 6423
Author's real name: Wesley B.
Author's nickname: CasualPokePlayer
Submitter: CasualPokePlayer
Submitted at: 2021-09-13 05:13:39
Text last edited at: 2021-09-13 19:49:39
Text last edited by: Samsara
Download: Download (8974 bytes)
Status: decision: delayed
Submission instructions
Discuss this submission (also rating / voting)
List all submissions by this submitter
List pages on this site that refer to this submission
View submission text history
Back to the submission list
Author's comments and explanations:

(Link to video)

Game objectives

  • Emulator used: BizHawk 2.6.3 dev
  • Breaks da rulez!
  • Testing da rulez!

Comments

Gamera is basically some Godzilla clone in Japan that became its own thing around there. This game is "based" on the movie of the same name, although the game's plot doesn't resemblance the movie's at all.

Now to get the elephant out of the room, why did I use SGB mode, and on Gambatte? This was mainly for testing SGB stability on Gambatte (which is now stable). And as for Gambatte, I have been adding support for SGB mode for use in BizHawk, featuring nearly everything an HLE SGB core can offer, including sound support.

To be clear, this is an HLE core, just like VBA and SameBoy. Every SGB thing is done with "hacks" so to say, mimicking the packet/VRAM transfers and such using native C++ code instead of "proper" emulated SNES code (which would be LLE). This ends up being interesting for acceptability. VBA's SGB mode was banned weirdly. The reason on the movie rules says it is banned due to "poor sound emulation," being the lack of SNES sound. However, some staff members say a slightly different story, saying it is banned due to not emulating the full SGB (ie, because it was HLE and not LLE), with one oddly citing the lack of SNES sound as such.

To respond to the last point, you do not have to emulate the entire SNES to get SNES audio. The SNES's APU has to be emulated (which blargg's snes_spc can easily provide), with sound transfers from VRAM to SPC RAM simply being able to be memcpy'd over, and sound commands just writing to SPC I/O using native C++ code instead of emulated SNES code.

Also, these being said to be "hacks" and thus unacceptable is also slightly weird. We accept HLE stuff for other systems, e.g. N64/GC/Wii/etc. If HLE stuff there is acceptable there, why not here? SGB HLE still mimics what the SNES does with the packet transfers and such. It's not actually too unlike the HLE approached done on the systems I mentioned.

Of course, SGB HLE can't do everything. SNES code can be uploaded and executed on the SGB, which is impossible to emulate without a full SNES (i.e. LLE). However, this is effectively restricted to a single commerical game (Space Invaders), some glitch playaround like Pokemon Plays Twitch, or some homebrew game. Effectively very little is actually lost going HLE, especially if sound support is put in.

This game in particular actually does end up being fairly interesting from an emulation perspective and is a factor in why it was choosen. Simply be, multiplayer. To preface this, multiplayer is handled by the ICD2 chip rather than the BIOS, so HLE is on equal grounds here with LLE. This game will constantly poll player one and player two. It does it in a fairly nonstandard way, which breaks on nearly every SGB implementation, including BSNESv115 (old BSNES doesn't break, although the game is poorly emulated in the sound department regardless, so using it was undesirable). I ended up writing testroms to research how this worked, which led to the discovery that original SGB multiplayer tests were misinterpreted due to a behavior written in the Pan Docs by an unknown source, which was wrong. More details can be read here: https://github.com/bsnes-emu/bsnes/issues/220

My personal preference in this debacle is for only LLE SGB emulators to be accepted anyways, as I see SGB HLE for casual players rather than ones aiming for accuracy. However, I'm not at liberty to decide this debacle, so I will leave it to this submission which I totally can resync to normal GB emulation anyways since RNG doesn't advance during SGB lag lol

Stage by stage comments

There are five opponents in the game, with 2 rounds needing to be won. Every fight here has the same strategy essentially. Charge, claw, charge, jet strike, throw. This ends the fight in 5 turns.

Charging is good to use due to it having a short animation, and doubling the damage of the next move. Note that getting hit by the opponent during the charge does not cancel the charge, although it does cancel the "fully charged" animation.

While the claw attack is slower than the throw attack, it ends up good to use due to it having the side effect of backing up Gamera. This allows for the jet strike attack to be used.

The jet strike is a powerful move, letting Gamera end the fight in 5 turns. It also has the ability to knock down the opponent, rendering them immobile for a turn.

The throw is the fastest move in the game, and is enough to land the final hit for the KO. An exception is at the final round of the last fight, which I use the most interesting attack out of my selection, since input ended right when the attack was inputted.

It should be noted RNG is easy to manipulate, since pressing B at any point seems to change RNG.

This TAS might be improvable with better luck manipulation or a better fight strategy, but I couldn't find anything better here.


Samsara: Setting to Delayed pending an official BizHawk 2.6.3 release.

Similar submissions (by title and categories where applicable):