1. 24

  2. 7

    Hah, I watched this the other day and seriously considered submitting it but didn’t know if it would fit here (in retrospect it’s obvious that it would). Thank you for submitting it!

    That channel in general has great content if you’re into that sort of thing.

    1. 6

      You’re welcome! :)

      One of the things I’m consistently impressed with is the visualization of the NPC behavior, measurements, and so forth. I kinda wonder if the author is using custom code for that.

      I think it’s also kinda neat seeing how gross some of the code is (inline checks for enemy type, etc.). It’s a humbling reminder for folks that fret over polishing their source too much.

    2. 5

      Delightful. Alternative solution: Instead of doing current time + 100 ms do last fire time + 100 ms. I THINK that would make it so that if your math accidentally calculates + 101 ms you would catch up on the next frame. You might have occasional single-frame glitches in firing rate, but it should correct itself. If I’m phrasing it right; I haven’t had coffee yet. You can also change the timing code from if(last_time + dt > current_time) { do_stuff } to while(last_time < current_time) { last_time += dt; do_stuff } and with some interpolation it catches up on its own.

      Using floating point numbers for times is dangerous! This is why modern timekeeping API’s tend to do integer seconds + integer nanoseconds. (Rust’s Duration is the one I’m most familiar with, but there are others.)

      1. 1

        Yeah this is ideal. It is similar to Bresenham’s line algorithm. It works really well for keeping the average rate of events exactly on track. Using this also lets you make things happen at the right rate with a non integer period too.

        Using floating point numbers for times is dangerous

        Yes. Perhaps they could have used simulation ticks (or milli-ticks) as their time unit? Then everything would be exact integers that seldom do anything very strange.