Colludium's Forum Posts

  • — - I agree with your calcs when using large lerp values. For the case A = lerp (A, B, X), the lerp equates to A = A + X * (B - A).

    So, the lerp won't work correctly if the value that is added to A (which is X * (B - A)) is greater than the difference between B and A ( which is simply B - A).

    So, X * (B - A) must not be greater than B - A

    So, at the max value for X the equation becomes:

    X * (B - A) = B - A

    So max X = (B - A) / (B - A)

    max X = 1

    I think it's a good lesson (for me, at least!) that care should be used when putting dt inside a lerp in this way, because an inadvertent value greater than 1 will cause unexpected behavior.

  • Somebody - it has been an emotional 30 minutes! I went from total confidence in using dt to a horrific realization that I had to go through my game and edit my lerps all the way back to where I started.

  • Ashley / Aphrodite,

    The use of a = lerp(a, b, z * dt) to compensate for variations in delta time is correct. I've just crunched an example to illustrate this in LibreOffice Calc. The lines in the image equate the results from using lerp with dt for fps values of 60, 72, 120 and 144. As you can see, the end result after 1 second at each frame rate is the same (well, the same within a value of approx 0.002).

    The x axis is number of frames, so the right hand side of each drawn line equates to 1 second of time, the y axis is the result of the lerp using cell value for B3, for example =B2 + (1 - B2) / $B$1 where B1 contains the fps value. I am not a LibreOffice guru and couldn't figure how to stretch the x axis for each line so they would overlap....

  • If you're using Chrome, it's entirely possible that this could be an artifact of the vsync non-adherence problem. Does the same happen when running on the 120 Hz monitor but in NW 10.5?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I agree. Android users don't seem to expect or wish to pay for apps, whereas Apple users are quite happy for fork out less than the price of a coffee on an app. Android development holds no interest for me because of this - I probably sell 30x more of my apps on iOS than I do on android.

  • Thanks GenkiGenga!

    Update: 48 levels now completed. Some are easy and some are quite hard. I've got lots of tidying to do - instruction screens and the like, then I think I'm just about ready to put it in a store! One more give to the beta test team and then my excuses start to run out. Gulp...

  • PS - this plugin is outstanding. You realize that I am going to have to re-write my game to incorporate it!! Do you take beverage donations?

  • Hi R0j0, I just downloaded v1.7 and found it won't load in C2 - I receive the following error:

    [attachment=0:3pkc97lh][/attachment:3pkc97lh]

    When I edit out the extra " then it loads correctly - just a type-o. Strange no one else has encountered this, though... I'm running c2 r195 64 bit.

    Some great updates, by the way!!

  • This is why some sort of canvas / paster object would be really useful!

  • If you could obtain collision polygon slope gradient then that would be very useful....

  • I remember being a real pain and asking for a 30 fps option a while ago (or, more precisely, it became a 1/2 vsync render option when I understood how c2 runs in the browser). I don't think c2 is mech'd to be able to be able to successfully vary the dt and diverge from what the browser engine is doing. I might be wrong, and it would not be the first time, but but the last attempt to provide an option in c2 to run at 1/2 vsync was a proper failure (after much nagging by me and few others, I recall...).

    I would dearly love for us to have a fraction-of-vsync option, where game logic can take more time to do required maths before a draw call, but I don't think it is possible within c2.

    I see similar weird behavior on my embryonic game when I test it on an old laptop - it's almost as if the event system breaks down under relatively high cpu load.

  • I think it's probably part of the bullet behavior.

  • What about something like Scroll To per layer? Could make for some interesting render possibilities...

    I have only a limited imagination and can only think that layer offset would be useful if you're looking to control your own parallax (nothing wrong with that, so +1 here), but only if the default parallax has to be opted out from.

  • Ashley - they were my thoughts too, so I added a comment right after posing the above. I'm in the notice distribution list as well and that bug report has been quite quiet for a while...

  • Ashley, here's the image from the very latest Canary - updated this morning! I'm guessing that spike is at around 20 ms vsync...