The NES PPU has a backdrop color and eight 3-color palettes, four for background tiles and four for sprites. Currently, they're used as follows: BG0: Grayscale, for the status bar at the top and for menus in the playfield areas BG1: Player 1's border BG2: Player 2's border BG3: Blocks in field OBJ0: Player 1's falling piece and ghost OBJ1: Player 2's falling piece and ghost OBJ2: Player 1's next piece OBJ3: Player 2's next piece Fighting games usually run on hardware significantly more powerful than the NES, one with more palettes (except maybe the Genesis), a lot more colors per palette, and a larger addressable memory for sprite textures. For each different palette, I have to include a corresponding set of 8 tiles in the CHR ROM, one for each of seven colors and one for garbage. That's why it'd be hard to make a code even for going back to grayscale blocks. And it would probably be impossible to give the two players different palettes unless either one of them is the grayscale set or I abandon separate palettes for the players' borders. But that doesn't affect my plan to implement Ti-ARS because the way I plan to implement Sega colors just reshuffles some indices before things get drawn. 0.38 (2009-04-22) Player can turn off music (requested by Yaz).
If you're going to have colored locked pieces, I suggest making the ghost piece more distinct, like say, making it an LJ-style outline or monochrome. It gets a little confusing having colored locked pieces and colored ghost piece.
I can't do monochrome because I'm out of palettes, but the "outline" style looks like pretty good in Nestopia (and the same on my NES): Take a wild guess what other feature I'm getting ready for 0.39.
It's fitting that ARS keeps JLSTZ touching the bottom of their bounding box, and ARS is also the first three letters of a word that means bottom. That said, Tetramino 0.39 is out. 0.39 (2009-04-27) Moved rotation system code to a separate file. Added a menu item to switch between "CENTER" (the current rotation system) and "BOTTOM" (Ti-ARS) (requested by gs68, Xkeeper, Kasumi, and others). Made the ghost piece an outline, so that the dithering used for a locked Z piece doesn't get confused with the dithering used for the ghost (requested by gs6. Draws the falling piece in white for one frame after lockdown. Cosmetic fix: Blocks from the vanish zone no longer cover up the word "LINES" after a player receives garbage (0.38 regression). Music engine and menu support more than one song. Added song "Leck mich im Arsch" by Wolfgang Mozart (catalogue no. K.231). Now roughly 3.4 KiB of empty space remains in PRG.
Wow, this is actually quite playable! I wish TOD would play like this, I've been playing that on my DS and the FRS (Frankenstein Rotation System) along with the weird ass lockdown behaviour is throwing me off. Yes, you may consider that an official feature request for TOD.
Awesome update, Tepples! Thanks! (though I kinda wish nesDS had a way to map [NES]Up to [DS]L since firm-dropping on a D-pad is kinda arse.)
Yeah, ARS in Tetramino made it very fun, but also as you noted nearly indefnitely sustainable. Edit: A couple of 20G gotchas: firstly, there seems to be an initial shift of sorts, and secondly, though this is not TGM, synchros are hit or miss.
Synchros should be fixable by changing the order of logic processing, should they not? Also, tepples, this is really pretty nice. I'm impressed that you've implemented a nearly correct ARS to an NES game.
I enjoy the single player game, but the multiplayer is not very fun/competitive. There's no line sending going on. Do you have plans for any of that? Also, the music gets annoying fast (I do realize you can turn it off). Other than that, it's one of the most solid homebrews I've seen. I look forward to your updates!
The description of garbage was missing from the manual. It will be fixed in 0.40. "But why does GARBAGE OFF even exist?" Tengen's Tet?is had it. Tengen's Klax for NES had it. Tetris Attack had it in time trial mode. The New Tetris had it in 40 lines and 150 points modes. Both Carbon Engine games for PC (freepuzzlearena Tetanus and TOD) had it. This game was originally developed in 2003, at the tail end of the Carbon Engine era. How critical is it that the initial frame behave just like TGM's? In TGM, the initial frame has no shifting. In TGM, wall kick is not applied in the initial frame. In TGM, you can IRS out of top out. This means collision detection isn't applied until the end of the initial frame. The issue here is that currently, all rotations and all shifts check for transitions from landed to falling. I've changed 0.40 to check after rotation and shifting before gravity if piece_was_moved is true, at the same time the ghost piece gets moved.
I tried out the multiplayer and ran into a lot of glitches. First, there were pieces landing above the left player's play area: http://yfrog.com/0d0001myvp This happened in a couple of games. Then the right player in an earlier game attempted an L spin (or t-spin? I don't know the terminology well) through an area two bricks wide... at the bottom was something that looked like it could be spun into. It might not have been possible to spin into it, but spinning early caused the piece to move halfway between the bricks and continue falling (now the L piece was three bricks wide, falling through an area 2 bricks wide!). This was with bottom rotation with everything we played, version .40 Also, the game seems to forget what speed you had it on last if you have a Game Over, then it forgets the rotation setting if it cycles back into the demonstration/title screen. Starting new games after a player dies was a bit awkward, because there are no strict vs rounds... it's like the old arcade tetris (atari? tengen?), which IMHO wasn't fun for competing. I think it would make more sense if you had a main title screen that had three choices: 1 player, 2 player, option. Then in options you could choose for Vs. mode rounds or continuous play, along with rotation system, garbage, speed, etc. And one last thing... is it possible you could have the option to start 20g at a slower rate?
I guess the change to synchro behavior introduced even more bugs, some of them caused by trying to push out releases faster than the 2-week cycle. Possibly a vanish zone bug. Can you give me a reliable technique to reproduce this? Only the bottom pixel of each block in the falling piece is checked for collision. This means that the top of each block in the falling piece can slightly overlap the bottom of a block in the well. This behavior is on purpose and matches that of Super Puzzle Fighter II. Can you show a diagram of what you're talking about? Erred on the side of safety, so that if you accidentally choose a setting that's much too fast for you, you don't feel cheated the next time you start a game. Or worse yet, if someone else walks up to the machine and starts a game, he doesn't feel cheated. Attract mode needs CENTER and SLOW on player 2. Did you mean save player 2's options before entering attract mode and restore them afterward? Do you mean like the difference between Master with 20G code and Death?
Unfortunately, I couldn't get the person to explain what they did. Sure, here's an MSPaint of what happened: As you can see, it wasn't the brightest move in the world... but I'm pretty sure that behaviour isn't supposed to happen, as it was pretty glitchy falling down. I think I tried to rotate again, and it kinda stopped midair. But, I was able to get the piece to fit perfectly when it landed Makes sense. I think it happens for both players. But yeah, that's what I meant. Well, what I'm asking for isn't really canon with any TGM game... A Master-like mode with 20g would be nice (I assumed the normal game would reach 20g, but I guess not), but I was thinking more on the lines for someone who sucks at Death mode, have the pieces fall (er, appear?) slower as a "training" mode. I'm mainly excited that there's now an NES tetris with 20g, so I should be thankful it exists at all I just need practice.
Huh. I just posted something similar to this on nesdev. I should have checked here first. Good to know it's not just me though. Edit: Hiroshi: The normal game does reach 20G eventually.
Tetramino is dead... ...long live LJ65. I've analyzed the problem a bit more. As far as I can tell, here's what happens in 0.39-0.40: Player 2's field uses the lockdown rule corresponding to the rotation system chosen by player 2, but it uses the rotation rule corresponding to the rotation system chosen by player 1. If player 2 is using BOTTOM rotation, the "unrotate" step at the end of JLSTZ kick processing restores the previous orientation to player 1, not player 2, even though it correctly restores the previous height to player 2. I can see how this might cause both errors that the reporter saw. This is one of the perils of working on a CPU architecture (MOS Technology 6502) that strongly prefers structure-of-arrays over the array-of-structures that Carbon Engine and Lockjaw Engine use. (What's the difference? See this page and this page.) I've added rules to the corresponding records topic to clarify how I will handle affected scores.
