Skip to content
Luis edited this page Sep 17, 2015 · 8 revisions

Welcome to the tec wiki!

Core Principles:

Messaging

  • CommandSystem
  • Used to modify system states. Can be thought of as input.
  • Sent to a specific system and are in the form of a function object.
  • Queued for processing when a system enters a write-safe state.
  • Events
  • Used to notify of input or system event. Can be thought of as output.
  • Systems subscribe to various event types.
  • All systems that are subscribed to that event type are notified when an event occurs.
  • Queued for handling when a system enters a write-safe states.

Component Entity System

Components can be accessed directly via the central component storage for iteration over all components of a type, or indirectly through the Entity Interface which is just a thin wrapper over the central component storage with an entity id property.

Component state changes are done via ComponentUpdateSystem which stores update lists for future frames, and only applies changes to the central component storage during an update cycle.

The central component storage it's the ReflectionEntityList entity_list that it's a map of entity ID -> entity components. (See include/reflection.hpp)

Main Loop

The main loop is the heart of any game or engine. This is where system-level messages and events are checked, graphics are rendered, and physics are simulated. In order to provide a thread friendly order of execution certain events need to happen in a specific order. The following is a pseduo-code that shows how the main loop works in the Trillek Engine:

while (!Closing) {
	ComponentUpdateSystemList::UpdateAll(frame_id) // Applies all component state changes up to frame_id
	NewThread(PhysicsSimulation())
	NewThread(PlayAudio())
	NewThread(...) // Each system that is updated every loop is executed on a worker thread.

	RenderGraphics() // Graphics is updated on the main thread because that's where the context is
	SwapBuffers()
	DoOSMessageLoop()
	frame_id++
}

Logging / Console output

We adopted Spdlog as logger implementation, mainly because it's a lightweight, header only, multi-thread safe, fast and easy to implement sinks.

Read more about it on Logger