Please read this fully before providing solutions as I've already gone to a ton of different projects and discussion boards trying to find one that's already solved this
I've recently made a small project messing with deltatime and a lot of other ways of going around scratch limits (https://scratch.mit.edu/projects/935282742/) and right now deltatime has been working for the most part but when I go beyond 30 fps in turbowarp however in the game I want a one frame dely (in 30 fps) whenever you fire the main weapon and have said delay feel exact when used in 60 fps and beyond whoever no matter what it always feels twice as fast along with movement just feeling weird and occasionally jittery (That last part I don't know if I should blame that on delta time or if it's just me imagining things)

I've tired:

• Using different ways of calculating deltatime from griffpatch's 3d raycaster and the one found on the scratch wiki
  Alternating between using days since 2000 and the timer
  Having a wait 0 seconds block
  Having a wait 0.033 seconds block
  Having a repeat block repeat wait zero seconds depending on the framerate
  Implementing that one “Dear game developers, stop messing this up!” video but putting that into scratch just caused movement to accelerate over time which obviously isn't what I'm trying to do
  

I've reached a bit of a dead end and finding anything regarding deltatime that covers more than just “Walk 10 steps but multiply it by deltatime” is really hard

nuggedboy wrote:

Please read this fully before providing solutions as I've already gone to a ton of different projects and discussion boards trying to find one that's already solved this
I've recently made a small project messing with deltatime and a lot of other ways of going around scratch limits (https://scratch.mit.edu/projects/935282742/) and right now deltatime has been working for the most part but when I go beyond 30 fps in turbowarp however in the game I want a one frame dely (in 30 fps) whenever you fire the main weapon and have said delay feel exact when used in 60 fps and beyond whoever no matter what it always feels twice as fast along with movement just feeling weird and occasionally jittery (That last part I don't know if I should blame that on delta time or if it's just me imagining things)

I've tired:

• Using different ways of calculating deltatime from griffpatch's 3d raycaster and the one found on the scratch wiki
  Alternating between using days since 2000 and the timer
  Having a wait 0 seconds block
  Having a wait 0.033 seconds block
  Having a repeat block repeat wait zero seconds depending on the framerate
  Implementing that one “Dear game developers, stop messing this up!” video but putting that into scratch just caused movement to accelerate over time which obviously isn't what I'm trying to do
  

I've reached a bit of a dead end and finding anything regarding deltatime that covers more than just “Walk 10 steps but multiply it by deltatime” is really hard

Hello, nuggedboy. This is a very nice project! You can solve this issue by recording the time when the last attack was performed and only starting a new attack if it is a certain amount of time after that timestamp. This can be done by adding a few blocks to your plyrAttacks sprite (changes are highlighted):

