Puyo Puyo Tsu/Frame Data Tables

From Puyo Nexus Wiki
Jump to navigation Jump to search

This page sums up frame data timings for various game sequences, events, animations, etc.

Gamepad Input Repeat

This data is fully reverse-engineered

Internal details of the game routines are discussed on the following page: Puyo Puyo Tsu/Gamepad Input.

This table sums up default frame counts for gamepad input repeat during different phases.

Phase Delay until repeat Button repeat
During game 8 2
Main menu 16 3
Settings menu 16 5
Solo menu 32 8

This means that, during a game, there's an 8-frame delay before a pressed button is first repeated, while subsequent repeats are 2 frames apart (1 frame of inactive button before repetition on the 2nd frame).

An input sequence is as follows:

  1. a button is held down, being active for 1 frame
    • the button's action may be triggered there
  2. 7 frames pass with the button being inactive
    • the counter is decremented for each frame no new input is detected
  3. a single frame has the button active again
    • counter value was 1, gets decremented to zero, then gets reset to 2 and the button is thus made active, all in the very same frame
    • the button's action may be triggered again there
  4. 1 frame passes with the button inactive
    • the counter is decremented and now equals 1
  5. go back to #3 unless a new button is pressed

Note: the game keeps two distinct timers:

  • for Right/Left arrows
  • for Up/Down and Start/A/B/C together

Rotation

This data is fully reverse-engineered

Internal details of the game routines are discussed on the following page: Puyo Puyo Tsu/Rotation, collision and push back.

Rotation frame data is currently measured at:

  • Action input lock: none. The player can trigger a rotation on two consecutive frames.
  • Same button lock: 1-frame lock-out, due to gamepad readout routine. The player cannot input the same button alone in two consecutive frames.
  • Rotation animation: 7 frames for calculation. May be skipped if a new rotation input occurs before the end.

Rotation is acknowledged by the game on the same frame the input was read from the gamepad. There is no transition phase for the collision data: new coordinates are immediately used upon rotation acknowledgment (on the next frame).

