Medusa Slockbower
ff27caab4f
- Added boost-atomic and boost-thread as dependencies for concurrency support
4.2 KiB
Planning Documentation for fennec
Table of Contents
Introduction
These files serve as general planning documentation for engine structure, systems, pipelines, and implementation.
Implementations of core engine systems should strive to be O(1) in
implementations, both in terms of runtime and memory performance. This is obviously
not a realistic goal, so rather than the goal requiring the entire engine to be O(1),
we should more specifically look at achieving O(1) performance on hot paths.
I distinctly use 'strive' and 'goal' as different concepts, where designs should
strive to accommodate function implementations for O(1), however the specifics
of the implementation might not always be able to achieve that, so the end goal is
that hot paths should be O(1).
Functions should be highly verbose and any bugprone or erroneous behaviour should throw assertions. DO NOT USE EXCEPTIONS.
System implementations should be independent of architecture or platforms. i.e. the code of the graphics system should not care if OpenGL or Vulkan is used and should not use any direct calls to OpenGL or Vulkan.
The engine should not care about the types of objects loaded from a so/dll. In fact, most of the code should be type independent. Any shared information among a collection of objects should be held either implicitly or explicitly in the super-class. It will be the responsibility of the linked code to initialize and cleanup the objects related to it. This principle should extend to the submodules of the engine.
It is also best to avoid objects having behaviour that is not defined by the system they are in. There are some exceptions in extensions or mods, which should be given configurability and programmability within those systems and their stages. This can be achieved using events at different stages of those engines that are on-demand.
External Libraries
cpptrace- Walking the stack and retrieving information about the code is very platform dependent, and it makes little sense spending days writing a library that will be less effective.
boost-atomicboost-thread- Concurrency support is extremely platform dependent. Each OS has its own implementations with its own idiosyncrasies. We are not writing an operating system, we do not want to spend days writing a library that will be less performant and much more bugprone. Comparing this with the containers library, the containers library is worth reimplementing since it is not platform dependent and we can make an implementation with consistent behavior. Boost is slightly better for our purposes since its implementation is more consistent across implementations than the C++ stdlib.
Definitions
Many subpages of these documents will contain tables that use symbols to denote implementation and testing progress. The symbols are defined below.
| Symbol | Meaning | Notes |
|---|---|---|
| ✅ | Completed | Complete implementation and all tests passing. |
| 🚧 | Partial | Partial implementation and all tests implemented passing. |
| ⛔ | Unimplemented / Failing | Not implemented or any test is failing. |