From 5c20c659ec371957df08a6347fadfac9bf78a5a3 Mon Sep 17 00:00:00 2001
From: Loek Le Blansch <loek@pipeframe.xyz>
Date: Wed, 11 Sep 2024 15:10:03 +0200
Subject: add notes + callgrind profiling poc

---
 research.tex | 35 ++++++++++++++++++++++++++++++-----
 1 file changed, 30 insertions(+), 5 deletions(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index ca2afed..16dcef4 100644
--- a/research.tex
+++ b/research.tex
@@ -176,15 +176,36 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 
 \subsection{Conclusion}
 
-\section{Memory/debugging}
+% TODO: this entire section
+\section{Profiling and debugging}
+
+% Which profiling and debugging features are wanted?
+% How to provide those profiling and debugging features?
+% Can most of the profiling/debugging be handled by external tools?
+
+% Ideas:
+% - flame graph
+% - watchtable (combine w/ fps/speed control overlay?)
+% - debug printing utility functions
 
 \subsection{Introduction}
 
 \subsection{Findings}
 
+\subsubsection{Callgrind}
+
+\begin{comparison}
+	\pro{Source code does not need to be modified for profiling}
+	\con{Execution speed is severely impacted}
+\end{comparison}
+
 \subsection{Conclusion}
 
-\section{Physics/scripting}
+% TODO: this entire section
+\section{Audio}
+
+% should audio research be scoped down to SDL2 (if that's what we're going with) or
+% standalone libraries only (for modularity?).
 
 \subsection{Introduction}
 
@@ -192,7 +213,13 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 
 \subsection{Conclusion}
 
-\section{Conclusion}
+\section{Physics/scripting}
+
+\subsection{Introduction}
+
+\subsection{Findings}
+
+\subsection{Conclusion}
 
 \section{Gameobjects/components}
 
@@ -202,6 +229,4 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 
 \subsection{Conclusion}
 
-\section{Conclusion}
-
 \end{document}
-- 
cgit v1.2.3


From 08f65674dc02f613c72e84385a8374c0535d88cb Mon Sep 17 00:00:00 2001
From: heavydemon21 <nielsstunnebrink1@gmail.com>
Date: Wed, 11 Sep 2024 16:31:43 +0200
Subject: research started

---
 research.tex | 43 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 42 insertions(+), 1 deletion(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index ca2afed..8ce9098 100644
--- a/research.tex
+++ b/research.tex
@@ -152,12 +152,53 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 
 \subsection{Conclusion}
 
-\section{Gameloop/resource manager}
+\section{resource manager}
 
 \subsection{Introduction}
 
 \subsection{Findings}
 
+\subsection{unity formats}
+Unity has many different asset file types that can be imported to use for a game \href{https://docs.unity3d.com/Manual/BuiltInImporters.html}{unity imports}. The most important formats are the audio, text and sprite formats.
+
+\paragraph{Audio}
+
+Unity uses a *Audio Source* component that holds the reference of the audio format which are all these different types.
+\begin{itemize}
+	\item ogg.
+	\item aif.
+	\item aiff.
+	\item flac.
+	\item wav.
+	\item mp3.
+	\item mod.
+	\item it.
+	\item s3m.
+	\item xm.
+\end{itemize}
+
+Where then the *Audio clip* contains all the audio data used by the *Audio Source* components. Inside the audio clip are options about each specified audio file to change specific settings from the origanl file. for example load type, compression format, quality, sample rate and more \href{https://docs.unity.cn/2018.4/Documentation/Manual/class-AudioClip.html}{audio clip}
+
+\paragraph{Sprite formats}
+Unity supports many different image formats:
+\begin{itemize}
+	\item jpg.
+	\item jpeg.
+	\item tif/tiff.
+	\item tga.
+	\item gif.
+	\item png.
+	\item psd.
+	\item bmp.
+	\item iff.
+	\item pict.
+	\item pic.
+	\item pct.
+	\item exr.
+	\item hdr.
+\end{itemize}
+
+
 \subsection{Conclusion}
 
 \section{Rendering}
-- 
cgit v1.2.3


From 37cd579403c86833d3fdb6ebe7f3cd2235649b27 Mon Sep 17 00:00:00 2001
From: WBoerenkamps <wrj.boerenkamps@student.avans.nl>
Date: Thu, 12 Sep 2024 13:00:55 +0200
Subject: changed some research headers and added time

---
 research.tex | 31 +++++++++++++++++++++++++------
 time.txt     |  2 ++
 2 files changed, 27 insertions(+), 6 deletions(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index ca2afed..7ae6856 100644
--- a/research.tex
+++ b/research.tex
@@ -152,7 +152,7 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 
 \subsection{Conclusion}
 
-\section{Gameloop/resource manager}
+\section{Resource manager}
 
 \subsection{Introduction}
 
@@ -168,7 +168,7 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 
 \subsection{Conclusion}
 
-\section{Event manager}
+\section{Event manager/game loop}
 
 \subsection{Introduction}
 
@@ -176,7 +176,7 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 
 \subsection{Conclusion}
 
-\section{Memory/debugging}
+\section{Profiling/debugging}
 
 \subsection{Introduction}
 
@@ -184,7 +184,7 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 
 \subsection{Conclusion}
 
-\section{Physics/scripting}
+\section{Physics}
 
 \subsection{Introduction}
 
@@ -192,16 +192,35 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 
 \subsection{Conclusion}
 
-\section{Conclusion}
+\section{Scripting}
+
+\subsection{Introduction}
+
+\subsection{Findings}
+
+\subsection{Conclusion}
+\section{Audio}
+
+\subsection{Introduction}
+
+\subsection{Findings}
+
+\subsection{Conclusion}
 
 \section{Gameobjects/components}
 
 \subsection{Introduction}
 
+\subsection{Findings}
+\subsection{Conclusion}
+\section{AI}
+
+\subsection{Introduction}
+
 \subsection{Findings}
 
 \subsection{Conclusion}
 
-\section{Conclusion}
 
+\section{Conclusion}
 \end{document}
diff --git a/time.txt b/time.txt
index db345f3..dbf3107 100644
--- a/time.txt
+++ b/time.txt
@@ -33,6 +33,8 @@ wouter: 2024-09-04 1h30m researching 3rd party tools
 wouter: 2024-09-05 1h30m first group meeting
 wouter: 2024-09-05 20m setting up research document
 wouter: 2024-09-05 1h researching game enigne
+wouter: 2024-09-06 3h researching game enigne
+wouter: 2024-09-09 2h researching SDL and SFML2
 
 niels: 2024-09-02 1h project meeting :: project kickoff
 niels: 2024-09-02 45m project meeting
-- 
cgit v1.2.3


From 05911a90908e3fb2bd1c1ca2add2ef4fef1fed1e Mon Sep 17 00:00:00 2001
From: heavydemon21 <nielsstunnebrink1@gmail.com>
Date: Thu, 12 Sep 2024 14:17:12 +0200
Subject: research

---
 research.tex | 30 +++++++++++++++++++++++++++---
 1 file changed, 27 insertions(+), 3 deletions(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index 8ce9098..b26018e 100644
--- a/research.tex
+++ b/research.tex
@@ -163,7 +163,7 @@ Unity has many different asset file types that can be imported to use for a game
 
 \paragraph{Audio}
 
-Unity uses a *Audio Source* component that holds the reference of the audio format which are all these different types.
+The unity engine supports a lot of different audio formats:
 \begin{itemize}
 	\item ogg.
 	\item aif.
@@ -177,9 +177,8 @@ Unity uses a *Audio Source* component that holds the reference of the audio form
 	\item xm.
 \end{itemize}
 
-Where then the *Audio clip* contains all the audio data used by the *Audio Source* components. Inside the audio clip are options about each specified audio file to change specific settings from the origanl file. for example load type, compression format, quality, sample rate and more \href{https://docs.unity.cn/2018.4/Documentation/Manual/class-AudioClip.html}{audio clip}
-
 \paragraph{Sprite formats}
+
 Unity supports many different image formats:
 \begin{itemize}
 	\item jpg.
@@ -198,6 +197,31 @@ Unity supports many different image formats:
 	\item hdr.
 \end{itemize}
 
+\paragraph{scripts}
+The different text scripts unity supports:
+ \begin{itemize}
+	 \item txt
+	 \item html 
+	 \item htm 
+	 \item xml
+	 \item json
+	 \item csv
+	 \item yaml
+	 \item bytes
+	 \item fnt 
+	 \item manifest
+	 \item md 
+	 \item js
+	 \item boo
+	 \item rsp
+ \end{itemize}
+
+\subsection{Audio Format} The choice of audio format for the Crepe game engine depends on several factors, including sound quality, memory usage, and licensing. According to various sources \href{https://dev.to/tenry/comparison-of-audio-formats-for-games-jak}{comparison audio formats}, \href{https://www.universityofgames.net/articles/audio-file-formats-used-in-game-development/}{Audio files in games} , the most commonly used audio formats in game development are WAV, MP3, and Ogg.
+
+\paragraph{Licensing} Historically, MP3 had patents on the audio format, but these restrictions have expired. Ogg and FLAC, both developed by Xiph.Org, are open-source formats. Additionally, the WAV format, though widely used, does not require a specific license for distribution.
+
+\paragraph{Conclusion} For the Crepe game engine, Ogg and FLAC are the preferred audio formats due to their open-source licenses and high compatibility. FLAC is ideal for high-quality audio with minimal compression, while Ogg is better suited for lower-quality audio that requires reduced memory usage. Both formats come from the same non-profit organization, Xiph.Org, ensuring that they align with open-source values and licensing flexibility.
+
 
 \subsection{Conclusion}
 
-- 
cgit v1.2.3


From 4de2d802fcca20c4759e3bf1ce269dbee9c03b8a Mon Sep 17 00:00:00 2001
From: Max-001 <80035972+Max-001@users.noreply.github.com>
Date: Thu, 12 Sep 2024 17:08:36 +0200
Subject: Started GameObjects section

---
 research.tex | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index ca2afed..9f95428 100644
--- a/research.tex
+++ b/research.tex
@@ -195,11 +195,10 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 \section{Conclusion}
 
 \section{Gameobjects/components}
-
 \subsection{Introduction}
-
+One of the requirements of our customer, is that the game engine's structure is similar to Unity. The customer has created a class diagram of the game engine's API, which is (of course) very similar to Unity. One of the most important parts of the class diagram is a so-called gameObject (with several components). It's needed to understand the exact meaning/function of these gameObjects, that's why this research question arose.
 \subsection{Findings}
-
+A gameObject itself does/is nothing.
 \subsection{Conclusion}
 
 \section{Conclusion}
-- 
cgit v1.2.3


From f7f4849f1ca92f3b0689e4eacb60291d1306d865 Mon Sep 17 00:00:00 2001
From: Max-001 <80035972+Max-001@users.noreply.github.com>
Date: Thu, 12 Sep 2024 17:44:58 +0200
Subject: Worked on gameObject research

---
 research.tex | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index 9f95428..8f368a1 100644
--- a/research.tex
+++ b/research.tex
@@ -198,7 +198,15 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 \subsection{Introduction}
 One of the requirements of our customer, is that the game engine's structure is similar to Unity. The customer has created a class diagram of the game engine's API, which is (of course) very similar to Unity. One of the most important parts of the class diagram is a so-called gameObject (with several components). It's needed to understand the exact meaning/function of these gameObjects, that's why this research question arose.
 \subsection{Findings}
-A gameObject itself does/is nothing.
+A gameObject is the most important concept in Unity. Every object in a game is a GameObject, from characters and collectible items to the lights, cameras and special effects. However, a gameObject itself can't do anything on its own. A gameObject needs to be given properties before it can become a character, an envirnment, or a special effect. https://docs.unity3d.com/Manual/GameObjects.html
+
+A gameObject can be seen as a container for components. Components are the properties of the gameObject. A few examples of components are sprites, animators, audioSources, and so on. Multiple (different) components can be assigned to a single gameObject (e.g. a sprite and an audioSource).
+
+Since we now know that a gameObject needs components to do something, it's obvious that there should be a way to add components to a gameObject. Some components (e.g. the behaviorScript component) should also be able to reference to its gameObject.
+
+Each gameObject always has one transform class. The transform class describes the position, rotation, and scale within the scene. Some component use this information to e.g. scale a sprite. Other components eddit this information to e.g. model gravity. https://docs.unity3d.com/Manual/class-Transform.html
+
+A gameObject can have one (or multiple) children gameObject(s). All children gameObjects, of course, also have one transform class. However, the position, rotation, and scale of this class, is always the same as the child's parent. A child can not have more than one parent. https://docs.unity3d.com/Manual/class-Transform.html
 \subsection{Conclusion}
 
 \section{Conclusion}
-- 
cgit v1.2.3


From 188fbffafda0942014b12dd2e2313ad139bcd1cc Mon Sep 17 00:00:00 2001
From: Loek Le Blansch <loek@pipeframe.xyz>
Date: Thu, 12 Sep 2024 20:35:24 +0200
Subject: add some audio research

---
 research.tex | 34 ++++++++++++++++++++++++++++++++++
 time.txt     |  1 +
 2 files changed, 35 insertions(+)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index 00b006d..ad33d10 100644
--- a/research.tex
+++ b/research.tex
@@ -207,6 +207,40 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 % should audio research be scoped down to SDL2 (if that's what we're going with) or
 % standalone libraries only (for modularity?).
 
+The game engine is required to have an audio system with support for playing multiple
+audio streams (i.e.~tracks or samples) simultaniously. Since writing a custom live
+audio mixing engine is outside the scope of this project, this section compares
+various standalone audio engines that could be used in the engine.
+
+% TODO: requirements first!
+
+% REQ ~ is cross-platform
+% REQ ~ supports multiple audio formats (TODO: which)
+% REQ ~ supports simultanious playback / mixing
+% REQ ~ has an open-source license
+\begin{table}
+	\centering
+	\begin{tabular}{llc}
+		\toprule
+		\textbf{Library} & \textbf{License} & \textbf{API}\\
+		\midrule
+		miniaudio & MIT-0 & C\\
+		YSE & EPL & C++\\
+		SoLoud & Zlip/LibPng & C++\\
+		\bottomrule
+	\end{tabular}
+	\caption{Audio engine library comparison}
+	\label{tab:audio-engines}
+\end{table}
+% TODO: ref https://miniaud.io/
+% TODO: ref https://www.attr-x.net/yse/
+
+Not considered further:
+\begin{description}
+	\item[FMOD] is proprietary
+	\item[PortAudio] requires manual mixing
+\end{description}
+
 \section{Physics}
 
 \subsection{Introduction}
diff --git a/time.txt b/time.txt
index 3a8b547..d9190f5 100644
--- a/time.txt
+++ b/time.txt
@@ -20,6 +20,7 @@ loek: 2024-09-10 5m docs :: update readme
 loek: 2024-09-10 12m docs :: add comparison package and more example latex code
 loek: 2024-09-10 30m project meeting
 loek: 2024-09-11 1h40m research :: profiling and debugging
+loek: 2024-09-12 30m research :: audio
 
 max: 2024-09-02 1h project kickoff
 max: 2024-09-02 45m first project meeting
-- 
cgit v1.2.3


From 83999b29846e1338e43bf9b2fe7489d778cb7d0c Mon Sep 17 00:00:00 2001
From: heavydemon21 <nielsstunnebrink1@gmail.com>
Date: Sun, 15 Sep 2024 13:12:27 +0200
Subject: research

---
 research.tex | 19 -------------------
 1 file changed, 19 deletions(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index b26018e..8dfb2a6 100644
--- a/research.tex
+++ b/research.tex
@@ -197,25 +197,6 @@ Unity supports many different image formats:
 	\item hdr.
 \end{itemize}
 
-\paragraph{scripts}
-The different text scripts unity supports:
- \begin{itemize}
-	 \item txt
-	 \item html 
-	 \item htm 
-	 \item xml
-	 \item json
-	 \item csv
-	 \item yaml
-	 \item bytes
-	 \item fnt 
-	 \item manifest
-	 \item md 
-	 \item js
-	 \item boo
-	 \item rsp
- \end{itemize}
-
 \subsection{Audio Format} The choice of audio format for the Crepe game engine depends on several factors, including sound quality, memory usage, and licensing. According to various sources \href{https://dev.to/tenry/comparison-of-audio-formats-for-games-jak}{comparison audio formats}, \href{https://www.universityofgames.net/articles/audio-file-formats-used-in-game-development/}{Audio files in games} , the most commonly used audio formats in game development are WAV, MP3, and Ogg.
 
 \paragraph{Licensing} Historically, MP3 had patents on the audio format, but these restrictions have expired. Ogg and FLAC, both developed by Xiph.Org, are open-source formats. Additionally, the WAV format, though widely used, does not require a specific license for distribution.
-- 
cgit v1.2.3


From f923835a5e82d727dc27d61ef9ef9d731580b0c9 Mon Sep 17 00:00:00 2001
From: Max-001 <80035972+Max-001@users.noreply.github.com>
Date: Mon, 16 Sep 2024 16:53:41 +0200
Subject: Added popular ECS

---
 research.tex | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index ad33d10..3e2e103 100644
--- a/research.tex
+++ b/research.tex
@@ -66,10 +66,30 @@ must be stored efficiently, and entities must be provided with the required beha
 such as audio, position, or physics. To create diverse entities with specific
 functions: A scene can contain many different kinds of entities, each with different
 properties and functions. But no matter how different each entity is, it remains an
-entity. To assign properties and functions to entities, components are used. Entt is
-an example of an \gls{ecs}.
+entity. To assign properties and functions to entities, components are used.
 % TODO: ref?entt
 
+There are many C/C++ libraries available, completely dedicated to \gls{ecs}. The most
+popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is based
+on the amount of stars on GitHub.
+\begin{table}
+	\begin{tabularx}{\linewidth}{lXr}
+		\toprule
+		\textbf{Name} & \textbf{Short Description} & \textbf{GitHub Stars} \\
+		\midrule
+		EnTT & Fast and reliable entity-component system & 10k \\
+		Flecs & A Multithreaded Entity Component System written for C89 and C99 & 6.3k \\
+		EntityX & Fast, type-safe C++ entity component system & 2.2k \\
+		\bottomrule
+	\end{tabularx}
+	\caption{Popular \gls{ecs} libraries}
+	\label{tab:popularECSLibraries}
+\end{table}
+https://github.com/abeimler/ecs_benchmark
+
+It is, of course, not necessary to use a library to implement an \gls{ecs} architecture.
+However, it seems very hard to achieve the same performance as a library. https://github.com/SanderMertens/ecs-faq?tab=readme-ov-file#should-i-write-my-own-ecs
+
 \subsection{Conclusion}
 
 \section{Third-party Tools}
-- 
cgit v1.2.3


From f89ee3feb7e514ec7fbb469a16d34569a57bd0dc Mon Sep 17 00:00:00 2001
From: Max-001 <80035972+Max-001@users.noreply.github.com>
Date: Wed, 18 Sep 2024 15:03:23 +0200
Subject: Added sources to text

---
 research.tex | 28 ++++++++++++++--------------
 sources.bib  | 12 ++++++++++++
 2 files changed, 26 insertions(+), 14 deletions(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index 3e2e103..d453df5 100644
--- a/research.tex
+++ b/research.tex
@@ -72,23 +72,23 @@ entity. To assign properties and functions to entities, components are used.
 There are many C/C++ libraries available, completely dedicated to \gls{ecs}. The most
 popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is based
 on the amount of stars on GitHub.
-\begin{table}
-	\begin{tabularx}{\linewidth}{lXr}
-		\toprule
-		\textbf{Name} & \textbf{Short Description} & \textbf{GitHub Stars} \\
-		\midrule
-		EnTT & Fast and reliable entity-component system & 10k \\
-		Flecs & A Multithreaded Entity Component System written for C89 and C99 & 6.3k \\
-		EntityX & Fast, type-safe C++ entity component system & 2.2k \\
-		\bottomrule
-	\end{tabularx}
-	\caption{Popular \gls{ecs} libraries}
-	\label{tab:popularECSLibraries}
+\begin{table}[ht]
+    \centering
+    \begin{tabular}{ll@{\qquad}lr}
+        \toprule
+        \textbf{Name} & \textbf{Short Description} & \textbf{Stars} & \textbf{License} \\
+        \midrule
+        EnTT & Fast and reliable entity-component system & 10k & MIT \\
+        Flecs & A Multithreaded Entity Component System & 6.3k & MIT \\
+        EntityX & Fast, type-safe C++ entity component system & 2.2k & MIT \\
+        \bottomrule
+    \end{tabular}
+    \caption{Popular \gls{ecs} libraries \autocite{github:001}}
+    \label{tab:popularECSLibraries}
 \end{table}
-https://github.com/abeimler/ecs_benchmark
 
 It is, of course, not necessary to use a library to implement an \gls{ecs} architecture.
-However, it seems very hard to achieve the same performance as a library. https://github.com/SanderMertens/ecs-faq?tab=readme-ov-file#should-i-write-my-own-ecs
+However, it seems very hard to achieve the same performance as a library. \autocite{github:002}
 
 \subsection{Conclusion}
 
diff --git a/sources.bib b/sources.bib
index 50f5ead..9b08c96 100644
--- a/sources.bib
+++ b/sources.bib
@@ -47,4 +47,16 @@
   date = {2024-09-10},
 }
 
+@misc{github:001,
+  author = {Sangjun Lee},
+  title = {Awesome Entity Component System},
+  url = {https://github.com/jslee02/awesome-entity-component-system?tab=readme-ov-file},
+	date = {2023}
+}
 
+@misc{github:002,
+  author = {Sander Mertens},
+  title = {ECS FAQ},
+  url = {https://github.com/SanderMertens/ecs-faq?tab=readme-ov-file#should-i-write-my-own-ecs},
+	date = {2023}
+}
-- 
cgit v1.2.3


From 105cab5fc6f88f7e71e71910c5f598d39fba3262 Mon Sep 17 00:00:00 2001
From: Max-001 <80035972+Max-001@users.noreply.github.com>
Date: Wed, 18 Sep 2024 16:25:37 +0200
Subject: Rectified gameObject/components section, added references to
 gameObject/components section and created new subsubsection for the game
 engine's structure

---
 research.tex | 34 ++++++++++++++++++----------------
 sources.bib  | 16 ++++++++++++++++
 2 files changed, 34 insertions(+), 16 deletions(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index d453df5..f62f736 100644
--- a/research.tex
+++ b/research.tex
@@ -44,13 +44,17 @@ layers are divided into the following categories:\noparbreak
 		performance profiling.
 	\item[Scripting layer] Runs scripts, such as Lua or Python.
 	\item[Memory systems] Handles and monitors memory usage.
-	\item[\gls{ecs}] Provides a modular way to create game objects, add physics, and
-		define how the engine interacts with objects.
 	\item[Physics] Adds specific physics to objects.
 	\item[Audio] Processes audio.
 	\item[AI] Provides artificial inteligent behavior.
 \end{description}
 
+\subsubsection{Structure}
+
+The above mentioned layers should be structured, somehow. One of the requirements is
+that the game engine's API uses a so-called gameObject (with one or more component(s)).
+The gameObject is described in more detail at \cref{sec:Gameobjects/components}. ...
+
 \subsubsection{ECS}
 
 A game engine must have the ability to keep track and update several game objects. To
@@ -286,6 +290,7 @@ Not considered further:
 \subsection{Conclusion}
 
 \section{Gameobjects/components}
+\label{sec:Gameobjects/components}
 
 \subsection{Introduction}
 
@@ -302,16 +307,7 @@ A gameObject is the most important concept in Unity. Every object in a game is a
 GameObject, from characters and collectible items to the lights, cameras and special
 effects. However, a gameObject itself can't do anything on its own. A gameObject
 needs to be given properties before it can become a character, an envirnment, or a
-special effect.
-% TODO: cite https://docs.unity3d.com/Manual/GameObjects.html
-
-\subsection{Conclusion}
-
-\section{AI}
-
-\subsection{Introduction}
-
-\subsection{Findings}
+special effect. \autocite{man:unityGameobjects}
 
 A gameObject can be seen as a container for components. Components are the properties
 of the gameObject. A few examples of components are sprites, animators, audioSources,
@@ -326,14 +322,20 @@ gameObject.
 Each gameObject always has one transform class. The transform class describes the
 position, rotation, and scale within the scene. Some component use this information
 to e.g. scale a sprite. Other components eddit this information to e.g.~model
-gravity.
-% TODO: cite https://docs.unity3d.com/Manual/class-Transform.html
+gravity. \autocite{man:unityTransformClass}
 
 A gameObject can have one (or multiple) children gameObject(s). All children
 gameObjects, of course, also have one transform class. However, the position,
 rotation, and scale of this class, is always the same as the child's parent. A child
-can not have more than one parent.
-% TODO: cite https://docs.unity3d.com/Manual/class-Transform.html
+can not have more than one parent. \autocite{man:unityTransformClass}
+
+\subsection{Conclusion}
+
+\section{AI}
+
+\subsection{Introduction}
+
+\subsection{Findings}
 
 \subsection{Conclusion}
 
diff --git a/sources.bib b/sources.bib
index 9b08c96..d6b960b 100644
--- a/sources.bib
+++ b/sources.bib
@@ -60,3 +60,19 @@
   url = {https://github.com/SanderMertens/ecs-faq?tab=readme-ov-file#should-i-write-my-own-ecs},
 	date = {2023}
 }
+
+@manual{man:unityGameobjects,
+	title = {GameObject},
+	author = {Unity Technologies},
+  organization = {Unity},
+  url = {https://docs.unity3d.com/Manual/GameObjects.html},
+	date = {2024}
+}
+
+@manual{man:unityTransformClass,
+  title = {Transform Class},
+  author = {Unity Technologies},
+  organization = {Unity},
+  url = {https://docs.unity3d.com/Manual/class-Transform.html},
+  date = {2024}
+}
-- 
cgit v1.2.3


From c37f21e48f17abe9fb6bf1549f680e6f730aed8c Mon Sep 17 00:00:00 2001
From: Loek Le Blansch <loek@pipeframe.xyz>
Date: Wed, 18 Sep 2024 16:52:40 +0200
Subject: WIP research

---
 projdoc.cls         |  3 +++
 reqs.toml           | 16 ++++++++++-
 research.tex        | 34 ++++++++++-------------
 scripts/reqs2tex.py |  3 +++
 sources.bib         | 77 +++++++++++++++++++++++++++++++++++++++--------------
 5 files changed, 92 insertions(+), 41 deletions(-)

(limited to 'research.tex')

diff --git a/projdoc.cls b/projdoc.cls
index fccf8c1..05e401c 100644
--- a/projdoc.cls
+++ b/projdoc.cls
@@ -389,3 +389,6 @@
 }
 \makeatother
 
+% missing reference marker
+\def\mref{\textsuperscript{\textit{\,ref?}}}
+
diff --git a/reqs.toml b/reqs.toml
index 6645ea4..2da91ac 100644
--- a/reqs.toml
+++ b/reqs.toml
@@ -67,7 +67,9 @@ The public audio \gls{api} allows the game programmer to control the volume of
 audio samples.
 '''
 
-[aux.license]
+# TODO: audio encoding support?
+
+[lib.license]
 type = 'system'
 priority = 'must'
 description = '''
@@ -75,3 +77,15 @@ External libraries must have a license that is MIT-compatible, or one that
 allows linking against MIT code.
 '''
 
+[lib.platform]
+type = 'system'
+priority = 'must'
+description = '''
+External libraries must have cross-platform support for at least Linux and
+Windows.
+'''
+
+# TODO: library popularity as quality factor?
+# TODO: library documentation as quality factor?
+# TODO: modularity over less libraries? (i.e. why don't we just SDL2 everything?)
+
diff --git a/research.tex b/research.tex
index ad33d10..abfde3b 100644
--- a/research.tex
+++ b/research.tex
@@ -201,44 +201,38 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 
 \subsection{Conclusion}
 
-% TODO: this entire section
 \section{Audio}
 
-% should audio research be scoped down to SDL2 (if that's what we're going with) or
-% standalone libraries only (for modularity?).
-
-The game engine is required to have an audio system with support for playing multiple
-audio streams (i.e.~tracks or samples) simultaniously. Since writing a custom live
-audio mixing engine is outside the scope of this project, this section compares
+The game engine is required to have an audio system
+\autocite[\ref{req:audio}]{crepe:requirements}. Since writing a custom real-time
+audio mixing engine is outside the scope of this project\mref, this section compares
 various standalone audio engines that could be used in the engine.
 
-% TODO: requirements first!
+\subsection{Libraries}
+
+\Cref{tab:audio-engines} compares several standalone audio engine libraries that fit
+\cref{req:audio,req:lib:license}.
 
-% REQ ~ is cross-platform
-% REQ ~ supports multiple audio formats (TODO: which)
-% REQ ~ supports simultanious playback / mixing
-% REQ ~ has an open-source license
 \begin{table}
 	\centering
 	\begin{tabular}{llc}
 		\toprule
 		\textbf{Library} & \textbf{License} & \textbf{API}\\
 		\midrule
-		miniaudio & MIT-0 & C\\
-		YSE & EPL & C++\\
-		SoLoud & Zlip/LibPng & C++\\
+		miniaudio \autocite{lib:miniaudio} & MIT-0 & C\\
+		YSE \autocite{lib:yse} & EPL & C++\\
+		SoLoud \autocite{lib:soloud} & Zlip/LibPng & C++\\
 		\bottomrule
 	\end{tabular}
 	\caption{Audio engine library comparison}
 	\label{tab:audio-engines}
 \end{table}
-% TODO: ref https://miniaud.io/
-% TODO: ref https://www.attr-x.net/yse/
 
-Not considered further:
+Other popular libraries that were researched but are unsuitable for this project
+include:\noparbreak
 \begin{description}
-	\item[FMOD] is proprietary
-	\item[PortAudio] requires manual mixing
+	\item[FMOD \autocite{lib:fmod}] Is proprietary (violates \cref{req:lib:license})
+	\item[PortAudio \autocite{lib:portaudio}] Does not handle mixing
 \end{description}
 
 \section{Physics}
diff --git a/scripts/reqs2tex.py b/scripts/reqs2tex.py
index e5f063d..6984466 100755
--- a/scripts/reqs2tex.py
+++ b/scripts/reqs2tex.py
@@ -94,6 +94,9 @@ def convert(data):
   # skip deleted requirements (but process for make_id)
   reqs = [item for item in reqs if item[KEY.DELETED] == False]
 
+  # sort by label
+  reqs = sorted(reqs, key=lambda item: item[KEY.LABEL])
+
   return reqs
 
 def fmt_aux(data):
diff --git a/sources.bib b/sources.bib
index 50f5ead..6f5ce0c 100644
--- a/sources.bib
+++ b/sources.bib
@@ -13,38 +13,75 @@
 }
 
 @misc{miro:scrum-board,
-  author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
-  title = {Scrum Board on Miro},
-  url = {https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474},
-  date = {2024-09-10},
+	author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
+	title = {Scrum Board on Miro},
+	url = {https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474},
+	date = {2024-09-10},
 }
 
 @misc{crepe:code-repo,
-  author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
-  title = {Crepe Code Repository},
-  url = {https://github.com/lonkaars/crepe},
-  date = {2024-09-10},
+	author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
+	title = {Crepe Code Repository},
+	url = {https://github.com/lonkaars/crepe},
+	date = {2024-09-10},
 }
 
 @misc{crepe:docs-repo,
-  author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
-  title = {Crepe Documentation Repository},
-  url = {https://github.com/lonkaars},
-  date = {2024-09-10},
+	author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
+	title = {Crepe Documentation Repository},
+	url = {https://github.com/lonkaars},
+	date = {2024-09-10},
 }
 
 @misc{crepe:docs-standard,
-  author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
-  title = {Crepe Documentation Standard},
-  url = {https://github.com/lonkaars/crepe-docs/blob/master/contributing.md},
-  date = {2024-09-10},
+	author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
+	title = {Crepe Documentation Standard},
+	url = {https://github.com/lonkaars/crepe-docs/blob/master/contributing.md},
+	date = {2024-09-10},
 }
 
 @misc{crepe:code-standard,
-  author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
-  title = {Crepe Code Standard},
-  url = {https://github.com/lonkaars/crepe/blob/master/contributing.md},
-  date = {2024-09-10},
+	author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
+	title = {Crepe Code Standard},
+	url = {https://github.com/lonkaars/crepe/blob/master/contributing.md},
+	date = {2024-09-10},
 }
 
+@report{crepe:requirements,
+	author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
+	title = {Requirements},
+	date = {2024-09-18},
+}
+
+@online{lib:miniaudio,
+	title = {miniaudio - A single file audio playback and capture library.},
+	% author = {David Reid},
+	url = {https://miniaud.io},
+	urldate = {2024-09-18},
+}
+
+@online{lib:yse,
+	title = {YSE - cross-platform sound engine},
+	url = {https://www.attr-x.net/yse},
+	urldate = {2024-09-18},
+}
+
+@online{lib:soloud,
+	title = {SoLoud},
+	% author = {Jari Komppa},
+	url = {https://solhsa.com/soloud},
+	urldate = {2024-09-18},
+}
+
+@online{lib:fmod,
+	title = {FMOD},
+	url = {https://www.fmod.com},
+	urldate = {2024-09-18},
+}
+
+@online{lib:portaudio,
+	title = {PortAudio - an Open-Source Cross-Platform Audio API},
+	url = {https://www.portaudio.com},
+	urldate = {2024-09-18},
+}
 
-- 
cgit v1.2.3


From 395ef912d0b5d398874cc37021ea0e6c0e94f38a Mon Sep 17 00:00:00 2001
From: Loek Le Blansch <loek@pipeframe.xyz>
Date: Wed, 18 Sep 2024 17:39:53 +0200
Subject: WIP research

---
 research.tex | 49 ++++++++++++++++++++++++++++++++++++++++++++++---
 sources.bib  |  6 ++++++
 2 files changed, 52 insertions(+), 3 deletions(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index abfde3b..175c92b 100644
--- a/research.tex
+++ b/research.tex
@@ -206,11 +206,17 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 The game engine is required to have an audio system
 \autocite[\ref{req:audio}]{crepe:requirements}. Since writing a custom real-time
 audio mixing engine is outside the scope of this project\mref, this section compares
-various standalone audio engines that could be used in the engine.
+various standalone audio libraries for suitability in the engine.
+
+\Cref{sec:audio:libs} details which libraries were considered,
+\cref{sec:audio:benchmark} compares their performance, and
+\cref{sec:audio:conclusion} concludes with a recommendation for most performant audio
+library.
 
 \subsection{Libraries}
+\label{sec:audio:libs}
 
-\Cref{tab:audio-engines} compares several standalone audio engine libraries that fit
+\Cref{tab:audio:libs} lists the standalone audio engine libraries that fit
 \cref{req:audio,req:lib:license}.
 
 \begin{table}
@@ -225,7 +231,7 @@ various standalone audio engines that could be used in the engine.
 		\bottomrule
 	\end{tabular}
 	\caption{Audio engine library comparison}
-	\label{tab:audio-engines}
+	\label{tab:audio:libs}
 \end{table}
 
 Other popular libraries that were researched but are unsuitable for this project
@@ -235,6 +241,43 @@ include:\noparbreak
 	\item[PortAudio \autocite{lib:portaudio}] Does not handle mixing
 \end{description}
 
+\subsection{Benchmarks}
+\label{sec:audio:benchmark}
+
+The same benchmark application was written for each of the libraries listed in
+\cref{tab:audio:libs}. The application does the following:\noparbreak
+\begin{enumerate}
+	\item Load a background track (Ogg Vorbis)
+	\item Load three short samples (WAV)
+	\item Start the background track
+	\item Play each sample sequentially while pausing and resuming the background track
+	\item Play all samples simultaniously
+	\item Stop all audio and exit
+\end{enumerate}
+
+Each benchmark was profiled using \emph{perf} \autocite{tool:perf} and compared based
+on total CPU and memory utilization. The results of these benchmarks are listed in
+\cref{tab:audio:benchmark}.
+
+\begin{table}
+	\centering
+	\begin{tabular}{lr}
+		\toprule
+		\textbf{Library} & \textbf{???}\\
+		\midrule
+		miniaudio &\\
+		YSE &\\
+		SoLoud &\\
+		\bottomrule
+	\end{tabular}
+	\caption{Audio engine library benchmark results}
+	\label{tab:audio:benchmark}
+\end{table}
+
+\subsection{Conclusion}
+\label{sec:audio:conclusion}
+
+
 \section{Physics}
 
 \subsection{Introduction}
diff --git a/sources.bib b/sources.bib
index 6f5ce0c..33f3a2e 100644
--- a/sources.bib
+++ b/sources.bib
@@ -85,3 +85,9 @@
 	urldate = {2024-09-18},
 }
 
+@online{tool:perf,
+	title = {\texttt{perf:} Linux profiling with performance counters},
+	url = {https://perf.wiki.kernel.org/index.php/Main_Page},
+	urldate = {2024-09-18},
+}
+
-- 
cgit v1.2.3


From d8d57711c340ae58bf14946372fdffd9642532b5 Mon Sep 17 00:00:00 2001
From: Max-001 <80035972+Max-001@users.noreply.github.com>
Date: Wed, 18 Sep 2024 17:51:58 +0200
Subject: Described possible game engine structures

---
 img/DecoratorDesignPattern.png | Bin 0 -> 13528 bytes
 research.tex                   |  30 +++++++++++++++++++++++++++---
 sources.bib                    |  23 +++++++++++++++++++++++
 3 files changed, 50 insertions(+), 3 deletions(-)
 create mode 100644 img/DecoratorDesignPattern.png

(limited to 'research.tex')

diff --git a/img/DecoratorDesignPattern.png b/img/DecoratorDesignPattern.png
new file mode 100644
index 0000000..8830a3d
Binary files /dev/null and b/img/DecoratorDesignPattern.png differ
diff --git a/research.tex b/research.tex
index f62f736..052a5b2 100644
--- a/research.tex
+++ b/research.tex
@@ -53,9 +53,34 @@ layers are divided into the following categories:\noparbreak
 
 The above mentioned layers should be structured, somehow. One of the requirements is
 that the game engine's API uses a so-called gameObject (with one or more component(s)).
-The gameObject is described in more detail at \cref{sec:Gameobjects/components}. ...
+The gameObject is described in more detail at \cref{sec:Gameobjects/components}.
+
+There are multiple structures that could be used to structure a game engine. It's of
+course possible to use inheritance. A major disadvantages of inheritance is that it's
+not flexible. However, the provided class diagram of the game engine's API already
+specifies that composition should be used (in stead of inheritance). So, let's take a
+look at structures that use composition.
+
+The Decorator design pattern (as shown in \cref{fig:decorator}) could be used to structure
+the game engine. A gameObject's propperties/behavior is determined by one (or more)
+components. The Decorator design pattern allows to modify an object's propperties/behavior
+by adding one (or more) Decorators. The object that is modified, could be the gameObject and
+the components could be the Decorators. This is not exactly the same as the required API,
+but it's very close. A major disadvantage of such Decorator design pattern, is that the
+interface of all components should be the same (they should share the same methods), because
+the client (which is the scene in our case) can only call/reach the components through the
+interface. This would require very general methods (at the interface), which might make the
+programming harder. \autocite{man:DecoratorDesignPattern} \autocite{man:Decorator}
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.5\textwidth]{img/DecoratorDesignPattern.png}
+    \caption{Decorator design pattern \autocite{img:Decorator}}
+    \label{fig:decorator}
+\end{figure}
+
+Another very popular design pattern, is the Entity Component System (\gls{ecs}). ...
 
-\subsubsection{ECS}
+\paragraph{ECS}
 
 A game engine must have the ability to keep track and update several game objects. To
 do this most game engines employ an \gls{ecs} model which uses modulair components to
@@ -71,7 +96,6 @@ such as audio, position, or physics. To create diverse entities with specific
 functions: A scene can contain many different kinds of entities, each with different
 properties and functions. But no matter how different each entity is, it remains an
 entity. To assign properties and functions to entities, components are used.
-% TODO: ref?entt
 
 There are many C/C++ libraries available, completely dedicated to \gls{ecs}. The most
 popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is based
diff --git a/sources.bib b/sources.bib
index d6b960b..e754959 100644
--- a/sources.bib
+++ b/sources.bib
@@ -76,3 +76,26 @@
   url = {https://docs.unity3d.com/Manual/class-Transform.html},
   date = {2024}
 }
+
+@misc{img:Decorator,
+  title = {Decorator Pattern Structure Diagram},
+  author = {Refactoring Guru},
+  url = {https://refactoring.guru/images/patterns/diagrams/decorator/structure.png},
+  date = {2024}
+}
+
+@manual{man:DecoratorDesignPattern,
+  title = {Extension Object Design Pattern},
+  author = {James Fawcett},
+  organization = {Syracuse University},
+  url = {https://ecs.syr.edu/faculty/fawcett/handouts/CSE776/PatternPDFs/ExtensionObject.pdf},
+  date = {2024}
+}
+
+@manual{man:Decorator,
+  title = {Decorator Design Pattern},
+  author = {Refactoring Guru},
+	organization = {Refactoring Guru},
+  url = {https://refactoring.guru/design-patterns/decorator},
+  date = {2024}
+}
-- 
cgit v1.2.3


From c69c8815df1c0e1e6ef155a9cfc4747132e0e1c6 Mon Sep 17 00:00:00 2001
From: Max-001 <80035972+Max-001@users.noreply.github.com>
Date: Wed, 18 Sep 2024 18:11:19 +0200
Subject: Made a begin for the ECS

---
 research.tex | 30 +++++++++++-------------------
 1 file changed, 11 insertions(+), 19 deletions(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index 052a5b2..1ca5a2e 100644
--- a/research.tex
+++ b/research.tex
@@ -49,7 +49,7 @@ layers are divided into the following categories:\noparbreak
 	\item[AI] Provides artificial inteligent behavior.
 \end{description}
 
-\subsubsection{Structure}
+\subsubsection{Structures}
 
 The above mentioned layers should be structured, somehow. One of the requirements is
 that the game engine's API uses a so-called gameObject (with one or more component(s)).
@@ -78,24 +78,16 @@ programming harder. \autocite{man:DecoratorDesignPattern} \autocite{man:Decorato
     \label{fig:decorator}
 \end{figure}
 
-Another very popular design pattern, is the Entity Component System (\gls{ecs}). ...
-
-\paragraph{ECS}
-
-A game engine must have the ability to keep track and update several game objects. To
-do this most game engines employ an \gls{ecs} model which uses modulair components to
-give entities properties and features. The need for an entity component system arises
-because multiple game objects are required to create a scene in a game. These game
-objects exist within the scene and perform actions, such as a UI display for a score.
-This game object does not need to be rendered; it could be a script running in the
-background. It could also be a player sprite that is controlled. These entities need
-to be aware of other entities, for example, during collisions. For this to function,
-a scene is required to host all game objects. Within this scene, the game objects
-must be stored efficiently, and entities must be provided with the required behavior,
-such as audio, position, or physics. To create diverse entities with specific
-functions: A scene can contain many different kinds of entities, each with different
-properties and functions. But no matter how different each entity is, it remains an
-entity. To assign properties and functions to entities, components are used.
+TODO: Add Extension Objects design pattern (if this is applicable)!
+
+Another (very popular) design pattern to structure the game engine, is the Entity Component
+System (\gls{ecs}). The \gls{ecs} is made out of three main subsystems, namely entities,
+components and systems. Entities are just IDs. An entity is made out of a gameObject and one
+(or more) components. Components are the classes that hold the data. The components determine
+what kind of entity it is (e.g. a sprite, audio, and so on). Systems take care of the behavior
+of the entities. Systems mainly read and write the enity's components data. The \gls{ecs}
+clearly distinguishes the data (components) from the functionality (systems).
+TODO: Continue this explanation (also add some diagrams to make the ECS more clear)!
 
 There are many C/C++ libraries available, completely dedicated to \gls{ecs}. The most
 popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is based
-- 
cgit v1.2.3


From 7dc00a616e186bb8b02902e06b7cb38164acbbbd Mon Sep 17 00:00:00 2001
From: Loek Le Blansch <loek@pipeframe.xyz>
Date: Wed, 18 Sep 2024 20:51:55 +0200
Subject: merge #15

---
 img/decorator-design-pattern.puml | 62 +++++++++++++++++++++++++
 img/theme.ipuml                   |  9 +++-
 research.tex                      | 93 ++++++++++++++++++++-----------------
 sources.bib                       | 97 ++++++++++++++++++++-------------------
 4 files changed, 169 insertions(+), 92 deletions(-)
 create mode 100644 img/decorator-design-pattern.puml

(limited to 'research.tex')

diff --git a/img/decorator-design-pattern.puml b/img/decorator-design-pattern.puml
new file mode 100644
index 0000000..2bc406b
--- /dev/null
+++ b/img/decorator-design-pattern.puml
@@ -0,0 +1,62 @@
+@startuml
+!include theme.ipuml
+skinparam style strictuml
+skinparam Linetype ortho
+
+class Client
+class Component <<interface>> {
+	+ execute()
+	--
+}
+class ConcComponent as "Concrete\nComponent" {
+	...
+	--
+	+ execute()
+}
+class BaseDecorator as "Base Decorator" {
+	- wrappee: Component
+	+ BaseDecorator(c: Component)
+	+ execute()
+}
+class ConcDecorator as "Concrete\nDecorators" {
+	...
+	--
+	+ execute()
+	+ extra()
+}
+
+hide Client members
+hide circle
+
+Client --> Component
+Component <|.. ConcComponent
+Component <|.. BaseDecorator
+Component <--o BaseDecorator
+BaseDecorator <|-- ConcDecorator
+
+ConcComponent -right[hidden] BaseDecorator
+
+note right of Client
+	a = <b>new</b> ConcComponent()
+	b = <b>new</b> ConcDecorator1(a)
+	c = <b>new</b> ConcDecorator1(b)
+	c.execute()
+	// Decorator -> Decorator -> Component
+end note
+
+note right of BaseDecorator::BaseDecorator
+	wrappee = c
+end note
+
+note right of BaseDecorator::execute
+	wrappee.execute()
+end note
+
+note right of ConcDecorator::execute
+	super::execute()
+	extra()
+end note
+
+@enduml
+
+" referenced from <https://github.com/algamza/algamza.github.io>
diff --git a/img/theme.ipuml b/img/theme.ipuml
index 88d183a..4e3613e 100644
--- a/img/theme.ipuml
+++ b/img/theme.ipuml
@@ -1,5 +1,10 @@
 !theme plain
-skinparam DefaultFontSize 14
+skinparam ClassAttributeIconSize 0
+skinparam ClassFontStyle bold
 skinparam DefaultFontName Inter
+skinparam DefaultFontSize 14
+skinparam MaxMessageSize 200
+skinparam Nodesep 25
+skinparam Padding 2
+skinparam Ranksep 50
 skinparam RoundCorner 0
-skinparam maxMessageSize 200
diff --git a/research.tex b/research.tex
index 1ca5a2e..e07a428 100644
--- a/research.tex
+++ b/research.tex
@@ -52,8 +52,9 @@ layers are divided into the following categories:\noparbreak
 \subsubsection{Structures}
 
 The above mentioned layers should be structured, somehow. One of the requirements is
-that the game engine's API uses a so-called gameObject (with one or more component(s)).
-The gameObject is described in more detail at \cref{sec:Gameobjects/components}.
+that the game engine's API uses a so-called gameObject (with one or more
+component(s)). The gameObject is described in more detail at
+\cref{sec:Gameobjects/components}.
 
 There are multiple structures that could be used to structure a game engine. It's of
 course possible to use inheritance. A major disadvantages of inheritance is that it's
@@ -61,54 +62,62 @@ not flexible. However, the provided class diagram of the game engine's API alrea
 specifies that composition should be used (in stead of inheritance). So, let's take a
 look at structures that use composition.
 
-The Decorator design pattern (as shown in \cref{fig:decorator}) could be used to structure
-the game engine. A gameObject's propperties/behavior is determined by one (or more)
-components. The Decorator design pattern allows to modify an object's propperties/behavior
-by adding one (or more) Decorators. The object that is modified, could be the gameObject and
-the components could be the Decorators. This is not exactly the same as the required API,
-but it's very close. A major disadvantage of such Decorator design pattern, is that the
-interface of all components should be the same (they should share the same methods), because
-the client (which is the scene in our case) can only call/reach the components through the
-interface. This would require very general methods (at the interface), which might make the
-programming harder. \autocite{man:DecoratorDesignPattern} \autocite{man:Decorator}
-\begin{figure}[H]
-    \centering
-    \includegraphics[width=0.5\textwidth]{img/DecoratorDesignPattern.png}
-    \caption{Decorator design pattern \autocite{img:Decorator}}
-    \label{fig:decorator}
+The Decorator design pattern (as shown in \cref{fig:decorator}) could be used to
+structure the game engine. A gameObject's propperties/behavior is determined by one
+(or more) components. The Decorator design pattern allows to modify an object's
+propperties/behavior by adding one (or more) Decorators. The object that is modified,
+could be the gameObject and the components could be the Decorators. This is not
+exactly the same as the required API, but it's very close. A major disadvantage of
+such Decorator design pattern, is that the interface of all components should be the
+same (they should share the same methods), because the client (which is the scene in
+our case) can only call/reach the components through the interface. This would
+require very general methods (at the interface), which might make the programming
+harder \autocite{man:DecoratorDesignPattern,man:Decorator}.
+
+\begin{figure}
+	\centering
+	\includepumldiag{img/decorator-design-pattern.puml}
+	\caption{Decorator design pattern}
+	Source: \autocite{img:Decorator}
+	\label{fig:decorator}
 \end{figure}
 
 TODO: Add Extension Objects design pattern (if this is applicable)!
 
-Another (very popular) design pattern to structure the game engine, is the Entity Component
-System (\gls{ecs}). The \gls{ecs} is made out of three main subsystems, namely entities,
-components and systems. Entities are just IDs. An entity is made out of a gameObject and one
-(or more) components. Components are the classes that hold the data. The components determine
-what kind of entity it is (e.g. a sprite, audio, and so on). Systems take care of the behavior
-of the entities. Systems mainly read and write the enity's components data. The \gls{ecs}
-clearly distinguishes the data (components) from the functionality (systems).
-TODO: Continue this explanation (also add some diagrams to make the ECS more clear)!
+Another (very popular) design pattern to structure the game engine, is the Entity
+Component System (\gls{ecs}). The \gls{ecs} is made out of three main subsystems,
+namely entities, components and systems. Entities are just IDs. An entity is made out
+of a gameObject and one (or more) components. Components are the classes that hold
+the data. The components determine what kind of entity it is (e.g. a sprite, audio,
+and so on). Systems take care of the behavior of the entities. Systems mainly read
+and write the enity's components data. The \gls{ecs} clearly distinguishes the data
+(components) from the functionality (systems).
+
+% TODO: Continue this explanation (also add some diagrams to make the ECS more clear)!
 
 There are many C/C++ libraries available, completely dedicated to \gls{ecs}. The most
-popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is based
-on the amount of stars on GitHub.
-\begin{table}[ht]
-    \centering
-    \begin{tabular}{ll@{\qquad}lr}
-        \toprule
-        \textbf{Name} & \textbf{Short Description} & \textbf{Stars} & \textbf{License} \\
-        \midrule
-        EnTT & Fast and reliable entity-component system & 10k & MIT \\
-        Flecs & A Multithreaded Entity Component System & 6.3k & MIT \\
-        EntityX & Fast, type-safe C++ entity component system & 2.2k & MIT \\
-        \bottomrule
-    \end{tabular}
-    \caption{Popular \gls{ecs} libraries \autocite{github:001}}
-    \label{tab:popularECSLibraries}
+popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is
+based on the amount of stars on GitHub.
+
+\begin{table}
+	\centering
+	\begin{tabular}{ll@{\qquad}lr}
+		\toprule
+		\textbf{Name} & \textbf{Short Description} & \textbf{Stars} & \textbf{License}\\
+		\midrule
+		EnTT & Fast and reliable entity-component system & 10k & MIT\\
+		Flecs & A Multithreaded Entity Component System & 6.3k & MIT\\
+		EntityX & Fast, type-safe C++ entity component system & 2.2k & MIT\\
+		\bottomrule
+	\end{tabular}
+	\caption{Popular \gls{ecs} libraries}
+	Source: \autocite{github:awesome-ecs}
+	\label{tab:popularECSLibraries}
 \end{table}
 
-It is, of course, not necessary to use a library to implement an \gls{ecs} architecture.
-However, it seems very hard to achieve the same performance as a library. \autocite{github:002}
+It is, of course, not necessary to use a library to implement an \gls{ecs}
+architecture. However, it seems very hard to achieve the same performance as a
+library \autocite{github:ecsfaq}.
 
 \subsection{Conclusion}
 
diff --git a/sources.bib b/sources.bib
index e754959..bf04165 100644
--- a/sources.bib
+++ b/sources.bib
@@ -13,89 +13,90 @@
 }
 
 @misc{miro:scrum-board,
-  author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
-  title = {Scrum Board on Miro},
-  url = {https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474},
-  date = {2024-09-10},
+	author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
+	title = {Scrum Board on Miro},
+	url = {https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474},
+	date = {2024-09-10},
 }
 
 @misc{crepe:code-repo,
-  author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
-  title = {Crepe Code Repository},
-  url = {https://github.com/lonkaars/crepe},
-  date = {2024-09-10},
+	author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
+	title = {Crepe Code Repository},
+	url = {https://github.com/lonkaars/crepe},
+	date = {2024-09-10},
 }
 
 @misc{crepe:docs-repo,
-  author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
-  title = {Crepe Documentation Repository},
-  url = {https://github.com/lonkaars},
-  date = {2024-09-10},
+	author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
+	title = {Crepe Documentation Repository},
+	url = {https://github.com/lonkaars},
+	date = {2024-09-10},
 }
 
 @misc{crepe:docs-standard,
-  author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
-  title = {Crepe Documentation Standard},
-  url = {https://github.com/lonkaars/crepe-docs/blob/master/contributing.md},
-  date = {2024-09-10},
+	author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
+	title = {Crepe Documentation Standard},
+	url = {https://github.com/lonkaars/crepe-docs/blob/master/contributing.md},
+	date = {2024-09-10},
 }
 
 @misc{crepe:code-standard,
-  author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
-  title = {Crepe Code Standard},
-  url = {https://github.com/lonkaars/crepe/blob/master/contributing.md},
-  date = {2024-09-10},
+	author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
+	title = {Crepe Code Standard},
+	url = {https://github.com/lonkaars/crepe/blob/master/contributing.md},
+	date = {2024-09-10},
 }
 
-@misc{github:001,
-  author = {Sangjun Lee},
-  title = {Awesome Entity Component System},
-  url = {https://github.com/jslee02/awesome-entity-component-system?tab=readme-ov-file},
+@misc{github:awesome-ecs,
+	author = {Sangjun Lee},
+	title = {Awesome Entity Component System},
+	url = {https://github.com/jslee02/awesome-entity-component-system?tab=readme-ov-file},
 	date = {2023}
 }
 
-@misc{github:002,
-  author = {Sander Mertens},
-  title = {ECS FAQ},
-  url = {https://github.com/SanderMertens/ecs-faq?tab=readme-ov-file#should-i-write-my-own-ecs},
+@misc{github:ecsfaq,
+	author = {Sander Mertens},
+	title = {ECS FAQ},
+	url = {https://github.com/SanderMertens/ecs-faq?tab=readme-ov-file#should-i-write-my-own-ecs},
 	date = {2023}
 }
 
 @manual{man:unityGameobjects,
 	title = {GameObject},
 	author = {Unity Technologies},
-  organization = {Unity},
-  url = {https://docs.unity3d.com/Manual/GameObjects.html},
+	organization = {Unity},
+	url = {https://docs.unity3d.com/Manual/GameObjects.html},
 	date = {2024}
 }
 
 @manual{man:unityTransformClass,
-  title = {Transform Class},
-  author = {Unity Technologies},
-  organization = {Unity},
-  url = {https://docs.unity3d.com/Manual/class-Transform.html},
-  date = {2024}
+	title = {Transform Class},
+	author = {Unity Technologies},
+	organization = {Unity},
+	url = {https://docs.unity3d.com/Manual/class-Transform.html},
+	date = {2024}
 }
 
 @misc{img:Decorator,
-  title = {Decorator Pattern Structure Diagram},
-  author = {Refactoring Guru},
-  url = {https://refactoring.guru/images/patterns/diagrams/decorator/structure.png},
-  date = {2024}
+	title = {Decorator Pattern Structure Diagram},
+	author = {Refactoring Guru},
+	url = {https://refactoring.guru/images/patterns/diagrams/decorator/structure.png},
+	date = {2024}
 }
 
 @manual{man:DecoratorDesignPattern,
-  title = {Extension Object Design Pattern},
-  author = {James Fawcett},
-  organization = {Syracuse University},
-  url = {https://ecs.syr.edu/faculty/fawcett/handouts/CSE776/PatternPDFs/ExtensionObject.pdf},
-  date = {2024}
+	title = {Extension Object Design Pattern},
+	author = {James Fawcett},
+	organization = {Syracuse University},
+	url = {https://ecs.syr.edu/faculty/fawcett/handouts/CSE776/PatternPDFs/ExtensionObject.pdf},
+	date = {2024}
 }
 
 @manual{man:Decorator,
-  title = {Decorator Design Pattern},
-  author = {Refactoring Guru},
+	title = {Decorator Design Pattern},
+	author = {Refactoring Guru},
 	organization = {Refactoring Guru},
-  url = {https://refactoring.guru/design-patterns/decorator},
-  date = {2024}
+	url = {https://refactoring.guru/design-patterns/decorator},
+	date = {2024}
 }
+
-- 
cgit v1.2.3


From 14788335ba110076e8beb72a0330712d238cf12a Mon Sep 17 00:00:00 2001
From: Loek Le Blansch <loek@pipeframe.xyz>
Date: Wed, 18 Sep 2024 20:54:41 +0200
Subject: refactor pro/cons in research

---
 research.tex | 60 +++++++++++++++++++++++++-----------------------------------
 1 file changed, 25 insertions(+), 35 deletions(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index e07a428..5340bf5 100644
--- a/research.tex
+++ b/research.tex
@@ -152,23 +152,18 @@ software, emulators, and popular games, including Valve's award-winning catalog
 many Humble Bundle games.''} \gls{sdl2} is written in the C programming language, and
 therefore, structs and functions are used instead of objects and methods.
 
-The advantages of \gls{sdl2} are:\noparbreak
-\begin{itemize}
-	\item Controller support is provided.
-	\item 2D and 3D rendering are supported.
-	\item Broad multiplatform support is offered, including older consoles such as the
-		Wii.
-	\item Low-level control is available.
-	\item A large community ensures wide usage.
-	\item Extended libraries can be used to add functionalities, such as SDL\_Mixer for
-		sound.
-\end{itemize}
-
-The disadvantages of \gls{sdl2} are:\noparbreak
-\begin{itemize}
-	\item A limited built-in 2D renderer is provided.
-	\item Extended libraries require setup.
-\end{itemize}
+\begin{comparison}
+	\pro{Controller support is provided.}
+	\pro{2D and 3D rendering are supported.}
+	\pro{Broad multiplatform support is offered, including older consoles such as the
+	Wii.}
+	\pro{Low-level control is available.}
+	\pro{A large community ensures wide usage.}
+	\pro{Extended libraries can be used to add functionalities, such as SDL\_Mixer for
+	sound.}
+	\con{A limited built-in 2D renderer is provided.}
+	\con{Extended libraries require setup.}
+\end{comparison}
 
 \paragraph{SFML}
 
@@ -176,24 +171,19 @@ The disadvantages of \gls{sdl2} are:\noparbreak
 network, system, and window. This framework, written in C++, was designed to simplify
 game development.
 
-The advantages of \gls{sfml} are:
-\begin{itemize}
-	\item Object-oriented design is provided since it is written in C++.
-	\item A built-in 2D renderer is available for ease of use.
-	\item A built-in audio system is included.
-	\item Cross-platform support is available for Linux, Windows, and macOS.
-	\item Networking capabilities are provided for multiplayer or networked
-		applications.
-\end{itemize}
-
-The disadvantages of \gls{sfml} are:
-\begin{itemize}
-	\item The 2D rendering engine may experience performance issues in large-scale
-		games.
-	\item The community is smaller compared to \gls{sdl2}.
-	\item No native 3D support is provided.
-	\item Not all image formats are supported.
-\end{itemize}
+\begin{comparison}
+	\pro{Object-oriented design is provided since it is written in C++.}
+	\pro{A built-in 2D renderer is available for ease of use.}
+	\pro{A built-in audio system is included.}
+	\pro{Cross-platform support is available for Linux, Windows, and macOS.}
+	\pro{Networking capabilities are provided for multiplayer or networked
+	applications.}
+	\con{The 2D rendering engine may experience performance issues in large-scale
+	games.}
+	\con{The community is smaller compared to \gls{sdl2}.}
+	\con{No native 3D support is provided.}
+	\con{Not all image formats are supported.}
+\end{comparison}
 
 \subsubsection{Audio}
 
-- 
cgit v1.2.3


From 7102902f319d450253159a20da207b013d77f7ce Mon Sep 17 00:00:00 2001
From: Max-001 <80035972+Max-001@users.noreply.github.com>
Date: Fri, 20 Sep 2024 13:13:33 +0200
Subject: Replaced .puml with .png, since .puml was causing LaTeX errors

---
 research.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index 5340bf5..ffba7ca 100644
--- a/research.tex
+++ b/research.tex
@@ -76,7 +76,7 @@ harder \autocite{man:DecoratorDesignPattern,man:Decorator}.
 
 \begin{figure}
 	\centering
-	\includepumldiag{img/decorator-design-pattern.puml}
+	\includegraphics[width=0.5\textwidth]{img/DecoratorDesignPattern.png}
 	\caption{Decorator design pattern}
 	Source: \autocite{img:Decorator}
 	\label{fig:decorator}
-- 
cgit v1.2.3


From 6f802231674685b9d1bb365d345c96aa15cdd311 Mon Sep 17 00:00:00 2001
From: Max-001 <80035972+Max-001@users.noreply.github.com>
Date: Fri, 20 Sep 2024 14:47:03 +0200
Subject: Added the Extension Objects and ECS design patterns

---
 img/ECSBlockDiagram.png     | Bin 0 -> 64822 bytes
 img/ECSComponentManager.png | Bin 0 -> 247012 bytes
 img/ExtensionObjects.jpg    | Bin 0 -> 48639 bytes
 research.tex                |  72 ++++++++++++++++++++++++++++++++++++--------
 sources.bib                 |  32 ++++++++++++++++++--
 5 files changed, 90 insertions(+), 14 deletions(-)
 create mode 100644 img/ECSBlockDiagram.png
 create mode 100644 img/ECSComponentManager.png
 create mode 100644 img/ExtensionObjects.jpg

(limited to 'research.tex')

diff --git a/img/ECSBlockDiagram.png b/img/ECSBlockDiagram.png
new file mode 100644
index 0000000..4d36afa
Binary files /dev/null and b/img/ECSBlockDiagram.png differ
diff --git a/img/ECSComponentManager.png b/img/ECSComponentManager.png
new file mode 100644
index 0000000..6602cd6
Binary files /dev/null and b/img/ECSComponentManager.png differ
diff --git a/img/ExtensionObjects.jpg b/img/ExtensionObjects.jpg
new file mode 100644
index 0000000..4807ff7
Binary files /dev/null and b/img/ExtensionObjects.jpg differ
diff --git a/research.tex b/research.tex
index ffba7ca..bec9471 100644
--- a/research.tex
+++ b/research.tex
@@ -24,7 +24,7 @@ A game engine is not the game itself but a platform with which games are built.
 should provide the functionalities with which the game is constructed. The purpose of
 a game engine is not to create data out of nothing. Instead, data is read, and the
 correlating features and effects are generated. However, the engine is also used to
-create these files, referred to as ``assets.'' The game engine must be able to accept
+create these files, referred to as ``assets''. The game engine must be able to accept
 a certain format of these assets---whether levels, sprites, or textures---and convert
 them into usable data.
 
@@ -72,7 +72,7 @@ such Decorator design pattern, is that the interface of all components should be
 same (they should share the same methods), because the client (which is the scene in
 our case) can only call/reach the components through the interface. This would
 require very general methods (at the interface), which might make the programming
-harder \autocite{man:DecoratorDesignPattern,man:Decorator}.
+harder \autocite{man:DecoratorDesignPattern}.
 
 \begin{figure}
 	\centering
@@ -82,18 +82,66 @@ harder \autocite{man:DecoratorDesignPattern,man:Decorator}.
 	\label{fig:decorator}
 \end{figure}
 
-TODO: Add Extension Objects design pattern (if this is applicable)!
+The Extension Objects design pattern (as shown in \cref{fig:extension objects}) could
+also be used to structure the game engine. The Extension Objects design pattern allows
+to modify an object's propperties/behavior by adding one (or more) Extensions. The
+object that is modified, could be the gameObject and the components could be the
+Extensions. This is quite the same as the required API. An advantage is, that the client
+(which is the scene in our case) can call all kind of different Extension's methods
+(depending on the kind of Externsion, e.g. the method render() for the sprite Extension
+and the method update() for the script Extension). In other words, the interfaces of the
+different Extensions should not be the same. This is way more flexible than the Decorator
+design pattern. A disadvantage is that the data and functionality are in the same class
+(namely inside the Extion's methods), so it's not sepperated. Another disadvantage is
+that the Extension Objects design pattern can be quite slow, because objects are scattered
+in memory (and it is very hard to quickly get their memory address)
+\autocite{man:ExtensionObjectDesignPattern, man:extionsionObjectsStackOverflow}.
+
+\begin{figure}
+	\centering
+	\includegraphics[width=0.5\textwidth]{img/ExtensionObjects.jpg}
+	\caption{Extension Objects design pattern}
+	Source: \autocite{img:extionsionObjects}
+	\label{fig:extension objects}
+\end{figure}
 
 Another (very popular) design pattern to structure the game engine, is the Entity
-Component System (\gls{ecs}). The \gls{ecs} is made out of three main subsystems,
-namely entities, components and systems. Entities are just IDs. An entity is made out
-of a gameObject and one (or more) components. Components are the classes that hold
-the data. The components determine what kind of entity it is (e.g. a sprite, audio,
-and so on). Systems take care of the behavior of the entities. Systems mainly read
-and write the enity's components data. The \gls{ecs} clearly distinguishes the data
-(components) from the functionality (systems).
-
-% TODO: Continue this explanation (also add some diagrams to make the ECS more clear)!
+Component System (\gls{ecs}) (as shown in \cref{fig:ECS Block Diagram}). The
+\gls{ecs} is made out of three main subsystems, namely entities, components and
+systems. Entities are just IDs. An entity is made out of a gameObject and one (or
+more) components. Components are the classes that hold the data. The components
+determine what kind of entity it is (e.g. a sprite, audio, and so on). Systems
+take care of the behavior of the entities. Systems mainly read and write the enity's
+components data. The \gls{ecs} clearly distinguishes the data (components) from
+the functionality (systems), which is an advantage.
+
+\begin{figure}
+	\centering
+	\includegraphics[width=0.5\textwidth]{img/ECSBlockDiagram.png}
+	\caption{ECS design pattern}
+	Source: \autocite{img:ECSBlockDiagram}
+	\label{fig:ECS Block Diagram}
+\end{figure}
+
+The \gls{ecs} is normally equipped with a component manager (as shown in
+\cref{fig:ECS Component manager}). The component manager keeps track of the entities
+(Alien, Player, Target, etc in \cref{fig:ECS Component manager}) and the connected
+components (Position, Movement, Render, etc in \cref{fig:ECS Component manager}).
+The component manager stores two lists (key value pairs). The key of the first list
+is the ID of an entity, and the value of this list are the connected components. The key
+of the second list is the component, and the value of this list are the entities that
+have this component. These two lists make it possible to very quickly gather components
+or entities. This makes the \gls{ecs} very fast, which is of course an advantage.
+
+\begin{figure}
+	\centering
+	\includegraphics[width=0.5\textwidth]{img/ECSComponentManager.png}
+	\caption{ECS Component manager}
+	Source: \autocite{img:ECSComponentSystem}
+	\label{fig:ECS Component manager}
+\end{figure}
+
+Disadvantage: systems have to cummincate with each other...
 
 There are many C/C++ libraries available, completely dedicated to \gls{ecs}. The most
 popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is
diff --git a/sources.bib b/sources.bib
index bf04165..e025492 100644
--- a/sources.bib
+++ b/sources.bib
@@ -84,7 +84,7 @@
 	date = {2024}
 }
 
-@manual{man:DecoratorDesignPattern,
+@manual{man:ExtensionObjectDesignPattern,
 	title = {Extension Object Design Pattern},
 	author = {James Fawcett},
 	organization = {Syracuse University},
@@ -92,7 +92,7 @@
 	date = {2024}
 }
 
-@manual{man:Decorator,
+@manual{man:DecoratorDesignPattern,
 	title = {Decorator Design Pattern},
 	author = {Refactoring Guru},
 	organization = {Refactoring Guru},
@@ -100,3 +100,31 @@
 	date = {2024}
 }
 
+@misc{img:extionsionObjects,
+	title = {Extension Objects Diagram},
+	author = {stackoverflow},
+	url = {https://i.sstatic.net/GoIQ6.jpg},
+	date = {2024}
+}
+
+@manual{man:extionsionObjectsStackOverflow,
+	title = {Extension Object Design Pattern},
+	author = {Supun Wijerathne},
+	organization = {stackoverflow},
+	url = {https://stackoverflow.com/questions/39331752/what-is-the-difference-between-extension-objects-pattern-and-adapter-pattern},
+	date = {2016}
+}
+
+@misc{img:ECSBlockDiagram,
+	title = {ECS Diagram},
+	author = {Unity},
+	url = {https://docs.unity3d.com/Packages/com.unity.entities@0.1/manual/images/ECSBlockDiagram.png},
+	date = {2024}
+}
+
+@misc{img:ECSComponentSystem,
+	title = {ECS Component System},
+	author = {Joel van der Werf},
+	url = {https://i.imgur.com/VMQFIjW.png},
+	date = {2024}
+}
-- 
cgit v1.2.3


From 110ffb785a8eaf54106b92f49f008f0003193a2b Mon Sep 17 00:00:00 2001
From: Max-001 <80035972+Max-001@users.noreply.github.com>
Date: Fri, 20 Sep 2024 15:13:48 +0200
Subject: Continued ECS research

---
 research.tex | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index bec9471..8a2ad7b 100644
--- a/research.tex
+++ b/research.tex
@@ -141,7 +141,25 @@ or entities. This makes the \gls{ecs} very fast, which is of course an advantage
 	\label{fig:ECS Component manager}
 \end{figure}
 
-Disadvantage: systems have to cummincate with each other...
+Another aspect that makes the \gls{ecs} very fast, is that a system can handle all
+components (of the same type) together at once. This is possible because all entities
+are independent of each other.
+
+There are many ways of implementing the systems. Some say that each component type has
+their own system. This interpretation of the systems does not take the interplay of
+different component types, into account. A less restrictive approach is to let different
+systems deal with all components they should be concerned with. For instance a Physics
+Systems should be aware of Collision Components and Rigidbody Components, as both
+probably contain necessary information regarding physics simulation. It's best to see
+systems as “closed environments”. That is, they do not take ownership of entities nor
+components. They do access them through independent manager objects, which in turn will
+take care of the entities and components life-cycle.
+
+Sometimes systems, entities and even components need to cummincate with each other. This
+might be very hard because systems, entities and components are more or less independent.
+One option is to use an event systems. A system, entity and component can raise an event
+and other systems, entities and components can react to that event. This is what makes the
+\gls{ecs} a complicated system (disadvantage).
 
 There are many C/C++ libraries available, completely dedicated to \gls{ecs}. The most
 popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is
-- 
cgit v1.2.3


From af0fa4a2ffce5f6a000c376cdadaec935dfc2fc4 Mon Sep 17 00:00:00 2001
From: Max-001 <80035972+Max-001@users.noreply.github.com>
Date: Fri, 20 Sep 2024 15:22:50 +0200
Subject: Added sources

---
 research.tex |  7 ++++---
 sources.bib  | 17 +++++++++++++++++
 2 files changed, 21 insertions(+), 3 deletions(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index 8a2ad7b..f9de6a5 100644
--- a/research.tex
+++ b/research.tex
@@ -131,7 +131,8 @@ The component manager stores two lists (key value pairs). The key of the first l
 is the ID of an entity, and the value of this list are the connected components. The key
 of the second list is the component, and the value of this list are the entities that
 have this component. These two lists make it possible to very quickly gather components
-or entities. This makes the \gls{ecs} very fast, which is of course an advantage.
+or entities. This makes the \gls{ecs} very fast, which is of course an advantage
+\autocite{man:ECSComponentManager}.
 
 \begin{figure}
 	\centering
@@ -153,13 +154,13 @@ Systems should be aware of Collision Components and Rigidbody Components, as bot
 probably contain necessary information regarding physics simulation. It's best to see
 systems as “closed environments”. That is, they do not take ownership of entities nor
 components. They do access them through independent manager objects, which in turn will
-take care of the entities and components life-cycle.
+take care of the entities and components life-cycle \autocite{man:ECSExplanation}.
 
 Sometimes systems, entities and even components need to cummincate with each other. This
 might be very hard because systems, entities and components are more or less independent.
 One option is to use an event systems. A system, entity and component can raise an event
 and other systems, entities and components can react to that event. This is what makes the
-\gls{ecs} a complicated system (disadvantage).
+\gls{ecs} a complicated system (disadvantage) \autocite{man:ECSExplanation}.
 
 There are many C/C++ libraries available, completely dedicated to \gls{ecs}. The most
 popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is
diff --git a/sources.bib b/sources.bib
index e025492..f48e8c3 100644
--- a/sources.bib
+++ b/sources.bib
@@ -128,3 +128,20 @@
 	url = {https://i.imgur.com/VMQFIjW.png},
 	date = {2024}
 }
+
+@manual{man:ECSExplanation,
+  title = {The Entity Component System C++ Game Design Pattern - Part 1},
+  author = {GameDev.net},
+  organization = {GameDev.net},
+  url = {https://www.gamedev.net/tutorials/programming/general-and-gameplay-programming/the-entity-component-system-c-game-design-pattern-part-1-r4803/},
+  date = {2024}
+}
+
+@manual{man:ECSComponentManager,
+  title = {ECS Core API},
+  author = {Unity Technologies},
+  organization = {Unity},
+  url = {https://docs.unity3d.com/Packages/com.unity.entities@0.1/manual/ecs_core.html},
+  date = {2024}
+}
+
-- 
cgit v1.2.3


From b8e3fcbe333558d3c0aa1ae36fe80c161d8202c1 Mon Sep 17 00:00:00 2001
From: Max-001 <80035972+Max-001@users.noreply.github.com>
Date: Fri, 20 Sep 2024 15:34:19 +0200
Subject: Moved the section GameObject/Components upwards

---
 research.tex | 84 ++++++++++++++++++++++++++++++------------------------------
 1 file changed, 42 insertions(+), 42 deletions(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index f9de6a5..ed3d2cf 100644
--- a/research.tex
+++ b/research.tex
@@ -188,6 +188,48 @@ library \autocite{github:ecsfaq}.
 
 \subsection{Conclusion}
 
+\section{Gameobjects/components}
+\label{sec:Gameobjects/components}
+
+\subsection{Introduction}
+
+One of the requirements of our customer, is that the game engine's structure is
+similar to Unity. The customer has created a class diagram of the game engine's API,
+which is (of course) very similar to Unity. One of the most important parts of the
+class diagram is a so-called gameObject (with several components). It's needed to
+understand the exact meaning/function of these gameObjects, that's why this research
+question arose.
+
+\subsection{Findings}
+
+A gameObject is the most important concept in Unity. Every object in a game is a
+GameObject, from characters and collectible items to the lights, cameras and special
+effects. However, a gameObject itself can't do anything on its own. A gameObject
+needs to be given properties before it can become a character, an envirnment, or a
+special effect. \autocite{man:unityGameobjects}
+
+A gameObject can be seen as a container for components. Components are the properties
+of the gameObject. A few examples of components are sprites, animators, audioSources,
+and so on. Multiple (different) components can be assigned to a single gameObject
+(e.g.~a sprite and an audioSource).
+
+Since we now know that a gameObject needs components to do something, it's obvious
+that there should be a way to add components to a gameObject. Some components
+(e.g.~the behaviorScript component) should also be able to reference to its
+gameObject.
+
+Each gameObject always has one transform class. The transform class describes the
+position, rotation, and scale within the scene. Some component use this information
+to e.g. scale a sprite. Other components eddit this information to e.g.~model
+gravity. \autocite{man:unityTransformClass}
+
+A gameObject can have one (or multiple) children gameObject(s). All children
+gameObjects, of course, also have one transform class. However, the position,
+rotation, and scale of this class, is always the same as the child's parent. A child
+can not have more than one parent. \autocite{man:unityTransformClass}
+
+\subsection{Conclusion}
+
 \section{Third-party Tools}
 
 \subsection{Introduction}
@@ -371,48 +413,6 @@ Not considered further:
 
 \subsection{Conclusion}
 
-\section{Gameobjects/components}
-\label{sec:Gameobjects/components}
-
-\subsection{Introduction}
-
-One of the requirements of our customer, is that the game engine's structure is
-similar to Unity. The customer has created a class diagram of the game engine's API,
-which is (of course) very similar to Unity. One of the most important parts of the
-class diagram is a so-called gameObject (with several components). It's needed to
-understand the exact meaning/function of these gameObjects, that's why this research
-question arose.
-
-\subsection{Findings}
-
-A gameObject is the most important concept in Unity. Every object in a game is a
-GameObject, from characters and collectible items to the lights, cameras and special
-effects. However, a gameObject itself can't do anything on its own. A gameObject
-needs to be given properties before it can become a character, an envirnment, or a
-special effect. \autocite{man:unityGameobjects}
-
-A gameObject can be seen as a container for components. Components are the properties
-of the gameObject. A few examples of components are sprites, animators, audioSources,
-and so on. Multiple (different) components can be assigned to a single gameObject
-(e.g.~a sprite and an audioSource).
-
-Since we now know that a gameObject needs components to do something, it's obvious
-that there should be a way to add components to a gameObject. Some components
-(e.g.~the behaviorScript component) should also be able to reference to its
-gameObject.
-
-Each gameObject always has one transform class. The transform class describes the
-position, rotation, and scale within the scene. Some component use this information
-to e.g. scale a sprite. Other components eddit this information to e.g.~model
-gravity. \autocite{man:unityTransformClass}
-
-A gameObject can have one (or multiple) children gameObject(s). All children
-gameObjects, of course, also have one transform class. However, the position,
-rotation, and scale of this class, is always the same as the child's parent. A child
-can not have more than one parent. \autocite{man:unityTransformClass}
-
-\subsection{Conclusion}
-
 \section{AI}
 
 \subsection{Introduction}
-- 
cgit v1.2.3


From 444550c8fa8c88fcfe4c450012156051a0ea60c7 Mon Sep 17 00:00:00 2001
From: Max-001 <80035972+Max-001@users.noreply.github.com>
Date: Fri, 20 Sep 2024 15:48:13 +0200
Subject: Added a TODO

---
 research.tex | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index ed3d2cf..ed34730 100644
--- a/research.tex
+++ b/research.tex
@@ -182,6 +182,8 @@ based on the amount of stars on GitHub.
 	\label{tab:popularECSLibraries}
 \end{table}
 
+TODO: Add library benchmark to find the best library.
+
 It is, of course, not necessary to use a library to implement an \gls{ecs}
 architecture. However, it seems very hard to achieve the same performance as a
 library \autocite{github:ecsfaq}.
-- 
cgit v1.2.3


From 375a551a1b59bfa34b3a419b2f00363afd4206ea Mon Sep 17 00:00:00 2001
From: Loek Le Blansch <loek@pipeframe.xyz>
Date: Sat, 21 Sep 2024 14:50:19 +0200
Subject: merge #21

---
 research.tex | 79 +++++++++++++++++++++++++++++++-----------------------------
 1 file changed, 41 insertions(+), 38 deletions(-)

(limited to 'research.tex')

diff --git a/research.tex b/research.tex
index ed34730..1f55d70 100644
--- a/research.tex
+++ b/research.tex
@@ -83,18 +83,19 @@ harder \autocite{man:DecoratorDesignPattern}.
 \end{figure}
 
 The Extension Objects design pattern (as shown in \cref{fig:extension objects}) could
-also be used to structure the game engine. The Extension Objects design pattern allows
-to modify an object's propperties/behavior by adding one (or more) Extensions. The
-object that is modified, could be the gameObject and the components could be the
-Extensions. This is quite the same as the required API. An advantage is, that the client
-(which is the scene in our case) can call all kind of different Extension's methods
-(depending on the kind of Externsion, e.g. the method render() for the sprite Extension
-and the method update() for the script Extension). In other words, the interfaces of the
-different Extensions should not be the same. This is way more flexible than the Decorator
-design pattern. A disadvantage is that the data and functionality are in the same class
-(namely inside the Extion's methods), so it's not sepperated. Another disadvantage is
-that the Extension Objects design pattern can be quite slow, because objects are scattered
-in memory (and it is very hard to quickly get their memory address)
+also be used to structure the game engine. The Extension Objects design pattern
+allows to modify an object's propperties/behavior by adding one (or more) Extensions.
+The object that is modified, could be the gameObject and the components could be the
+Extensions. This is quite the same as the required API. An advantage is, that the
+client (which is the scene in our case) can call all kind of different Extension's
+methods (depending on the kind of Externsion, e.g.~the method \codeinline{render()}
+for the sprite Extension and the method \codeinline{update()} for the script
+Extension). In other words, the interfaces of the different Extensions should not be
+the same. This is way more flexible than the Decorator design pattern. A disadvantage
+is that the data and functionality are in the same class (namely inside the Extion's
+methods), so it's not sepperated. Another disadvantage is that the Extension Objects
+design pattern can be quite slow, because objects are scattered in memory (and it is
+very hard to quickly get their memory address)
 \autocite{man:ExtensionObjectDesignPattern, man:extionsionObjectsStackOverflow}.
 
 \begin{figure}
@@ -110,10 +111,10 @@ Component System (\gls{ecs}) (as shown in \cref{fig:ECS Block Diagram}). The
 \gls{ecs} is made out of three main subsystems, namely entities, components and
 systems. Entities are just IDs. An entity is made out of a gameObject and one (or
 more) components. Components are the classes that hold the data. The components
-determine what kind of entity it is (e.g. a sprite, audio, and so on). Systems
-take care of the behavior of the entities. Systems mainly read and write the enity's
-components data. The \gls{ecs} clearly distinguishes the data (components) from
-the functionality (systems), which is an advantage.
+determine what kind of entity it is (e.g.~a sprite, audio, and so on). Systems take
+care of the behavior of the entities. Systems mainly read and write the enity's
+components data. The \gls{ecs} clearly distinguishes the data (components) from the
+functionality (systems), which is an advantage.
 
 \begin{figure}
 	\centering
@@ -126,13 +127,13 @@ the functionality (systems), which is an advantage.
 The \gls{ecs} is normally equipped with a component manager (as shown in
 \cref{fig:ECS Component manager}). The component manager keeps track of the entities
 (Alien, Player, Target, etc in \cref{fig:ECS Component manager}) and the connected
-components (Position, Movement, Render, etc in \cref{fig:ECS Component manager}).
-The component manager stores two lists (key value pairs). The key of the first list
-is the ID of an entity, and the value of this list are the connected components. The key
+components (Position, Movement, Render, etc in \cref{fig:ECS Component manager}). The
+component manager stores two lists (key value pairs). The key of the first list is
+the ID of an entity, and the value of this list are the connected components. The key
 of the second list is the component, and the value of this list are the entities that
-have this component. These two lists make it possible to very quickly gather components
-or entities. This makes the \gls{ecs} very fast, which is of course an advantage
-\autocite{man:ECSComponentManager}.
+have this component. These two lists make it possible to very quickly gather
+components or entities. This makes the \gls{ecs} very fast, which is of course an
+advantage \autocite{man:ECSComponentManager}.
 
 \begin{figure}
 	\centering
@@ -146,21 +147,23 @@ Another aspect that makes the \gls{ecs} very fast, is that a system can handle a
 components (of the same type) together at once. This is possible because all entities
 are independent of each other.
 
-There are many ways of implementing the systems. Some say that each component type has
-their own system. This interpretation of the systems does not take the interplay of
-different component types, into account. A less restrictive approach is to let different
-systems deal with all components they should be concerned with. For instance a Physics
-Systems should be aware of Collision Components and Rigidbody Components, as both
-probably contain necessary information regarding physics simulation. It's best to see
-systems as “closed environments”. That is, they do not take ownership of entities nor
-components. They do access them through independent manager objects, which in turn will
-take care of the entities and components life-cycle \autocite{man:ECSExplanation}.
-
-Sometimes systems, entities and even components need to cummincate with each other. This
-might be very hard because systems, entities and components are more or less independent.
-One option is to use an event systems. A system, entity and component can raise an event
-and other systems, entities and components can react to that event. This is what makes the
-\gls{ecs} a complicated system (disadvantage) \autocite{man:ECSExplanation}.
+There are many ways of implementing the systems. Some say that each component type
+has their own system. This interpretation of the systems does not take the interplay
+of different component types, into account. A less restrictive approach is to let
+different systems deal with all components they should be concerned with. For
+instance a Physics Systems should be aware of Collision Components and Rigidbody
+Components, as both probably contain necessary information regarding physics
+simulation. It's best to see systems as ``closed environments''. That is, they do not
+take ownership of entities nor components. They do access them through independent
+manager objects, which in turn will take care of the entities and components
+life-cycle \autocite{man:ECSExplanation}.
+
+Sometimes systems, entities and even components need to cummincate with each other.
+This might be very hard because systems, entities and components are more or less
+independent. One option is to use an event systems. A system, entity and component
+can raise an event and other systems, entities and components can react to that
+event. This is what makes the \gls{ecs} a complicated system (disadvantage)
+\autocite{man:ECSExplanation}.
 
 There are many C/C++ libraries available, completely dedicated to \gls{ecs}. The most
 popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is
@@ -222,7 +225,7 @@ gameObject.
 
 Each gameObject always has one transform class. The transform class describes the
 position, rotation, and scale within the scene. Some component use this information
-to e.g. scale a sprite. Other components eddit this information to e.g.~model
+to e.g.~scale a sprite. Other components eddit this information to e.g.~model
 gravity. \autocite{man:unityTransformClass}
 
 A gameObject can have one (or multiple) children gameObject(s). All children
-- 
cgit v1.2.3


From 46d07c2c9e68597f3f6af76b4f8e837786781029 Mon Sep 17 00:00:00 2001
From: Loek Le Blansch <loek@pipeframe.xyz>
Date: Sun, 22 Sep 2024 19:25:02 +0200
Subject: finish audio research

---
 glossary.bib |  6 +++++
 research.tex | 72 +++++++++++++++++-------------------------------------------
 sources.bib  |  4 ++--
 3 files changed, 28 insertions(+), 54 deletions(-)

(limited to 'research.tex')

diff --git a/glossary.bib b/glossary.bib
index 8bf48ac..fda634f 100644
--- a/glossary.bib
+++ b/glossary.bib
@@ -46,3 +46,9 @@
 	long = {definition of done},
 }
 
+@abbreviation{poc,
+	short = {POC},
+	long = {proof-of-concept},
+}
+
+
diff --git a/research.tex b/research.tex
index f3424c4..4ca3d3d 100644
--- a/research.tex
+++ b/research.tex
@@ -247,44 +247,14 @@ The game engine is required to have an audio system
 audio mixing engine is outside the scope of this project\mref, this section compares
 various standalone audio libraries for suitability in the engine.
 
-\Cref{sec:audio:libs} details which libraries were considered,
-\cref{sec:audio:benchmark} compares their performance, and
-\cref{sec:audio:conclusion} concludes with a recommendation for most performant audio
-library.
-
 \subsection{Libraries}
 \label{sec:audio:libs}
 
-\Cref{tab:audio:libs} lists the standalone audio engine libraries that fit
-\cref{req:audio,req:lib:license}.
-
-\begin{table}
-	\centering
-	\begin{tabular}{llc}
-		\toprule
-		\textbf{Library} & \textbf{License} & \textbf{API}\\
-		\midrule
-		miniaudio \autocite{lib:miniaudio} & MIT-0 & C\\
-		YSE \autocite{lib:yse} & EPL & C++\\
-		SoLoud \autocite{lib:soloud} & Zlip/LibPng & C++\\
-		\bottomrule
-	\end{tabular}
-	\caption{Audio engine library comparison}
-	\label{tab:audio:libs}
-\end{table}
-
-Other popular libraries that were researched but are unsuitable for this project
-include:\noparbreak
-\begin{description}
-	\item[FMOD \autocite{lib:fmod}] Is proprietary (violates \cref{req:lib:license})
-	\item[PortAudio \autocite{lib:portaudio}] Does not handle mixing
-\end{description}
-
-\subsection{Benchmarks}
-\label{sec:audio:benchmark}
-
-The same benchmark application was written for each of the libraries listed in
-\cref{tab:audio:libs}. The application does the following:\noparbreak
+After searching for libraries (search terms: `dynamic/adaptive audio', `real-time
+audio', `audio library', `game audio engine'), several libraries were found. These
+libraries were checked against the audio engine requirements
+\autocite{crepe:requirements} and then tested by writing the same benchmark-style
+\gls{poc} using the remaining qualifying libraries:\noparbreak
 \begin{enumerate}
 	\item Load a background track (Ogg Vorbis)
 	\item Load three short samples (WAV)
@@ -294,28 +264,26 @@ The same benchmark application was written for each of the libraries listed in
 	\item Stop all audio and exit
 \end{enumerate}
 
-Each benchmark was profiled using \emph{perf} \autocite{tool:perf} and compared based
-on total CPU and memory utilization. The results of these benchmarks are listed in
-\cref{tab:audio:benchmark}.
+Of these libraries the following were determined to be unsuitable for use in this
+project due to various reasons:\noparbreak
+\begin{description}
+	\item[FMOD \autocite{lib:fmod}] Is proprietary (violates \cref{req:lib:license})
+	\item[PortAudio \autocite{lib:portaudio}] Does not handle mixing
+	\item[miniaudio \autocite{lib:miniaudio}] With finished \gls{poc}, but dropped due
+		to very limited codec support (WAV, MP3 and FLAC only); Also does not have an
+		\gls{api} reference (only programming manual)
+	\item[YSE \autocite{lib:yse}] Attempted to write \gls{poc}, but CMake configuration
+		in repository is broken; This project seems to have been abandoned
+\end{description}
 
-\begin{table}
-	\centering
-	\begin{tabular}{lr}
-		\toprule
-		\textbf{Library} & \textbf{???}\\
-		\midrule
-		miniaudio &\\
-		YSE &\\
-		SoLoud &\\
-		\bottomrule
-	\end{tabular}
-	\caption{Audio engine library benchmark results}
-	\label{tab:audio:benchmark}
-\end{table}
+The only library that remained after these tests is SoLoud \autocite{lib:soloud}. It
+is Zlib/LibPng licensed and provides a high-level object-oriented C++ \gls{api}.
 
 \subsection{Conclusion}
 \label{sec:audio:conclusion}
 
+Due to a severe shortage of libraries that fit our requirements, SoLoud appears to be
+the most suitable (and only) audio library for use in this project.
 
 \section{Physics}
 
diff --git a/sources.bib b/sources.bib
index bb68067..adcfdd5 100644
--- a/sources.bib
+++ b/sources.bib
@@ -56,8 +56,8 @@
 @online{lib:miniaudio,
 	title = {miniaudio - A single file audio playback and capture library.},
 	% author = {David Reid},
-	url = {https://miniaud.io},
-	urldate = {2024-09-18},
+	url = {https://miniaud.io/docs/manual/index.html},
+	urldate = {2024-09-22},
 }
 
 @online{lib:yse,
-- 
cgit v1.2.3


From 6329755a372d90985bda1cd164fae8d91d4a60c6 Mon Sep 17 00:00:00 2001
From: Loek Le Blansch <loek@pipeframe.xyz>
Date: Thu, 26 Sep 2024 15:50:58 +0200
Subject: remove meta.tex and just set defaults directly in projdoc.cls

---
 example.tex      |  1 -
 meta.tex         |  9 ---------
 plan.tex         |  1 -
 projdoc.cls      | 15 +++++++++++++--
 requirements.tex |  1 -
 research.tex     |  1 -
 timerep.tex      |  1 -
 7 files changed, 13 insertions(+), 16 deletions(-)
 delete mode 100644 meta.tex

(limited to 'research.tex')

diff --git a/example.tex b/example.tex
index 24c525b..9f36f59 100644
--- a/example.tex
+++ b/example.tex
@@ -1,7 +1,6 @@
 \documentclass{projdoc}
 % if the document compiles too slow (likely due to many/large images), try compiling
 % with the [draft] option. this replaces all images with placeholders.
-\input{meta.tex}
 
 \title{Example Document}
 
diff --git a/meta.tex b/meta.tex
deleted file mode 100644
index db7c7b1..0000000
--- a/meta.tex
+++ /dev/null
@@ -1,9 +0,0 @@
-\organization{Avans University of Applied Sciences}
-\project{Project cr\^epe}
-\author{%
-	Loek Le Blansch\and%
-	Wouter Boerenkamps\and%
-	Jaro Rutjes\and%
-	Max Smits\and%
-	Niels Stunnebrink%
-}
diff --git a/plan.tex b/plan.tex
index c439aa7..a67598e 100644
--- a/plan.tex
+++ b/plan.tex
@@ -1,5 +1,4 @@
 \documentclass{projdoc}
-\input{meta.tex}
 
 \title{Project Plan}
 
diff --git a/projdoc.cls b/projdoc.cls
index 16b1790..8a2c05d 100644
--- a/projdoc.cls
+++ b/projdoc.cls
@@ -1,6 +1,19 @@
 \NeedsTeXFormat{LaTeX2e}
 \ProvidesClass{projdoc}[2024-09-03 class projdoc]
 
+% project defaults
+\makeatletter
+\def\@project{Project cr\^epe}
+\def\@organization{Avans University of Applied Sciences}
+\def\@author{%
+	Loek Le Blansch\and%
+	Wouter Boerenkamps\and%
+	Jaro Rutjes\and%
+	Max Smits\and%
+	Niels Stunnebrink%
+}
+\makeatother
+
 % based on article
 \LoadClass{article}
 
@@ -160,9 +173,7 @@
 
 % \maketitle format
 \makeatletter
-\let\@project\relax
 \def\project#1{\def\@project{#1}}
-\let\@organization\relax
 \def\organization#1{\def\@organization{#1}}
 \def\@maketitle{%
 	\centering%
diff --git a/requirements.tex b/requirements.tex
index be0e103..6b4a87a 100644
--- a/requirements.tex
+++ b/requirements.tex
@@ -1,5 +1,4 @@
 \documentclass{projdoc}
-\input{meta.tex}
 
 \makeatletter
 \projdoc@description@leftmargin=2ex
diff --git a/research.tex b/research.tex
index 228f3ac..5aa7c4f 100644
--- a/research.tex
+++ b/research.tex
@@ -1,5 +1,4 @@
 \documentclass{projdoc}
-\input{meta.tex}
 
 \title{Research document}
 
diff --git a/timerep.tex b/timerep.tex
index 7590217..34a30ea 100644
--- a/timerep.tex
+++ b/timerep.tex
@@ -1,5 +1,4 @@
 \documentclass{projdoc}
-\input{meta.tex}
 
 \title{Time Report}
 
-- 
cgit v1.2.3


From e89a3fa70f59cd32cba4572aef2b9c2967c22f77 Mon Sep 17 00:00:00 2001
From: Loek Le Blansch <loek@pipeframe.xyz>
Date: Fri, 27 Sep 2024 15:08:36 +0200
Subject: merge #26 + style guide update

---
 contributing.md |  2 +-
 design.tex      | 25 +++++++++++++++----------
 research.tex    | 49 +++++++++++++++++++++++++++++++++++++++----------
 style.md        |  3 +++
 4 files changed, 58 insertions(+), 21 deletions(-)

(limited to 'research.tex')

diff --git a/contributing.md b/contributing.md
index 46cfeca..8105e0d 100644
--- a/contributing.md
+++ b/contributing.md
@@ -7,7 +7,7 @@ other document.
 - Indent using tabs
 - Wrap long lines at column 80
 - ASCII only (LaTeX syntax should be used instead of UTF-8, i.e. `fa\c{c}ade`
-  instead of `façade`, `---` instead of `—`)
+  instead of `façade`, `---` instead of `—`, `cr\^epe` instead of `crêpe`)
 - Images should be placed in the img/ folder
 - Labels and bibliography keys should only consist of characters from the
   following set: `[a-z0-9:-]` (lower-case, numbers, colon, dash).
diff --git a/design.tex b/design.tex
index 30e574b..c5bd017 100644
--- a/design.tex
+++ b/design.tex
@@ -1,24 +1,32 @@
 \documentclass{projdoc}
-\input{meta.tex}
 
-\title{design document}
+\title{Software Design}
 
 \begin{document}
 \tablestables
 \newpage
 
-\section{Introduction} This document outlines the design and development process of the Crepe Game Engine, detailing the key decisions made during its creation. The primary goal of this engine is to offer a streamlined, Unity-like experience tailored for developing 2D games similar to Jetpack Joyride.
+\section{Introduction}
 
-The Crepe Engine is designed to ease the transition for developers familiar with Unity, ensuring minimal friction when switching platforms. Our aim is to preserve many of Unity’s core features while introducing a lightweight and open-source alternative, licensed under the MIT License.
+This document outlines the design and development process of the cr\^epe game engine,
+detailing the key decisions made during its creation. The primary goal of this engine
+is to offer a streamlined, Unity-like experience tailored for developing 2D games
+similar to Jetpack Joyride.
 
-The engine is primarily aimed at indie developers who have prior experience with Unity and are looking for a flexible, cost-effective solution with familiar workflows.
+The cr\^epe engine is designed to ease the transition for developers familiar with
+Unity, ensuring minimal friction when switching platforms. Our aim is to preserve
+many of Unity’s core features while introducing a lightweight and open-source
+alternative, licensed under the MIT License.
 
+The engine is primarily aimed at indie developers who have prior experience with
+Unity and are looking for a flexible, cost-effective solution with familiar
+workflows.
 
-\section{Architectural overview}
+\section{Overview}
 
 \subsection{Core}
 
-\subsection{patterns}
+\subsection{Patterns}
 
 \section{Design}
 
@@ -34,12 +42,9 @@ The engine is primarily aimed at indie developers who have prior experience with
 
 \subsection{Physics}
 
-
 \section{Tools}
 
 \section{Conclusion}
 
-
-
 \end{document}
 
diff --git a/research.tex b/research.tex
index 4a65ec3..1b8a5ab 100644
--- a/research.tex
+++ b/research.tex
@@ -1,6 +1,6 @@
 \documentclass{projdoc}
 
-\title{Research document}
+\title{Research Document}
 
 \begin{document}
 \tablestables
@@ -310,12 +310,18 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 
 \subsection{Findings}
 
-\subsection{unity formats}
-Unity has many different asset file types that can be imported to use for a game \href{https://docs.unity3d.com/Manual/BuiltInImporters.html}{unity imports}. The most important formats are the audio, text and sprite formats.
+\subsection{Unity formats}
 
-\paragraph{Audio}
+% TODO: +ref (urldate 2024-09-11)
+Unity has many different asset file types that can be imported to use for a game
+\href{https://docs.unity3d.com/Manual/BuiltInImporters.html}{unity imports}. The most
+important formats are the audio, text and sprite formats.
 
-The unity engine supports a lot of different audio formats:
+\subsubsection{Audio}
+
+% NOTE: multicols to save space (is this list necessary?)
+The unity engine supports a lot of different audio formats:\noparbreak
+\begin{multicols}{5}
 \begin{itemize}
 	\item ogg.
 	\item aif.
@@ -328,10 +334,13 @@ The unity engine supports a lot of different audio formats:
 	\item s3m.
 	\item xm.
 \end{itemize}
+\end{multicols}
 
-\paragraph{Sprite formats}
+\subsubsection{Sprite formats}
 
-Unity supports many different image formats:
+% NOTE: multicols to save space (is this list necessary?)
+Unity supports many different image formats:\noparbreak
+\begin{multicols}{5}
 \begin{itemize}
 	\item jpg.
 	\item jpeg.
@@ -348,13 +357,32 @@ Unity supports many different image formats:
 	\item exr.
 	\item hdr.
 \end{itemize}
+\end{multicols}
+
+\subsection{Audio Format}
 
-\subsection{Audio Format} The choice of audio format for the Crepe game engine depends on several factors, including sound quality, memory usage, and licensing. According to various sources \href{https://dev.to/tenry/comparison-of-audio-formats-for-games-jak}{comparison audio formats}, \href{https://www.universityofgames.net/articles/audio-file-formats-used-in-game-development/}{Audio files in games} , the most commonly used audio formats in game development are WAV, MP3, and Ogg.
+% TODO: +ref (both urldate 2024-09-12)
+The choice of audio format for the cr\^epe game engine depends on several factors,
+including sound quality, memory usage, and licensing. According to various sources
+\href{https://dev.to/tenry/comparison-of-audio-formats-for-games-jak}{comparison audio formats},
+\href{https://www.universityofgames.net/articles/audio-file-formats-used-in-game-development/}{Audio files in games},
+the most commonly used audio formats in game development are WAV, MP3, and Ogg.
 
-\paragraph{Licensing} Historically, MP3 had patents on the audio format, but these restrictions have expired. Ogg and FLAC, both developed by Xiph.Org, are open-source formats. Additionally, the WAV format, though widely used, does not require a specific license for distribution.
+\subsubsection{Licensing}
 
-\paragraph{Conclusion} For the Crepe game engine, Ogg and FLAC are the preferred audio formats due to their open-source licenses and high compatibility. FLAC is ideal for high-quality audio with minimal compression, while Ogg is better suited for lower-quality audio that requires reduced memory usage. Both formats come from the same non-profit organization, Xiph.Org, ensuring that they align with open-source values and licensing flexibility.
+Historically, MP3 had patents on the audio format, but these restrictions have
+expired. Ogg and FLAC, both developed by Xiph.Org, are open-source formats.
+Additionally, the WAV format, though widely used, does not require a specific license
+for distribution.
 
+\subsubsection{Conclusion}
+
+For the cr\^epe game engine, Ogg and FLAC are the preferred audio formats due to
+their open-source licenses and high compatibility. FLAC is ideal for high-quality
+audio with minimal compression, while Ogg is better suited for lower-quality audio
+that requires reduced memory usage. Both formats come from the same non-profit
+organization, Xiph.Org, ensuring that they align with open-source values and
+licensing flexibility.
 
 \subsection{Conclusion}
 
@@ -477,3 +505,4 @@ the most suitable (and only) audio library for use in this project.
 \subsection{Conclusion}
 
 \end{document}
+
diff --git a/style.md b/style.md
index 8dca81b..2229947 100644
--- a/style.md
+++ b/style.md
@@ -13,6 +13,9 @@ reference.
   instead of a slash, etc.)
 - Quotes are closed before punctuation marks.
 - Do not use contractions, modal adverbs or rhetorical questions.
+- The engine is stylized in lowercase, and is just called 'crêpe'. Additional
+  words describing what crêpe is (i.e. '(game) engine') should not be
+  capitalized, as crêpe is not written like a porper noun.
 
 # References
 
-- 
cgit v1.2.3

