Jail Break is an arcade game produced and released by Konami in 1986. The game's story is loosely based on the 1981 film Escape from New York, wherein Manhattan has become an island prison from which the hero must rescue the President of the United States, who is being held hostage. In Jail Break, the game's hero, Aki, must fight through 5 stages to rescue the warden of a prison following a mass escape. The settings for the various stages are all real locations in and around Manhattan, and the game follows a logical geographic progression. Even the game's original title, マンハッタン24分署: N.Y.151・西・第100ストリート (Manhattan 24 Bunsho: N.Y. 151 Nishi Dai 100 Sutorīto) refers, with curious specificity, to the New York City Police Department 24th Precinct, down to the address at 151 West 100th Street! Of technical interest, Jail Break was built on modified Green Beret (Rush'n Attack) hardware. Certain sound effects may be familiar to those who played contemporary Konami arcade games--even the NES games of the era used this shared sample library. The game also features digitized speech, using the same hardware as previous games such as Track & Field.

Game Objectives

  • Emulator used: MAME-RR v0.139 v0.1-beta
  • Aims for fastest game completion
  • Aims for maximum score without sacrificing Frames
  • Uses maximum difficulty settings
  • Abuses programming errors
  • Uses U+D/L+R
  • Entertains without sacrificing Frames
  • Teleports Behind You

DIP Switch Settings

  • Lives set to 1
  • Coin A set to Free Play
  • Bonus Life set to 40K 80K+
  • Difficulty set to Very Difficult

"Thank me very much."

Tricks and Glitches

The Bum's Rush:
Ordinarily, Aki travels at a rate of 1 pixel per Frame. Using this technique, Aki can travel at a rate 37 times greater: 111 pixels per each 3 Frames, or 37 pixels per Frame. Hold Down, Right, and Left on the joystick simultaneously to cause Aki to rush forward. The Bum's Rush prevents enemies from spawning. It also causes Aki's Y location to fluctuate and causes his sprite to appear glitched. Holding Up, Down, and Right or Up, Down, and Left on the joystick simultaneously produces mostly the same effect, but reduces Aki's speed somewhat to 64 pixels per each 2 Frames, or 32 pixels per Frame. This is useful in a situation where using either technique as the last movement increment will reach the destination, because the "slower" technique requires only 2 Frames of travel as opposed to 3 Frames of travel with the "faster" technique. As a point of reference, even if Aki could advance to the end of the Stage without interruption at his normal rate (which he can not), it would require 12,820 additional Frames...more than 2 times as long as the entire TAS.
Teleport:
While screen scrolling is unlocked, pressing Down, Right, and Left on the joystick simultaneously causes the screen to scroll rapidly. However, when the end of a Stage is reached and screen scrolling is locked, using this same input allows Aki to instantaneously move to an arbitrary location on the screen, including a location which is beyond the screen boundary. There are various locations to which Aki may teleport. Pressing Up, Down, and Right or Up, Down, and Left on the joystick simultaneously produces a similar effect, but allows fewer destination possibilities. Holding Teleport input allows Aki to change his location every Frame that the input is held.
Carry On:
Pressing Down, Right, and Left on the joystick simultaneously while any of the first 2 character memory blocks are occupied causes any of the characters occupying those memory blocks to be "carried" with Aki to his destination, where they are then juxtaposed near him. This technique applies to Citizens as well as Prisoners. This is useful for forcing Housewife to despawn early on Stage 2 through Stage 4.
Prevent Enemy Spawn:
If all 7 character memory blocks are occupied when an enemy is scheduled to spawn, the enemy will fail to spawn. In such a case, the game considers the enemy to have spawned and been destroyed. Destroying the final "scheduled" enemy of a Stage on the earliest possible Frame requires 30 Frames for the enemy to despawn after being destroyed. As such, it is faster to allow the 7 "occupying" enemies to remain destroyed but not yet despawned just long enough to prevent the final scheduled enemy from spawning. This is useful on Stage 1, where the last character scheduled to spawn is a Machinegan.
Angle On Demand:
Normally, when Aki changes angle he is facing by less than 90° and then fires a Weapon, the projectile will be fired at an intermediate angle between the original facing angle and the current facing angle. This effect persists for 8 Frames, after which a fired projectile's angle will match the current facing angle. This game mechanic allows firing at 16 possible angles with an 8-direction joystick. This 8-Frame delay can be prevented by simply changing the angle that Aki is facing by 90° or more before then turning to face the desired angle and firing. This technique allows for more precise firing in a shorter amount of time.
Kill The Warden:
Normally, if Aki hits the Warden with a projectile, the dynamite strapped to his chair is detonated, the message "MISS SHOT !!" is displayed, and the game is over, regardless of how many lives remain. However, the detonator has a delay, the Warden can be destroyed, and if Aki can destroy the Warden before the detonator delay expires, the explosion is prevented, and there is no penalty!

Comments

The hero's name is Aki.
When an enemy is hit, Aki becomes impervious to collision damage from enemies. This status persists until the enemy despawns. Note that Aki can still be hit by a projectile during this status.
A weapon can be fired at any of 15 different angles for pinpoint accuracy. To fire at a secondary-intermediate angle, first press the joystick in one of the 2 directions nearest to the desired angle for 1 Frame, and then press the joystick in the other nearest direction for 1 Frame. For the next 8 Frames, the Weapon will fire at the desired secondary-intermediate angle. For example, to fire at a 23° angle, press Right on the joystick for 1 Frame, press Up and Right on the joystick for 1 Frame, and then press the Shoot button. It does not matter in which order the directions are pressed on the joystick. Strangely, it is not possible to fire at a 202° angle, though it is possible to fire at all other secondary-intermediate angles.
Frighteningly, enemies are capable of chasing Aki even out of bounds. Furthermore, enemies can fire from anywhere out of bounds, unlike Aki.
After an enemy has been hit, it requires 30 Frames to despawn.
A maximum of 7 enemies are allowed to simultaneously occupy the screen.
Input can only be entered for 1 Frame per each 2 Frames.
Using Bum's Rush while there is an object on the screen causes the game to generate Lag Frames.
The playfield extends horizontally from X 32 to X 208. Horizontal center is X 120. Note that until the end of a Stage is reached, Aki can not move beyond X 128, as this is the point at which the screen begins to scroll.
The playfield extends vertically from Y 89 to Y 208. Vertical center is Y 148. Using Teleport can allow Aki to move beyond these limitations. If Aki walks up beyond Y 89 (where the background meets the playfield), he will not be able to walk back down to the playfield using normal input. However, he can return to the playfield by continuing to walk up beyond Y 0, which causes him to wraparound to the bottom of the screen, where he is then ejected back up to Y 208 within the playfield. Of course, using Teleport again can also allow Aki to escape from the background as desired.
The end of a Stage is at Screen X High 10 Screen X Lower 73.
Normal screen scroll speed is 1 pixel per Frame.
The Hand Pistol can be fired before the Stage begins, but the muzzle flash will not appear until joystick input is unlocked.
When Free Play is enabled, pressing the Start button for 1 Frame during the gameplay segment of demonstration mode will cause the game to crash.
If an enemy is hit while he is in attack posture, his attack will be allowed to complete before he is destroyed.
Coin must be held for a minimum of 2 Frames, though these 2 Frames do not necessarily need to be sequential.
If Aki is killed after the last enemy has been destroyed, the transition to the next Stage begins, and the Player does not lose a Life. The transition audio clip "Thank you. You've saved me." fails to play.
At the end of a Stage, when the last enemy despawns, the transition to the next Stage begins, regardless of whether the enemy was destroyed or simply walked off of the screen.
At the end of a Stage, after sufficient time has elapsed, the transition to the next Stage begins, regardless of whether any enemies remain.
If there are too many objects simultaneously occupying the screen, the game will generate Lag Frames to compensate.
Rescuing a Citizen requires 30 Frames.
A Citizen can not be harmed by a Prisoner.
Holding Right and Left on the joystick simultaneously causes Aki to run to the left while facing to the right.

The Weapons

All weapons combined are allowed a maximum of 7 projectiles to simultaneously occupy the screen (e.g. 4 of Hand Pistol, 1 of Bazooka, and 2 of Tear Gas).
Hand Pistol does 1 Hit Point of damage. Hand Pistol allows a maximum of 7 projectiles to simultaneously occupy the screen. A Hand Pistol projectile moves faster than the other Weapon types. Aki must be at Y 68 or lower on the screen in order for a Hand Pistol projectile to avoid being destroyed by the background. At Y 68, Hand Pistol must be fired directly down. Starting at Y 70, Hand Pistol may be fired downward at a 45° angle. At Y 71 and lower, Hand Pistol may be fired at any angle. Aki must be at Y 13 or higher on the screen in order for a Hand Pistol projectile to wraparound to the bottom of the screen. Aki must be at Y 8 or higher on the screen in order for a Hand Pistol projectile fired at any angle to wraparound to the bottom of the screen.
Bazooka does 1 Hit Point of damage per each Frame that it is in contact with a target. Bazooka allows a maximum of 1 projectile to occupy the screen. If there are 3 Tear Gas projectiles on the screen, Bazooka can not be fired. A Bazooka projectile moves slower than a Hand Pistol projectile, but faster than a Tear Gas projectile. Aki must be at Y 69 or lower on the screen in order for a Bazooka projectile to avoid being destroyed by the background. At Y 69, Bazooka must be fired directly down. Starting at Y 70, Bazooka may be fired downward at a 45° angle. At Y 71 and lower, Bazooka may be fired at any angle. Aki must be at Y 12 or higher on the screen in order for a Bazooka projectile to wraparound to the bottom of the screen. Aki must be at Y 10 or higher on the screen in order for a Bazooka projectile fired at any angle to wraparound to the bottom of the screen. A Bazooka projectile will penetrate any Enemy or Citizen. Any.
Tear Gas does 1 Hit Point of damage per each Frame that it is in contact with a target. Tear Gas allows a maximum of 3 projectiles to simultaneously occupy the screen. If there is a Bazooka projectile on the screen, only 2 Tear Gas projectiles can be fired. A Tear Gas projectile moves slower than the other Weapon types. Aki must be at Y 40 or lower on the screen in order for a Tear Gas projectile to avoid being destroyed by the background. At Y 40, Tear Gas must be fired directly down. Starting at Y 44, Tear Gas may be fired downward at a 45° angle. At Y 45 and lower, Tear Gas may be fired at any angle. Aki must be at Y 12 or higher on the screen in order for a Tear Gas projectile to wraparound to the bottom of the screen. Aki must be at Y 6 or higher on the screen in order for a Tear Gas projectile fired at any angle to wraparound to the bottom of the screen. A Tear Gas projectile has homing capability against an enemy in a window. When a Tear Gas projectile collides with an obstacle, enemy, or Citizen, it explodes. The explosion from Tear Gas remains damaging for 16 Frames until it has despawned. If an additional target collides with a Tear Gas explosion before the explosion's timer has expired, the explosion's timer is reset to 16. If a target remains in contact with a Tear Gas explosion, the explosion's timer remains at 16 until the target is destroyed. It is the ultimate power in the universe.

