Open deathtrip opened 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?
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.
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.
i'll try it in the coming days
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.
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?
The newest version has fractional falling speeds. Can you test it out and see if it makes any difference?
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.
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.
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.
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
?
I think smooth
would be the better name. How about setting 60 steps as the default ? It's the refresh rate of most monitors.
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.
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
.