Add Deltatime.js

[XeroName]

Hello, I would like to ask if I can add Unsandboxed Extension at TurboWarp.

Extension description : A soft, precision Delta Timing blocks with adjustable filter.
Credit : whole code and cover/icon image made by myself.

Thank you.

[XeroName]

Sorry I forgot uploading screenshot of blocks.
Here's the screenshot when Deltatime extension loaded :

[LilyMakesThings]

God-tier extension, not gonna lie :O this solves a lot of my problems! (ﾉ◕ヮ◕)ﾉ*:･ﾟ✧

[XeroName]

So much appreciate it.

Recently, I started using quite of extensions to my game, and most of that are yours such as "Temp Vars" and "Comment blocks".
I'm really happy with those cool functions and would like to say thank you!

[XeroName]

Oops, seems I forgot some of process before to merge extension.

I've just edited images/README.md and website/index.ejs files.
Sorry for about that and would be thankful to point out if I still missed something. 😀

[GarboMuffin]

thank you for your patience, will try to get this in tonight

[XeroName]

Much appreciated it! 🎉

[GarboMuffin]

What is the point of the getTimeRes block?

[XeroName]

What is the point of the getTimeRes block?

Based on my experience, "Deltatime" and "FPS" block used at many cases of with operator blocks, so I thought those blocks are needs to be short length and easy draggable to user's convenience.

That's why Dt and FPS blocks are separated, while getTimeRes block is for users who want to change target resource easy and instantly.
Functionally works same with Dt and FPS blocks.

Seems that getTimeRes block is unnecessary, so willing to hide or remove that block if anyone suggests.

[XeroName]

This is the screenshot of Deltatime v1.2.2

[True-Fantom]

Hello! I have recently returned and I want to share my impressions about the new extensions :)

I really like the idea of expansion, considering how laggy TW can be, it will be very useful, especially with the box 2d extension. But I also found the cons. I have several suggestions and one bug found.

I'll start with a bug: dt cannot be greater than 1 (or immediately equal to infinity). if the FPS of the project is equal to 1, given the TW prolags, the project will still run slower than at high fps. And since you can set FPS less than 1, it's really important. Also, at low values, dt clearly loses accuracy, which is also a problem. I do not know if it is possible to change everything, because I still do not have time to dig into the code, but in theory it is definitely possible.

Next, the main offer! Add a dt limit. This mechanics is in Construct 2, where the maximum value of dt is 0.2. This is done so that objects dependent on it do not teleport through walls and so on. Setting a fixed limit would be unpleasant, but adding the ability to set it at will would be nice. There will be 2 blocks in total: set dt limit & dt limit. By default, it can be set to infinity, 1 or 0.2 (you will need to check which will be more convenient).

This suggestion and bugfix will also solve the problem with the "FPS > 0" block, which will no longer be needed.

Well, and more: I really don't see the need for separate blocks for the filter and calculator. Yes, they help to use dt, but in my opinion they still clog up the palette more, because they are VERY easy to recreate. If I were you, I would still remove them.

[True-Fantom]

I realized what the problem was! This line is to blame: vmFPS = Math.round(1000 / frameTime);
If you remove the rounding, dt will work stably. In this case, the FPS will also not be whole, but I think that this was originally supposed to be the case, if you need to round them, it's better to do it manually, instead of additional extension editing.

[XeroName]

@XeroName I might be using it the wrong way but a lot of people who told me how to use delta time they show me a pic and they did not even try it.. can you please explain this wonderful block in a picture? that will help me a lott!

Deltatime is commonly used to fairly compensate for differences in computer performance.

As FPS increases, the ΔT value will be decreases as opposite and same at vice-versa.
You can use it just multiplying ΔT value to originally purposed value to move/rotate sprite.

This video may be helpful : https://youtu.be/rWtfClpWSb8

[Azulcat]

thx

[True-Fantom]

@XeroName Hello again! I hope you haven't forgotten about me in all this time :)

Unfortunately, I did not manage to solve that very problem in one day, and then many "distracting" events followed that did not allow me to write earlier. Anyway, during all this time I gradually developed the extension and as a result I got a completely new version unlike either yours or my old one. Here is a screenshot:

But despite all this, I could not solve the original problem. I have seen your solution, but to be honest, it seems to me very crutchy, and can cause a lot of misunderstandings among users who do not read the documentation. I thought and experimented for a long time and eventually came to the conclusion that it is impossible to make a filter that will carefully preserve the original values by simply feeding them in a different form. Moreover, I don't see the point in it. After conducting some experiments, I realized that the "noise" for which the filter is needed perfectly fits with the actual frame changes, giving failures only due to the limitations of the length of the number in JS. And when using the filter itself, on the contrary, strong errors appear, which largely depend on randomness.

