search

tetrio / issues

Report issues and discuss improvements / feature requests around TETR.IO
https://tetr.io
405 stars 21 forks source link

Adjustable DAS & ARR (ms) #33

Closed julf0 closed 4 years ago

julf0 commented 4 years ago

DAS and ARR 100% adjustable in all ranges.

Like: DAS 0 ~ 333ms (20F) / ARR X ~ 83ms (5F) Unlike: DAS 17ms (1F)~33ms (2F)~etc.

alex-ong commented 4 years ago

Is the engine 60hz locked (i.e. is pressing a button for 80ms rounded to either 66.6666 or 83.3333?) If thats the case, ms ranges aren't possible until an engine overhaul.

o5k commented 4 years ago

The engine is frame-based, so this is not possible for now.

o5k commented 4 years ago

Reopening as I have an idea on how I might want to implement subframe inputs and DAS.

alex-ong commented 4 years ago

As long as you have a way of counting inputs subframe using JavaScript, you can queue them up for when draw time comes around and then process them in the right order. This is what jstris does.

If you have extremely accurate timers then you don't need to worry about pressing two keys on the same frame.

The main "innovation" is ensuring you process stuff like dassing sub frame and then tapback. If you've set it up right it should be possible ok low frame rate devices to das tapback with no visible wall touching frame. There will be a big of cognitive dissonance from desync of sound and keypress but if it's a small frame drop from 60 to 45 then it should be unnoticeable

o5k commented 4 years ago

@alex-ong The engine already does this (using its EventSource/Replay/RollingReplay system) but it'd not save the exact timing in the queue, so I'll add the exact timings (up to a certain resolution) and run DAS/gravity at that same resolution. While there will still be certain vsync (for example in the audio) it shouldn't be noticable enough to matter unless the frame drops as you said

alex-ong commented 4 years ago

Can't wait for jstris style input! Its one of the main complaints from the old farts who have gone through tf(40hz framelocked with timers in Ms increments that round. Lmao) to toj (60fps, silky smooth but no IRS/IHS and a 1 frame ARE) to PPT (variable framerate and variable are with inputs tied directly to framerate...) To jstris (completely decoupled)

itll still have input lag in a sense but if you have muscle memory of 100ms-then-hard-drop or whatever the fuck it'll actually work instead of over/undershooting

This is the exact issue Ms timing solves.

o5k commented 4 years ago

This is hopefully properly implemented and will go out in the next patch. Please let me know if it's still bad (or worse)!