Serena's SGB Ultraman Ball

Ultraman Ball is a platform game featuring the ability to morph into a ball form, which bounces and is in general much harder to control. I was unaware of this game's existence before seeing it at the recent GDQ event, and thought it looked short and simple enough to TAS as a small project before moving on to another large one.

This movie beats the previous submission by TaoTao by a significant margin, although I am unsure on an exact frame count as their submission appears to use a non-standard method of timing. From looking at the provided youtube encode, their time from power on to final input appears to be around 6:18, rather than the listed 6:04.45. This places my movie roughly 9 seconds ahead.

Aside from general movement improvements, I also discovered two new glitches used in this run: the ladder clip and wall jump. There were also places in the previous submission where movement that should be optimal ended up being significantly slower due to lag.

The game startup sequence in their submission is noticeably faster, but I believe this is due to an emulation inaccuracy in VBA. I was unable to replicate it when using BizHawk.

Horizontal speed values:

Due to the much higher speed of the ball form, this run uses it almost exclusively. The two exceptions where the ultraman form is faster are when accelerating up to 16 units/frame, and when jumping off of a ladder/vine, which sets the player's speed to 48 units for a single frame.

Switching into ball form cancels all acceleration for that frame, as well as setting the Y velocity to 0. This can be abused to move horizontally while losing minimal height by repeatedly switching form, however this is of limited use due to it reducing the player's speed to the slower 16 units/frame of the ultraman form. If moving downward, the higher speed can be maintained by switching away from and back to the ball on two consecutive gameplay frames. This can be accomplished either by pausing and unpausing the game, or by timing the form switch inputs around a lag frame. Pausing the game loses 2 frames, but is often worth it to keep higher speed.

As an additional note, the acceleration cancelling effect happens regardless of if switching form is actually possible. This can be abused when near a ceiling in order to either rise up to it faster, or fall away from it slower.

When colliding with a breakable block in ball form, the player is normally forced to bounce away from it. If moving upward, this can be prevented by switching away from ball form on the same frame the block is broken. This maintains a speed of 16 units/frame, but in most situations ultraman will collide with another block before it is possible to switch back, immediately losing this speed. As in the levitation trick above, lag frames or pausing may be abused to switch back to ball form faster in order to keep high speed past the breakable block.

When jumping off of a ladder/vine towards a wall, ultraman is normally placed into a wall sliding state. If both a directional input and the jump button are pressed, he will instead be placed inside of the wall. From here, it is impossible to continue moving horizontally through the wall, but switching to ball form and jumping will quickly zip the player to the top of the wall. This has an odd side effect of offsetting the visual tile data slightly, allowing it to be read from unrelated memory. If repeated enough times, the screen can be completely filled with nonsense data. Since this is visual only, I was unable to find a use for it, but this is likely still worth looking into.

Example of the visual glitch:

Without a ladder, moving towards a wall will still clip ultraman slightly into it before immediately pushing him away. Switching to ball form on the frame this clip happens and immediately jumping allows a jump to be performed before the player is pushed out of the wall. This additionally bumps the player up to the next tile vertically, allowing extremely fast movement up walls if this glitch is chained in quick succession. On walls to the right of the player, this can be done simply by alternating B and A, but on left walls it is necessary to move slightly away from the wall and back towards it to clip again.

Memory addresses:

ROM SHA-1: 3CDFCFB1A88D0CBFEB1C7B12751409FAF69BBA02

CasualPokePlayer: Replaced movie file with one with the correct cycle count

ThunderAxe31: Claiming for judging.

ThunderAxe31: All right, putting aside all emulation differences, this movie only brings improvements. As such, accepting as an improvement over the published movie.

Additional note for the publisher: I've made sure that the CycleCount value in the Header.txt is correct, however I'm not sure if the site is parsing it correctly, or if the System Framerate setting is correct in the Catalogging Information for this submission. We know for sure that this submission uses SGB2, because Gambatte doesn't emulate SGB1. The difference is that SGB1 is known for running GB/C games faster than intended, leading to incorrectly shorter timings, while SGB2 instead runs at the intended GB/C speed, thanks to improved hardware. However, according to CasualPokePlayer, the output video framerate in practicality is the same as the SNES, with frames skipped/duped internally to maintain the SNES framerate. So, to make it short, I can't tell for sure if the currently displayed timing is correct, or if the current framerate in Catalog is correct for encoding. Please refer to CasualPokePlayer and feos if you also have any doubt.

fsvgm777: Processing.