Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

increasing fps also increases rain falling speed #27

Open
deathtrip opened this issue Apr 10, 2021 · 13 comments
Open

increasing fps also increases rain falling speed #27

deathtrip opened this issue Apr 10, 2021 · 13 comments

Comments

@deathtrip
Copy link

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
Copy link
Owner

M4444 commented Apr 11, 2021

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
Copy link
Author

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
Copy link
Owner

M4444 commented Apr 12, 2021

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
Copy link
Author

i'll try it in the coming days

@deathtrip
Copy link
Author

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
Copy link
Owner

M4444 commented Apr 20, 2021

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
Copy link
Owner

M4444 commented May 6, 2022

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

@deathtrip
Copy link
Author

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
Copy link
Owner

M4444 commented May 11, 2022

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
Copy link
Author

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
Copy link
Owner

M4444 commented May 24, 2022

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
Copy link
Author

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
Copy link
Owner

M4444 commented May 27, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants