M4444 / TMatrix

Terminal based replica of the digital rain from The Matrix.
GNU General Public License v2.0
380 stars 14 forks source link

increasing fps also increases rain falling speed #27

Open deathtrip opened 3 years ago

deathtrip commented 3 years ago

Currently the default value for --steps-per-sec of 10 looks choppy. But when you set it higher, it also raises the rain falling speed, separately from the -fall-speed setting. At 60 steps you cannot even see the characters properly, because they fall so fast, even if you set -f 0,1.

M4444 commented 3 years ago

Well the fall speed property is in units of steps so it's relative to the steps per second property. This could probably be better explained in the help section.

Is there a specific behavior you are looking for configuring?

deathtrip commented 3 years ago

I want the smoothness of 60 fps, but without the insane speed. But the minimal speed of 0,1 is way too fast. I think accepting fractional values for it would solve the problem.

M4444 commented 3 years ago

I don't know how smooth 10 changes per second can look. The frame rate could be increased to always be 60 fps, though my guess is that rendering something 5 times more that in needs would just make it costlier but it doesn't hurt to try. If anything the issue probably lies in the exact sync between app, terminal and screen and I don't have an idea how this would be addressed other than empirically. Of course, the amount of processing can also have an effect. I added a small optimization and also put up an experimental branch with 60 fps always set and if you would like you can test it and help me dial it in. It would also be useful to test out --no-fade mode and compare if it makes a difference. Do you have the means to compile from source or would you like me to provide the executable too?

As for the fractional speeds, this is already in the works, though as a separate idea from this.

deathtrip commented 3 years ago

i'll try it in the coming days

deathtrip commented 3 years ago

I tried the 60 fps version, and it has the same problems {as described above) as the release version. I think the only solution to this is to decouple the fall speed from the number of steps taken.

M4444 commented 3 years ago

They are kinda decoupled in the 60 fps version so I don't know what better thing you have in mind and why do you think it would work if this didn't?

M4444 commented 2 years ago

The newest version has fractional falling speeds. Can you test it out and see if it makes any difference?

deathtrip commented 2 years ago

Just tested it, and now i can get the desired falling speed at 60 fps. Next step would be to remove the frame rate cap completely.

M4444 commented 2 years ago

Oh that's great! You can apply this diff to try out how it looks without a frame rate cap. I'm curious what settings you'll find best looking. Maybe it can be added as a new mode.

deathtrip commented 2 years ago

After short testing, it seems to be working well without the frame rate cap. As for settings i found tmatrix -s 120 -f 0.1,0.3 or even tmatrix -s 120 -f 0.01,0.3 to be the best looking. Basically the more steps/fps, the lower you have to set the falling speed.

M4444 commented 2 years ago

Setting the speed to 0.01 is actually the same as 0.1. The speeds are meant to be in increments of 0.1 and accepting 0.01 was a bug. It's nice that you found it, I pushed a fix for it.

What do you think about adding your setting as a new mode (tmatrix --mode=X)? What would it be called? Maybe fast or smooth?

deathtrip commented 2 years ago

I think smooth would be the better name. How about setting 60 steps as the default ? It's the refresh rate of most monitors.

M4444 commented 2 years ago

Ok, I'll add the mode and credit you if you're ok with that. As for setting it to 60 steps, I'll have to think about it more because to maintain the same speed it would have to be -f 0.1,0.3 which has a bit less variety than -f 0.5,1.5. But the smoothness does seem to make a lot of sense.