Skip to content
Tanner Mickelson edited this page Jan 24, 2015 · 18 revisions

File system

The Icicle Engine uses a virtual file system that allows mounting multiple folders/archives as file systems. Folder/archive locations can be added to the file system, and the file system abstracts away the handling of paths and streams.

Game loop

The game loop of the Icicle Engine will be optimized for multithreaded systems. Frames will be synchronized only at key synchronization points where certain data is required to be ready. An update step should end up following an execution flow like shown below for each frame:

  • resource loading thread
  • process current frame
    • collect input
      • buffer controller input
      • buffer keyboard input
      • buffer network messages
      • etc...
    • process events generated last frame
    • update subsystems
      • update physics
      • update animation
      • update audio
    • update game logic
      • user created game classes (player movement, scoring, etc.)
      • scripts
  • render frame
    • interpolate/extrapolate scene transforms
    • cull invisible objects
    • draw visible objects
    • sort object list for rendering
    • submit frame to GPU The resource loading thread is a separate thread that runs in the background. It waits until resources are requested, then loads them into memory.

The update thread is split into four stages. 1 Input is collected asynchronously from different devices and buffered in the input collection stage. Network messages are also collected here. All input collection operations are joined to ensure that input is prepared for the subsystem update stage. 2 Events generated during the last frame are sent to all listeners. 3 The subsystem update stage updates physics, animation, audio, etc. asynchronously. These updates are synchronized right before the game logic stage. 4 The game logic stage is a simple synchronous update. Multithreading is not exploited here, because gameplay code is generally too difficult to write asynchronously and is usually not complex enough to bother. The results of the update thread are stored for the rendering thread before the update thread continues to the next frame.

The rendering thread draws the last frame generated by the update thread. The rendering thread interpolates or extrapolates the transformations of objects from the update thread. This allows the rendering thread to run at a different rate (preferably 60FPS), than the update thread.

Clone this wiki locally