The Enemies

Cats is worth 200 points. Cats is unarmed.
Molotov Cocktail is worth 200 points. The explosion from Molotov Cocktail remains damaging until it has despawned. The Molotov Cocktail itself can not hit Aki. Molotov Cocktail enters attack posture 32 Frames after spawning. Attack posture requires 16 Frames. Molotov Cocktail enters attack posture 32 Frames after attack posture ends. If there are no mitigating factors, Molotov Cocktail enters attack posture every 54 Frames until he is either destroyed or despawned. Note that if there are (or are scheduled to be) 8 enemy projectiles on the screen, Molotov Cocktail will not attack as scheduled. He may attack after a delay of 2-4 Frames, or he may not attack again at all until one of the enemy projectiles on the screen has despawned. If it is the latter, Molotov Cocktail will enter attack posture 18 Frames after one of the enemy projectiles on the screen has despawned.
Machinegan [sic] is worth 200 points. Machinegan enters attack posture 32 Frames after spawning. Attack posture requires 22 Frames. Machinegan enters attack posture 32 Frames after attack posture ends. If there are no mitigating factors, Machinegan enters attack posture every 54 Frames until he is either destroyed or despawned. Note that if there are (or are scheduled to be) 8 enemy projectiles on the screen, Machinegan will not fire as scheduled. He may fire after a delay of 2-4 Frames, or he may not fire again at all until one of the enemy projectiles on the screen has despawned. If it is the latter, Machinegan will enter attack posture 18 Frames after one of the enemy projectiles on the screen has despawned.
Trash Truck is worth 400 points. Trash Truck can only be destroyed with Bazooka.

The Score

Drum is worth 100 points. Drum can only be destroyed with Bazooka.
Citizen is worth 500 points.
Housewife is worth 1,000 points.
Child is worth 2,000 points.
Batman is worth 5,000 points.
Topless Woman is worth 5,000 points.

Stage By Stage Comments

Stage 1: Upper West Side

Unlike the other Stages, the game's voice-over does not announce the name of Stage 1. However, assuming a point of origin at West 100th Street, it seems reasonable that the setting for Stage 1 is the Upper West Side.
Using Bum's Rush prevents 5 Machinegan from spawning at the end of the Stage.
Hold Down, Right, and Left on the joystick for 80 Frames from Frame 840 to Frame 920 to reach Screen X High 10 Screen X Low 9.
Press Up, Down, and Right or Up, Down, and Left on the joystick on Frame 920 to reach Screen X High 10 Screen X Low 73 on Frame 922. This saves 1 Frame compared to pressing Down, Right, and Left on Frame 920.
Enemy 14 is scheduled to spawn on Frame 1578.
Machinegan 7-13 are allowed to remain just long enough to prevent Machinegan 14 from spawning. This allows the final enemy to be destroyed on an earlier Frame. This saves 20 Frames compared to allowing Machinegan 14 to spawn and then destroying him on the earliest possible Frame.
Aki is killed during the battle, but his sense of civic duty will not let him rest. Onward!

Stage 2: Battery Park

Using Bum's Rush prevents 5 Machinegan from spawning at the end of the Stage.
Machinegan, Molotov Cocktail, and Housewife spawn at the end of the Stage.
Rescuing Housewife gains Bazooka.
The final character to spawn on this Stage is Housewife. Because Housewife travels vertically, she can be carried to a vertical screen boundary and forced to quickly despawn. The ideal location to which to Carry Housewife is between Y 15 and Y 29. Prior to the final Teleport Aki's location is adjusted such that 1 Frame of Carrying Housewife will cause her to instantaneously despawn. This saves 30 Frames compared to shooting Housewife (thank God), and saves 118 Frames compared to rescuing her.
Stage 3 and Stage 4 progress in the same manner as Stage 2.

Stage 3: The Navy Yard

Presumably, this Stage refers to the Brooklyn Navy Yard.
Rescuing Housewife gains Tear Gas.

Stage 4: Manhattan Bridge

Aki becomes as a dervish as enemies are cut down all around him.

Stage 5: Manhattan Prison

