|
Post by walker7 on Aug 2, 2008 0:34:10 GMT -5
I'm sure many of you would want to program your own version of Tetris using BasiEgaXorz. I have played Tetris for a very long time, as well as most (if not all) of you. But, for those who want to program their own version of Tetris using BasiEgaXorz, what would be a good way to make some of the tests required? For instance, the "lock" condition, where after the falling piece lands on at least one solid block in the playfield, it locks into place (indicated by the Carry flag: 1 = Yes, 0 = No)? Or how about the game-ending "top out" condition, where either a piece locks overlapping at least one block in the playfield (a "block out") or locking a block above the topmost legal row of the playfield (a "lock out")?
Now, suppose you wanted to program the playfield as a series of 16-bit values, in 20 rows of 10 blocks each. Say that you want 0x0000 to be an empty space, and anything else to be a solid block. The 16-bit values actually represent the tile in VRAM. Then, to check for any individual line clear is easy. Just do a TST.W w/post-increment followed by a SEQ, and then bitwise-OR the results of the 10 SEQs. Then, if the Zero flag is 1, then there is a line clear, since none of the 10 SEQs resulted in a value of 0xFF.
Say that you want the currently falling block to be represented as a 32x32 sprite, and the already-existing blocks in the playfield to be represented as tiles on a layer.
The question is, what is some efficient code you can use for all the vital parts of the game?
|
|
|
Post by Mairtrus on Aug 2, 2008 10:29:22 GMT -5
I think it would be a better idea create a playfield as an array, then it is easier and faster to read the individual position of each "solid block" on the screen, and instead use a 32x32 sprite, use several of 8x8 sprites to create the piece, because the detection of collisions could become a nightmare. The detection of collisions could be carried out by calculating individually the position of each block of the piece BEFORE hit against a solid block. That way, if some of the blocks clashes whit the playfield in the next movement, sprites are destroyed and at the same place the tiles are drawn in the positions they occupied sprites above. If not (no impact), the piece moves downward. Of course, something similar applies if the moves left or right. PS: I do not know if this was exactly what you were looking for, but I felt good idea do some light on the matter. PS2: You just give me a great idea! I will start a tetris in BEX, and when it's ready I will release it, with source code and all (unless someone win me )
|
|
|
Post by haroldoop on Aug 2, 2008 10:48:19 GMT -5
Well, not sure if it'll help, but some years ago I've coded a version of Tetris for the Sega Genesis, using SGCC: www.zophar.net/pdroms/genesis/ultimate-tetris.htmlIt's pretty slow, and not really what one could call a finished product, but maybe it would be of some help. BTW, it uses the array approach for storing the playfield.
|
|
oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Aug 2, 2008 12:32:23 GMT -5
the array method works the best. i think mixing it with assembly language is going to be overkill, haha, as there are only a few collision checks. when the block falls by one tile, you have to check the tiles below it. when another tile is detected, your game will then bust out a new block piece. when a new piece is brought out, you also need to check for completed lines, and for a game over. the only slow part in basiegaxorz would be shifting all the blocks down by one yea, if you guys need anything from me, like a new compiler, or some examples, just ask . i'm glad that people have been recently using the compiler, and then showing what they have done
|
|
|
Post by walker7 on Aug 2, 2008 17:29:36 GMT -5
Checking for collision detection is rather easy; just record the positions of the four blocks of each piece as X/Y coordinates relative to the bounding box. Then, add an X/Y offset to both coordinates. The X offset is affected by movement of the piece to the left or right. The Y offset is affected by either pressing down or letting it fall. For collision detection, once the actual block position is calculated, then when it is time to move the block down one row, check the blocks immediately below by using a TST.W w/an offset of +20, because there are 20 bytes in one row. Then, use a SNE instruction so that 0x00 means nothing there, and 0xFF means a solid block is there. Logical-OR the four SNE results together, then if the Zero flag is clear, move the piece down one row, otherwise lock the block in place and deal out the next block. With this setup, you can use either the individual 8x8 sprites or the single 32x32 sprite. Left- and right- collision checking work the same way. To learn more about bounding boxes and rotation systems, go to this website: www.tetrisconcept.com/wiki/index.php/Category:Rotation_Systems. Here is an example: Say that the current piece is a T. Its bounding box looks like this: O O O O O O O O O O O O O O O OLabel the units both across and down from 0-3. In relation to the bounding box, the four blocks, represented as (X,Y) pairs, are at (0,1), (1,1), (1,2), and (2,1). Then, these could be represented as the bytes 00 01 01 01 01 02 02 01. Now, say that the X offset is 3, meaning that the leftmost column of the bounding box is three units to the right of the left wall of the playfield. That means that the T block is slightly left-of-center. Then, you add 3 to the first byte in each pair, giving 03 01 04 01 04 02 05 01. If any of those first bytes in any pair after a left movement would go below 0x00, or there is a solid block in the way (using an offset of -2 bytes), don't move it left. Similarly for moving right, check to see if any of those four bytes would go above 0x09 or if any blocks are in the way (using an offset of +2 bytes).
|
|
|
Post by walker7 on Aug 3, 2008 14:05:22 GMT -5
Here is another question: What would be a way to add a small number of points depending on how far a piece dropped while holding down until it locks, similar to the NES or Game Boy versions of Tetris? This means, how can you detect that the Down button is being held, and when to increase the variable by 1 per row dropped while holding Down, and when to reset to 0?
|
|
|
Post by Mairtrus on Aug 3, 2008 19:10:45 GMT -5
Easy. Add a counter that increase it value in 1 by each time the button is pressed, and clean it when you free the down button.
|
|
|
Post by Mairtrus on Aug 10, 2008 10:16:13 GMT -5
Well, is finally here, as I promised some post above: A tetris completely done at BEX! It took me more than expected because I was sick all week (damned flu), and my doctor recommended I rest, so I couldn't hardly use the PC in almost the entire week. The game is fully commented, so that anyone can use it to create its own tetris. Attached is a .png explaining the method I used to create the rotations of the pieces. Enjoy! PS: Excuse absences spelling of the comments in the game. www.fileden.com/files/2007/11/30/1616239/Tetrex.zip
|
|
|
Post by ScroGer on Aug 10, 2008 16:00:53 GMT -5
WOW great Tetris clone, and its about time someone included there precise source code and its even well commented on, this is great well done Mairtrus I hope to see more of ur games real soon. ;D
|
|
|
Post by Tom Maneiro on Dec 7, 2008 11:48:50 GMT -5
|
|
|
Post by FragHeadFred on Mar 16, 2017 15:22:23 GMT -5
So I was looking at this and was trying to figure out how to make the frozen pieces move with the playfield.... I can move the playfield with const #XInit=136 const #YInit=144 but the frozen pieces stay in the same spot? Any help would be greatly appreciated. I uploaded the code again since original link is long dead (Attachment). Thanks in advance. Attachments:tetris.bex (11.88 KB)
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Mar 17, 2017 6:11:14 GMT -5
I'm not sure what's going on in the source (I'm on my phone and I haven't really touched BEX in a long while), but I made a similar game to Tetris a few years back, and this is what you'll need to do:
Your game pieces are sprites so they can move. You'll need to keep a map of where current pieces landed for collision. Once the Sprite collides, you'll need to draw that piece in place to the background, then check to see if a full row has been made, then either shift the tiles down by redrawing them, or scroll the background plane down (I would suggest redrawing the tiles).
|
|
|
Post by wraith on Mar 17, 2017 19:47:42 GMT -5
So I was looking at this and was trying to figure out how to make the frozen pieces move with the playfield.... Something like this I suppose. tetris.bex (11.99 KB)
|
|
|
Post by FragHeadFred on Mar 17, 2017 21:46:44 GMT -5
Yeah, I had figured it out this morning before I left for work, can't believe I missed it! Thanks to both of you for your time!
|
|
|
Post by FragHeadFred on Mar 17, 2017 21:47:58 GMT -5
I'm going to replace all instances with a variable to make moving the playfield more convenient.
|
|