Skip to content
This repository


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Realtime Indiscrete Simulation Engine

branch: master

Fetching latest commit…


Cannot retrieve the latest commit at this time

Octocat-spinner-32 examples
Octocat-spinner-32 src
Octocat-spinner-32 test
Octocat-spinner-32 README
Octocat-spinner-32 opttry
Octocat-spinner-32 outline
Octocat-spinner-32 proftry
Octocat-spinner-32 try

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.

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
 - 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.

Something went wrong with that request. Please try again.