fennec-org/fennec
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

- Fixed some variable naming with graph and it's PrettyPrinter

Browse Source 
- Added boost-atomic and boost-thread as dependencies for concurrency support
This commit is contained in:
Medusa Slockbower
2025-08-21 06:44:22 -04:00
parent fe4c49d092
commit ff27caab4f
22 changed files with 235 additions and 275 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
.gitmodules vendored
View File

@@ -1,3 +1,9 @@
[submodule "external/cpptrace"] [submodule "external/cpptrace"]
path = external/cpptrace path = external/cpptrace
url = https://github.com/jeremy-rifkin/cpptrace.git url = https://github.com/jeremy-rifkin/cpptrace.git
[submodule "external/boost-atomic"]
path = external/boost-atomic
url = https://github.com/boostorg/atomic
[submodule "external/boost-thread"]
path = external/boost-thread
url = https://github.com/boostorg/thread

14
CMakeLists.txt
View File

@@ -20,9 +20,9 @@ cmake_minimum_required(VERSION 3.30)
project(fennec) project(fennec)
# External dependencies should be loaded here # External dependencies should be loaded here
# CppTrace is a dependency of the project, added as a git submodule
add_subdirectory(external/cpptrace) add_subdirectory(external/cpptrace)
add_subdirectory(external/boost-atomic)
add_subdirectory(external/boost-thread)
set(CMAKE_CXX_STANDARD 23) set(CMAKE_CXX_STANDARD 23)
set(CMAKE_C_STANDARD 23) set(CMAKE_C_STANDARD 23)
@@ -138,11 +138,6 @@ add_library(fennec STATIC
include/fennec/memory/detail/_ptr_traits.h include/fennec/memory/detail/_ptr_traits.h
# CONCURRENCY ==========================================================================================================
include/fennec/concurrency/thread.h
include/fennec/concurrency/mutex.h
include/fennec/concurrency/atomic.h
# DEBUG ================================================================================================================ # DEBUG ================================================================================================================
source/debug/assert_impl.cpp source/debug/assert_impl.cpp
@@ -223,8 +218,11 @@ target_link_options(fennec PRIVATE ${FENNEC_PRIVATE_LINK_OPTIONS}) # Do not comp
# This implementation is designed to be as readable as possible, and expose information that would otherwise be obfuscated # This implementation is designed to be as readable as possible, and expose information that would otherwise be obfuscated
target_link_libraries(fennec PRIVATE target_link_libraries(fennec PRIVATE
cpptrace::cpptrace
${FENNEC_LINK_LIBRARIES} ${FENNEC_LINK_LIBRARIES}
cpptrace::cpptrace
Boost::atomic
Boost::thread
) )

2
READINGS.md
View File

@@ -3,7 +3,7 @@
# Readings # Readings
Here is a list of relevant books and articles on various concepts related to Here is a list of relevant books and articles on various concepts related to
developing a game engine and its subsystems. developing a game engine and its subsystems.
- Game Engine Architecture, Ed. 3 – Jason Gregory - Game Engine Architecture, Ed. 3 – Jason Gregory

2
README.md
View File

@@ -90,7 +90,7 @@ fennec Standards:
immediate events to listeners so that outside functionality may decide how to handle the impending crash. immediate events to listeners so that outside functionality may decide how to handle the impending crash.
In Debug Mode there is nothing that can be done to stop the crash, as soon as the branch finishes, In Debug Mode there is nothing that can be done to stop the crash, as soon as the branch finishes,
`abort()` will be called. `abort()` will be called.
<br> <br>

1
external/boost-atomic vendored Submodule

Submodule external/boost-atomic added at 8a6de6d93d

1
external/boost-thread vendored Submodule

Submodule external/boost-thread added at a1f89c9518

10
gdb/fennec/containers.py
View File

@@ -396,10 +396,10 @@ class GraphPrinter:
class Iterator: class Iterator:
def __init__(self, val): def __init__(self, val):
self.node_pool = val['_node_pool']['_table']['_alloc']['_data'] self.node_pool = val['_vertex_pool']['_table']['_alloc']['_data']
self.max_nodes = val['_node_pool']['_table']['_alloc']['_capacity'] self.max_nodes = val['_vertex_pool']['_table']['_alloc']['_capacity']
self.conn_map = val['_conn_map']['_alloc']['_data'] self.conn_map = val['_edge_map']['_alloc']['_data']
self.max_conn = val['_conn_map']['_size'] self.max_conn = val['_edge_map']['_size']
self.index = 0 self.index = 0
def __iter__(self): def __iter__(self):
@@ -447,7 +447,7 @@ class GraphPrinter:
def __init__(self, val): def __init__(self, val):
self.val = val self.val = val
self.size = val['_node_pool']['_size'] self.size = val['_vertex_pool']['_size']
def to_string(self): def to_string(self):
if self.size == 0: if self.size == 0:

22
include/fennec/concurrency/atomic.h
View File

@@ -1,22 +0,0 @@
// =====================================================================================================================
// fennec, a free and open source game engine
// Copyright © 2025 Medusa Slockbower
//
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program. If not, see <https://www.gnu.org/licenses/>.
// =====================================================================================================================
#ifndef FENNEC_CONCURRENCY_ATOMIC_H
#define FENNEC_CONCURRENCY_ATOMIC_H
#endif // FENNEC_CONCURRENCY_ATOMIC_H

22
include/fennec/concurrency/mutex.h
View File

@@ -1,22 +0,0 @@
// =====================================================================================================================
// fennec, a free and open source game engine
// Copyright © 2025 Medusa Slockbower
//
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program. If not, see <https://www.gnu.org/licenses/>.
// =====================================================================================================================
#ifndef FENNEC_CONCURRENCY_MUTEX_H
#define FENNEC_CONCURRENCY_MUTEX_H
#endif // FENNEC_CONCURRENCY_MUTEX_H

22
include/fennec/concurrency/thread.h
View File

@@ -1,22 +0,0 @@
// =====================================================================================================================
// fennec, a free and open source game engine
// Copyright © 2025 Medusa Slockbower
//
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program. If not, see <https://www.gnu.org/licenses/>.
// =====================================================================================================================
#ifndef FENNEC_CONCURRENCY_THREAD_H
#define FENNEC_CONCURRENCY_THREAD_H
#endif // FENNEC_CONCURRENCY_THREAD_H

96
include/fennec/containers/graph.h
View File

@@ -149,7 +149,7 @@ public:
/// ///
/// \returns The number of edges in the graph /// \returns The number of edges in the graph
constexpr size_t num_edges() const { constexpr size_t num_edges() const {
return _conn_pool.size(); return _edge_pool.size();
} }
/// ///
@@ -170,7 +170,7 @@ public:
/// \param b The second vertex /// \param b The second vertex
/// \returns `true` if the edge exists, `false` otherwise /// \returns `true` if the edge exists, `false` otherwise
constexpr bool exists(size_t a, size_t b) const { constexpr bool exists(size_t a, size_t b) const {
return _conn_map[a][b] != nullptr; return _edge_map[a][b] != nullptr;
} }
/// ///
@@ -189,8 +189,8 @@ public:
/// \param b The second vertex /// \param b The second vertex
/// \returns `true` if both edges exist, `false` otherwise /// \returns `true` if both edges exist, `false` otherwise
constexpr bool is_undirected(size_t a, size_t b) const { constexpr bool is_undirected(size_t a, size_t b) const {
const auto* e0 = _conn_map[a][b]; const auto* e0 = _edge_map[a][b];
const auto* e1 = _conn_map[b][a]; const auto* e1 = _edge_map[b][a];
if (not (e0 != nullptr && e1 != nullptr)) { if (not (e0 != nullptr && e1 != nullptr)) {
return false; return false;
} }
@@ -232,9 +232,9 @@ public:
if (empty()) { if (empty()) {
return nullptr; return nullptr;
} }
edge_t* it = _conn_map[a][b]; edge_t* it = _edge_map[a][b];
if (it) { if (it) {
return _conn_pool[*it]; return _edge_pool[*it];
} }
return nullptr; return nullptr;
} }
@@ -248,9 +248,9 @@ public:
if (empty()) { if (empty()) {
return nullptr; return nullptr;
} }
const edge_t* it = _conn_map[a][b]; const edge_t* it = _edge_map[a][b];
if (it) { if (it) {
return _conn_pool[*it]; return _edge_pool[*it];
} }
return nullptr; return nullptr;
} }
@@ -261,10 +261,10 @@ public:
/// \returns A list containing all vertices `x` with edges from `vertex` to `x...` /// \returns A list containing all vertices `x` with edges from `vertex` to `x...`
list<size_t> outgoing(size_t vertex) { list<size_t> outgoing(size_t vertex) {
list<size_t> res; list<size_t> res;
if (empty() || vertex >= _conn_map.size()) { if (empty() || vertex >= _edge_map.size()) {
return res; return res;
} }
for (const auto& it : _conn_map[vertex]) { for (const auto& it : _edge_map[vertex]) {
res.push_back(it.first); res.push_back(it.first);
} }
return res; return res;
@@ -276,11 +276,11 @@ public:
/// \returns A list containing all vertices `x` with edges from `x...` to `vertex` /// \returns A list containing all vertices `x` with edges from `x...` to `vertex`
list<size_t> incoming(size_t vertex) { list<size_t> incoming(size_t vertex) {
list<size_t> res; list<size_t> res;
if (empty() || vertex >= _conn_map.size()) { if (empty() || vertex >= _edge_map.size()) {
return res; return res;
} }
for (size_t n = 0; n < _conn_map.size(); ++n) { for (size_t n = 0; n < _edge_map.size(); ++n) {
if (_conn_map[n][vertex]) { if (_edge_map[n][vertex]) {
res.push_back(n); res.push_back(n);
} }
} }
@@ -293,11 +293,11 @@ public:
/// \returns A list containing all vertices `x` that have symmetric edges with `vertex` /// \returns A list containing all vertices `x` that have symmetric edges with `vertex`
list<size_t> symmetric(size_t vertex) { list<size_t> symmetric(size_t vertex) {
list<size_t> res; list<size_t> res;
if (empty() || vertex >= _conn_map.size()) { if (empty() || vertex >= _edge_map.size()) {
return res; return res;
} }
for (const auto& it : _conn_map[vertex]) { for (const auto& it : _edge_map[vertex]) {
if (_conn_map[it.first][vertex]) { if (_edge_map[it.first][vertex]) {
res.push_back(it.first); res.push_back(it.first);
} }
} }
@@ -314,11 +314,11 @@ public:
/// \returns A list containing all vertices `x` that have symmetric edges with `vertex` /// \returns A list containing all vertices `x` that have symmetric edges with `vertex`
list<size_t> undirected(size_t vertex) { list<size_t> undirected(size_t vertex) {
list<size_t> res; list<size_t> res;
if (empty() || vertex >= _conn_map.size()) { if (empty() || vertex >= _edge_map.size()) {
return res; return res;
} }
for (const auto& it : _conn_map[vertex]) { for (const auto& it : _edge_map[vertex]) {
const auto* at = _conn_map[it.first][vertex]; const auto* at = _edge_map[it.first][vertex];
if (at != nullptr && *at == it.second) { if (at != nullptr && *at == it.second) {
res.push_back(it.first); res.push_back(it.first);
} }
@@ -332,10 +332,10 @@ public:
/// \param vertex The id of the vertex /// \param vertex The id of the vertex
/// \returns A pointer to a map containing edges mapped from this vertex /// \returns A pointer to a map containing edges mapped from this vertex
const auto* edges(size_t vertex) { const auto* edges(size_t vertex) {
if (empty() || vertex >= _conn_map.size()) { if (empty() || vertex >= _edge_map.size()) {
return nullptr; return nullptr;
} }
return &_conn_map[vertex]; return &_edge_map[vertex];
} }
/// @} /// @}
@@ -392,19 +392,19 @@ public:
return; return;
} }
if (_conn_map.size() < _vertex_pool.capacity()) { if (_edge_map.size() < _vertex_pool.capacity()) {
_conn_map.resize(_vertex_pool.capacity()); _edge_map.resize(_vertex_pool.capacity());
} }
auto it = _conn_map[a][b]; auto it = _edge_map[a][b];
size_t conn; size_t conn;
if (it != nullptr) { if (it != nullptr) {
conn = *it; conn = *it;
_conn_pool[conn] = vertex_t(fennec::forward<ArgsT>(args)...); _edge_pool[conn] = vertex_t(fennec::forward<ArgsT>(args)...);
} else { } else {
conn = _conn_pool.emplace(fennec::forward<ArgsT>(args)...); conn = _edge_pool.emplace(fennec::forward<ArgsT>(args)...);
} }
_conn_map[a].emplace(b, conn); _edge_map[a].emplace(b, conn);
} }
/// ///
@@ -419,21 +419,21 @@ public:
return; return;
} }
if (_conn_map.size() < _vertex_pool.capacity()) { if (_edge_map.size() < _vertex_pool.capacity()) {
_conn_map.resize(_vertex_pool.capacity()); _edge_map.resize(_vertex_pool.capacity());
} }
auto it = _conn_map[a][b]; auto it = _edge_map[a][b];
size_t conn; size_t conn;
if (it != nullptr) { if (it != nullptr) {
conn = *it; conn = *it;
_conn_pool[conn] = vertex_t(fennec::forward<ArgsT>(args)...); _edge_pool[conn] = vertex_t(fennec::forward<ArgsT>(args)...);
} else { } else {
conn = _conn_pool.emplace(fennec::forward<ArgsT>(args)...); conn = _edge_pool.emplace(fennec::forward<ArgsT>(args)...);
} }
_conn_map[a].emplace(b, conn); _edge_map[a].emplace(b, conn);
_conn_map[b].emplace(a, conn); _edge_map[b].emplace(a, conn);
} }
/// ///
@@ -443,20 +443,20 @@ public:
constexpr void cut_edge(size_t a, size_t b) { constexpr void cut_edge(size_t a, size_t b) {
// Find the edge object // Find the edge object
const auto* it = _conn_map[a][b]; const auto* it = _edge_map[a][b];
if (not it) { if (not it) {
return; return;
} }
size_t c = *it; size_t c = *it;
// Check if undirected // Check if undirected
const auto* at = _conn_map[b][a]; const auto* at = _edge_map[b][a];
if (not at || *at != c) { if (not at || *at != c) {
_conn_pool.erase(c); _edge_pool.erase(c);
} }
// Erase the edge mapping // Erase the edge mapping
_conn_map[a].erase(b); _edge_map[a].erase(b);
} }
/// ///
@@ -464,15 +464,15 @@ public:
/// \param a The first vertex id /// \param a The first vertex id
/// \param b The second vertex id /// \param b The second vertex id
constexpr void cut_edge2(size_t a, size_t b) { constexpr void cut_edge2(size_t a, size_t b) {
const auto* ita = _conn_map[a][b]; const auto* ita = _edge_map[a][b];
const auto* itb = _conn_map[a][b]; const auto* itb = _edge_map[a][b];
if (not (ita || itb)) { if (not (ita || itb)) {
return; return;
} }
if (ita) _conn_pool.erase(*ita); if (ita) _edge_pool.erase(*ita);
if (itb) _conn_pool.erase(*itb); if (itb) _edge_pool.erase(*itb);
_conn_map[a].erase(b); _edge_map[a].erase(b);
_conn_map[b].erase(a); _edge_map[b].erase(a);
} }
/// ///
@@ -491,8 +491,8 @@ public:
/// \brief Clear the graph, destructing all vertices and edges. /// \brief Clear the graph, destructing all vertices and edges.
void clear() { void clear() {
_vertex_pool.clear(); _vertex_pool.clear();
_conn_pool.clear(); _edge_pool.clear();
_conn_map.clear(); _edge_map.clear();
} }
/// @} /// @}
@@ -503,8 +503,8 @@ public:
private: private:
vertex_pool_t _vertex_pool; vertex_pool_t _vertex_pool;
edge_pool_t _conn_pool; edge_pool_t _edge_pool;
edge_map_t _conn_map; edge_map_t _edge_map;
template<typename...ArgsT> template<typename...ArgsT>
size_t _insert(ArgsT&&...args) { size_t _insert(ArgsT&&...args) {

8
planning/2D_GRAPHICS.md
View File

@@ -23,8 +23,8 @@ Links:
### Structures (`gfx2d`) ### Structures (`gfx2d`)
For the 2d rendering framework, Materials need to be rendered independently because we have For the 2d rendering framework, Materials need to be rendered independently because we have
no size constraints for images. This disallows us from using a meta-shader like in no size constraints for images. This disallows us from using a meta-shader like in
the 3d rendering framework. the 3d rendering framework.
```c++ ```c++
@@ -59,6 +59,6 @@ struct Object
- Adjust Buffer Size using the counts - Adjust Buffer Size using the counts
- Insert using another atomic buffer - Insert using another atomic buffer
- Translucent objects will be sorted. We can cheat by using a z-index instead of a z-coordinate. - Translucent objects will be sorted. We can cheat by using a z-index instead of a z-coordinate.
This will allow us to sort objects as they are created. We can still bulk render each z-index, This will allow us to sort objects as they are created. We can still bulk render each z-index,
with meshes and objects being grouped by material. with meshes and objects being grouped by material.

12
planning/3D_GRAPHICS.md
View File

@@ -15,16 +15,16 @@
## Introduction ## Introduction
&ensp; This system handles the rendering of 3D meshes, materials, lights, and post-processing &ensp; This system handles the rendering of 3D meshes, materials, lights, and post-processing
effects. effects.
**DirectX will never have official support.** **DirectX will never have official support.**
If you would like to make a fork, have at it, but know that I will hold a deep disdain for you. If you would like to make a fork, have at it, but know that I will hold a deep disdain for you.
The graphics pipeline will have a buffer with a list of objects and their rendering data. The graphics pipeline will have a buffer with a list of objects and their rendering data.
This will be referred to as the Object Buffer. There will be two, for both the Deferred and Forward Passes. This will be referred to as the Object Buffer. There will be two, for both the Deferred and Forward Passes.
The buffers will be optimized by scene prediction. The buffers will be optimized by scene prediction.
This involves tracking the meshes and textures directly and indirectly used by a scene. This involves tracking the meshes and textures directly and indirectly used by a scene.
A callback function in the graphics system for scene loading can do this. A callback function in the graphics system for scene loading can do this.
@@ -66,8 +66,8 @@ Objects are identified with a manually provided type and ID. Object types includ
A user should never have to specify these and should be automatically generated by the respective components. A user should never have to specify these and should be automatically generated by the respective components.
Textures for 3D rendering are stored in various buffers with sizes of powers of 2. Ratios of `1:1` Textures for 3D rendering are stored in various buffers with sizes of powers of 2. Ratios of `1:1`
and `2:1` are allowed. The `2:1` ratio is specifically for spherical and cylindrical projection. UVs and `2:1` are allowed. The `2:1` ratio is specifically for spherical and cylindrical projection. UVs
may be transformed to use a `2:1` as if it were `1:2`. may be transformed to use a `2:1` as if it were `1:2`.
Cubemaps and 3D textures may only be `1:1`. Cubemaps and 3D textures may only be `1:1`.

8
planning/3D_PHYSICS.md
View File

@@ -14,10 +14,10 @@
## Introduction ## Introduction
&ensp; This system will handle newtonian physics for 3D rigid and soft-bodies. This should include &ensp; This system will handle newtonian physics for 3D rigid and soft-bodies. This should include
articulated skeletal systems, particle physics, and soft-body physics. The following soft-body systems articulated skeletal systems, particle physics, and soft-body physics. The following soft-body systems
will be supported with the associated implementation; elastics with finite element simulation, cloth will be supported with the associated implementation; elastics with finite element simulation, cloth
physics with position-based dynamics, oceans with iWave, 3D fluid dynamics with smoothed-particle physics with position-based dynamics, oceans with iWave, 3D fluid dynamics with smoothed-particle
hydrodynamics, 2D surface fluid dynamics with force-based dynamics. hydrodynamics, 2D surface fluid dynamics with force-based dynamics.

10
planning/ARTIFICIAL_INTELLIGENCE.md
View File

@@ -8,10 +8,10 @@
## Introduction ## Introduction
&ensp; This system implements pathing and decision systems for general-purpose traditional &ensp; This system implements pathing and decision systems for general-purpose traditional
artifical intelligence algorithms. This library will not support Machine-Learning Artificial artifical intelligence algorithms. This library will not support Machine-Learning Artificial
Intelligence (ML/AI). This artificial intelligence method only differs in static generation Intelligence (ML/AI). This artificial intelligence method only differs in static generation
between 2D and 3D. The solvers are dimension independent since they work on a graph. between 2D and 3D. The solvers are dimension independent since they work on a graph.
## General Process ## General Process
@@ -25,5 +25,5 @@ between 2D and 3D. The solvers are dimension independent since they work on a gr
* update paths using dijkstra's algorithm * update paths using dijkstra's algorithm
* apply rigid-body forces with constraints * apply rigid-body forces with constraints
The update loop for artificial intelligence should only update every `n` ticks. Where The update loop for artificial intelligence should only update every `n` ticks. Where
`n <= k`, with `k` being the tick rate of the physics engine. `n <= k`, with `k` being the tick rate of the physics engine.

28
planning/CONTAINERS.md
View File

@@ -16,8 +16,8 @@
## Introduction ## Introduction
&ensp; This library contains headers and classes that implement common data &ensp; This library contains headers and classes that implement common data
structures. The contents include the Containers Library of the C++ Standard structures. The contents include the Containers Library of the C++ Standard
Library and Template Library. Library and Template Library.
@@ -29,29 +29,29 @@ Library and Template Library.
| Symbol | Implemented | Passed | | Symbol | Implemented | Passed |
|:-------------------------------------|:-----------:|:------:| |:-------------------------------------|:-----------:|:------:|
| map (`std::unordered_map`) | ✅ | ✅ | | map (`std::unordered_map`) | ✅ | ✅ |
| map_sequence (`std::map`) | ⛔ | ⛔ | | map_sequence (`std::map`) | ⛔ | ⛔ |
| multiset (`std::unordered_multiset`) | ⛔ | ⛔ | | multiset (`std::unordered_multiset`) | ⛔ | ⛔ |
| multisequence (`std::multiset`) | ⛔ | ⛔ | | multisequence (`std::multiset`) | ⛔ | ⛔ |
| multimap (`std::unordered_multimap`) | ⛔ | ⛔ | | multimap (`std::unordered_multimap`) | ⛔ | ⛔ |
| multimap_sequence (`std::multimap`) | ⛔ | ⛔ | | multimap_sequence (`std::multimap`) | ⛔ | ⛔ |
| pair | ✅ | ✅ | | pair | ✅ | ✅ |
| tuple | 🚧 | 🚧 | | tuple | 🚧 | 🚧 |
| optional | ✅ | ✅ | | optional | ✅ | ✅ |
| variant | ⛔ | ⛔ | | variant | ⛔ | ⛔ |
| any | ⛔ | ⛔ | | any | ⛔ | ⛔ |
| bitset | ⛔ | ⛔ | | bitset | ⛔ | ⛔ |
| array | ✅ | ✅ | | array | ✅ | ✅ |
| dynarray (`std::vector`) | 🚧 | 🚧 | | dynarray (`std::vector`) | 🚧 | 🚧 |
| deque | ⛔ | ⛔ | | deque | ⛔ | ⛔ |
| list | ✅ | ✅ | | list | ✅ | ✅ |
| set (`std::unordered_set`) | ✅ | ✅ | | set (`std::unordered_set`) | ✅ | ✅ |
| sequence (`std::set`) | ⛔ | ⛔ | | sequence (`std::set`) | ⛔ | ⛔ |
### fennec ### fennec
| Symbol | Implemented | Passed | | Symbol | Implemented | Passed |
|:------------|:-----------:|:------:| |:------------|:-----------:|:------:|
| graph | 🚧 | 🚧 | | graph | 🚧 | 🚧 |
| object_pool | 🚧 | 🚧 | | object_pool | 🚧 | 🚧 |
| rd_tree | ✅ | ✅ | | rd_tree | ✅ | ✅ |

60
planning/CONTENTS.md
View File

@@ -15,41 +15,58 @@
## Introduction ## Introduction
&ensp; These files serve as general planning documentation for engine structure, systems, &ensp; These files serve as general planning documentation for engine structure, systems,
pipelines, and implementation. pipelines, and implementation.
&ensp; Implementations of core engine systems should strive to be `O(1)` in &ensp; Implementations of core engine systems should strive to be `O(1)` in
implementations, both in terms of runtime and memory performance. This is obviously 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)`, 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. 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 I distinctly use 'strive' and 'goal' as different concepts, where designs should
*strive* to accommodate function implementations for `O(1)`, however the specifics *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 of the implementation might not always be able to achieve that, so the end *goal* is
that hot paths should be `O(1)`. that hot paths should be `O(1)`.
&ensp; Functions should be highly verbose and any bugprone or erroneous behaviour should &ensp; Functions should be highly verbose and any bugprone or erroneous behaviour should
throw assertions. **DO NOT USE EXCEPTIONS**. throw assertions. **DO NOT USE EXCEPTIONS**.
&ensp; System implementations should be independent of architecture or platforms. i.e. &ensp; 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 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. not use any direct calls to OpenGL or Vulkan.
&ensp; The engine should not care about the types of objects loaded from a so/dll. In &ensp; 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 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. 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 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. related to it. This principle should extend to the submodules of the engine.
&ensp; It is also best to avoid objects having behaviour that is not defined by the system &ensp; 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 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 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. 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-atomic` `boost-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 ## Definitions
&ensp; Many subpages of these documents will contain tables that use symbols to &ensp; Many subpages of these documents will contain tables that use symbols to
denote implementation and testing progress. The symbols are defined below. denote implementation and testing progress. The symbols are defined below.
| Symbol | Meaning | Notes | | Symbol | Meaning | Notes |
@@ -62,4 +79,7 @@ denote implementation and testing progress. The symbols are defined below.
## Libraries ## Libraries
- [C++ Language Library](./CPP_LANGUAGE.md#c-language-library-lang) - [C++ Language Library](./CPP_LANGUAGE.md#c-language-library-lang)
- [Platform Support Library](./PLATFORM_SUPPORT.md#platform--api-support) - [Platform Support Library](./PLATFORM_SUPPORT.md#platform-support-library-platform)
- [Memory Library](./MEMORY.md#memory-library-memory)
- [Containers Library](./CONTAINERS.md#containers-library-containers)
- [Language Processing Library](./LANGUAGE_PROCESSING.md#language-processing-library-langproc)

84
planning/CPP_LANGUAGE.md
View File

@@ -26,8 +26,8 @@
## Introduction ## Introduction
&ensp; This library contains headers and classes related to the C++ language. The &ensp; This library contains headers and classes related to the C++ language. The
contents of this library include the Language Support, Diagnostics, and contents of this library include the Language Support, Diagnostics, and
Metaprogramming libraries of the C++ Standard Library and Template Library. Metaprogramming libraries of the C++ Standard Library and Template Library.
See: See:
@@ -59,22 +59,22 @@ See:
| is_null_pointer | ✅ | ✅ | | is_null_pointer | ✅ | ✅ |
| is_integral | ✅ | ✅ | | is_integral | ✅ | ✅ |
| is_floating_point | ✅ | ✅ | | is_floating_point | ✅ | ✅ |
| is_array | ✅ | ❓ | | is_array | ✅ | 🚧 |
| is_enum | ⛔ | ⛔ | | is_enum | ⛔ | ⛔ |
| is_union | ⛔ | ⛔ | | is_union | ⛔ | ⛔ |
| is_class | ✅ | ✅ | | is_class | ✅ | ✅ |
| is_function | ⛔ | ⛔ | | is_function | ⛔ | ⛔ |
| is_pointer | ✅ | ✅ | | is_pointer | ✅ | ✅ |
| is_lvalue_reference | ✅ | ✅ | | is_lvalue_reference | ✅ | ✅ |
| is_rvalue_reference | ✔ | ✔ | | is_rvalue_reference | ✅ | ✅ |
| is_member_object_pointer | ⛔ | ⛔ | | is_member_object_pointer | ⛔ | ⛔ |
| is_member_function_pointer | ⛔ | ⛔ | | is_member_function_pointer | ⛔ | ⛔ |
### Composite Types ### Composite Types
| Symbol | Implemented | Passed | | Symbol | Implemented | Passed |
|:------------------|:-----------:|:------:| |:------------------|:-----------:|:------:|
| is_fundamental | ✔ | ✔ | | is_fundamental | ✅ | ✅ |
| is_arithmetic | ✔ | ✔ | | is_arithmetic | ✅ | ✅ |
| is_scalar | ⛔ | ⛔ | | is_scalar | ⛔ | ⛔ |
| is_object | ⛔ | ⛔ | | is_object | ⛔ | ⛔ |
| is_compound | ⛔ | ⛔ | | is_compound | ⛔ | ⛔ |
@@ -84,9 +84,9 @@ See:
### Type Properties ### Type Properties
| Symbol | Implemented | Passed | | Symbol | Implemented | Passed |
|:----------------------------------|:-----------:|:------:| |:----------------------------------|:-----------:|:------:|
| is_const | ✔ | ✔ | | is_const | ✅ | ✅ |
| is_volatile | ✔ | ✔ | | is_volatile | ✅ | ✅ |
| is_trivially_copyable | ✔ | ✔ | | is_trivially_copyable | ✅ | ✅ |
| is_standard_layout | ⛔ | ⛔ | | is_standard_layout | ⛔ | ⛔ |
| has_unique_object_representations | ⛔ | ⛔ | | has_unique_object_representations | ⛔ | ⛔ |
| is_empty | ⛔ | ⛔ | | is_empty | ⛔ | ⛔ |
@@ -95,8 +95,8 @@ See:
| is_final | ⛔ | ⛔ | | is_final | ⛔ | ⛔ |
| is_aggregate | ⛔ | ⛔ | | is_aggregate | ⛔ | ⛔ |
| is_implicit_lifetime | ⛔ | ⛔ | | is_implicit_lifetime | ⛔ | ⛔ |
| is_signed | ✔ | ✔ | | is_signed | ✅ | ✅ |
| is_unsigned | ✔ | ✔ | | is_unsigned | ✅ | ✅ |
| is_bounded_array | ⛔ | ⛔ | | is_bounded_array | ⛔ | ⛔ |
| is_unbounded_array | ⛔ | ⛔ | | is_unbounded_array | ⛔ | ⛔ |
| is_scoped_enum | ⛔ | ⛔ | | is_scoped_enum | ⛔ | ⛔ |
@@ -104,16 +104,16 @@ See:
### Supported Operations ### Supported Operations
| Symbol | Implemented | Passed | | Symbol | Implemented | Passed |
|:------------------------------------|:-----------:|:------:| |:------------------------------------|:-----------:|:------:|
| is_constructible | ✔ | ✔ | | is_constructible | ✅ | ✅ |
| is_trivially_constructible | ✔ | ✔ | | is_trivially_constructible | ✅ | ✅ |
| is_nothrow_constructible | ⛔ | ⛔ | | is_nothrow_constructible | ⛔ | ⛔ |
| is_default_constructible | ✔ | ✔ | | is_default_constructible | ✅ | ✅ |
| is_trivially_default_constructible | ⛔ | ⛔ | | is_trivially_default_constructible | ⛔ | ⛔ |
| is_nothrow_default_constructible | ⛔ | ⛔ | | is_nothrow_default_constructible | ⛔ | ⛔ |
| is_copy_constructible | ✔ | ✔ | | is_copy_constructible | ✅ | ✅ |
| is_trivially_copy_constructible | ⛔ | ⛔ | | is_trivially_copy_constructible | ⛔ | ⛔ |
| is_nothrow_copy_constructible | ⛔ | ⛔ | | is_nothrow_copy_constructible | ⛔ | ⛔ |
| is_move_constructible | ✔ | ✔ | | is_move_constructible | ✅ | ✅ |
| is_trivially_move_constructible | ⛔ | ⛔ | | is_trivially_move_constructible | ⛔ | ⛔ |
| is_nothrow_move_constructible | ⛔ | ⛔ | | is_nothrow_move_constructible | ⛔ | ⛔ |
| is_destructible | ⛔ | ⛔ | | is_destructible | ⛔ | ⛔ |
@@ -137,10 +137,10 @@ See:
### Type Relationships ### Type Relationships
| Symbol | Implemented | Passed | | Symbol | Implemented | Passed |
|:------------------------------------|:-----------:|:------:| |:------------------------------------|:-----------:|:------:|
| is_same | ✔ | ✔ | | is_same | ✅ | ✅ |
| is_base_of | ❌ | ❌ | | is_base_of | ❌ | ❌ |
| is_virtual_base_of | ❌ | ❌ | | is_virtual_base_of | ❌ | ❌ |
| is_convertible | ✔ | ✔ | | is_convertible | ✅ | ✅ |
| is_nothrow_convertible | ❌ | ❌ | | is_nothrow_convertible | ❌ | ❌ |
| is_layout_compatible | ❌ | ❌ | | is_layout_compatible | ❌ | ❌ |
| is_pointer_interconvertible_base_of | ❌ | ❌ | | is_pointer_interconvertible_base_of | ❌ | ❌ |
@@ -152,19 +152,19 @@ See:
### Type Transformations ### Type Transformations
| Symbol | Implemented | Passed | | Symbol | Implemented | Passed |
|:---------------------|:-----------:|:------:| |:---------------------|:-----------:|:------:|
| add_const | ✔ | ✔ | | add_const | ✅ | ✅ |
| add_volatile | ✔ | ✔ | | add_volatile | ✅ | ✅ |
| add_cv | ✔ | ✔ | | add_cv | ✅ | ✅ |
| remove_const | ✔ | ✔ | | remove_const | ✅ | ✅ |
| remove_volatile | ✔ | ✔ | | remove_volatile | ✅ | ✅ |
| remove_cv | ✔ | ✔ | | remove_cv | ✅ | ✅ |
| add_lvalue_reference | ✔ | ✔ | | add_lvalue_reference | ✅ | ✅ |
| add_rvalue_reference | ✔ | ✔ | | add_rvalue_reference | ✅ | ✅ |
| remove_reference | ✔ | ✔ | | remove_reference | ✅ | ✅ |
| add_pointer | ✔ | ✔ | | add_pointer | ✅ | ✅ |
| remove_pointer | ✔ | ✔ | | remove_pointer | ✅ | ✅ |
| make_signed | ✔ | ✔ | | make_signed | ✅ | ✅ |
| make_unsigned | ✔ | ✔ | | make_unsigned | ✅ | ✅ |
| remove_extent | ❌ | ❌ | | remove_extent | ❌ | ❌ |
| remove_all_extents | ❌ | ❌ | | remove_all_extents | ❌ | ❌ |
@@ -174,17 +174,17 @@ See:
| aligned_storage | ❌ | ❌ | | aligned_storage | ❌ | ❌ |
| aligned_union | ❌ | ❌ | | aligned_union | ❌ | ❌ |
| aligned_union | ❌ | ❌ | | aligned_union | ❌ | ❌ |
| decay | 🚧 | 🚧 | | decay | 🚧 | 🚧 |
| remove_cvref | ✔ | ✔ | | remove_cvref | ✅ | ✅ |
| enable_if | ✔ | ✔ | | enable_if | ✅ | ✅ |
| conditional | ✔ | ✔ | | conditional | ✅ | ✅ |
| common_type | ❌ | ❌ | | common_type | ❌ | ❌ |
| common_reference | ❌ | ❌ | | common_reference | ❌ | ❌ |
| basic_common_reference | ❌ | ❌ | | basic_common_reference | ❌ | ❌ |
| underlying_type | ❌ | ❌ | | underlying_type | ❌ | ❌ |
| result_of | ❌ | ❌ | | result_of | ❌ | ❌ |
| invoke_result | ❌ | ❌ | | invoke_result | ❌ | ❌ |
| void_t | ✔ | ✔ | | void_t | ✅ | ✅ |
### Logical Operations ### Logical Operations
| Symbol | Implemented | Passed | | Symbol | Implemented | Passed |
@@ -196,9 +196,9 @@ See:
### Sequences ### Sequences
| Symbol | Implemented | Passed | | Symbol | Implemented | Passed |
|:-------------------------------------------------|:-----------:|:------:| |:-------------------------------------------------|:-----------:|:------:|
| const_sequence | ✔ | ✔ | | const_sequence | ✅ | ✅ |
| const_integer_sequence (`std::integer_sequence`) | ✔ | ✔ | | const_integer_sequence (`std::integer_sequence`) | ✅ | ✅ |
| make_integer_sequence | ✔ | ✔ | | make_integer_sequence | ✅ | ✅ |
| const_index_sequence (`std::index_sequence`) | ✔ | ✔ | | const_index_sequence (`std::index_sequence`) | ✅ | ✅ |
| make_index_sequence | ✔ | ✔ | | make_index_sequence | ✅ | ✅ |
| concat_sequence | ✔ | ✔ | | concat_sequence | ✅ | ✅ |

58
planning/ENGINE.md
View File

@@ -24,7 +24,7 @@
## Introduction ## Introduction
&ensp; This file outlines the core engine structure and all necessary systems for &ensp; This file outlines the core engine structure and all necessary systems for
the engine to run. the engine to run.
@@ -35,70 +35,70 @@ This section outlines core systems to the engine and brief overviews.
### Events ### Events
&ensp; fennec will be largely event based, the system should be able to handle multiple &ensp; fennec will be largely event based, the system should be able to handle multiple
event types without having any type-specific code. There will be a few categories of events, event types without having any type-specific code. There will be a few categories of events,
predominantly on-demand and delayed events. On-demand events are fired immediately, which is predominantly on-demand and delayed events. On-demand events are fired immediately, which is
useful for events related to graphics and audio. Delayed events are fired at the next tick or useful for events related to graphics and audio. Delayed events are fired at the next tick or
after a certain period of time, this is useful for physics events which can't be handled after a certain period of time, this is useful for physics events which can't be handled
immediately without potentially harming the state of the physics engine. Events should be immediately without potentially harming the state of the physics engine. Events should be
optionally able to be handled with multithreading. optionally able to be handled with multithreading.
### Scene ### Scene
&ensp; The core structure of the engine and its levels will be a scene hierarchy. The hierarchy &ensp; The core structure of the engine and its levels will be a scene hierarchy. The hierarchy
will be implemented using a rooted-directed tree (rdtree, not to be confused with rbtree). will be implemented using a rooted-directed tree (rdtree, not to be confused with rbtree).
Each element in the tree will be a node with a name and some very basic flags. Component Each element in the tree will be a node with a name and some very basic flags. Component
dependent behaviour *must* be handled in systems to avoid the overhead of an object-oriented dependent behaviour *must* be handled in systems to avoid the overhead of an object-oriented
scene hierarchy. This is predominantly caused by the recursive nature of parsing an object- scene hierarchy. This is predominantly caused by the recursive nature of parsing an object-
oriented scene hierarchy where each node records its children and updates them accordingly. oriented scene hierarchy where each node records its children and updates them accordingly.
### Scripts ### Scripts
&ensp; Scripts won't be handled the same way scripts are in other engines, they will be translated &ensp; Scripts won't be handled the same way scripts are in other engines, they will be translated
as a system which will be data-oriented. This is to reduce the overhead of the object-oriented as a system which will be data-oriented. This is to reduce the overhead of the object-oriented
approach in C++ while maintaining the appearance of being object-oriented. approach in C++ while maintaining the appearance of being object-oriented.
### AI ### AI
&ensp; AI will be a fairly multi-parted system as we need to handle different use-cases. &ensp; AI will be a fairly multi-parted system as we need to handle different use-cases.
The first use case is characters that can "walk" and "jump" on surfaces. The second use-case The first use case is characters that can "walk" and "jump" on surfaces. The second use-case
is characters that "fly" in some manner. The static path generation will be the only difference is characters that "fly" in some manner. The static path generation will be the only difference
between 2D and 3D. between 2D and 3D.
### Physics ### Physics
&ensp; Physics, like other systems, will be separated into 2D and 3D specific implementations. &ensp; Physics, like other systems, will be separated into 2D and 3D specific implementations.
This system should be able to handle both Newtonian Rigid-Bodies and Soft-Bodies. The 2D This system should be able to handle both Newtonian Rigid-Bodies and Soft-Bodies. The 2D
and 3D systems should be able to co-exist but not interact. This is for such cases where one and 3D systems should be able to co-exist but not interact. This is for such cases where one
might decide to have a minigame with physics enabled in a 2D environment. might decide to have a minigame with physics enabled in a 2D environment.
### Graphics ### Graphics
&ensp; Graphics, like other systems, will be separated into 2D and 3D specific implementations. &ensp; Graphics, like other systems, will be separated into 2D and 3D specific implementations.
Graphics will exist on a separate thread that handles "frames" vs "ticks," see definitions below Graphics will exist on a separate thread that handles "frames" vs "ticks," see definitions below
for more information. From an abstract, the graphics system should be able to handle static models, for more information. From an abstract, the graphics system should be able to handle static models,
dynamic models, skeletons, materials, lights, lighting models, and post-processing effects. dynamic models, skeletons, materials, lights, lighting models, and post-processing effects.
### Audio ### Audio
&ensp; Audio may actually be implemented generically since the principles of spatial audio apply &ensp; Audio may actually be implemented generically since the principles of spatial audio apply
identically in both 2D and 3D. The only thing that may change for 2D is which axis is "up" and which identically in both 2D and 3D. The only thing that may change for 2D is which axis is "up" and which
axis is "forwards," for example side-scrollers vs top-down. However, this does not mandate specific axis is "forwards," for example side-scrollers vs top-down. However, this does not mandate specific
implementations and rather just aliases which axis is "up." The X-axis can always be "left" and "right" implementations and rather just aliases which axis is "up." The X-axis can always be "left" and "right"
while the Y axis may be interpreted as "up" or "forwards." Audio also won't be handled in the same while the Y axis may be interpreted as "up" or "forwards." Audio also won't be handled in the same
manner as other systems which have explicit ticks and frames. manner as other systems which have explicit ticks and frames.
## Core Game Loop ## Core Game Loop
&ensp; The core game loop is divided into Ticks and Frames. Ticks represent updates in the engine &ensp; The core game loop is divided into Ticks and Frames. Ticks represent updates in the engine
state while Frames represent the generation of the visual output of the engine. state while Frames represent the generation of the visual output of the engine.
### Tick ### Tick

24
planning/LANGUAGE_PROCESSING.md
View File

@@ -17,20 +17,20 @@
## Introduction ## Introduction
&ensp; This library contains implementations of headers and classes related to processing &ensp; This library contains implementations of headers and classes related to processing
languages. This includes; ascii/utf8/utf16 string processing, file formats, machine language, languages. This includes; ascii/utf8/utf16 string processing, file formats, machine language,
and programming languages. and programming languages.
&ensp; fennec should be able to process documentation in files, the main ways it will support &ensp; fennec should be able to process documentation in files, the main ways it will support
this is through Doxygen and LaTeX. Consider including binaries with releases. this is through Doxygen and LaTeX. Consider including binaries with releases.
## String Analysis (`langproc/strings`) ## String Analysis (`langproc/strings`)
&ensp; fennec reimplements the C++ Strings Library as a submodule of this library. This &ensp; fennec reimplements the C++ Strings Library as a submodule of this library. This
is because C++ `std::string` has a lot of overhead. I would say that `std::string` is because C++ `std::string` has a lot of overhead. I would say that `std::string`
is a Jeep, while `fennec::string` is an F2 Car, if that analogy makes any sense. i.e. is a Jeep, while `fennec::string` is an F2 Car, if that analogy makes any sense. i.e.
`std::string` offers a lot of use cases, but is slower, while an F2 Car is barebones and `std::string` offers a lot of use cases, but is slower, while an F2 Car is barebones and
highly performant on the right surface. highly performant on the right surface.
### Implementation ### Implementation
@@ -46,7 +46,7 @@ highly performant on the right surface.
## File System (`filesystem`) ## File System (`filesystem`)
&ensp; fennec *does not* reimplement the C++ I/O Library. What it does do &ensp; fennec *does not* reimplement the C++ I/O Library. What it does do
is create C++ classes that handle file streams, directory streams, and file paths. is create C++ classes that handle file streams, directory streams, and file paths.
### Implementation ### Implementation
@@ -86,7 +86,7 @@ certain specification. Here are some concepts that will need to be implemented a
### Writing ### Writing
&ensp; The writers will be responsible for writing data as a specific format. I.E. converting &ensp; The writers will be responsible for writing data as a specific format. I.E. converting
data values (e.g. floats, ints, etc.) to a readable language (e.g. ascii/utf8/utf16). data values (e.g. floats, ints, etc.) to a readable language (e.g. ascii/utf8/utf16).
- Writer - Writer
@@ -96,7 +96,7 @@ data values (e.g. floats, ints, etc.) to a readable language (e.g. ascii/utf8/ut
## Formats (`langproc/formats`) ## Formats (`langproc/formats`)
&ensp; This submodule will contain classes for processing a variety of file formats. &ensp; This submodule will contain classes for processing a variety of file formats.
### Serialization ### Serialization
@@ -166,8 +166,8 @@ data values (e.g. floats, ints, etc.) to a readable language (e.g. ascii/utf8/ut
#### 3D Model Formats #### 3D Model Formats
&ensp; unfortunately, most formats are esoteric due to copyright/trademark/etc. &ensp; unfortunately, most formats are esoteric due to copyright/trademark/etc.
I will be using assimp for the time being, below is a list of formats supported I will be using assimp for the time being, below is a list of formats supported
by assimp. by assimp.
| Symbol | Implemented | Passed | | Symbol | Implemented | Passed |

6
planning/MEMORY.md
View File

@@ -14,9 +14,9 @@
## Introduction ## Introduction
&ensp; This library contains headers and classes related to memory allocation and &ensp; This library contains headers and classes related to memory allocation and
management in C++. The contents include the Memory Management Library of management in C++. The contents include the Memory Management Library of
the C++ Standard Library and Template Library. This pulls some functions from the the C++ Standard Library and Template Library. This pulls some functions from the
C stdlib and either wraps them or aliases them. C stdlib and either wraps them or aliases them.

14
planning/PLATFORM_SUPPORT.md
View File

@@ -15,8 +15,8 @@
## Introduction ## Introduction
&ensp; The platform support library will include headers, functions, and classes related &ensp; The platform support library will include headers, functions, and classes related
to supporting various platforms. Platforms may be defined as any Hardware, OS, or to supporting various platforms. Platforms may be defined as any Hardware, OS, or
Drivers that must be initialized for the engine context. Drivers that must be initialized for the engine context.
@@ -48,14 +48,14 @@ Platform Support will be implemented in the following order:
- Vulkan - Vulkan
- Metal - Metal
&ensp; Linux Wayland will be implemented first. Once setup, the core engine will be &ensp; Linux Wayland will be implemented first. Once setup, the core engine will be
implemented and tested on top of Wayland. Once the engine is in a stable state, implemented and tested on top of Wayland. Once the engine is in a stable state,
then support for other platforms will be resumed. then support for other platforms will be resumed.
## Consoles ## Consoles
&ensp; Most consoles will never get official platform support due to NDAs which conflict &ensp; Most consoles will never get official platform support due to NDAs which conflict
with the principles of this engine. fennec will avoid using proprietary libraries except with the principles of this engine. fennec will avoid using proprietary libraries except
when strictly necessary, such as support for Windows and MacOS. fennec will interact when strictly necessary, such as support for Windows and MacOS. fennec will interact
with any drivers required for the listed operating systems above, even if proprietary. with any drivers required for the listed operating systems above, even if proprietary.