Problems with bullet turning - behaves differently on devices (dt?)

0 favourites
  • 14 posts
From the Asset Store
This pack contains 10 types of bullet effects, with different shapes and colors.
  • I recently discovered (with some of my other games as well) some issues with my code. It must have started since I got a new, much faster computer.

    I believe that I need to add delta time somewhere on line 79? To make the code 'framerate independent'? I set out WayPoints that a car will follow. On my new computer, the turning is much more off, while on my phone, it aligns perfectly around the corner.

    If I do need to add dt, where does it need to be added, should it also be dt*6 like on line 75 and 77? I'm a little confused about this. I've read similar posts, but I often find it hard to apply explanations to my own situation.


  • If you're using behaviors, you shouldn't use dt in the events that utilize behaviors. Behaviors by default are frame rate independant already, so by using dt you're actually forcing them to become frame rate dependant.

  • Thanks for your reply.

    Someone made this lerp code for me a long time ago. I wasn't sure what all of that line of code 'meant' at the time, heck, still not even sure yet what the delta time part is for. But will the behavior change if I remove the dt*6 part? Or can I swap that part with something else (wouldn't know what though)?

  • Try replacing that with 0.1.

  • Actually in this case in a lerp it might be right to use dt, not sure. For the rotation you can try changing 200 to dt*12000 instead

  • When using lerp it should be lerp(Self.BulletSpeed,600,1-0.1^dt)

    change the 0.1 part to adjust speed of change , 0.001 for example will make it faster

    And yes, as the post above says line 79 should be rotate 200*dt degrees and since you are using delta time instead of 200 it should be a much higher number, try 10000*dt or more and see what works best

  • Thanks for your replies.

    oosyrag OK I changed '200' to 'dt*12000', I now have: Self.Bullet.Speed/dt*12000

    But it rotates almost instantly, so it's way too fast.

    Or does changing the other lines' lerp code (line 75 & 77) influence line 79?

    BadMario So used lerp(Self.BulletSpeed,600,1-0.1^dt) as you said, it accepts that line, but should it be exactly like that or did you mean that the 1-0.1^dt part is variable and you posted an example? So that it could be ranging from 1 to 0.1? And shouldn't it be 1-0.1*dt instead of 1-0.1^dt?

    I'm a bit puzzled by all of this. Sometimes it feels like I just don't seem to be able to understand code that's beyond a basic to intermediate level. I love making games but sometimes I have my doubts!

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • that part should be 1 - any number less than 1

    1 - 0.9 will be very slow

    1- 0.001 will be very fast

    so 1 - 0.1^dt only change 0.1 part to adjust lerp speed

    has to be ^ not *

  • Hey thanks, don't we need the ( ) characters for this somewhere in the code though?

    Anyway, after some testing;

    Self.Bullet.Speed/dt*12000 Is the part that makes the car turn 'instantly' - there's no smooth movement at all. Lowering it to for example dt*200 or dt*2000 doesn't appear to make any difference. 200 without the dt* part worked.

    Since I've got little experience with this, how should I proceed?

  • Well dt is the time between frames, so assuming you're getting 60 frames per second, dt*60 would equal 1, so dt*60*200 should equal 200, giving you the same result. What framerates are you normally getting on your devices?

    Edit: bullet.speed/(dt*12000) would make a difference

  • Funny enough I tried (dt*12000) before, I figured it would be necessary otherwise the calculation would do different things.

    Now with that (dt*12000) the turning is smoother, however it still turns very fast. It does seem to be smoothed though, it's just that it makes its turn within a blink of an eye. Ah yes, it also does a weird rotation around its own axis just before it heads to a waypoint. Also happens in the blink of an eye.

    I'm not sure what the framerates are on my devices, can I add a code for that in Construct? Anyway, I used to have a 6 year old PC, which at the time was already made out of second hand parts mostly. At that time I used a 60hz monitor, currently using a 144hz one with a very fast all new parts PC, built it about 9 months ago.

    As for the game, when I run it on that new PC, in debug preview it says I get 140-144 fps. It seems that the engine is limited to what your monitor can render?

  • Yes, the engine will try to run at your monitor/system's refresh rate.

    Regarding your problem, it's not clear what your exact issue is from the information you have given. If you could create a minimal example project and upload that it would be much simpler to help you.

  • Hey, allright, brought it down an example;

    To what numbers could I change the code to make sure the Car always turns the same way on different devices?

    It's a bit difficult to explain, I just want the car to always follow the same path regardless of the device's fps. With my old, initial code it would deviate on my new PC and not lign up with the road, sorta following a different route.

  • OK, so two things.

    Regarding the angle of motion to start - if your bullet speed is 0, it does not have an angle of motion, and then it defaults to -180 for some reason (left). If you set the speed by default to some small number like 0.1, it will be able to set the motion properly to 270 (up), but also immediately go back to 0 speed due to event 2. Then when you start moving again the correct angle of motion is already set.

    Second regarding the rotation speed, perhaps your original device was running at 30 fps to follow the road with /200, so the correct dt value would actually be /(dt*6000) instead. On both my computer (60fps) and phone (90fps) it now follows the road.

    However do note that this method of turning in general is subject to minor imprecision due to rounding errors and fps variations. You won't get the same exact result every time, but it should be enough to follow the road.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)