This Stage is announced simply as "Manhattan Prison". Considering the proximity to Manhattan Bridge, and its high-profile nature, this can be inferred to mean the Metropolitan Correctional Center.
Aki scores a sixfer with the Bazooka.
Rather than preventing the final enemy from spawning, he is allowed to spawn as scheduled. This allows Aki time to move to and attack this enemy from long range. This in turn allows Aki time to move to and attack the final enemies from maximum range. Thus, input is ended on the earliest possible Frame.
Normally, if Aki hits the Warden with a projectile, the dynamite strapped to his chair is detonated, the message "MISS SHOT !!" is displayed, and the game is over, regardless of how many lives remain. However, the detonator has a delay, the Warden can be destroyed, and if Aki can destroy the Warden before the detonator delay expires, the explosion is prevented, and there is no penalty! When the Warden is hit for the 1st time, the bomb is armed, and the delay timer begins to increment at a rate of 1 per Frame. Additionally, Aki becomes invincible. When the Warden is hit again, his damage counter is incremented. Each hit increments this damage counter by 1, to a maximum of 30. When the Warden's damage counter is at 30, the next hit will disarm the bomb and destroy the Warden. It is difficult to tell whether this game mechanic is a glitch or an Easter egg. Considering Konami's penchant for such things (even within this game), as well as the relative ease of exploiting it, it is plausible that it could be the latter. The Warden is worth 200 points per hit, to a maximum of 6,400 points. More than any bonus in the game!
The final shot is fired from maximum effective range at a 45° angle. The combination of the slowest-moving projectile with indefinite damage duration makes Tear Gas a godsend for ending a TAS of this game.
Simultaneous with firing the final shot, Aki also Teleports back within the screen boundary. Otherwise, when the cutscene begins, Aki would run down into the screen boundary continuously, and thus never be able to complete the transition to the ending.

feos: Okay, okay, FINE! Judging.
feos: This run is incredible. I don't remember ever seeing opposite directions cause so much damage to the game. And with everything broken apart, it remains highly entertaining as well!
The legitimacy questions were thoroughly discussed in the thread, the bottom line is that even on arcades opposite directions are possible if you send input data directly to the ports, just like TASBot sends those to home consoles. On the other hand, opposite analog directions are completely impossible by nature, even though this game doesn't have that. So we're not breaking any rules here, just acting consistent with the all-time site stance.
One more note, this run didn't use my modified input system, it used what was already available in mame 0.139. The latter just wasn't very consistent with what opposing directions it allowed. Anyway, later on mame switched to allowing all directions through an option.
Accepting to Moons.


TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15580
Location: 127.0.0.1
This topic is for the purpose of discussing #5728: £e_Nécroyeur's Arcade Jail Break in 01:36.62
Joined: 5/12/2009
Posts: 748
Location: Brazil
I'm always amazed by how much £e Nécroyeur can push these arcade games and how much stuff he can find and detail in submission text. Congrats on the great work! Yes vote! I'm going to watch that Final Fight run again now. Edit: It would be cool to see other Arcade beat'em ups runs from you, like Cadillacs and Dinosaurs (with the heavy damage rick), Captain Commando, Alien Vs Predator, Punisher... etc...
Spikestuff
They/Them
Editor, Publisher, Expert player (2642)
Joined: 10/12/2011
Posts: 6438
Location: The land down under.
Pressing Down, Right, and Left on the joystick simultaneously
So what you're saying is something completely impossible on an Arcade Machine was used and abused. Now for console games L+R/U+D is possible, insane and not recommended, for Arcade with a stick the max you can do is any diagonal movement. This leaves salt in my mouth for this TAS knowing that the primary movement is something that's not even possible.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. Something better for yourself and also others.
mklip2001
He/Him
Editor
Joined: 6/23/2009
Posts: 2227
Location: Georgia, USA
I'm willing to accept the use of non-directional inputs. Besides, it's the only way we get this incredibly hilarious short run. The stage endings of "Hello! Is Anyone There?" sounds like the enemies are asking the hero where the heck he teleported. I'm voting Yes, though I think I would also be interested in seeing a run of this game without the Bum Rush glitch. I know it would be a lot longer, but it seems like the game has enough difficulty to keep it interesting.
Used to be a frequent submissions commenter. My new computer has had some issues running emulators, so I've been here more sporadically. Still haven't gotten around to actually TASing yet... I was going to improve Kid Dracula for GB. It seems I was beaten to it, though, with a recent awesome run by Hetfield90 and StarvinStruthers. (http://tasvideos.org/2928M.html.) Thanks to goofydylan8 for running Gargoyle's Quest 2 because I mentioned the game! (http://tasvideos.org/2001M.html) Thanks to feos and MESHUGGAH for taking up runs of Duck Tales 2 because of my old signature! Thanks also to Samsara for finishing a Treasure Master run. From the submission comments:
Shoutouts and thanks to mklip2001 for arguably being the nicest and most supportive person on the forums.
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
Spikestuff wrote:
Pressing Down, Right, and Left on the joystick simultaneously
So what you're saying is something completely impossible on an Arcade Machine was used and abused. Now for console games L+R/U+D is possible, insane and not recommended, for Arcade with a stick the max you can do is any diagonal movement. This leaves salt in my mouth for this TAS knowing that the primary movement is something that's not even possible.
It's physically impossible if you're standing before an unmodified cabinet. But it's digitally possible to send those inputs, and it's possible for the game to process them. We're not TASing physical cabinets, we're TASing digital entities, spherical cows in a vacuum: games in abstraction. For consoles like SNES, we're accepting L+R not because it's physically possible, but because it's only physically impossible on an official controller that you don't try to overpower. Same with non-existent buttons: the data can be sent (for instance, with a SNES mouse) and processed, therefore it's digitally legit.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
fsvgm777
She/Her
Senior Publisher, Player (226)
Joined: 5/28/2009
Posts: 1213
Location: Luxembourg
feos wrote:
It's physically impossible if you're standing before an unmodified cabinet. But it's digitally possible to send those inputs, and it's possible for the game to process them.
You're missing the point. This is an unmodified arcade cabinet of the game (ignore the condition). On a SNES controller, it is possible with a ton of twiddling to actually input L+R/U+D. On an arcade cabinet, with a joystick, as Spikestuff pointed out, it's literally impossible unless you want to completely break the joystick (and the cabinet) apart. Similarly, you can't input L+R/U+D on an N64 joystick or basically any joystick. £e Nécroyeur, it would be really nice of you to actually respond to criticism instead of flatly ignoring it, just like you did with your Track & Field submission.
Steam Community page - Bluesky profile Oh, I'm just a concerned observer.
Player (80)
Joined: 8/5/2007
Posts: 865
fsvgm777 wrote:
feos wrote:
It's physically impossible if you're standing before an unmodified cabinet. But it's digitally possible to send those inputs, and it's possible for the game to process them.
You're missing the point. This is an unmodified arcade cabinet of the game (ignore the condition). On a SNES controller, it is possible with a ton of twiddling to actually input L+R/U+D. On an arcade cabinet, with a joystick, as Spikestuff pointed out, it's literally impossible unless you want to completely break the joystick (and the cabinet) apart. Similarly, you can't input L+R/U+D on an N64 joystick or basically any joystick. £e Nécroyeur, it would be really nice of you to actually respond to criticism instead of flatly ignoring it, just like you did with your Track & Field submission.
I wouldn't be so quick to accuse feos of missing the point. You both make valid points. The game's coding is perfectly willing and ready to accept an input that includes both left and right or up and down. That's feos's point. Your point is that it's physically impossible to do so with actual hardware. (Well, maybe you could waggle the joystick back and forth quickly enough that it interprets it as left+right, but I'll take a "I'll believe it when I see it" standpoint.) So the question really comes down to whether we see the physical hardware as an integral component of the game-playing process. If it is, then left+right can't be allowed. If it isn't, then all we care about is the digital input sent to the game. To muddy the waters further, I'll mention that on a home console, we can perhaps purchase controllers that allow us to perform inputs that are effectively impossible on stock controllers. With an arcade game, such as this one, the controller is presumably fixed by the manufacturer. I'm not sure if that is an argument for or against allowing left+right. Incidentally, I take the left+right question to not apply to the N64. The controller's output should be something like an x-y coordinate pair based on the state of the joystick. Any N64 game should be completely unable to meaningfully interpret a left+right input, even if it were physically possible. Someone with a bit more knowledge of N64 hardware will need to back me up on this. Edit: By the way, I'm personally indifferent as to what the fate of this run is, but as a general rule, I fall back on entertainment value, since TASes are a form of entertainment at their core. Glancing at the submission text, I notice that allowing impossible joystick inputs opens up multiple interesting tricks, which may significantly increase the entertainment value of the run. I suggest that £e Nécroyeur or someone else could produce a quick run that attempts to show what a run that doesn't use left+right might look like.
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
fsvgm777 wrote:
feos wrote:
It's physically impossible if you're standing before an unmodified cabinet. But it's digitally possible to send those inputs, and it's possible for the game to process them.
You're missing the point. This is an unmodified arcade cabinet of the game (ignore the condition). On a SNES controller, it is possible with a ton of twiddling to actually input L+R/U+D. On an arcade cabinet, with a joystick, as Spikestuff pointed out, it's literally impossible unless you want to completely break the joystick (and the cabinet) apart. Similarly, you can't input L+R/U+D on an N64 joystick or basically any joystick.
I'm not missing it at all, read my post carefully. And then, this thread: Thread #14051: Debate: allowed or not?. And starting from this post: Post #345991.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Editor, Reviewer, Skilled player (1358)
Joined: 9/12/2016
Posts: 1646
Location: Italy
I wonder, would be *theorically* possible to do L+R on a cabinet if you move the joystick toward the L and then the R during the same input poll, assuming a superhuman moving faster than the electric signals inside the hardware?
my personal page - my YouTube channel - my GitHub - my Discord: thunderaxe31 <Masterjun> if you look at the "NES" in a weird angle, it actually clearly says "GBA"
Spikestuff
They/Them
Editor, Publisher, Expert player (2642)
Joined: 10/12/2011
Posts: 6438
Location: The land down under.
feos wrote:
I'm not missing it at all, read my post carefully.
No you're missing the point completely feos, we're stating that you shouldn't physically modify an arcade machine to get what you want out of it. This falsifies the cabinet itself as something that's completely impossible is being done. SNES/NES/PS1/N64 (dpad) etc. all have a free pass for a simple reason. They're not analog controls, this is a stick, represented by an analog movement. The system is being modified in a way where it's literally abusing everything that's not meant to be physically possible. On directional input, it is possible to do U/D and L/R input, there shouldn't be a debate for that, but for something analog there is no bloody way doing that without ripping out the machine and getting into the inside, which is what this TAS is doing.
feos wrote:
And then, this thread: Thread #14051: Debate: allowed or not?.
There's a difference between analog input and directional input. Don't bring up threads that hold literally next to no weight to arcade machines where the main movement is analog, and it's being broken apart. This is a whole different can of worms that you're insisting belongs in the same field when it doesn't. Also I'd rather have the author who actively avoids controversy behind his TASes respond to this rather than someone who is on the outside trying to make it up and save it. Talking about can of worms.
feos wrote:
And starting from this post: Post #345991.
Entirely different again.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. Something better for yourself and also others.
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
Bobo the King wrote:
Well, maybe you could waggle the joystick back and forth quickly enough that it interprets it as left+right, but I'll take a "I'll believe it when I see it" standpoint.
That's not how it works: Post #346153. Overall, the ruling to allow anything that's digitally possible has been there forever. SNES does not have the buttons for the last 4 bits used in SMB ACE. But we allow it, because it just requires a different controller, and you'll be able to send all the bits you wish, all the bits the game can process. Moreover, look at the TASbot. It does press LR, even all directions at once. The game reacts to that the way it does in an emulator. The key is, we plug directly to the controller port, ignoring the controller limitations completely. If arcade cabinets allowed changing the controller, we'd use that. But guess what? Arcade games are just electronic circuits, you plug to their ports and voila, you send any data you want.
Spikestuff wrote:
They're not analog controls, this is a stick, represented by an analog movement. The system is being modified in a way where it's literally abusing everything that's not meant to be physically possible. On directional input, it is possible to do U/D and L/R input, there shouldn't be a debate for that, but for something analog there is no bloody way doing that without ripping out the machine and getting into the inside, which is what this TAS is doing.
feos wrote:
And then, this thread: Thread #14051: Debate: allowed or not?.
There's a difference between analog input and directional input.
Can I read a proof that this particular arcade machine uses analog processing internally for this stick?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Editor, Reviewer, Skilled player (1358)
Joined: 9/12/2016
Posts: 1646
Location: Italy
feos wrote:
Bobo the King wrote:
Well, maybe you could waggle the joystick back and forth quickly enough that it interprets it as left+right, but I'll take a "I'll believe it when I see it" standpoint.
That's not how it works: Post #346153.
In that very same post you linked, it's also said this, with microscopic font:
AnS wrote:
(well, of course in the asynchronous circuits there's always a race condition of propagation delays, so the signal about releasing Left may somehow arrive later than the signal about pressing Right, and the sampling may just happen at this very moment, but it's too improbable and unreliable, definitely not something with which you should justify L+R)
We already accepted a TAS that makes 8000+ inputs for second, so why not allowing this? Edit: I know the TAS in this submission is actually doing L+R inputs on the same frame, while the one I've pointed out makes extensive use of subframes inputs. My question is, if it would be possible to achieve the same results of L+R with very fast subframe inputs.
my personal page - my YouTube channel - my GitHub - my Discord: thunderaxe31 <Masterjun> if you look at the "NES" in a weird angle, it actually clearly says "GBA"
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
ThunderAxe31 wrote:
I know the TAS in this submission is actually doing L+R inputs on the same frame, while the one I've pointed out makes extensive use of subframes inputs. My question is, if it would be possible to achieve the same results of L+R with very fast subframe inputs.
That post says that it would depend on the hardware. Asynchronous circuits are an entirely different thing than what we're dealing with here. I can't say if such implementations have ever been used for gaming consoles, but I'm pretty sure none of our traditional consoles was asynchronous. So yeah, the input latch process remains more or less the same and matches AnS's main point.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Player (80)
Joined: 8/5/2007
Posts: 865
ThunderAxe31 wrote:
We already accepted a TAS that makes 8000+ inputs for second, so why not allowing this?
This is perhaps the best argument in favor of ending this debate.
fsvgm777
She/Her
Senior Publisher, Player (226)
Joined: 5/28/2009
Posts: 1213
Location: Luxembourg
Here's the operators manual for the arcade game/cabinet, complete with a wiring diagram. A more detailed manual (with a detailed schematic on the last page) can be found here. I'm going to focus on the operators manual. Page 2 clearly displays a joystick (but that's already established). However, it only allows for 8 directional inputs. Therefore, the input in this case is semi-analog (as is the case with many other Arcade games), like in the Atari 2600 controller.
Bobo the King wrote:
This is perhaps the best argument in favor of ending this debate.
You missed ThunderAxe31's edit:
ThunderAxe31 wrote:
I know the TAS in this submission is actually doing L+R inputs on the same frame, while the one I've pointed out makes extensive use of subframes inputs. My question is, if it would be possible to achieve the same results of L+R with very fast subframe inputs.
Steam Community page - Bluesky profile Oh, I'm just a concerned observer.
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
Spikestuff wrote:
feos wrote:
I'm not missing it at all, read my post carefully.
No you're missing the point completely feos, we're stating that you shouldn't physically modify an arcade machine to get what you want out of it. This falsifies the cabinet itself as something that's completely impossible is being done. SNES/NES/PS1/N64 (dpad) etc. all have a free pass for a simple reason. They're not analog controls, this is a stick, represented by an analog movement. The system is being modified in a way where it's literally abusing everything that's not meant to be physically possible. On directional input, it is possible to do U/D and L/R input, there shouldn't be a debate for that, but for something analog there is no bloody way doing that without ripping out the machine and getting into the inside, which is what this TAS is doing.
feos wrote:
And then, this thread: Thread #14051: Debate: allowed or not?.
There's a difference between analog input and directional input. Don't bring up threads that hold literally next to no weight to arcade machines where the main movement is analog, and it's being broken apart. This is a whole different can of worms that you're insisting belongs in the same field when it doesn't. Also I'd rather have the author who actively avoids controversy behind his TASes respond to this rather than someone who is on the outside trying to make it up and save it. Talking about can of worms.
feos wrote:
And starting from this post: Post #345991.
Entirely different again.
Stop these fantasies. You're talking to the person who made this feature available in mame-rr. Read the name of the function here: https://github.com/TASVideos/mame-rr/commit/0304a831f1d8726fc03434e3f6be0a11fc0e0600 https://github.com/TASVideos/mame-rr/commit/88ab3fab2f6e0e86645905e7a831de6e5e6c40f2 Hint: it's frame_update_digital_joysticks(). I'm not touching analog input. I'm removing limitations of digital processing logic. After 0.139, mame removed that limitation officially and made it an actual option. This is why my argumentation and threads I linked perfectly and fully apply.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Skilled player (1416)
Joined: 10/27/2004
Posts: 1978
Location: Making an escape
Spikestuff wrote:
SNES/NES/PS1/N64 (dpad) etc. all have a free pass for a simple reason. They're not analog controls, this is a stick, represented by an analog movement. The system is being modified in a way where it's literally abusing everything that's not meant to be physically possible.
You may be conflating two things here: The N64 analogue stick and the arcade joystick. Just because the former resembles the latter does not mean they function the same way. The N64 and other such systems use a couple of potentiometers in order to simulate a whole range of values - but only two at a time - whereas many arcade joysticks use four simple mechanical contacts, so aesthetically, it resembles an analogue stick but functions like a digital dpad.
A hundred years from now, they will gaze upon my work and marvel at my skills but never know my name. And that will be good enough for me.
DrD2k9
He/Him
Editor, Judge, Expert player (2213)
Joined: 8/21/2016
Posts: 1090
Location: US
fsvgm777 wrote:
Page 2 clearly displays a joystick (but that's already established). However, it only allows for 8 directional inputs. Therefore, the input in this case is semi-analog (as is the case with many other Arcade games), like in the Atari 2600 controller.
It's fully digital. The 8 directions are achieved through 4 switches and combinations of the signals coming from them just like in an NES controller. The only difference is that in the NES controller, the 'wires' are the electrical traces attached to the internal circuit board, while the arcade cabinet uses actual copper wires. Gluing a thumbstick to the top of an NES controller wouldn't magically make it analog anymore than arcade joysticks make their internal switches analog. I've had multiple jobs through college repairing arcade machines. The VAST majority of older games (and many) newer ones use on/off switches (either leaf or button style) underneath the joystick and are thus digital input, not analog. There were a few analog controlled games, but they were rare in my experience. This means an arcade joystick is essentially the same as an NES control pad. Where the only limitation to pressing U+D/L+R on the NES is the rigid D-Pad on the stock NES controller, the only limitation to pressing U+D/L+R on the arcade cabinet is the rigid joystick structure. If NES TASes are accepted because these multidirectional inputs can be physically performed on non-stock controllers, the argument could be made that modifying a cabinet's controls to accept these inputs would be that same as using an aftermarket/non-official controller. To further support the side of accepting these inputs on arcade machine TASes... While I was working in those repair jobs, I took the opportunity to press the switches for opposite directions simultaneously during internal maintenance on various cabinets. I can confirm that this would indeed glitch some games, in some cases requiring a complete reboot of the unit to return the game to normal function. EDIT: My apologies to Ferret Warlord, I was in the midst of typing my response when you posted yours saying essentially the same thing in a much more concise manner.
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
Back to my point of being digitally possible. Internally, everything is digits. Even actual analog controls are represented as digits, the only difference from buttons is that each button is represented as one bit of data, and analog control takes several bits. An NES controller is just buttons, and it occupies 8 bits, being 1 byte. N64 analog stick is represented as two single-byte values. You can only digitally send a signal that arbitrarily sets different bits, but you can't send a signal that sets and clears the same bit at once. Similarly, you can not digitally send opposing analog directions. Because in both buttons and sticks, directions are just an abstraction that holds no internal meaning: you can map 256 variants to 1 in-game direction, and 0 to others. You can map every bit to its own direction. You can interpret it all in any way. But you can't combine in a single value numbers that contradict each other bit-wise. tl;dr: I'm not advocating accepting opposing analog inputs, they are digitally impossible (unless you're into quantum computers, which none of the TASable machines are).
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 11/3/2010
Posts: 1
It's not hard to do, and in fact all it takes is a semi-trivial change to how the inputs are wired to allow for a button based directional input layout(example, the HitBOX). I can't see why this would be disallowed while stuff like the Zelda 2 TAS was, when you can easily make SOCD happen if you have access to a cab's guts....
Joined: 4/3/2005
Posts: 575
Location: Spain
This looks more like a bad dream than a videogame. Does it count as a bullet hell?
No.
Joined: 11/15/2004
Posts: 804
Location: Canada
I've never been a fan of U+D or L+R on console runs, since they violate the "What Would Data Do?" aspect of perfect play. Such runs don't demonstrate what's possible with perfect play, since not even the android Data could reproduce these runs because the controller couldn't produce the inputs... unless, of course, you were to take the controller apart so that he could press the left and right/up and down buttons under the D-pad directly. That would not be possible for a controller with an analog joystick... but it seems that this arcade machine did not use an analog joystick. It's like screwing the stick into the D-pad on a Gravis PC Gamepad: it's still just four buttons getting pushed by rocking the D-pad around. I still don't like the concept of needing to take the controller (or in this case, the arcade machine) apart in order to press those buttons, but if we're allowing it for console runs, it seems we have to accept it for any system that uses digital direction controls. As feos stated so well, "you can not digitally send opposing analog directions", so it seems that this will never be a debate on systems that actually use analog joysticks. So there we have it, then: there will be no special cases where U+D or L+R won't be allowed in a TAS. Even if I don't like a rule, I'm relieved when it can be universally applied. Edit: Just in case anyone doesn't understand why you can't send U+D or L+R in a system that has an analog joystick, it's about how the system determines what direction you're trying to go. A system with a D-pad has up, down, left, and right buttons, and the software figures out what direction you're pressing by checking which of them are being pressed. Is up being pressed -- yes or no? Is down being pressed -- yes or no? Is left being pressed -- yes or no? Is right being pressed -- yes or no? The controller itself doesn't actually send a single value for direction to the console -- though such a thing would have been possible if the controller's CPU were programmed to do that. It could send 0 for U, 1 for U+L, 2 for L, 3 for D+L, etc. -- some value between 0 and 7, which would be sent in binary as a number between 000 and 111, sending only 1 less bit of data than if it just sent a 0 or 1 for each of the buttons. It's not worth doing, so they don't do that. If you ever opened a "ball mouse" -- before they had lasers, they had a ball that would carry dirt inside the mouse -- you'll remember seeing two plastic rollers. One represented vertical movement and the other represented horizontal movement. Keeping track of how much each roller had turned determined how many pixels up/down and left/right to move the cursor on your screen. Mouse movement is, therefore, represented as a combination of two values: "delta x" and "delta y". You can't send two x values or two y values in the same frame, i.e. horizontal values of +10 and -7. Likewise, if you've ever opened an N64 controller, you'll have seen two wheels near the joystick that get turned when the thumbstick moves around. How far the stick moved horizontally and vertically -- delta x and delta y -- can be used to calculate the direction. If the ball mouse had registered the same amount of vertical and horizontal movement -- say, 10 pixels down and 10 pixels left -- then your direction was due southeast, or 135°. The delta x and delta y can also be used to determine how far the mouse travelled, and the combination of direction and distance is called a vector. Vectors are what made the N64 controller so amazing: it calculated not just what direction you were pushing the stick, but also how much you were tilting it. This allowed Mario to walk slowly if you pushed the stick a little bit, or run fast if you pushed it all the way. Again, you can't send two of these values in the same frame. Even with an emulator, there is no way to send (or record in an input list for movie playback) 90° and 270° direction information in the same frame, nor 0° and 180° tilt information in the same frame. For any system that uses analog direction input, the controller will either send a single value for direction and tilt per frame (calculated by the controller's CPU), or a single value for delta x and delta y (letting the console CPU calculate the direction and tilt). Regardless of where the math occurs, the input file cannot contain contradictory direction information, so the U+D/L+R debate will never occur for TASes of systems with analog joysticks. Isn't that lovely?
TASing or playing back a DOS game? Make sure your files match the archive at RGB Classic Games.
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
Banning opposing directions each time the stock controller has happened to ban them is not a consistent rule. As I said, we don't TAS arcade cabinets, or physical controllers, we TAS the software in isolation. If we throw physical device factors in, we're not emulating anymore, we're simulating. And perfect simulation is impossible, let alone non-deterministic. Even if we start this simulation of a physical device, where shall we stop? Let's simulate temperature as well, which will allow us to bend the plastic enough to be able to reach those opposing directions physically. Then why won't we also simulate all the non-determinism caused by different initial RAM on different consoles? Why won't we simulate half-connected cartridge and its glitches? Why won't we simulate kicking the console while holding a dog that has just bitten a cat that was sleeping? I want all the factors to be considered, what the hell? Then, we can't base on the lack of information. Maybe someone has just done poor research and because of that they state that no official controller allowed opposing directions. Then someone else does better research and finds the one that allowed that. Like https://en.wikipedia.org/wiki/Power_Pad Now if someone declares that only the controller that went with the console itself is allowed, like SDA do, then we hit the first problem I described. Finally, this technique has been there forever, it won't be possible to ban it anymore. However, it can happen that opposing directions get banned by the TAS author as a way to improve entertainment and provide a low-gitch run. If it meets the Moons criteria, it will be published.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Skilled player (1003)
Joined: 10/13/2014
Posts: 409
Location: nowhereatthemiddleofnoone
Get my yes vote... And I forgot the joystick doomed by numerous inputs in same time... If it's possible with MAME then it's possible to use this technique to TASing. Some moves are very entertaining! I had want more levels to be more entertained, but game is game... How many coins are be uses to make this run? lol Thank to doing know this game by this cool run.
GAW sms... Totally destroyed
Challenger
He/Him
Skilled player (1689)
Joined: 2/23/2016
Posts: 1061
What the...WOW! This was unexpected. Yes vote.
My homepage --Currently not much motived for TASing as before...-- But I'm still working.