tetr.js development thread

[UJS3]

Yeah, I think that's it then. Still not sure how to get a replay that only starts with DAS to wall some of the time though.

[simonlc]

Well I fixed the keys not resetting when you start a new game and a keys is held down. That shouldn't be able to happen, if it wasn't one of those two bugs. Going to add DAS loading during countdown so it instantly spawns next to the wall, like nullpo.

[simonlc]

Just added das preloading during countdown.

[FelipeMayrink]

I gotta say, the progress of implementing things in this game is pretty fast.
Nice work.

[UJS3]

You mentioned that the timer is inconsistent because it's framerate dependent. Is it just the displayed time during replay, or is the entire game sped up/slowed down? Is the timer during the sprint itself accurate?

I'm asking because I just destroyed my nullpo record, but I want to know the exact time.

[simonlc]

When you're playing, the timer shows the exact time it took you to clear 40 lines. When playing a replay, it goes through the same motions you did.

The framerate isn't a consistent 60 fps, it sometimes goes down, or up from that, meaning some frames are more than 16.66ms, and some are less. When playing this doesn't have any noticeable effect (unless it's lagging). When replaying the game you just played, the frames will vary differently than when you played. The time calculates how fast the replay took to play. So it's accurate, just not accurate in the sense that it's exactly how it happened the first time.

[UJS3]

That sounds like a very general issue which many frame based online applications would have to deal with, do you know how to solve it yet? Tetrisfriends replays are all kinds of broken, but one of the bugs seems similar to this. During asynchronous multiplayer you may win a game where you're nearly knocked out, but the replay shows you getting knocked out and losing.

I improved my personal best from 56.31 to 51.08  

[simonlc]

Good job on your PR. I have a few ideas on how to fix it, and I think I will log the time difference between key inputs. There is some inherit problems that come with that though, but I have a good idea oh how to fix that with the replays. Hopefully it works lol. I'm currently cleaning up the code a bit, since I added a lot of duplicate code, so once I get that done I'll try fixing it.

[insatiate]

The replay has to record timing info, but you're recording it by frame count obviously. Why not record it by timestamp instead? Then rather than synching up inputs to specific frames, you synch them to specific time-points. The replay will be a little more robust that way (if the playback lags up, it will compensate; if the original recording lagged, it will display true to the original input).

The only thing you really need frames for is ... well, nothing, but if you plan to implement ARS and synchro moves then frames is an easier way to do it.

[simonlc]

Some people (or person) contributed code to the project and now pausing is fully functional.

I recently got a new job, which should explain the absence of updates. Don't worry though, once I get some things sorted I'll be back on the project.

[XaeL]

When you're playing, the timer shows the exact time it took you to clear 40 lines. When playing a replay, it goes through the same motions you did.

The framerate isn't a consistent 60 fps, it sometimes goes down, or up from that, meaning some frames are more than 16.66ms, and some are less. When playing this doesn't have any noticeable effect (unless it's lagging). When replaying the game you just played, the frames will vary differently than when you played. The time calculates how fast the replay took to play. So it's accurate, just not accurate in the sense that it's exactly how it happened the first time.

Have u attempted to implement a frame-rate independent engine?

You can measure everything in MS (including das etc).

[simonlc]

I haven't yet, but that's what I will be working on before continuing working on replays.

EDIT: just to note though, you still wont be able to drop multiple pieces per frame and things like that.

[XaeL]

EDIT: just to note though, you still wont be able to drop multiple pieces per frame and things like that.

How often does Javascript poll input? I know for java it just goes in a huge queue. that way you can pick up like 10 harddrops in one frame (if u were hypothetically lagging...)

Though if u make it framerate independent, you should just play it with vsync off and pump it at like max speed (say 1000 frames/second)

[simonlc]

I'm not sure about how fast it polls, it possibly relies on the browsers implementation. For games and animations, javascript has an api that manages the drawing, and is a fixed 60hz. It's possible to redraw the game at up to 1000fps, though that would be terribly inefficient, and would serve no good purpose since your screen is still only drawing 60 frames. A much simpler way to separate the two would be to just call functions when an input is pressed, and draw at a normal 60hz. One problem with this is, like you mentioned, 10 hard drops in one frame.

[UJS3]

The problem in that case is lag. As long as inputs are never dropped, that might be the best behavior you can hope for. It sounds much better to me than unpredictable dropped inputs.

How's the new job? Are you a programmer?