1.0.Game Loop

[DanielBullimore]

Priority: 1

Depends:

Description:

Stable Loop, executes queued interrupts between drawing the "world". Drawing the world involves redrawing all the rendered objects to synchronize their GUI state with their programmatic states. Interrupts are generated by events and are intended to ether act (small immediate animations) or solve (change a instances properties). I envision the loop+interrupt relationship working like an appointment book, except the book is kept by the sun at the center of a solar system.

• That suns line of sight is static

• The sun only sees interrupts by appointment, but they must be on time

• Each page of an appoint book is normally divided into denominated appointment slots. For our sun those slots are its planets

• More than one Interrupt can queue on a single planet appointment slot

• Interrupts can not queue on the planet furthest from the sun, that slot draws the world

• The planets distances from the sun is determined by a benchmark run before the sun ever existed

• Each time a planet crosses the suns line of sight, the sun executes one interrupt.

• A solar year ends when the most distant planet crosses the suns line of sight it redraws the world (one frame)

As a result the sun can now deal with one off interrupts on a priority basses. A four planet solar system will see its closest planet 4 times before it sees its most distant planet once (complete iteration of the stable loop). Highest priority interrupts go on the closest planet and lower priority on more distant ones. As a cool side effect an HID interrupt on planet 1 might set an interrupt on planet 2 which could be executed before the solar year ends. It also allows 3 intensity settings for high frequency repeating interrupts.

So what I'm trying to do here is remove the time in exact milliseconds from the framework. The number of milliseconds each iteration of the game loop takes is dynamic per machine it benchmarks. So developers implementing my OoMutiny framework couldn't book an interrupt in 67milliseconds if a benchmark determined a 1000 millisecond loop because it wouldn't ever be executed. However if we benchmark two machines A and B. A scored 1000ms solar year (complete loop, 1 frame), B scored 400ms . Then we divide those scores by three to get the first planets cycles per solar year, divide by 4 to get planet 2, 7 for planet 3... Thus our developers can book an interrupt in "Cycles" on both machines confident that it will be executed in a timely and graceful fashion regardless of an individual client machines computing power. Real time can be derived in a Cycles per second benchmark. This one system quickly provides:

• Prioritization of immediate interrupts
• Intensity of high frequency interrupts
• scaled time critical interrupts over multi solar year runs
• Performance tailored to each client.

UML:

Properties:

numBenchmarkSolarYear - Protected number, interval in milliseconds between drawing each frame. (one solar year)
numCyclesPerSecond - private number,  derived value, effectively frames per second. Used to calculate realtime. 
rayMecury - public array, highest priority appointment slot for interrupts.  11:1 solar year
rayVenus - public array, medium priority appointment slot for interrupts. 7:1 solar year
rayEarth -  public array, lowest priority appointment slot for interrupts. 4:1 solar year
rayMars - public array, list of all the objects to render in the next frame.

Methods:

funBenchmark() - determines a stable interval in milliseconds for the users computer to run the game loop
funStartLoop() - initiates the game loop
funStopLoop() - ends the game loop
funTurnCircle() - set game loop intensity in milliseconds manually
funRedrawTheWorld - Renders one full frame by calling funRender() method of all the objects in rayMars

[DanielBullimore]

dividing the length of solar year by number of planets would cause eclipses. Not certain but Fibonacci might help ?

[DanielBullimore]

a 3,4,7,11 based fib sequence would not have any eclipses in a 4 planet system but maybe taking the solar system description too literal

[DanielBullimore]

However if we benchmark two machines A and B. A scored 1000ms loop, B scored 400ms but both machines also scored a 5 planet system. Then we divide both scores by 5 to get a planetary cycle: (Machine A) 1000/5=200ms Cycle (Machine B) 400/5=80ms Cycle; Thus our developers can book an interrupt in "Cycles" on both machines confident that it will be executed in a timely and graceful fashion.

After close consideration, I am thinking every system should have the same number of planets. Dynamic solar systems would make programming needlessly complex for developers who implement the OoMutiny framework. And the bench marked loop timings will still provide tailored performance to individual machines.
Also modeling fib sequences for the different planetary denominations is a total time burner. 3,4,7,11 works lets run it.

[DanielBullimore]

My Current version of OGameLoop UML

[DanielBullimore]

Sanity check passed

[DanielBullimore]

I've had to implement the four planet arrays with in a multi-dimensional called threads. I've done that so I can iterate through it without using the name of a planet etc... This way I can put all 4 threads through one loop as. Better than writing 4 of every logic statement.