search

GregoryCannon / TetrisTrainer

A web-based tetris client that allows you to enter custom piece sets to practice builds.
46 stars 10 forks source link

60Hz Das on Firefox #41

Open finegeometer opened 7 months ago

finegeometer commented 7 months ago

Recently, the Tetris pieces have been moving significantly faster than normal. After a bit of testing, it seems that the pieces are moving at roughly 60Hz, or twice the maximum possible rolling speed. While fun, that's not exactly a realistic setting.

I don't recall exactly when I noticed this, but it was no more than a few days ago. This suggests the bug was either caused by your latest batch of commits, or by upgrading Firefox to version 122.0.

I play on Firefox. When I tried it on Chrome, the pieces moved at normal speed. I suppose it's possible that one of my browser settings is relevant, but I don't know how to test that.

Steps to reproduce:

As a side note, I notice that the piece movement is slightly inconsistent. In the testing strategy above, sometimes the seventeenth I reaches the left, and sometimes it doesn't. I suspect this inconsistency is also a bug, but I don't know if it's part of the same bug, or an unrelated bug that I only noticed because I was testing this one.

wikedawsom commented 7 months ago

Inconsistent behavior may make this issue hard to test, and also hard to track down. If you have any other browsers installed, does it do the same thing on those ones?

finegeometer commented 7 months ago

Inconsistent behavior may make this issue hard to test, and also hard to track down.

The inconsistency here is whether 16 or 17 long bars make it to the left, and in the precise locations where the others land. But if there were no bug, only five or six would make it to the left. So I don't think the inconsistency I mentioned should cause problems tracking down this bug.

If you have any other browsers installed, does it do the same thing on those ones?

Sorry, I only have Firefox and Chrome. As I said, I observe the buggy 60Hz DAS on Firefox, but the regular 10Hz DAS on Chrome.

After a bit more experimenting, I've noticed that adding a right tap into the experimental procedure above, just before the first bar falls, can cause it to revert to 10Hz DAS. I'm not sure why this is, but it might be a clue.

finegeometer commented 3 months ago

I think I've tracked down the issue. On my Firefox installation, KeyboardEvent.repeat always returns false, even when it should return true. As a result, the function handleTappedDirection in input_manager.js is being called far more often than it should.

To fix this, it might make sense to replace or augment the !repeat test with a check that the key is not already being held. This is, after all, closer to what the original game does.