I'm writing about this because I think I'm missing something. Does the filter have any really useful properties that make it necessary to include it in the extension? Because so far I only find bugs.

PS: When I tried to fix everything, I got this version, but it also did not bring any benefit and was not completely stable:

In any case, although you were not against adding my alternative version, only one will get into the gallery, so I suggest discussing all our solutions and coming to one common extension.

PPS: I have also started making extremely detailed documentation, but it has not yet been completed and is a bit outdated. I will return to it when there is a ready version of the extension. In the meantime, here is this sketch: https://true-fantom.github.io/docs/deltatime.html (It's really very broken, but I'll fix it!)

PPPS: It is also possible to say in advance about the expansion design (block colors, text, block layout, etc). In my version, all this corresponds to the Scratch 3 style as much as possible, and therefore, despite the fact that I am quite open to changes, I would like to keep it. I picked up this color for an hour ._.

[XeroName]

@True-Fantom
Hello Fantom.

The filter topology I've used is for smooth phase-changing of FPS and Dt, not for precision.
As you talked about, for precision, there should be no filtering at that values.
Although the standing reason of the filtering blocks are there may be a people who wanted.

For example, there may be some situation to prefer stability of value instead of precision.
Simply thought by graph or text display like FPS meter, which requires visibility first.
In these cases, fluctuating values even with superb precision, is likely less prefered than the stability of value because it should be easy to read, being compared and recognized by human.

Yet except upon situation mentioned, the user who using extension still have the option to compelety turn off the filtering by setting Filter Strength by 1, which will focus on updating time and precision hang on with noise.

I do not big brain at mathmatics or calculating, etc and have not much knowledge about programming.
Most of user who decided to use Deltatime extension may be same with me.
They do not need ultra precision FPS or messy other options causing headace. (Otherwise would not use Scratch or TurboWarp!)
The functions who wanted by people like me may simple, easy to use and flexible at many applications.

Conclusion is that filter gives an option to choose precision or smoothing of deltatime values.

And I'm almost new at Github, have no idea why this is still in not approval(maybe there are something I've missed).
So maintaining this extension honestly makes me tired.
If you're ready to open your own deltatime extension, I'm ready to close this PR.
Do not mind me, make your own extension and even you don't have to mention me at any credits.

I don't know if I would being help you that much., but always feel free to ask something to me.

Thanks

[True-Fantom]

@XeroName Thank you very much for your reply!

I understood why the filter is needed, and I support the fact that users should be able to use it! But I think the filter should not work by default. And it would also be cool to be able to create filters on any user variables, not just on fps from the extension. So, I think the best option would be to create a separate filter extension, and write about it in the DT documentation!

And well, yes, you can not worry at all that this PR has not merged for so long. Most likely this is due to the fact that Garbo is either very busy at a normal job, or just really likes to relax ^_^

So if you like this solution, let's do as you said, I will make a new PR with a new version of this extension and a filtering extension. The only point: I insist that you be mentioned as a co-author, because without you this extension would not exist at all :)

Thanks!

[True-Fantom]

@XeroName Hm... I experimented a little and found out that the code of your filter is extremely easy to recreate, and it may even be useless to do a filter extension:

Also, all the disadvantages of manual re-creation can be eliminated using custom blocks:

Now I do not know what to do... Maybe just show this example in the DT documentation and that's it? What do you think?

[XeroName]

@True-Fantom
Removing the filtering blocks and showing an example how to make it makes sense to me.

[GarboMuffin]

Is the consensus to completely remove the filter for both delta time and FPS?

[XeroName]

Is the consensus to completely remove the filter for both delta time and FPS?

Yes it is.
I don't know that much detail but maybe @True-Fantom will recreate the PR about new deltatime.

[GarboMuffin]

Hey, thank you very much for your patience. I assure you, the delay is all my fault, not yours

I have slightly massacred this extension. More blocks can be added later

[XeroName]

You don't have to sorry to me. I've been some time to rest or other things to do waiting for this.
I can understand your situation managing whole TurboWarp and others.

What I concerned about is something mistake I made because I don't know how to use GitHub :)

Appreciate that this PR has been merged!
Thank you!

[True-Fantom]

@XeroName Hello! After so much time, I finally finished my PR!

As I see a lot of things have changed while I was away. I hope I did everything right with the new format.