From c37f21e48f17abe9fb6bf1549f680e6f730aed8c Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Wed, 18 Sep 2024 16:52:40 +0200 Subject: WIP research --- sources.bib | 77 +++++++++++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 57 insertions(+), 20 deletions(-) (limited to 'sources.bib') 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 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 'sources.bib') 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 28d0733146aa3a8ba720bda20ff66ffa4cf4e64d Mon Sep 17 00:00:00 2001 From: Jaro Date: Wed, 18 Sep 2024 19:30:48 +0200 Subject: added feedback to project plan --- plan.tex | 5 ++++- sources.bib | 7 +++++++ 2 files changed, 11 insertions(+), 1 deletion(-) (limited to 'sources.bib') diff --git a/plan.tex b/plan.tex index 2f9cc94..147e49c 100644 --- a/plan.tex +++ b/plan.tex @@ -53,7 +53,10 @@ Finally, because the client does not want to dive deeply into the engine himself \subsection{Goal} -The goal is to develop a custom game engine that meets the client's requirements for maintainability, extensibility, user-friendliness, and adherence to a Unity-like structure. In addition, a validation application is created to show and test the engine's features. +The goal is to develop a custom game engine that meets the client's requirements for maintainability, extensibility, user-friendliness, and adherence to a Unity-like structure. The engine may integrate third-party software (as agreed with the client) to support specific features, such as audio, physics, and rendering. In addition, a validation application is created to show and test the engine's features. + +\subsection{Scope} +The requirements document \autocite{crepe:requirements} has several requirements with a MoSCoW `must', `should', `could' or `won't' priority to indicate the project's scope. \subsection{Result} diff --git a/sources.bib b/sources.bib index 50f5ead..8d96ce1 100644 --- a/sources.bib +++ b/sources.bib @@ -47,4 +47,11 @@ date = {2024-09-10}, } +@misc{crepe:requirements, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, + title = {Requirements}, + url = {https://github.com/lonkaars/crepe/blob/master/requirements.pdf}, + date = {2024-09-10}, +} + -- cgit v1.2.3 From be63aadea11619a08878c25a26b7ccafc6174b53 Mon Sep 17 00:00:00 2001 From: Jaro Date: Thu, 19 Sep 2024 18:10:43 +0200 Subject: added some feedback --- plan.tex | 32 +++++++++++--------------------- sources.bib | 7 +++++++ 2 files changed, 18 insertions(+), 21 deletions(-) (limited to 'sources.bib') diff --git a/plan.tex b/plan.tex index 147e49c..13c487d 100644 --- a/plan.tex +++ b/plan.tex @@ -1,13 +1,6 @@ \documentclass{projdoc} \input{meta.tex} -% @Jaro: Zie hieronder -% Version 0.0 seems not right -% I'm also missing a 'version table' -% Shall we use this version system?: -% Version numbers after the comma indicate an interim version and version numbers -% before the comma indicate versions ready for publication - \title{Project Plan} \version{0.1} @@ -18,19 +11,12 @@ \section{Background} This project is part of the fourth-year minor `Systems Programming in C++'. The minor -consists of several courses troughout 20 weeks, which create the basis for this -project. The project is focussed on building a game engine using the programming +consists of several courses throughout 20 weeks, which create the basis for this +project. The project focus is on building a game engine using the programming language C++. This document describes the plan of attack for the project. \section{Problem Definition} -% The assignments will be discussed with the project supervisor on specifics for this -% project. This will give the team the ability to direct the project. - -% @Jaro: Ik snap niet wat je met deze zinnen wil zeggen. Het lijkt een soort van -% background information, maar toch niet helemaal ofzo. Hoe dan ook heb ik het er nu -% even uit gehaald en een nieuw kopje background toegevoegd. - \subsection{Problem Analysis} CodedFun Games is a small, single-person game company looking to scale up. The owner, @@ -45,7 +31,7 @@ user-friendly. Additionally, the engine should be well-documented, which is considered an essential aspect of being user-friendly. So far, the client has made all his games in Unity and is very fond of the structure. -Therefore, he wants the new engine to adhere to a similar structure. A simple +Therefore, the client wants the new engine to adhere to a similar structure. A simple requirements document is defined to specify how strictly this structure should be followed. @@ -62,6 +48,10 @@ The requirements document \autocite{crepe:requirements} has several requirements The expected result is a well-documented, custom game engine that follows a structure similar to Unity. Additionally, a validation application should be provided to test and showcase the engine's capabilities. +\subsection{validation application} + +The validation application \autocite{crepe:validation-application} is explained in a document where the features of the validation application are linked to the user stories. + \section{Planning} The customer specified multiple deliverables throughout the 20 weeks of this project. Despite the fact that 20 weeks have been reserved for this project, the game will be delivered in week 17. Any delay/resit will take place between weeks 17 and 20. A rough planning can be found in \cref{tab:planning}. @@ -72,10 +62,9 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro \textbf{Week\#} & \textbf{Deliverable}\\ \midrule 4 & Project Plan\\ - 7 & Requirements document\\ + 7 & POCs\\ 10 & POCs and Design document\\ - 17 & Game engine, Validation application, Research document, and Qualification - document\\ + 17 & Game engine, Validation application\\ \bottomrule \end{tabularx} \caption{Planning} @@ -100,6 +89,7 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro requirements. Lack of Team Collaboration: Insufficient collaboration among team members may hinder progress. \item[Lack of Team Collaboration] Within the team a lack of collaboration can result in miscommunication or delay in work. + \item[Falling out of specific team member] Within the team the scrum master and integrator have additional roles. If one or both members can not continue it can hinder progress of the project. \end{description} \subsection{Measures} @@ -113,6 +103,7 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro meetings, to check if the progress is within the scope, should be sufficient to decrease the risk. \item[Lack of Team Collaboration] Weekly team meetings will result in collaboration among team members and discussing what each other tasks is, will decease this risk. + \item[Falling out of specific team member] The scrum master can be taken over by any other team member. All tools (e.g. scrum board) are open to all members. The tasks of the integrator can be taken over by the team. Within GitHub the team as a whole has the same rights as the integrator. \end{description} \section{Documentation} @@ -128,7 +119,6 @@ This project consists of seven main documents:\noparbreak project, including timelines, milestones, roles, and responsibilities. \item[Requirements] Details the requirements and user stories, including both functional and non-functional requirements. - \item[Research] Consists of all research related to this project. \item[Design] Describes the design choices, including architecture, user interface, and system components. \item[Qualification] Includes test cases, test plans, and quality measures to diff --git a/sources.bib b/sources.bib index 8d96ce1..31262fb 100644 --- a/sources.bib +++ b/sources.bib @@ -54,4 +54,11 @@ date = {2024-09-10}, } +@misc{crepe:validation-application, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, + title = {Validation Application}, + url = {https://github.com/lonkaars/crepe/blob/master/Validation-Application.pdf}, + date = {2024-09-10}, +} + -- 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 'sources.bib') 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 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 'sources.bib') 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 46d07c2c9e68597f3f6af76b4f8e837786781029 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch 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 'sources.bib') 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