And as of right now, LJ65 0.41 is out with a couple bug fixes for you to bang on. 0.41 (2009-06-02) Renamed to LJ65 so that it can have its own domain. Reviewed which files to put under a permissive license and which to make GPLv3. BOTTOM isn't broken for player 2 anymore (reported by Kasumi). Scores ending in 00 aren't displayed as ending in 09. Hard drop gives one additional point so that it isn't weaker than soft drop (requested by Kasumi). Fixed strange interactions between one player's shifting and the other player's rotation, caused by sound code trashing X register (0.40 regression; reported by Matthew).
I actually meant to report these "bugs" on the last version but forgot... sorry. They're mostly ignorable ones anyway. If player one ( this happens with either player, but for the sake of example, I'm using player one) is holding left or right on the Music or garbage option and the autorepeat has kicked in, if player two presses A+B to make the options appear, part of the game over screen remains drawn to the screen until player one lets go of left or right. Having player one (once again for the sake of example, though it works with either player) hold left or right also delays the game over screen from appearing if player two has topped out until the first player has let go of the button. While this certainly seems like intentional behavior, I find it unusual that letting go of the button for a single frame (tested on Nintendulator) and then immediately holding it again allows the game over screen to appear without any strange side effects. (That I could see) I really need to look through this game's source again. I have guesses about why these might occur, and would like to see if I'm right. As well, I don't have a good way to mess around with two player bottom rotation at the moment, but I am VERY happy that you fixed it.
i wonder if anyone has played this on a cell phone. if your phone runs Java apps you can try NesCube or vNes. if you can get the emulator to run smoothly, this would be one of your better mobile tetris options. my phone only runs BREW, which means no homebrew.
What you're seeing is a limitation on the NTSC NES's video memory bandwidth. Even with my unrolled loop, there's only enough bandwidth to the PPU to draw 22 rows to the screen each frame, and each playfield is 20 rows tall. (The authentic Tetris game for NES, on the other hand, manages to draw about 4 rows each frame, which is enough for everything but falling after line clears.) When DAS was 30 Hz, this wasn't a problem: either you'd get one player's field updating each frame and the other updating the next frame, or you'd get both bottom halves updating and then both top halves updating. That's similar: it only updates the playfield's color scheme (blue-orange-green vs. grayscale) on a frame when there aren't any rows to update. But is this any worse than the glitches on the far right side of the screen in Super Mario Bros. 3?
No, it's not any worse than the wrong paletted metatiles to the right of SMB3 which is why I put bugs in quotation marks. I simply found how those cases were handled interesting and I figured I'd report them to be on the side of safety. I also learned some things since updating many rows of tiles to the nametable is something I'm not too familiar with. In the future I suppose I'll try only report things that truly affect the end user's experience.