when I receive [startGameLoops v]
set [lastAttack v] to [0]//Resetting the last attack time variable. This could also be done elswhere, but it needs to run whenever the flag is clicked or the timer is reset.
forever
if <(item (5) of [gameData v]) = [0]> then
if <<<key (item (4) of [gameData v]) pressed?> and <not <(item (4) of [gameData v]) = [lMouse]>>> or <<(truMouseDown) = [2]> and <(item (4) of [gameData v]) = [lMouse]>>> then
if <(wpn#) = [0]> then//The code below should only attack if the last attack was 1/30 seconds ago. This can be applied to other attacks as well.
while <<(truMouseDown) > (0)> and <(item (5) of [gameData v]) = (0)>> {
if <(timer) > ((lastAttack) + (0.033))> then
set [lastAttack v] to (timer)
summonAttack ([direction v] of (plyrCode v))::custom
end
}@loopArrow::control
else
summonAttack (([direction v] of [plyrCode v]::sensing) - (15))::custom
summonAttack ([direction v] of [plyrCode v]::sensing)::custom
summonAttack (([direction v] of [plyrCode v]::sensing) + (15))::custom
wait until <not <<<key (item (4) of [gameData v]) pressed?> and <not <(item (4) of [gameData v]) = [lMouse]>>> or <<(truMouseDown) = [2]> and <(item (4) of [gameData v]) = [lMouse]>>>>
end
end
if <key [1 v] pressed?> then
set [wpn# v] to [0]
end
if <key [2 v] pressed?> then
set [wpn# v] to [1]
end
end
wait until <not (item (5) of [gameData v])>
end

For some reason the scratchblocks glitched out and I couldn't put a comment on the code that I wanted to lol.

Anyways, let me know if that helps

N8_D_GR8_1 wrote:

nuggedboy wrote:

Please read this fully before providing solutions as I've already gone to a ton of different projects and discussion boards trying to find one that's already solved this
I've recently made a small project messing with deltatime and a lot of other ways of going around scratch limits (https://scratch.mit.edu/projects/935282742/) and right now deltatime has been working for the most part but when I go beyond 30 fps in turbowarp however in the game I want a one frame dely (in 30 fps) whenever you fire the main weapon and have said delay feel exact when used in 60 fps and beyond whoever no matter what it always feels twice as fast along with movement just feeling weird and occasionally jittery (That last part I don't know if I should blame that on delta time or if it's just me imagining things)

I've tired:

• Using different ways of calculating deltatime from griffpatch's 3d raycaster and the one found on the scratch wiki
  Alternating between using days since 2000 and the timer
  Having a wait 0 seconds block
  Having a wait 0.033 seconds block
  Having a repeat block repeat wait zero seconds depending on the framerate
  Implementing that one “Dear game developers, stop messing this up!” video but putting that into scratch just caused movement to accelerate over time which obviously isn't what I'm trying to do
  

I've reached a bit of a dead end and finding anything regarding deltatime that covers more than just “Walk 10 steps but multiply it by deltatime” is really hard

Hello, nuggedboy. This is a very nice project! You can solve this issue by recording the time when the last attack was performed and only starting a new attack if it is a certain amount of time after that timestamp. This can be done by adding a few blocks to your plyrAttacks sprite (changes are highlighted):

when I receive [startGameLoops v]
set [lastAttack v] to [0]//Resetting the last attack time variable. This could also be done elswhere, but it needs to run whenever the flag is clicked or the timer is reset.
forever
if <(item (5) of [gameData v]) = [0]> then
if <<<key (item (4) of [gameData v]) pressed?> and <not <(item (4) of [gameData v]) = [lMouse]>>> or <<(truMouseDown) = [2]> and <(item (4) of [gameData v]) = [lMouse]>>> then
if <(wpn#) = [0]> then//The code below should only attack if the last attack was 1/30 seconds ago. This can be applied to other attacks as well.
while <<(truMouseDown) > (0)> and <(item (5) of [gameData v]) = (0)>> {
if <(timer) > ((lastAttack) + (0.033))> then
set [lastAttack v] to (timer)
summonAttack ([direction v] of (plyrCode v))::custom
end
}@loopArrow::control
else
summonAttack (([direction v] of [plyrCode v]::sensing) - (15))::custom
summonAttack ([direction v] of [plyrCode v]::sensing)::custom
summonAttack (([direction v] of [plyrCode v]::sensing) + (15))::custom
wait until <not <<<key (item (4) of [gameData v]) pressed?> and <not <(item (4) of [gameData v]) = [lMouse]>>> or <<(truMouseDown) = [2]> and <(item (4) of [gameData v]) = [lMouse]>>>>
end
end
if <key [1 v] pressed?> then
set [wpn# v] to [0]
end
if <key [2 v] pressed?> then
set [wpn# v] to [1]
end
end
wait until <not (item (5) of [gameData v])>
end

For some reason the scratchblocks glitched out and I couldn't put a comment on the code that I wanted to lol.

Anyways, let me know if that helps

I've been playing around with this for a bit and honestly thanks a lot, it was a really clever idea, however it didn't give me the result I wanted BUT!, I then tried out this alternate way of doing it with days since 2000:

when I receive [startGameLoops v]
set [lastAttack v] to [0]//Resetting the last attack time variable. This could also be done elswhere, but it needs to run whenever the flag is clicked or the timer is reset.
forever
if <(item (5) of [gameData v]) = [0]> then
if <<<key (item (4) of [gameData v]) pressed?> and <not <(item (4) of [gameData v]) = [lMouse]>>> or <<(truMouseDown) = [2]> and <(item (4) of [gameData v]) = [lMouse]>>> then
if <(wpn#) = [0]> then//The code below should only attack if the last attack was 1/30 seconds ago. This can be applied to other attacks as well.
while <<(truMouseDown) > (0)> and <(item (5) of [gameData v]) = (0)>> {
if <(days since 2000) > ((lastAttack) + (0.00000099))> then
set [lastAttack v] to (days since 2000)
summonAttack ([direction v] of (plyrCode v))::custom
end
}@loopArrow::control
else
summonAttack (([direction v] of [plyrCode v]::sensing) - (15))::custom
summonAttack ([direction v] of [plyrCode v]::sensing)::custom
summonAttack (([direction v] of [plyrCode v]::sensing) + (15))::custom
wait until <not <<<key (item (4) of [gameData v]) pressed?> and <not <(item (4) of [gameData v]) = [lMouse]>>> or <<(truMouseDown) = [2]> and <(item (4) of [gameData v]) = [lMouse]>>>>
end
end
if <key [1 v] pressed?> then
set [wpn# v] to [0]
end
if <key [2 v] pressed?> then
set [wpn# v] to [1]
end
end
wait until <not (item (5) of [gameData v])>
end

And after doing this it's mostly what I wanted after swapping between 30 fps, 60 fps, and 250 fps. But there is still a subtle increase in speed of attacks being fired when bumping up the frame rate. And when firing from a long distance and checking the “plyrProj” list there's visibly more being created more on higher framerates still albeit still VERY VERY close to perfect. Not sure what else could be done but this feels like we're getting somewhere

Actually scratch that, I'm realizing the extra shot being fired is likely just the fact the attacks are moving slower at higher framerates due to the deltatime I've got setup at least I think so, I found another post after making this one on getting fixed deltatime (https://scratch.mit.edu/discuss/topic/421102/) so I'll try and implement that to see if it helps. Thanks a lot for the help! If there's anything I got wrong with what I just said though feel free to correct me ^-^

I hear you have a fix, but i'd like to add some details that fix some inaccuracies that haven't been covered yet.

Currently, every time you fire a bullet, you set lastAttack to the current time. This will cause variation depending on the framerate, because even though you want to fire every 1/30th of a second your system has to wait for the next frame to start to fire a bullet, which can take longer for lower framerates. Fixing this comes in two parts: updating lastAttack properly and pre-advancing the bullets.

To update lastAttack properly, all you need to do is advance it by 1/30th of a second, instead of updating it to the current time (most of the time). This accounts for the possibility of shooting two bullets in one frame on low framerates since you will repeat this check and advance by 1/30th of a second until you surpass the current time, and additionally this method allows you to fix any jittering in the bullet pattern by adjusting their firing position.

Sometimes, especially on lower framerates, the bullets won't come out evenly due to frames limiting which times it can fire. To fix this, you need to know the exact time it was supposed to fire (as opposed to the current time), then when you fire the bullet, pre-advance it by the amount it would've moved between the time it should've fired and the current time. This is where the new method for updating lastAttack comes in handy again. Since you advance it by 1/30th of a second instead of just setting it to the current time, there is a difference between the current time and the time the bullet should fire. This difference is how much time the bullet should already have been moving. So for example (using timer for clarity) if lastAttack is 5.5 and the current time is 5.6, then when the bullet fires, it should have already moved 0.1 seconds worth of its speed on spawn.

If you have any questions just let me know.

DEMO

Sorry for the two week delay in responding life has been a little crazy but here's what I've gotten done so far: https://scratch.mit.edu/projects/1325349751/

The code I ported over can all be found under the “plyrAttacks” sprite and are all next to one another.

I managed to get it working just fine despite my project not utilizing clones, although something I'd like to ask is I noticed both on your project and mine when putting the speed of the bullets really high (400 for example) and you keep firing continually they seem to sometimes not be consistent on where they move and it looks pretty jittery, I don't know if this is just how deltatime is supposed to make this happen or if it's an actual problem that needs to be fixed so if you have any insight on that it'd be really helpful! Also thanks a lot for the help you've given

This is an unfortunate result of using deltatime. When everything moves based on frames rather than time, the amount of movement between frames is consistent. But when switching to deltatime, the time between frames is not perfectly consistent, and therefore neither is the amount each projectile moves. When using frames, you're seeing the outcome after 1 frame, 2 frames, 3 frames, but with deltatime you're seeing the result after 0.101s, 0.205s, 0.298s, which gives the jittery look. I'm not sure if there's any way to make it look better, though there probably are some.

Increasing FPS is one way to make it less noticeable. Scratch is more of the odd one out when it comes to game frame rate, many target 60 in current times.

Another way is to return to a fixed time step but vary the number of frames to make it consistent over time. This comes with its own visual issues though as the only way to maintain real time speed is by skipping or running multiple frames at once.

Thanks for all the input, I probably need to do some more research in other game engines to get what I'm going for. Then again I'm still curious as to what miracle work was done on vectoid 3d for that games deltatime to work so well, then again I don't have the knowledge or time to look in that project and find out what he did there. I'll still be testing out different solutions and figuring out if this can truly be solved but I'll leave where's we've gotten here for now and close this topic.

If there's anything though that any of you thinks deserves my attention just check out my limitless engine project alongside the deltatime test project on my profile as that's where I'm trying to figure this all out and comment whatever you feel is needed.

Again thanks so much for the insights and help and this really has all helped me greatly!