I've made simple camera movement, before facing this framerate dependent problem.. Camera was changing it's tilt - depending on forward/backward movement and roll - depending on left/right movement. I used the input forces (dist.x and dist.y), to see whatever player moves (which direction), but I'm not sure, will this approach work with what I want to archive.

I still can't get it.. Why it's framerate dependent???
I use time step, I did not use "accelerate"!!! But still, camera rotation depends on the framerate? WTF?

I'm trying to find what makes it framerate dependant but it's hard because I dont understand what you are doing in some places withough further explanation.
What are you using this part for? What is it supposed to do?
maxv(1 - time_step * 0.9, 0)
I understand you get a fraction of 0.9 (depending on framerate) and subtract it from 1, giving you a result between 0.1 and 1 as long as fps dont drop below 16. But what is that part being used for?

EDIT:
I think the problem is that you are using time_step too much in too many steps along the way. If you multiply by time_step two or three times along the way it's value will diminish/aughment exponentially, you are not really multiplying by time_step anymore, instead you are multiplying by time_step squared or cubed resulting in it getting exponentially smaller the smaller it is, thus being framerate dependant again besides using time_step
(in fact now it is even more framerate dependant than if you didnt use time_step at all, now it is exponentially frame rate dependant which is much worse)

EDIT2:
My advice would be to modify this in one of two ways:

#1. Don't use timestep at all in your calculations, do all the math for speed, acceleration, etc withough considering fps. And at the end multiply the result of everything once with timestep.
speed = x+y/z bla bla bla
accel = x+y/z bla bla bla
cam.pan += (speed+accel) * time_step

#2. or option 2 would be to do all the independant calculations separately using time_step but when combining results do it directly withought time_step. That way you make sure each component was only multiplied byy timestep once along the whole way to the result:
speed = (x+y/z bla bla bla) * time_step
accel = (x+y/z bla bla bla) * time_step
cam.pan += speed+accel

NOTE* in my programs I prefer approach #1 since the code is cleaner, easier to read and modify later, and faster since there will be less multiplications involved. Just keep in mind a general rule, once something has been multiplied by time_step never multiply it with time_step ever again (or anything that has been calculated using it).

Thank you man for your time, I guess I got the problem that I had.
And plus to that, I used time_step probably too much, as you've said
Here is the fixed version, is anyone will need this (with your first solution):
Thank you once again for your time and help! I appreciate it!

No problem, I have been helped alot these past years in the forum and always try to give something back whenever I can (at least for issues I think I have the necessary knowledge and feel comfortable/confident giving advice with).

Your new code seems very solid in general. But there is only one part that concerns me (having the time_step variable modified by a minv() function). By putting your time_step inside minv() you make the code ignore framerate in some cases (in my opinion the wrong cases), which could lead to problems due to low frames per second because time_step=16/(average_fps);
I understand placing time_step inside a "maxv(x*time_step,0.001);" instruction because of dangerously high fps, but I don't recommend time_step inside a minv() instruction.

Explanation:
Early-on when I started to use 3DGS I had some problems with time_step. I started making simple games for my friends (flavored with in-group humor about our own lives, but very dumbed-down due to maximum 2-4 weeks of devolpment).
Since they were aimed at friends and their varied system configurations, (fortunately?) I soon was forced into learning to use time_step prematurely.
But unfortunately, simple games = potencially extremely high frame rates for any high-end systems, and with higher fps rates you get lower time_step values. This was a problem because the most commonly used Lite-C in-built variables use a "fixed" data-format, which have a default weakness...
Lite-C's commonly-used data-type "var" are "fixed" and they only have a precision of 0.001 due to their 3 decimal limitation.
Even when using alternative methods (like the "round()" funcion that gave me an extra 0.0005 precision), whenever a player (or the camera) had a movement or rotation lower than 0,001 (per frame) due to using time_step... the player (or camera) would not move at all because a "fixed/var" would consider it as "zero" (result<0.0004999... = 0.000)!

Basic "work-around" and reasons:
After many problems, I started to use something like "maxv(((bla+bla-bla)*time_step),0.001);" to make sure that high frame rates would never produce results that end up in "rounding to" 0.000... Until you are comfortable with using "frame rate independant" programming I recommend you take this simplified aproach whenever using time_step (and even after growing accustomed to fps-independant programming this can still remain a totally viable option).

Why your "minv()" function concerns me:
For the reasons stated in the above sections I have sometimes felt the need to use "maxv(x*time_step,0.001)" functions as a precaution in cases where there could potencially be extremely high frame-rates (to prevent un-wanted "zero values"), but I have never felt the need to combine time_step with "minv()" when there are low frame rates. There could potencially be high frame rates that produce results below 0.001 causing serious problems (data-precision limitations being rounded mathematically to 0), but low frame rates (below 16 fps) would produce time_step values above "1.0" and that should not be problem.
Remember that extremely high fps can produce low time_step values below 0.001, but extremely low fps produce higher time_step values above 1.001! Withough "maxv()" high frame rates could result in values below "0.000..." making your game "virtually freeze (mathematically)", but low fps only accelerate your game above 1.0 "time_step" values enabeling it to "catch-up" and compensate for the time lost.

Conclusion:
Im my opinion "minv()" is never needed with time_step (to compensate fps differences) because your game movement/rotation will just speed-up the movement-per-frame to compensate the extremely low fps. And limiting the higher time_step values (that low fps produces) in these cases will only prevent the needed (extra) fps compesation, so you would only be causing it to slow down exessively when it shouldn't!
But "maxv(x,0.001)" could be used as a "simple" solution in case the fps are too high, to prevent the game from slowing down too much (under 0.001) to compensate the high fps, because if there are too many frames-per-second the movement each frame would be very little to compensate for so many frames, resulting in it being "rounded to" 0.000 (if it is too small) and "freezing" the game. So for high fps you really would need "maxv()" to avoid your game's values*time_step from "freezing" to zero.

If you didn't understand some of things above, keep in mind that (if I remember correctly) time_step=16/fps;
If necessary re-read the whole post keeping in mind this formulae.

After initially using "maxv(blablabla*time_step,0.001);" with "vars" for some time, I then started to understand the advice I was given from other users on the forum and instead "transformed" all my local variables involved in movement and rotation to more precice data-types like float. Understanding how time_step works and combinig it's results with these (more precise) variables enabled me to have more "acurate" and less noticeable "jumpy-effects" in my rotations and movements.
And when you are more confident with using the basic "maxv() and time_step combination" I recommend you substitute them with "time_frame and max_fps" and read further into the manuall about these and other related functions/variables like time_smooth and time_factor to fully understand how all these crazy "fps-independant" things work together and what is the best combination for your specific needs.


I know this is a long read, but a similar post helped me feel comfortable with all these things

This was actually a nice read man, thank you one more time! I got the idea with "maxv", I'll give it a try now.

The very first problem with framerate independency, was fixed this way:
All other stuff as well. Thanks all.