Realtime Indiscrete Simulation Engine
Fetching latest commit…
Cannot retrieve the latest commit at this time
RISE Realtime Indiscrete Simulation Engine ...what does indiscrete mean? It means RISE does not operate on a discrete time grid. Unlike most game engines, it does not work by iterating the positions of each object every frame and checking for interactions. Instead, it schedules the interactions ahead of time for the exact time they will occur. Most game engines that claim to be framerate-independent justify that claim by integrating the velocity of their objects over the length of the frame, but they still do collision checking once per frame, and so with low framerates they tend to exhibit physics errors. However, RISE is 100% framerate- independent.* That's because there are no frames except for rendering purposes, and rendering does not affect the movement of the objects. This means that physics in RISE are always just as accurate as they were programmed to be. To put it another way, timing in most game engines is accurate to about 1/60th of a second; timing in RISE is accurate to about one microsecond. Does that make it harder to program with RISE? Slightly, because the movement of objects must be described mathematically instead of by incrementing values every frame. However, you can still set periodic timers on your objects to have them exhibit behavior once every fraction of a second, which you can use if you wish to program your objects in a more discrete style. ===NOTICE=== This engine is under heavy development and its API is completely undocumented and may change without any warnings. Use at your own (in)discretion. ============ Advantages of an indiscrete engine: - No framerate-dependent physics glitches. Small or fast-moving objects never pass through one another. Objects do not have to compete for collision priority. - An indiscrete engine allows recovery from slowdown. After slowdown, the engine "fast-forwards" back to realtime. whereas a discrete engine would lose those frames and would stay behind realtime forever. This does not help, of course, if the CPU is consistently too slow to simulate events. - Better algorithmic efficiency in many cases. In a discrete engine, collision checking for n interacting objects requires n²*fps/2 checks every second, while in an indiscrete engine it requires on the order of n*m*2*s checks, where m is the average number of interactions per second, And s is a small constant (generally less than 2) related to the sloppiness of the event scheduling system. Take for example the examples/bouncing program: there are 200 squares that are moving around. In this situation, there are a very large number of interactions per second. However, upon review profiling data, I found that collision checks were performed less than 600,000 times per second, whereas if they were all performed every 60th of a second, there would be 1,200,000 checks. This is not the whole story; the fact that an indiscrete engine requires entirely sweeping collision tests means its checks take longer than a disrete engine's naive overlap tests. However, using overlap tests can cause the corners of rectangles to miss one another. If you were to implement physics in a discrete engine as accurately as in an indiscrete engine, it would fall behind in performance. There are some cases in which an indiscrete engine has worse algorithmic efficiency. When one object interacts simultaneously with each of a group of n objects, in a discrete engine it takes O(n) CPU, but in an indiscrete engine it takes O(n²) CPU unless the objects are being destroyed. * Currently, this is not quite true, because realtime input is not implemented and so input timing may change based on rendering framerate. Eventually this will be fixed, and at that time RISE will be truly 100% framerate-independent.