The reason for the objections to DirectX in this thread is that Nullpomino is intended to be a cross-platform application. I think that's really all they were trying to point out.
Thanks. You mean the old one, coded by noobs in the eighties? If this is doable on C64, so is TGM. Remember folks, that's 1 MHZ. Smooth and awesome TGM (something like TI but without 3D) is achievable even on a 286/386. The TAP hardware is only 28 MHZ but TAP works great because it's properly coded. Like most older games.
Well, you can do a lot more when you don't have to run game logic. That said, i mainly said that in hopes someone would get motivated enough to make TI for the c64.
The video he showed was a noninteractive scene demo, which, while technically impressive, is not indicative of actual game performance.
The big problem in programming TGM-style for old-school consoles and home computers is not game logic, but actually updating a tetromino field of 10x20 blocks with different colours at 60fps. Most older Tetris games either don't update in 60fps (instead 30), or colour the existing stack in a single colour/hue. Other hardware limitations can be things like not being able to handle two simultaneous fields at 60fps or only allowing simplistic line clear animations. In comparison, game logic is peanuts. You can probably run TGM game logic on an ATmega microcontroller. You just wouldn't have any graphics or sound.
Honestly, I've never had performance issues on my years-old rig, so I don't rightly know what's causing issues unless you're being dumb like Kitaru's friend Joe and trying to run it on CentOS or something like that.
Oh oh oh oh, I was approaching this from a different angle -- only running game logic and no overhead on account of the operating system and other programs competing for resources.
Literally updating a tetromino field of 10x20 blocks is a pretty bad idea since you're going to need larger-than-necessary loops when you render it. It's better to just make your own block class with position and color and store the number of blocks in a byte, that way you could just loop through an array of blocks when you render them.
Have you programmed a Tetris clone for an old console (or for anything) before? A Tetris game that has a 10x20 well should to be able to update a field of 10x20 blocks in a frame. Splitting the updates between frames is lame, and doesn't allow for 0 line clear delay 40 lines. Situation: Stack has pieces in the vanish zone. User clears a line. Result: All rows have to be updated that frame. More on topic: I too suffer performance issues from NullpoMino on this laptop. I actually think programming for some "old school" console could be a good solution, because everyone could play it via emulators for whatever system they have. Is there any emulator with something like kailerra that's cross platform? Or can a kailerra emulator be run fine through virtual machines? If so, someone (maybe me) could make a great game for Sega Genesis, or SNES. Then someone, (not me) could host a server so people could find games easily without dealing with all the people wanting to play Mario Kart or whatever. Here are a few of my thoughts on the matter: 1. I don't care about TGM/TAP/Ti clones. So many things do a good enough job of cloning TGM/TAP (maybe not Ti) for so many different consoles/operating systems. I say good enough because... the clones don't have to be more perfect than they already are. If someone is THAT concerned about authenticity, they should play the actual thing. Naturally, this doesn't work for Ti. But... eh. I'm indifferent. 2. I do care about multiplayer. I like 20G multiplayer. I can't run NullpoMino on my craptop, and Blockbox makes me pay for custom games. 3. I dislike millions of options. Lots of Tetris clones these days try to make everyone happy. I actually KNOW what all the options do, and I still don't like them. I've had to spend much longer than I think I should have helping people who are used to things like facebook Tetris play NullpoMino with settings they enjoy. I'd rather play LJ65 than lockjaw for this reason. I'd rather play Texmaster than NullpoMino for this reason. I realize these games aren't really trying to appeal to the average user, but I sometimes find it frustrating too. tl;dr: If I made a Sega Genesis or SNES multiplayer Tetris game with two rotation systems (ARS and *sigh* SRS) and no bells and whistles, would anyone be interested? Think LJ65 with synchronized 2 player start/both players get the same piece sequence. Could a mac user and PC user play against each other with it? If no to this, there's no point anyway.
Like, I think he's saying you have a linked-list of Blocks so you only blit as many cells as are filled, but a) you still need to be able to do at least 200 blits per frame per field or else you're going to have trouble when the stack is nearly full, and b) you lose constant time look-up that way (which is certainly more to your detriment than cutting some loop iterations is to your benefit). You'd get more out making your rendering code only update dirty rectangles if you're running into trouble blitting everything to a blank buffer every frame.
It's the same either way. Your Tetris game has to be capable of blitting/updating 190 cells in a frame. (Topping out with one hole per row.) If your game will slow down anywhere NEAR the worst case scenario, your player WILL experience it. You've said it better than I could. For whatever reason, I assumed he was talking about old hardware (like NES) where you don't even have to draw everything every frame, but you still have to be able to redraw the entire playfield in a frame whenever it changes. You're right, that may not be what he meant and your arguments are better against that, then. But eh, I could be poor programmer, or also having a bad day. I'm probably out of line.
Even in a case like the NES where you update a tilemap and forget about it, the hardware is still drawing everything each frame. Anyway, to address the rest of your post: Oh god Kaillera please no don't. Really though, that doesn't sound like the greatest solution. Passing around key presses between players and trying to keep things synced is a bit silly when we can write our own dedicated netcode. If what you want is a nice game for local multiplayer on a dedicated console, I say go for it. Otherwise, I don't think this will adequately accomplish what we're looking for. Assuming we could emulate a different platform and get the desired results, that just means we had the resources to do it on the target platform plus the overhead for translating it from code for another machine. (inb4 Java jokes) Within the Nullpomino project, there is an ongoing rewrite that (hopefully) will make it a lot easier to address the issues being brought up in this thread. I know Java isn't the best choice for games, but it should definitely be able to do lagless Tetris and I believe that's something we'll be able to deliver when all is said and done. The rule/tuning systems have been a big problem with Nullpomino for a while now, and we're hoping to clean things up with this rewrite. Figuring out and cleaning up that mess should also enable us to hide things away if they're not something that you see unless you really want to tinker with them instead of having to deal with option soup spilled out across several different menus and programs.
Field size isn't irrelevant. Tepples ran into problems like these when writing Tetramino/LJ65 for the NES:
A field the size of the whole screen isn't going to push the limits of PCs, and in either case it isn't directly affected by the field size, it's affected by the number of on-screen tetrominos. If I have 9 blocks on the screen, I only need to render 9 blocks.
Ah, okay. I know nothing about console games, and I'm not sure how you'd optimize it for an NES. I'm not sure why you'd want to design it for a console that isn't portable though.
AS for the commodore c64, You could just use character graphics, and directly manipulate character and color memory and the screen will change the next time the raster beam gets there. you can rapidly transfer blocks of memory form one spot to another. It has built in routines for doing exactly that. The official one solely used color memory manipulation to move the minos. (They were all solid colors) And sadly, i think it still ran at 30fps. I suspect it was not very well written. In addition, you can actually read where the raster beam is, to do mid frame updates safely. Mino colors are a non issue on the commodore 64. And it would be easy to make the active tetromino a single sprite and rotate it by changing the pointer, but i don't think it will even be needed.
