User:Kitaru: Difference between revisions
m Layout adjustments, and creating a section for PPT |
|||
Line 1: | Line 1: | ||
== NES Tetris | == NES Tetris == | ||
=== NTSC === | === Effective rate of DAS vs. tapping === | ||
==== NTSC ==== | |||
The aim of this write-up is to compare the worst/average/best cases of DAS usage compared to manual rapid tapping. Comparisons will be made using a vertical I-piece traveling to the left wall (i.e., moving the piece 5 cells). | The aim of this write-up is to compare the worst/average/best cases of DAS usage compared to manual rapid tapping. Comparisons will be made using a vertical I-piece traveling to the left wall (i.e., moving the piece 5 cells). | ||
Line 133: | Line 134: | ||
TODO: discuss cases where physical tapping could prove advantageous due to dangerous upstack in the center of the playfield -- i.e. slope of movement and distribution of acceleration | TODO: discuss cases where physical tapping could prove advantageous due to dangerous upstack in the center of the playfield -- i.e. slope of movement and distribution of acceleration | ||
=== PAL === | ==== PAL ==== | ||
The actual framerate of the PAL NES is ~50.006978hz. As with the NTSC section above, these calculations use 50hz for simplicity (~0.013956% difference, even less of a margin than NTSC). | The actual framerate of the PAL NES is ~50.006978hz. As with the NTSC section above, these calculations use 50hz for simplicity (~0.013956% difference, even less of a margin than NTSC). | ||
Line 228: | Line 229: | ||
|} | |} | ||
== | === B-Type garbage generation === | ||
If B-Type is the selected mode, it seems the garbage generation function is always called. The routine always generates 12 rows, then deletes the the unneeded ones according to whatever Height setting was selected. | If B-Type is the selected mode, it seems the garbage generation function is always called. The routine always generates 12 rows, then deletes the the unneeded ones according to whatever Height setting was selected. | ||
Line 289: | Line 290: | ||
| 50 | | 50 | ||
|} | |} | ||
== Puyo Puyo Tetris == |
Revision as of 04:48, 9 May 2017
NES Tetris
Effective rate of DAS vs. tapping
NTSC
The aim of this write-up is to compare the worst/average/best cases of DAS usage compared to manual rapid tapping. Comparisons will be made using a vertical I-piece traveling to the left wall (i.e., moving the piece 5 cells).
The NTSC NES technically runs at ~60.098814hz. The calculations here assume 60hz for simplicity since this does not affect the results very much (~0.16469% difference).
In the NTSC version of the game, DAS has a 16 frame start-up and a 10hz move rate (piece moves every 6th frame). Without discussing the particulars in-depth here, consider that DAS can be preserved from piece to piece under most circumstances.
Given the above, the naive assumption is that charged DAS is equivalent to tapping 10 times per second. However, under most circumstances, the piece is likely to enter the playfield ready to move earlier than the usual 6 frames. In fact, 10hz is the worst case for skillstop timing -- releasing left/right frame perfectly, just enough to get the final shift and no longer. The average case for skillstop is likely somewhere right in the middle (i.e. +3 frames). The best case (full charge) is also reasonably attainable via wall tech.
If we're charging DAS from scratch, the best case is when the piece is actively in the playfield. If we have no charge and hold left/right _before_ the piece appears, we have to wait a full 16 frames for the first shift. If the piece is already active, the first shift happens immediately (tap movement) and we only wait 15 more frames for the second shift.
Averaged across a shorter distance, the effective rates of charging from scratch appears rather low: the worst/best case for moving just two cells is 5.45hz and 7.5hz respectively. However, the parity with tapping improves when traversing greater distances. Of course, the player must take into account if current gravity and stack conditions allow for waiting through the full charge time, but -- given enough time -- the parity with manual tapping on simple recoveries looks rather favorable.
frames per cell | total | avg frame/cell | effective rate | |||||
---|---|---|---|---|---|---|---|---|
from scratch (worst case) | 16 | 6 | 6 | 6 | 6 | 40 | 8 | 7.5hz |
from scratch (best case) | 1 | 15 | 6 | 6 | 6 | 34 | 6.8 | 8.82hz |
charged (worst case) | 6 | 6 | 6 | 6 | 6 | 30 | 6 | 10hz |
charged (average case) | 3 | 6 | 6 | 6 | 6 | 27 | 5.4 | 11.1hz |
charged (best case) | 1 | 6 | 6 | 6 | 6 | 25 | 5 | 12hz |
The situation becomes even more advantageous if using the "extra tap" method to slightly raise the average rate -- you can get a bit of extra range by using a timed tap to get the final shift out a bit earlier than usual. The d-pad must be released for at least one frame in order to register the tap. The worst case is performing no better than just holding the direction (input pattern: ...1 111101). The best case is frame perfectly releasing on the frame of the final shift, then re-pressing on the next frame (bit pattern: ...1 01). So, the meaningful values for the last tap are in the range of 2~5 frames.
frames per cell | total | avg frame/cell | effective rate | |||||
---|---|---|---|---|---|---|---|---|
worst case | 1 | 6 | 6 | 6 | 6 | 25 | 5.0 | 12hz |
1 | 6 | 6 | 6 | 5 | 24 | 4.8 | 12.5hz | |
1 | 6 | 6 | 6 | 4 | 23 | 4.6 | 13.04hz | |
1 | 6 | 6 | 6 | 3 | 22 | 4.4 | 13.64hz | |
best case | 1 | 6 | 6 | 6 | 2 | 21 | 4.2 | 14.29hz |
TODO: discuss cases where physical tapping could prove advantageous due to dangerous upstack in the center of the playfield -- i.e. slope of movement and distribution of acceleration
PAL
The actual framerate of the PAL NES is ~50.006978hz. As with the NTSC section above, these calculations use 50hz for simplicity (~0.013956% difference, even less of a margin than NTSC).
Due to the difference in framerate between NTSC and PAL, the game was rebalanced to approximate the speed of the original game. However, because this would result in fractional numbers of frames, everything was rounded down to the nearest whole number. As a result, many frame timings are considerably faster. DAS has a 12 frame start-up and 12.5hz move rate (piece moves every 4th frame).
Due to the changes in the PAL version, DAS usage is almost always the most advantageous movement strategy. Even uncharged, it has parity with NTSC NES's charged DAS rate.
frames per cell | total | avg frame/cell | effective rate | |||||
---|---|---|---|---|---|---|---|---|
from scratch (worst case) | 12 | 4 | 4 | 4 | 4 | 28 | 5.6 | 8.93hz |
from scratch (best case) | 1 | 11 | 4 | 4 | 4 | 24 | 4.8 | 10.42hz |
charged (worst case) | 4 | 4 | 4 | 4 | 4 | 20 | 4 | 12.5hz |
charged (average case) | 2 | 4 | 4 | 4 | 4 | 18 | 3.6 | 13.89hz |
charged (best case) | 1 | 4 | 4 | 4 | 4 | 17 | 3.4 | 14.71hz |
The "extra tap" method is still usable, but the number of possibilities is much fewer due to the faster move rate. There is only a 2 frame timing window.
frames per cell | total | avg frame/cell | effective rate | |||||
---|---|---|---|---|---|---|---|---|
worst case | 1 | 4 | 4 | 4 | 3 | 16 | 3.2 | 15.625hz |
best case | 1 | 4 | 4 | 4 | 2 | 15 | 3.0 | 16.67hz |
B-Type garbage generation
If B-Type is the selected mode, it seems the garbage generation function is always called. The routine always generates 12 rows, then deletes the the unneeded ones according to whatever Height setting was selected.
There appears to be an off-by-one bug in the offsets used for the Height setting -- it appears the leftmost block of the top row of garbage will always be inadvertently deleted.
Based on the output of a quick test program I wrote, it appears the maximum number of holes that can appear in a row (before random removal step) is 3. As such (and along with the top-left cell removal bug), it is unlikely that a player can clear lines with the first piece. (The only hope would be an I-spin somewhere below the top line, but further testing seems to preclude this possibility as well.)
Here are the steps of the garbage generation:
- for each of the bottom 12 rows:
- row fill step: for each of the 10 cells, right-to-left:
- call the randomizer
- take the upper byte of the randomizer, mod 8
- use the generated random value 0-7 to look up a result to insert (50% chance to be filled, various colors)
- random removal step: call the randomizer
- take the upper byte of the randomizer
- take the lower nybble of that (AND 0x0F)
- if the value >= 10 (0x0A), then jump back to start of random removal step
- using the generated random value 0-9, clear the content of the corresponding cell of this row
- call start-of-frame functions (which will wait for vsync before continuing this garbage generation loop)
- row fill step: for each of the 10 cells, right-to-left:
- (copy the playfield to a mirror at $0500 for some reason? probably leftover 2P code. also might have a bug, it uses $C8 as an index and that appears uninitialized)
- using the Height setting selected, lookup playfield row offset
- clear every cell in the playfield at or above that offset
- (using 2P's (?) Height selection, clear every cell in playfield at or above row offset for mirror at $0500
Random block color lookup table:
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
---|---|---|---|---|---|---|---|
_ | A | _ | B | C | C | _ | _ |
Height setting offset table:
0 | 1 | 2 | 3 | 4 | 5 |
---|---|---|---|---|---|
C8 | AA | 96 | 78 | 64 | 50 |