User:Nightmareci: Difference between revisions

From TetrisWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 43: Line 43:
On the first frame of piece display, a soft drop input is simply ignored, so, for example, some variable representing whether soft drop "is pressed" or "not pressed" would be set to "not pressed" on the first frame. The second frame and later can have a soft drop input set, for example, as "is pressed"; this processing of input occurs outside this description.
On the first frame of piece display, a soft drop input is simply ignored, so, for example, some variable representing whether soft drop "is pressed" or "not pressed" would be set to "not pressed" on the first frame. The second frame and later can have a soft drop input set, for example, as "is pressed"; this processing of input occurs outside this description.
# Preparation for the pieces' first displayed frame (such as during ARE):
# Preparation for the pieces' first displayed frame (such as during ARE):
#* Gcount = Gspeed % 256
#* If Gspeed > 256:
#** Gcount = Gspeed % 256
#* Else:
#** Gcount = 0
#* Gspeed is set to the appropriate value for the current level
#* Gspeed is set to the appropriate value for the current level
#* Attempt to place the piece in row number 1 + Gspeed / 256, higher if necessary
#* Attempt to place the piece in row number 1 + Gspeed / 256, higher if necessary
Line 61: Line 64:
#* Go to 3.
#* Go to 3.
# Further processing after gravity (processing will come back to 2. if the piece hasn't locked)
# Further processing after gravity (processing will come back to 2. if the piece hasn't locked)
In the above, the line "Gcount = Gspeed % 256" may appear curious, as all Internal Gravity values in the TGM series are either <256 or an even multiple of 256, but it's purpose is to properly support gravity speeds such as 4.5G; none of the TGM games have gravity like this, but this makes this description more general. If your implementation is only conforming to actual TGM gravity, the line can be replaced with "Gcount = 0".
In the above, the first If...Else sequence may appear curious, as all Internal Gravity values in the TGM series are either <256 or an even multiple of 256, but it's purpose is to properly support gravity speeds such as 4.5G; none of the TGM games have gravity like this, but this makes this description more general. If your implementation is only conforming to actual TGM gravity, the sequence can be replaced with "Gcount = 0".


In ANSI C, one can use bitwise operators instead of the division and modulo (%) operators, because 256 is a power of 2; a simple example follows:
In ANSI C, one can use bitwise operators instead of the division and modulo (%) operators, because 256 is a power of 2; a simple example follows:

Revision as of 00:34, 18 February 2009

Definitions

In this page, the very top row is row number 0, the row below the top row is row number 1, and so on, until 20 (TGM1 has 20 visible rows + 1 vanish zone row).

Tetris The Grand Master

Some of the following information may not be consistent with other wiki pages; where this applies, simply ignore the information elsewhere in the wiki. Corrections to this information by others are only accepted if supported by examples. Information here is still work in progress.

Gravity

Directly from Tetris The Grand Master, here is the gravity curve:

Internal Gravity[1]
Level Interal Gravity
(1/256 G)
Level Internal Gravity
(1/256 G)
0 4 220 32
30 6 230 64
35 8 233 96
40 10 236 128
50 12 239 160
60 16 243 192
70 32 247 224
80 48 251 256 (1G)
90 64 300 512 (2G)
100 80 330 768 (3G)
120 96 360 1024 (4G)
140 112 400 1280 (5G)
160 128 420 1024 (4G)
170 144 450 768 (3G)
200 4 500 5120 (20G)

In the following, Gcount is the current Gravity Count; Gspeed is the Gravity Speed, and is equal to one of the Internal Gravity entries in the above table. All values can be represented with unsigned integers, as no negative values ever appear. All division has the fractional part truncated, as in ISO C (60/256 = 0, 252/256 = 0, 260/256 = 1).

On the first frame of piece display, a soft drop input is simply ignored, so, for example, some variable representing whether soft drop "is pressed" or "not pressed" would be set to "not pressed" on the first frame. The second frame and later can have a soft drop input set, for example, as "is pressed"; this processing of input occurs outside this description.

  1. Preparation for the pieces' first displayed frame (such as during ARE):
    • If Gspeed > 256:
      • Gcount = Gspeed % 256
    • Else:
      • Gcount = 0
    • Gspeed is set to the appropriate value for the current level
    • Attempt to place the piece in row number 1 + Gspeed / 256, higher if necessary
  2. Every frame this piece is displayed:
    • If soft drop is pressed:
      • If Gspeed < 256:
        • Attempt to drop one line
      • If the piece has blocks beneath it now:
        • Lock the piece
      • Go to 3.
    • If there are blocks below this piece:
      • Set Gcount to Gspeed
    • If Gcount is greater than or equal to 256:
      • Attempt to drop Gcount / 256 lines
      • Gcount %= 256
    • Increase Gcount by Gspeed
    • Go to 3.
  3. Further processing after gravity (processing will come back to 2. if the piece hasn't locked)

In the above, the first If...Else sequence may appear curious, as all Internal Gravity values in the TGM series are either <256 or an even multiple of 256, but it's purpose is to properly support gravity speeds such as 4.5G; none of the TGM games have gravity like this, but this makes this description more general. If your implementation is only conforming to actual TGM gravity, the sequence can be replaced with "Gcount = 0".

In ANSI C, one can use bitwise operators instead of the division and modulo (%) operators, because 256 is a power of 2; a simple example follows:

placeInRow = 1 + Gspeed >> 8; // equivalent to 'placeInRow = 1 + Gspeed / 256;'
linesToDrop = Gcount >> 8; // equivalent to 'linesToDrop = Gcount / 256;'
Gcount &= 255; // equivalent to 'Gcount %= 256;'

On more limited systems where division and modulo would be noticeably slow, using bitwise operators this way can significantly improve performance. Because only positive integers appear in these expressions, ANSI C guarantees these expressions are equivalent, on implementations following ANSI C. On very limited systems (such as the NES), these would be easy to translate to assembly.