The following breakpoints were used in the MESS debugger to validate this data (they won't work if two players are rotating pieces at the same time): 

bpset 62D2, 1, {printf "x%06X ROTATION: clockwise (frame: %d)", pc, frame; temp0=frame; g}
bpset 62CC, 1, {printf "x%06X ROTATION: counter-clockwise (frame: %d)", pc, frame; temp0=frame; g}
bpset 6458, b@(a0+0x37) == b@(a0+0x36), {printf "0x%06X ROTATION: end (frame: %d count: %d)", pc, frame, frame-temp0; g}

Here's a sample of the trace log of rotation animations:

The following section discusses the input tricks possible with an actual gamepad: Puyo Puyo Tsu/Gamepad Input (see "Consequences").

Drop speed

This data is partially reverse-engineered

This table sums up frame timings of falling pairs depending on initial speed and soft dropping (i.e. pressing the down arrow).

Speed Regular drop speed Soft drop speed
2P versus Easiest (difficulty level 1) 16 2
2P versus Easy (difficulty level 2) 16 2
2P versus Normal (difficulty level 3) 16 2
2P versus Hard (difficulty level 4) 16 2
2P versus Hardest (difficulty level 5) 8 2
1P solo level 1 32 2

(table to be completed)

Values are the number of frames needed for a pair to go through a single cell. Thus, going through the entire height of the board will take 12*16=192 frames (3.2 seconds) at normal speed (2P versus mode), and 32 frames (0.53 seconds) while soft dropping.

Notes:

  • soft drop is interrupted by any other direction (R/L) that would be sent to the game while soft dropping;
  • soft drop is not affected by the button input repeat mechanism: a full gamepad readout is performed for every single frame.

Grace period

This data is fully reverse-engineered

Internal details of the game routines are discussed on the following page: Puyo Puyo Tsu/Soft Drop##Consequences.

  • A falling pair can spend a total of 32 frames while being blocked by an obstacle below. Soft-dropping (holding down) will skip this grace period and lock the pair right away.
  • This grace period is also skipped if the player pushes his falling pair back up 8 times. On the 8th attempt, the pair is locked right away.

Bouncing animation

This data is fully reverse-engineered

Internal details of the game routines are discussed on the following page: Puyo Puyo Tsu/Soft Drop##Consequences.

  • Bouncing animation lasts for 16 frames.
  • It can be skipped with motion cancel.

Pair split speed

This data is fully reverse-engineered

Internal details of the game routines are discussed on the following page: Puyo Puyo Tsu/Falling Pair Control#Pair_split_and_free-fall.

From control lock (pair lock) to actual splitting (the moment a puyo starts free-falling), there is a fixed delay:

Free-falling puyo Frame delay before free-fall begins
Main puyo 1
Slave puyo 2

Those are frames during which nothing is applied to the puyos, which delays actual free-fall and placement on the board.

Free fall speed

Free fall speed differs for:

  • puyos controlled by the player, after splitting a pair in two;
  • single ojama puyos;
  • bulk ojama puyos, depending on their respective column;
  • puyo freefalling after a chaining event.

Free falling puyo after pair split

This data is fully reverse-engineered

Internal details of the game routines are discussed on the following page: Puyo Puyo Tsu/Free fall.

A board cell is 16 pixels high, initial freefall speed is 1 pixel/frame (0x10000), acceleration due to gravity is 0.1875 pixels/frame2 (0x03000). Terminal velocity is capped at 0x80000 (8 pixels/frame, half a cell), in theory reached in 39 frames. Due to roundoff error, terminal velocity is actually attained much quicker, in about 31 frames (after freefalling for 7 cells).

Puyo lockout occurs at the last frame of the freefall.

The following tables shows the accurate number of frames required for a puyo to freefall through a specific number of board cells:

Height Total frame count
1 cell 10
2 cells 15
3 cells 19
4 cells 22
5 cells 25
6 cells 28
7 cells1 31
8 cells 33
9 cells 35
10 cells 37
11 cells2 39
12 cells 41
13 cells3 43
  • 1: reached actual terminal velocity (due to roundoff errors)
  • 2: reached theoretical terminal velocity
  • 3: game physics prevent this fall from being possible

Free falling bulk ojama puyos (rocks)

This data is partially reverse-engineered

Internal details of the game routines are discussed on the following page: Puyo Puyo Tsu/Free fall.

Initial free-fall speed is 0 pixel/frame (0x0000) in a 2P versus battle, acceleration due to gravity depends on the column. Terminal velocity is capped at 0x80000 (8 pixels/frame, half a cell). Due to roundoff error, terminal velocity is actually attained much quicker that the theoretical value. Some columns have parameters that make reaching terminal velocity impossible.

Ojama puyo lockout occurs at the last frame of the freefall.

The following tables shows the accurate number of frames required for an ojama puyo to freefall through a specific number of board cells, depending on its column:

Height Column 1 Column 2 Column 3 Column 4 Column 5 Column 6
1 cell 16 16 17 15 17 15
2 cells 22 22 24 21 23 21
3 cells 27 26 29 25 28 26
4 cells 31 30 33 29 32 30
5 cells 35 34 37 32 36 33
6 cells 38 37 40 35 39 36
7 cells 41 40 43 38 42 39
8 cells 44 43 46 411 45 41
9 cells 46 45 49 43 48 44
10 cells 491 47 52 45 50 46
11 cells 51 501 54 47 52 48
12 cells 53 52 56 49 551 511
13 cells2 55 54 59 51 57 53
  • 1: reached actual terminal velocity (due to roundoff errors)
  • 2: game physics prevent this fall from being possible
Retrieved from "https://puyonexus.com/mediawiki/index.php?title=Puyo_Puyo_Tsu/Frame_Data_Tables&oldid=6171"