Puyo Puyo Tsu/Frame Data Tables

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/frame² (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

• ¹: reached actual terminal velocity (due to roundoff errors)
• ²: reached theoretical terminal velocity
• ³: 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

• ¹: reached actual terminal velocity (due to roundoff errors)
• ²: game physics prevent this fall from being possible