kuhyx/praca_magisterska
1
0
Fork 0
mirror of https://github.com/kuhyx/praca_magisterska.git synced 2026-07-04 12:03:01 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

chore: added dots everywhere

Browse Source
This commit is contained in:
Krzysztof kuhy Rudnicki 2026-02-07 16:43:12 +01:00
parent 9238f53e90
commit 2add3b3e6c
14 changed files with 691 additions and 567 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
latex/main.pdf
View File

Binary file not shown.

8
latex/main.tex
View File

@ -72,7 +72,7 @@
%-------------------------------------
\cleardoublepage % Zaczynamy od nieparzystej strony
\abstract
Przez ostatnią dekadę rynek tworzenia gier komputerowych \\ zdominowały dwa silniki: Unity oraz
Przez ostatnią dekadę rynek tworzenia gier komputerowych zdominowały dwa silniki: Unity oraz
Unreal Engine. Niniejsza praca podejmuje się wyzwania przeprowadzenia analizy
porównawczej
obu tych silników pod kątem wyd ajności oraz procesu
@ -204,9 +204,9 @@ Game development, Frame time, Engine architecture, Version control, GPU
%\begin{table}[!h] \centering
% \caption{Tabela w załączniku.}
% \begin{tabular} {| c | c | r |} \hline
% Kolumna 1 & Kolumna 2 & Liczba \\ \hline\hline
% cell1 & cell2 & 60 \\ \hline
% \multicolumn{2}{|r|}{Suma:} & 123,45 \\ \hline
% Kolumna 1 & Kolumna 2 & Liczba \hline\hline
% cell1 & cell2 & 60 \hline
% \multicolumn{2}{|r|}{Suma:} & 123,45 \hline
% \end{tabular}
%\end{table}
%\lipsum[3-4]

70
latex/tex/1-wstep.tex
View File

@ -17,11 +17,11 @@ oraz końcową jakość produktu.
\subsection{Zakres pracy}
Praca obejmuje analizę następujących aspektów:
\begin{itemize}
\item Wydajność renderowania grafiki
\item Możliwości i~funkcjonalności oferowane przez różne silniki
\item Łatwość użycia i~krzywa uczenia się
\item Praca z narzędziem przy użycji dużych modeli językowch
\item Ekosystem narzędzi i~społeczność deweloperska
\item Wydajność renderowania grafiki.
\item Możliwości i~funkcjonalności oferowane przez różne silniki.
\item Łatwość użycia i~krzywa uczenia się.
\item Praca z narzędziem przy użycji dużych modeli językowch.
\item Ekosystem narzędzi i~społeczność deweloperska.
\end{itemize}
\subsection{Wybór gry testowej -- gatunek bullet hell}\label{subsec:bullet-hell}
@ -39,14 +39,14 @@ ogromne ilości pocisków tworzących skomplikowane wzory na ekranie. Kluczowe c
\begin{itemize}
\item \textbf{Masowa ilość pocisków} -- na ekranie jednocześnie może znajdować się od kilkuset
do kilku tysięcy pocisków, tworzących złożone formacje \\ geometryczne
do kilku tysięcy pocisków, tworzących złożone formacje geometryczne.
\item \textbf{Precyzyjne hitboxy} -- obszar kolizji postaci gracza jest znacznie mniejszy niż
jej wizualna reprezentacja (często ograniczony do kilku pikseli), co umożliwia nawigację między
pociskami
\item \textbf{Duża liczba przeciwników} -- na ekranie jednocześnie pojawia się wiele jednostek przeciwnika, co zwiększa złożoność sytuacji i obciążenie systemu
\item \textbf{Ciągły ruch} -- gracz musi nieustannie przemieszczać się po ekranie, unikając kolizji
pociskami.
\item \textbf{Duża liczba przeciwników} -- na ekranie jednocześnie pojawia się wiele jednostek przeciwnika, co zwiększa złożoność sytuacji i obciążenie systemu.
\item \textbf{Ciągły ruch} -- gracz musi nieustannie przemieszczać się po ekranie, unikając kolizji.
\item \textbf{Eskalacja trudności} -- wraz z~postępem gry wzrasta liczba przeciwników
i~gęstość pocisków
i~gęstość pocisków.
\end{itemize}
Klasyczne przykłady gatunku to serie \textit{Touhou Project},
@ -66,19 +66,19 @@ Klasyczne przykłady gatunku to serie \textit{Touhou Project},
Gatunek bullet hell został wybrany jako podstawa testów wydajnościowych z~następujących powodów:
\begin{enumerate}
\item \textbf{Intensywne wykorzystanie zasobów} -- jednoczesne renderowanie setek lub tysięcy obiektów (pocisków) stanowi znaczące obciążenie dla systemu renderowania
\item \textbf{Intensywne wykorzystanie zasobów} -- jednoczesne renderowanie setek lub tysięcy obiektów (pocisków) stanowi znaczące obciążenie dla systemu renderowania.
\item \textbf{Testowanie zarządzania pamięcią} -- ciągłe tworzenie i~niszczenie obiektów
pocisków eksponuje różnice w~implementacji \\ garbage collectora (Unity/C\#) versus ręcznego
zarządzania pamięcią (Unreal/C++)
pocisków eksponuje różnice w~implementacji garbage collectora (Unity/C\#) versus ręcznego
zarządzania pamięcią (Unreal/C++).
\item \textbf{Wymagania systemu fizyki} -- wykrywanie kolizji między graczem a~setkami pocisków w~każdej klatce obciąża system fizyki
\item \textbf{Wymagania systemu fizyki} -- wykrywanie kolizji między graczem a~setkami pocisków w~każdej klatce obciąża system fizyki.
\item \textbf{Prostota implementacji} -- podstawowa mechanika gry jest stosunkowo prosta koncepcyjnie, co pozwala skupić się na porównaniu wydajności, a~nie złożoności logiki gry
\item \textbf{Prostota implementacji} -- podstawowa mechanika gry jest stosunkowo prosta koncepcyjnie, co pozwala skupić się na porównaniu wydajności, a~nie złożoności logiki gry.
\item \textbf{Skalowalność testu} -- łatwo kontrolować poziom obciążenia poprzez modyfikację liczby aktywnych pocisków i~przeciwników
\item \textbf{Skalowalność testu} -- łatwo kontrolować poziom obciążenia poprzez modyfikację liczby aktywnych pocisków i~przeciwników.
\item \textbf{Reprezentatywność dla gier 2D} -- gatunek jest typowym przedstawicielem gier 2D, co pozwala ocenić wsparcie silników dla tego segmentu rynku
\item \textbf{Reprezentatywność dla gier 2D} -- gatunek jest typowym przedstawicielem gier 2D, co pozwala ocenić wsparcie silników dla tego segmentu rynku.
\end{enumerate}
@ -87,10 +87,10 @@ Gatunek bullet hell został wybrany jako podstawa testów wydajnościowych z~nas
Zaimplementowana gra testowa charakteryzuje się następującymi parametrami:
\begin{itemize}
\item Czas rozgrywki: 90 sekund
\item Eskalacja trudności: liniowy wzrost częstotliwości spawnu przeciwników
\item Typy przeciwników: 3 warianty z~różnymi wzorami strzelania
\item System punktacji oparty na eliminacji przeciwników
\item Czas rozgrywki: 90 sekund.
\item Eskalacja trudności: liniowy wzrost częstotliwości spawnu przeciwników.
\item Typy przeciwników: 3 warianty z~różnymi wzorami strzelania.
\item System punktacji oparty na eliminacji przeciwników.
\end{itemize}
Te parametry zapewniają wystarczające obciążenie systemu do ujawnienia różnic wydajnościowych między silnikami, pozostając jednocześnie w~granicach typowych dla gier indie z~tego gatunku.
@ -100,24 +100,24 @@ Te parametry zapewniają wystarczające obciążenie systemu do ujawnienia róż
Praca składa się z~następujących rozdziałów:
\begin{enumerate}
\item \textbf{Wstęp} -- wprowadzenie do tematyki, motywacja, cel i~zakres pracy
\item \textbf{Przegląd literatury} -- analiza istniejących badań porównawczych silników gier
\item \textbf{Charakterystyka silników} -- szczegółowy opis Unity i~Unreal Engine
\item \textbf{Metodologia} -- opis metodyki badawczej i~kryteriów porównania
\item \textbf{Analiza wywiadów} -- wyniki badań jakościowych z~deweloperami
\item \textbf{Implementacja gry testowej} -- doświadczenia z~tworzenia gry w~obu silnikach
\item \textbf{Narzędzia profilowania} -- opis NVIDIA Nsight i~metodyki pomiarów
\item \textbf{Testy wydajności} -- wyniki pomiarów wydajnościowych
\item \textbf{Analiza możliwości} -- porównanie funkcjonalności silników
\item \textbf{Porównanie wyników} -- synteza i~analiza zebranych danych
\item \textbf{Podsumowanie} -- wnioski i~rekomendacje
\item \textbf{Wstęp} -- wprowadzenie do tematyki, motywacja, cel i~zakres pracy.
\item \textbf{Przegląd literatury} -- analiza istniejących badań porównawczych silników gier.
\item \textbf{Charakterystyka silników} -- szczegółowy opis Unity i~Unreal Engine.
\item \textbf{Metodologia} -- opis metodyki badawczej i~kryteriów porównania.
\item \textbf{Analiza wywiadów} -- wyniki badań jakościowych z~deweloperami.
\item \textbf{Implementacja gry testowej} -- doświadczenia z~tworzenia gry w~obu silnikach.
\item \textbf{Narzędzia profilowania} -- opis NVIDIA Nsight i~metodyki pomiarów.
\item \textbf{Testy wydajności} -- wyniki pomiarów wydajnościowych.
\item \textbf{Analiza możliwości} -- porównanie funkcjonalności silników.
\item \textbf{Porównanie wyników} -- synteza i~analiza zebranych danych.
\item \textbf{Podsumowanie} -- wnioski i~rekomendacje.
\end{enumerate}
\subsection{Metodologia}
\begin{itemize}
\item \textbf{Testy wydajnościowe} -- Pomiary z~wykorzystaniem NVIDIA Nsight Graphics, zapewniające porównywalność wyników między silnikami
\item \textbf{Wywiady z~deweloperami} -- badania jakościowe dostarczające kontekstu \\ praktycznego użytkowania silników
\item \textbf{Implementacja porównawcza} -- stworzenie identycznej gry w~obu silnikach, dokumentując różnice w~procesie deweloperskim
\item \textbf{Testy wydajnościowe} -- Pomiary z~wykorzystaniem NVIDIA Nsight Graphics, zapewniające porównywalność wyników między silnikami.
\item \textbf{Wywiady z~deweloperami} -- badania jakościowe dostarczające kontekstu praktycznego użytkowania silników.
\item \textbf{Implementacja porównawcza} -- stworzenie identycznej gry w~obu silnikach, dokumentując różnice w~procesie deweloperskim.
\end{itemize}

12
latex/tex/2-przeglad-literatury.tex
View File

@ -15,14 +15,14 @@ gier charakteryzują się modularną architekturą, która umożliwia
ponowne wykorzystanie komponentów między różnymi projektami.
Gregory \cite{gregory2018game} w~swojej pracy ,,Game Engine Architecture''
przedstawia kompleksowy \\ przegląd ewolucji silników gier, definiując je jako
przedstawia kompleksowy przegląd ewolucji silników gier, definiując je jako
,,oprogramowanie zaprojektowane specjalnie do tworzenia gier''.
Jego analiza pokazuje, że współczesne silniki gier składają się z~kilku
kluczowych warstw: warstwy platformy (platform layer),
warstwy podstawowych systemów (core systems), warstwy zasobów
(resource manager), warstwy renderingu (rendering engine),
systemów animacji, fizyki oraz gameplay.
Ta architektura warstwowa umożliwia modularność i~ponowne \\
Ta architektura warstwowa umożliwia modularność i~ponowne
wykorzystanie komponentów.
Pierwsze silniki gier były ściśle powiązane z konkretnym sprzętem
@ -39,13 +39,13 @@ zaawansowanymi narzędziami do debugowania.
\subsection{Klasyfikacja silników gier}
\subsubsection{Architektura silników według Gregory'ego}
Gregory \cite{gregory2018game} przedstawia taksonomię architektur silników gier, \\
Gregory \cite{gregory2018game} przedstawia taksonomię architektur silników gier,
wyróżniając kilka kluczowych typów organizacji:
\begin{itemize}
\item \textbf{Silniki obiektowe} - bazujące na hierarchii obiektów gry z dziedziczeniem
\item \textbf{Silniki komponentowe} - wykorzystujące systemy \\ entity-component-system (ECS)
\item \textbf{Silniki hybrydowe} - łączące elementy różnych podejść architektonicznych
\item \textbf{Silniki obiektowe} - bazujące na hierarchii obiektów gry z dziedziczeniem.
\item \textbf{Silniki komponentowe} - wykorzystujące systemy entity-component-system (ECS).
\item \textbf{Silniki hybrydowe} - łączące elementy różnych podejść architektonicznych.
\end{itemize}
Autor podkreśla, że wybór architektury ma fundamentalny wpływ na wydajność, skalowalność i łatwość rozwoju gier. Systemy ECS zyskują na popularności ze względu na lepszą wydajność cache procesora i większą elastyczność w definiowaniu zachowań obiektów gry.

90
latex/tex/3-silniki-gier.tex
View File

@ -16,22 +16,22 @@ kilkoma kluczowymi czynnikami:
\begin{itemize}
\item \textbf{Dominacja rynkowa} -- według raportu Video Game Insights,
w~2024 roku 51\% gier wydanych na platformie Steam powstało w~Unity,
\\ a 28\% w~Unreal Engine \cite{vgi2025engines}
a 28\% w~Unreal Engine \cite{vgi2025engines}.
\item \textbf{Reprezentatywność podejść architektonicznych} --
silniki reprezentują odmienne filozofie: Unity opiera się na
języku C\# z~garbage collectorem, \\ a~Unreal wykorzystuje C++
języku C\# z~garbage collectorem, a~Unreal wykorzystuje C++
z~własnym systemem refleksji, makrami oraz garbage collectorem
dla obiektów UObject
dla obiektów UObject.
\item \textbf{Różnorodność zastosowań} -- Unity dominuje
w~segmencie gier mobilnych (71\% z~top 1000 gier mobilnych)
oraz wśród deweloperów indie, natomiast
Unreal generuje większe przychody w~produkcjach AAA
(31\% przychodów Steam w~2024 vs 26\% dla Unity)
\cite{vgi2025engines, g2gameengines}
\cite{vgi2025engines, g2gameengines}.
\item \textbf{Dostępność} -- oba silniki oferują darmowe wersje
dla małych zespołów i projektów edukacyjnych
dla małych zespołów i projektów edukacyjnych.
\item \textbf{Aktywna społeczność} -- Unity posiada ponad
5~milionów zarejestrowanych deweloperów \cite{g2gameengines}
5~milionów zarejestrowanych deweloperów \cite{g2gameengines}.
\end{itemize}
\subsection{Unity}\label{subsec:unity}
@ -51,16 +51,16 @@ deweloperów i małych studiów \cite{unity_wikipedia}. Decyzja ta
przyczyniła się do wzrostu popularności silnika w segmencie gier
mobilnych oraz indie.
Unity wykorzystuje język programowania \textbf{C\#} działający \\
Unity wykorzystuje język programowania \textbf{C\#} działający
na platformie .NET/Mono, co zapewnia:
\begin{itemize}
\item Automatyczne zarządzanie pamięcią poprzez garbage collector
\item Bezpieczeństwo typów i obsługę wyjątków
\item Bogatą bibliotekę standardową
\item Automatyczne zarządzanie pamięcią poprzez garbage collector.
\item Bezpieczeństwo typów i obsługę wyjątków.
\item Bogatą bibliotekę standardową.
\end{itemize}
Architektura Unity opiera się na wzorcu \textit{GameObject-Component},
gdzie \\ każdy obiekt w scenie (GameObject) może posiadać dowolną
gdzie każdy obiekt w scenie (GameObject) może posiadać dowolną
liczbę komponentów definiujących jego zachowanie.
Podejście to promuje kompozycję nad dziedziczeniem i ułatwia
tworzenie modularnego kodu.
@ -73,32 +73,32 @@ Unity oferuje kompleksowy zestaw narzędzi do tworzenia gier 2D i 3D:
\item \textbf{Rendering} -- wsparcie dla wielu pipeline'ów
renderowania: Built-in, Universal Render Pipeline (URP) dla platform
mobilnych oraz High Definition Render Pipeline (HDRP) dla wysokiej
jakości grafiki
\item \textbf{Fizyka} -- integracja z silnikami PhysX (3D) i Box2D (2D)
jakości grafiki.
\item \textbf{Fizyka} -- integracja z silnikami PhysX (3D) i Box2D (2D).
\item \textbf{Animacja} -- system Mecanim z obsługą maszyn stanów
i blendingu animacji
\item \textbf{Audio} -- wbudowany system dźwięku przestrzennego
i blendingu animacji.
\item \textbf{Audio} -- wbudowany system dźwięku przestrzennego.
\item \textbf{UI} -- dwa systemy interfejsu użytkownika: uGUI oraz
nowoczesny UI Toolkit
nowoczesny UI Toolkit.
\item \textbf{Multiplayer} -- Netcode for GameObjects oraz
integracja z usługami sieciowymi
integracja z usługami sieciowymi.
\end{itemize}
\subsubsection{Narzędzia deweloperskie}
Edytor Unity zapewnia interfejs graficzny z~następującymi \\
Edytor Unity zapewnia interfejs graficzny z~następującymi
funkcjonalnościami \cite{unity_wikipedia}:
\begin{itemize}
\item Hierarchiczny widok sceny z możliwością edycji w czasie
rzeczywistym
\item Inspektor właściwości z obsługą serializacji pól \\ poprzez
atrybut \texttt{[SerializeField]}
rzeczywistym.
\item Inspektor właściwości z obsługą serializacji pól poprzez
atrybut \texttt{[SerializeField]}.
\item Wbudowany profiler wydajności (CPU, GPU, pamięć)
\cite{unity_profiler}
\cite{unity_profiler}.
\item Asset Store -- marketplace z gotowymi zasobami i
rozszerzeniami
rozszerzeniami.
\item Obsługa hot reload -- możliwość edycji kodu podczas działania
gry
gry.
\end{itemize}
\subsection{Unreal Engine}\label{subsec:unreal}
@ -120,9 +120,9 @@ technologie takie jak Nanite (wirtualizowana geometria) i Lumen
Unreal Engine wykorzystuje język programowania \textbf{C++} z
rozszerzeniami specyficznymi dla silnika (makra UE), co zapewnia:
\begin{itemize}
\item Maksymalną wydajność dzięki kompilacji do kodu natywnego
\item Pełną kontrolę nad zarządzaniem pamięcią
\item Strome krzywe uczenia, szczególnie dla programistów bez doświadczenia w C++
\item Maksymalną wydajność dzięki kompilacji do kodu natywnego.
\item Pełną kontrolę nad zarządzaniem pamięcią.
\item Strome krzywe uczenia, szczególnie dla programistów bez doświadczenia w C++.
\end{itemize}
Dodatkowo Unreal oferuje system \textbf{Blueprints} --
@ -136,25 +136,25 @@ być mniej wydajne niż natywny C++.
Unreal Engine wyróżnia się zaawansowanymi możliwościami graficznymi:
\begin{itemize}
\item \textbf{Rendering} -- fotorealistyczna grafika z obsługą ray tracingu, Nanite i Lumen
\item \textbf{Fizyka} -- silnik Chaos Physics z obsługą destrukcji i symulacji ciał miękkich
\item \textbf{Animacja} -- Control Rig, Animation Blueprints, IK Retargeting
\item \textbf{Landscape} -- zaawansowane narzędzia do tworzenia dużych terenów
\item \textbf{Niagara} -- system efektów cząsteczkowych nowej generacji
\item \textbf{Sequencer} -- narzędzie do tworzenia cinematików i cutscen
\item \textbf{Rendering} -- fotorealistyczna grafika z obsługą ray tracingu, Nanite i Lumen.
\item \textbf{Fizyka} -- silnik Chaos Physics z obsługą destrukcji i symulacji ciał miękkich.
\item \textbf{Animacja} -- Control Rig, Animation Blueprints, IK Retargeting.
\item \textbf{Landscape} -- zaawansowane narzędzia do tworzenia dużych terenów.
\item \textbf{Niagara} -- system efektów cząsteczkowych nowej generacji.
\item \textbf{Sequencer} -- narzędzie do tworzenia cinematików i cutscen.
\end{itemize}
\subsubsection{Narzędzia deweloperskie}
Unreal Editor oferuje rozbudowane środowisko deweloperskie~\cite{unreal_docs}:
\begin{itemize}
\item Edytor poziomów z obsługą streamingu i Level of Detail (LOD)
\item Blueprint Visual Scripting -- programowanie wizualne
\item Material Editor -- węzłowy edytor materiałów
\item Wbudowany profiler z analizą GPU/CPU i pamięci
\item Marketplace -- sklep z zasobami i pluginami
\item Dostęp do kodu źródłowego silnika
\item Live Coding -- eksperymentalne wsparcie dla hot reload w C++
\item Edytor poziomów z obsługą streamingu i Level of Detail (LOD).
\item Blueprint Visual Scripting -- programowanie wizualne.
\item Material Editor -- węzłowy edytor materiałów.
\item Wbudowany profiler z analizą GPU/CPU i pamięci.
\item Marketplace -- sklep z zasobami i pluginami.
\item Dostęp do kodu źródłowego silnika.
\item Live Coding -- eksperymentalne wsparcie dla hot reload w C++.
\end{itemize}
\textbf{Porównanie architektoniczne}
@ -198,15 +198,15 @@ analizę dwóch fundamentalnie różnych podejść do tworzenia gier:
\item \textbf{Produktywność vs wydajność} -- C\# w Unity oferuje
szybszy rozwój kosztem pewnego narzutu wydajnościowego, podczas
gdy C++ w Unreal wymaga więcej pracy, ale zapewnia maksymalną
kontrolę
kontrolę.
\item \textbf{Dostępność vs specjalizacja} -- Unity celuje w
szeroki rynek z niskim progiem wejścia, Unreal koncentruje się
na produkcjach premium
na produkcjach premium.
\item \textbf{Elastyczność vs integracja} -- Unity pozwala
na większą swobodę w doborze zewnętrznych narzędzi, Unreal
oferuje bardziej zintegrowane rozwiązania
oferuje bardziej zintegrowane rozwiązania.
\end{enumerate}
Analiza tych dwóch silników dostarcza kompleksowego obrazu \\
współczesnego stanu technologii do tworzenia gier i~pozwala na \\
Analiza tych dwóch silników dostarcza kompleksowego obrazu
współczesnego stanu technologii do tworzenia gier i~pozwala na
sformułowanie praktycznych rekomendacji dla deweloperów.

66
latex/tex/4-metodologia.tex
View File

@ -15,15 +15,15 @@ za pomocą narzędzia NVIDIA Nsight Systems:
\begin{itemize}
\item \textbf{Czas klatki} (ang. \emph{frame time}) -- czas potrzebny
na wyrenderowanie pojedynczej klatki, wyrażony w~milisekundach
\item \textbf{Liczba klatek na sekundę} (FPS) -- wartość \\ pochodna
od czasu klatki, kluczowa dla płynności rozgrywki
na wyrenderowanie pojedynczej klatki, wyrażony w~milisekundach.
\item \textbf{Liczba klatek na sekundę} (FPS) -- wartość pochodna
od czasu klatki, kluczowa dla płynności rozgrywki.
\item \textbf{Wykorzystanie GPU} -- procentowe obciążenie karty graficznej,
mierzone poprzez liczniki sprzętowe NVIDIA
mierzone poprzez liczniki sprzętowe NVIDIA.
\item \textbf{Wywołania Vulkan API} -- szczegółowa analiza wywołań
interfejsu graficznego, w~tym funkcji synchronizacji i~prezentacji
interfejsu graficznego, w~tym funkcji synchronizacji i~prezentacji.
\item \textbf{Wywołania systemowe} -- analiza mechanizmów wielowątkowości
i~synchronizacji na poziomie systemu operacyjnego
i~synchronizacji na poziomie systemu operacyjnego.
\end{itemize}
\subsection{Środowisko testowe}
@ -33,13 +33,13 @@ za pomocą narzędzia NVIDIA Nsight Systems:
Wszystkie testy wydajnościowe przeprowadzono na komputerze o następującej specyfikacji:
\begin{itemize}
\item \textbf{Procesor}: AMD Ryzen 9 7900X3D 12-Core Processor (24 rdzenie, 48 wątków)
\item \textbf{Karta graficzna}: NVIDIA GeForce RTX 3090
\item \textbf{Pamięć GPU}: 24 GB GDDR6X
\item \textbf{Sterowniki NVIDIA}: wersja 590.48.01
\item \textbf{Pamięć RAM}: 32 GB
\item \textbf{System operacyjny}: Arch Linux (jądro Linux 6.18.5-arch1-1)
\item \textbf{Dysk}: SSD o pojemności 3,6 TB
\item \textbf{Procesor}: AMD Ryzen 9 7900X3D 12-Core Processor (24 rdzenie, 48 wątków).
\item \textbf{Karta graficzna}: NVIDIA GeForce RTX 3090.
\item \textbf{Pamięć GPU}: 24 GB GDDR6X.
\item \textbf{Sterowniki NVIDIA}: wersja 590.48.01.
\item \textbf{Pamięć RAM}: 32 GB.
\item \textbf{System operacyjny}: Arch Linux (jądro Linux 6.18.5-arch1-1).
\item \textbf{Dysk}: SSD o pojemności 3,6 TB.
\end{itemize}
\label{subsubsec:specyfikacja-oprogramowania}
@ -47,9 +47,9 @@ Wszystkie testy wydajnościowe przeprowadzono na komputerze o następującej spe
W badaniach wykorzystano następujące wersje oprogramowania:
\begin{itemize}
\item \textbf{Unity}: 6.0 (6000.0.58f2) LTS
\item \textbf{Unreal Engine}: 5.5.3
\item \textbf{NVIDIA Nsight Systems}: 2025.5.2
\item \textbf{Unity}: 6.0 (6000.0.58f2) LTS.
\item \textbf{Unreal Engine}: 5.5.3.
\item \textbf{NVIDIA Nsight Systems}: 2025.5.2.
\end{itemize}
Wybór wersji LTS silnika Unity podyktowany był stabilnością oraz długoterminowym wsparciem,
@ -64,11 +64,11 @@ Na potrzeby badań porównawczych zaimplementowano identyczną grę w gatunku
\emph{bullet hell} w obu silnikach. Gra charakteryzuje się następującymi cechami:
\begin{itemize}
\item Sterowana przez gracza postać
\item System generowania przeciwników z progresywnie rosnącym obciążeniem
\item Generowanie wzorców pocisków
\item Wykrywanie kolizji między obiektami
\item Tryb przetrwania trwający 90 sekund
\item Sterowana przez gracza postać.
\item System generowania przeciwników z progresywnie rosnącym obciążeniem.
\item Generowanie wzorców pocisków.
\item Wykrywanie kolizji między obiektami.
\item Tryb przetrwania trwający 90 sekund.
\end{itemize}
Wybór gatunku \emph{bullet hell} podyktowany był możliwością generowania dużej
@ -83,14 +83,14 @@ progresywnie zwiększała obciążenie poprzez:
\begin{itemize}
\item \textbf{Przyspieszanie spawnu przeciwników} -- interwał między
spawnem zmniejsza się liniowo od 0,25~s (początek) do 0,08~s (koniec),
z~dodatkowym ,,finalnym szturmem'' przez ostatnie 5~sekund
z~dodatkowym ,,finalnym szturmem'' przez ostatnie 5~sekund.
\item \textbf{Zwiększanie różnorodności typów przeciwników} --
początkowo \\ (0--25\% czasu) pojawiają się tylko podstawowi
początkowo (0--25\% czasu) pojawiają się tylko podstawowi
przeciwnicy, później wprowadzane są kolejno szybsze jednostki
(25--50\%), strzelające wieżyczki (50--75\%) oraz wytrzymałe
czołgi (75--100\%)
czołgi (75--100\%).
\item \textbf{Maksymalna liczba przeciwników} -- limit jednoczesnych
przeciwników na scenie wynosi 200 jednostek
przeciwników na scenie wynosi 200 jednostek.
\end{itemize}
\newpage
Na potrzeby profilowania rozgrywka została podzielona na trzy fazy czasowe:
@ -110,21 +110,21 @@ interwał spawnu osiąga minimum 0,08~s. Ostatnie 5~sekund to
Przeprowadzono cztery sesje pomiarowe -- po dwie dla każdego silnika:
\begin{enumerate}
\item \textbf{Unity -- tryb statyczny}: Gracz nieruchomy z~włączoną \\
nieśmiertelnością, pełne 90~sekund rozgrywki profilowane w~jednej sesji
\item \textbf{Unity -- tryb statyczny}: Gracz nieruchomy z~włączoną
nieśmiertelnością, pełne 90~sekund rozgrywki profilowane w~jednej sesji.
\item \textbf{Unity -- tryb dynamiczny}: Gracz aktywnie poruszający się
i~strzelający, pełne 90~sekund rozgrywki
i~strzelający, pełne 90~sekund rozgrywki.
\item \textbf{Unreal Engine -- tryb statyczny}: Ze względu na ograniczenia
techniczne (awaria przy śledzeniu Vulkan API) rozgrywkę podzielono na
trzy 30-sekundowe fazy, uruchamiane z~flagą \texttt{-{}-start-time=N}
trzy 30-sekundowe fazy, uruchamiane z~flagą \texttt{-{}-start-time=N}.
\item \textbf{Unreal Engine -- tryb dynamiczny}: Analogicznie do trybu
statycznego, trzy fazy po 30~sekund z~aktywnym graczem
statycznego, trzy fazy po 30~sekund z~aktywnym graczem.
\end{enumerate}
Narzędzie NVIDIA Nsight Systems rejestrowało:
\begin{itemize}
\item Wywołania Vulkan API (dla Unity -- dla Unreal niemożliwe z~powodu
awarii)
\item Metryki sprzętowe GPU z~częstotliwością 10\,000~Hz
\item Wywołania funkcji systemowych (pthread, futex itp.)
awarii).
\item Metryki sprzętowe GPU z~częstotliwością 10\,000~Hz.
\item Wywołania funkcji systemowych (pthread, futex itp.).
\end{itemize}

238
latex/tex/5-testy-wydajnosci.tex
View File

@ -1,16 +1,17 @@
\clearpage
\raggedbottom
\section{Testy wydajności}
\label{sec:testy-wydajnosci}
Dla każdego scenariusza i~silnika rejestrowano następujące metryki przy użyciu NVIDIA Nsight Systems:
\begin{itemize}
\item \textbf{Czas klatki} (frame time) -- czas renderowania pojedynczej klatki w~milisekundach
\item \textbf{FPS} (frames per second) -- liczba klatek na sekundę, wyliczana jako \\ $1000 / \text{frame time}$
\item \textbf{Wykorzystanie GPU} -- procent wykorzystania mocy obliczeniowej karty graficznej
\item \textbf{Zużycie pamięci VRAM} -- ilość zajętej pamięci karty graficznej w~megabajtach
\item \textbf{Liczba wywołań rysowania} (draw calls) -- liczba instrukcji renderowania na klatkę
\item \textbf{Liczba wierzchołków} -- całkowita liczba przetworzonych wierzchołków na klatkę
\item \textbf{Czas klatki} (frame time) -- czas renderowania pojedynczej klatki w~milisekundach.
\item \textbf{FPS} (frames per second) -- liczba klatek na sekundę, wyliczana jako $1000 / \text{frame time}$.
\item \textbf{Wykorzystanie GPU} -- procent wykorzystania mocy obliczeniowej karty graficznej.
\item \textbf{Zużycie pamięci VRAM} -- ilość zajętej pamięci karty graficznej w~megabajtach.
\item \textbf{Liczba wywołań rysowania} (draw calls) -- liczba instrukcji renderowania na klatkę.
\item \textbf{Liczba wierzchołków} -- całkowita liczba przetworzonych wierzchołków na klatkę.
\end{itemize}
\subsection{Wyniki testów dla silnika Unity}
@ -60,12 +61,12 @@ klatki 0,08 ms odpowiada sytuacjom, gdy kolejne wywołania prezentacji następuj
sobie -- może to wynikać z mechanizmu
podwójnego buforowania (ang. \textit{double buffering}) lub chwilowego braku pracy do wykonania przez GPU.
Wartość maksymalna 1\,239,62 ms (ponad sekunda) występuje podczas \\ fazy inicjalizacji aplikacji,
gdy silnik Unity wykonuje jednorazowe \\ operacje: kompilację shaderów, alokację dużych bloków pamięci \\ GPU,
Wartość maksymalna 1\,239,62 ms (ponad sekunda) występuje podczas fazy inicjalizacji aplikacji,
gdy silnik Unity wykonuje jednorazowe operacje: kompilację shaderów, alokację dużych bloków pamięci \\ GPU,
tworzenie obiektów swapchain oraz
inicjalizację systemu renderowania. \\ Jest to zachowanie typowe dla aplikacji Vulkan, gdzie znaczna część
inicjalizację systemu renderowania. Jest to zachowanie typowe dla aplikacji Vulkan, gdzie znaczna część
pracy inicjalizacyjnej wykonywana jest przy
starcie, w przeciwieństwie \\ do OpenGL, gdzie inicjalizacja jest bardziej rozłożona w czasie.
starcie, w przeciwieństwie do OpenGL, gdzie inicjalizacja jest bardziej rozłożona w czasie.
Współczynnik zmienności (CV) wynoszący 153,24\% jest wysoki, jednak wynika on głównie z
uwzględnienia ekstremalnych wartości inicjalizacyjnych.
@ -167,15 +168,15 @@ renderującego na poziomie pojedynczych funkcji API. Podczas testu zarejestrowan
\end{tabular}
\end{table}
\texttt{vkWaitForFences} \\ pochłonęła \textbf{95,2\% całkowitego czasu}
\texttt{vkWaitForFences} pochłonęła \textbf{95,2\% całkowitego czasu}
profilowania wywołań Vulkan API, co stanowi 77,04 sekundy z
94-sekundowego testu. Funkcja ta, zdefiniowana w specyfikacji Vulkan w rozdziale 7.3 dotyczącym
synchronizacji, realizuje blokujące oczekiwanie
procesora na sygnalizację obiektów ogrodzenia (ang. \textit{fence}) przez GPU.
Mechanizm ogrodzeń w Vulkan działa następująco: aplikacja tworzy \\ obiekt fence,
dołącza go do operacji przesyłanej do kolejki GPU \\
(np. poprzez \texttt{vkQueueSubmit}), a następnie może \\wywołać \texttt{vkWaitForFences},
Mechanizm ogrodzeń w Vulkan działa następująco: aplikacja tworzy obiekt fence,
dołącza go do operacji przesyłanej do kolejki GPU
(np. poprzez \texttt{vkQueueSubmit}), a następnie może wywołać \texttt{vkWaitForFences},
aby zablokować wątek CPU do momentu zakończenia
powiązanej pracy przez GPU. Jest to fundamentalny mechanizm synchronizacji w architekturze
producent-konsument między CPU a GPU.
@ -189,7 +190,7 @@ zdąża przygotować pracę dla GPU przed zakończeniem poprzedniej klatki.
Różnica między średnią a medianą (0,26 ms) wynika z obecności bardzo krótkich
czasów oczekiwania w niektórych sytuacjach (np. gdy GPU zakończył pracę przed wywołaniem wait).
Maksymalny czas 1\,181,17 ms odpowiada fazie
inicjalizacji, \\ podczas której GPU wykonuje jednorazowe, kosztowne operacje.
inicjalizacji, podczas której GPU wykonuje jednorazowe, kosztowne operacje.
Stosunek liczby wywołań \texttt{vkWaitForFences} (12\,895) do liczby klatek (13\,556) wskazuje, że
Unity stosuje strategię oczekiwania, prawie na
@ -233,7 +234,7 @@ odbywa się asynchronicznie na GPU.
Tabela~\ref{tab:unity-vulkan-cmd} przedstawia statystyki funkcji związanych z buforami poleceń.
Liczba wywołań \texttt{vkBeginCommandBuffer} \\ oraz
Liczba wywołań \texttt{vkBeginCommandBuffer} oraz
\texttt{vkEndCommandBuffer} (po 40\,679) oznacza, że Unity nagrywa średnio 3 bufory poleceń na klatkę. Jest to typowa wartość dla nowoczesnych
silników stosujących wielowątkowe nagrywanie poleceń.
@ -269,14 +270,15 @@ Tabela~\ref{tab:unity-vulkan-init} przedstawia jednorazowe operacje inicjalizacy
urządzenie Vulkan -- jest to najdroższa pojedyncza operacja, obejmująca negocjację możliwości GPU, alokację struktur wewnętrznych sterownika i
inicjalizację kolejek.
\texttt{vkCreateSwapchainKHR} (77,02 ms) tworzy łańcuch wymiany (swapchain), \\ czyli zestaw
\texttt{vkCreateSwapchainKHR} (77,02 ms) tworzy łańcuch wymiany (swapchain), czyli zestaw
buforów służących do prezentacji obrazu. Operacja ta
obejmuje alokację pamięci dla buforów, konfigurację formatów i synchronizację z systemem okienkowym.
Utworzenie 341 obiektów fence (łącznie 135,60 ms) wskazuje na przygotowanie puli ogrodzeń do
wielokrotnego użytku w cyklu renderowania.
\\ Unity stosuje
strategię pre-alokacji zamiast tworzenia ogrodzeń na żądanie, co jest praktyką zalecaną w dokumentacji
Utworzenie 341 obiektów fence (łącznie 135,60 ms) wskazuje na
przygotowanie puli ogrodzeń do wielokrotnego użytku w cyklu renderowania.
Unity stosuje
strategię \\ pre-alokacji zamiast tworzenia ogrodzeń na żądanie, co
jest praktyką zalecaną w dokumentacji
Vulkan.
@ -361,21 +363,22 @@ Duża liczba wywołań \texttt{openat64} (22\,155) wskazuje na intensywne operac
gry (tekstur, modeli, shaderów) z dysku. Średni czas 1,07 $\mu$s potwierdza efektywne buforowanie przez system operacyjny.
\texttt{ioctl} (1\,907 wywołań) służy do kontroli urządzeń -- w kontekście grafiki Vulkan jest
używane do komunikacji ze sterownikiem GPU poprzez \\
używane do komunikacji ze sterownikiem GPU poprzez
interfejs DRM/KMS (Direct Rendering Manager / Kernel Mode Setting).
Przeprowadzona analiza pozwala na sformułowanie następujących wniosków dotyczących wydajności i architektury silnika Unity:
Dominacja \texttt{vkWaitForFences} \\ (95,2\% czasu Vulkan) i \texttt{futex} (95,9\% czasu systemowego)
Dominacja \texttt{vkWaitForFences} (95,2\% czasu Vulkan) i \texttt{futex} (95,9\% czasu systemowego)
jednoznacznie wskazuje na scenariusz
\textbf{GPU-bound}. Procesor główny efektywnie przygotowuje i przesyła pracę renderowania, po czym oczekuje na GPU. Jest to optymalny wzorzec dla
aplikacji graficznych, gdzie GPU wykonuje większość obliczeniowo intensywnej pracy.
W scenariuszu CPU-bound obserwowalibyśmy niższy udział funkcji synchronizacyjnych i wyższy udział
funkcji przygotowujących polecenia \\
(\texttt{vkBeginCommandBuffer}, \texttt{vkCmdBindPipeline} itp.), co wskazywałoby na wąskie gardło po stronie procesora.
W scenariuszu CPU-bound obserwowalibyśmy niższy udział funkcji
synchronizacyjnych i wyższy udział
funkcji przygotowujących polecenia
(\texttt{vkBeginCommandBuffer}, \\ \texttt{vkCmdBindPipeline} itp.), co wskazywałoby na wąskie gardło po stronie procesora.
Stosunek liczby wywołań \texttt{vkQueueSubmit} (27\,112) do \texttt{vkQueuePresentKHR} (13\,556) wynoszący 2:1 wskazuje na dwuetapowy potok
@ -383,7 +386,7 @@ renderowania dla każdej klatki. Może to odpowiadać architekturze z oddzielnym
odroczonego renderowania (ang. \textit{deferred rendering}).
Niska liczba wywołań \texttt{vkCmdBindPipeline} (27\,027, ~2 na klatkę)
sugeruje \\ efektywne grupowanie obiektów renderowanych tym samym shaderem,
sugeruje efektywne grupowanie obiektów renderowanych tym samym shaderem,
minimalizujące kosztowne zmiany stanu GPU.
@ -391,23 +394,23 @@ Pomimo wysokiego współczynnika zmienności (153\%) wynikającego z wartości e
inicjalizacji, właściwa stabilność renderowania jest
wysoka. Świadczy o tym:
\begin{itemize}
\item Wąski rozstęp międzykwartylowy (0,08 ms)
\item Zbieżność mediany (6,94 ms) ze średnią (6,95 ms)
\item Mała różnica między 50. a 99. percentylem (0,64 ms, 9,2\%)
\item 98,24\% klatek w przedziale 5--10 ms
\item Wąski rozstęp międzykwartylowy (0,08 ms).
\item Zbieżność mediany (6,94 ms) ze średnią (6,95 ms).
\item Mała różnica między 50. a 99. percentylem (0,64 ms, 9,2\%).
\item 98,24\% klatek w przedziale 5--10 ms.
\end{itemize}
Należy jednak podkreślić, że obserwowana stabilność jest w znacznej mierze wynikiem
działania synchronizacji pionowej (V-Sync), która sztucznie \\
wyrównuje czasy klatek poprzez oczekiwanie na sygnał odświeżania monitora. \\ Bez V-Sync
działania synchronizacji pionowej (V-Sync), która sztucznie
wyrównuje czasy klatek poprzez oczekiwanie na sygnał odświeżania monitora. Bez V-Sync
zmienność czasów klatek mogłaby być wyższa.
Analiza wywołań systemowych potwierdza intensywne wykorzystanie wielowątkowości:
\begin{itemize}
\item 81 utworzonych wątków wskazuje na rozbudowany system zadań
\item Dominacja \texttt{futex} sugeruje częstą komunikację między wątkami
\item Użycie zmiennych warunkowych z timeoutem świadczy o responsywnej architekturze
\item 81 utworzonych wątków wskazuje na rozbudowany system zadań.
\item Dominacja \texttt{futex} sugeruje częstą komunikację między wątkami.
\item Użycie zmiennych warunkowych z timeoutem świadczy o responsywnej architekturze.
\end{itemize}
Unity 2023 LTS stosuje architekturę DOTS (Data-Oriented Technology Stack) z systemem zadań (Job System), który automatycznie dystrybuuje pracę na
@ -418,44 +421,47 @@ dostępne rdzenie procesora. Wyniki profilowania potwierdzają aktywne wykorzyst
Profilowanie silnika Unreal Engine 5.5 przeprowadzono przy użyciu NVIDIA Nsight Systems w
wersji 2025.5.2. Ze względu na problemy ze stabilnością
połączenia agenta Nsight podczas długich sesji profilowania, 90-sekundową \\ rozgrywkę
połączenia agenta Nsight podczas długich sesji profilowania, 90-sekundową rozgrywkę
podzielono na \textbf{trzy fazy po 30 sekund każda}:
\begin{itemize}
\item \textbf{Faza 1} (0--30 s): Początkowa rozgrywka z niską trudnością
\item \textbf{Faza 2} (30--60 s): Środkowa rozgrywka ze średnią trudnością
\item \textbf{Faza 3} (60--90 s): Końcowa rozgrywka z wysoką trudnością + ekran zwycięstwa
\item \textbf{Faza 1} (0--30 s): Początkowa rozgrywka z niską trudnością.
\item \textbf{Faza 2} (30--60 s): Środkowa rozgrywka ze średnią trudnością.
\item \textbf{Faza 3} (60--90 s): Końcowa rozgrywka z wysoką trudnością + ekran zwycięstwa.
\end{itemize}
Każda faza była uruchamiana z flagą \texttt{--start-time=N}, która przesuwa \\ zarówno stan gry
Każda faza była uruchamiana z flagą \texttt{--start-time=N}, która przesuwa
zarówno stan gry
(w \texttt{STGGameDirector}), jak i poziom trudności
spawnu przeciwników \\ (w \texttt{STGEnemySpawner}) do odpowiedniej sekundy. \\ Grę skompilowano w konfiguracji DebugGame, która zachowuje symbole
spawnu przeciwników \\ (w \texttt{STGEnemySpawner}) do odpowiedniej sekundy. Grę skompilowano w konfiguracji DebugGame, która zachowuje symbole
debugowania przy częściowych optymalizacjach.
Ze względu na bardzo dużą ilość danych generowanych przez Unreal Engine podczas śledzenia wywołań Vulkan API (około 13 milionów zdarzeń
na 30 sekund rozgrywki, w porównaniu z 0,5 miliona dla Unity), 90-sekundową rozgrywkę podzielono na \textbf{trzy fazy po 30 sekund każda}:
\begin{itemize}
\item \textbf{Faza 1} (0--30 s): Początkowa rozgrywka z niską trudnością
\item \textbf{Faza 2} (30--60 s): Środkowa rozgrywka ze średnią trudnością
\item \textbf{Faza 3} (60--90 s): Końcowa rozgrywka z wysoką trudnością + ekran zwycięstwa
\item \textbf{Faza 1} (0--30 s): Początkowa rozgrywka z niską trudnością.
\item \textbf{Faza 2} (30--60 s): Środkowa rozgrywka ze średnią trudnością.
\item \textbf{Faza 3} (60--90 s): Końcowa rozgrywka z wysoką trudnością + ekran zwycięstwa.
\end{itemize}
Każda faza była uruchamiana z flagą \texttt{--start-time=N}, która przesuwa zarówno stan gry
(w \texttt{STGGameDirector}), jak i poziom trudności spawnu \\ przeciwników (w \texttt{STGEnemySpawner})
Każda faza była uruchamiana z flagą \texttt{--start-time=N},
która przesuwa zarówno stan gry
(w \texttt{STGGameDirector}), jak i poziom trudności spawnu przeciwników
\\ (w \texttt{STGEnemySpawner})
do odpowiedniej sekundy.
\\ Grę skompilowano w konfiguracji DebugGame, która zachowuje symbole debugowania przy częściowych optymalizacjach.
Grę skompilowano w konfiguracji DebugGame, która zachowuje symbole debugowania przy częściowych optymalizacjach.
Profilowanie przeprowadzono z wykorzystaniem tych samych metryk co dla Unity:
\begin{itemize}
\item \textbf{Śledzenia wywołań Vulkan API} (\texttt{--trace=vulkan}) -- przechwytywanie \\ wszystkich funkcji Vulkan
\item \textbf{Śledzenia wywołań systemowych} (\texttt{--trace=osrt}) -- przechwytywanie funkcji OS Runtime
\item \textbf{Metryk sprzętowych GPU} (\texttt{--gpu-metrics-devices=0}) -- próbkowanie \\ liczników wydajności GPU
\item \textbf{Śledzenia wywołań Vulkan API} (\texttt{--trace=vulkan}) -- przechwytywanie wszystkich funkcji Vulkan.
\item \textbf{Śledzenia wywołań systemowych} (\texttt{--trace=osrt}) -- przechwytywanie funkcji OS Runtime.
\item \textbf{Metryk sprzętowych GPU} (\texttt{--gpu-metrics-devices=0}) -- próbkowanie liczników wydajności GPU.
\end{itemize}
NVIDIA Nsight Systems zbiera metryki sprzętowe GPU poprzez bezpośredni dostęp do liczników
wydajności zintegrowanych w karcie graficznej.
\\ Podczas trzech 35-sekundowych sesji (30 sekund rozgrywki + 5 sekund buforu) zebrano łącznie \textbf{1\,050\,555 próbek} dla każdej z
Podczas trzech 35-sekundowych sesji (30 sekund rozgrywki + 5 sekund buforu) zebrano łącznie \textbf{1\,050\,555 próbek} dla każdej z
31 monitorowanych metryk.
\begin{table}[H]
@ -503,7 +509,7 @@ Liczba próbek & 350\,205 & 350\,249 & 350\,101 \\
Tabela~\ref{tab:unreal-gpu-phases} pokazuje stabilność metryk GPU między fazami 1 i 2
różnice <0,5 pp.),
co potwierdza poprawność metodologii
fazowego profilowania. \\
fazowego profilowania.
Wyraźny spadek w fazie
3 odzwierciedla zakończenie aktywnej rozgrywki i przejście do ekranu zwycięstwa.
@ -565,17 +571,17 @@ Unallocated Warps in Active SMs & 20,73 & 90,0 \\
Tabela~\ref{tab:unreal-warps} przedstawia rozkład typów aktywnych wątków shader
(warps -- grupy 32 wątków CUDA wykonywanych synchronicznie).
\\Dominacja \texttt{Compute Warps} (13,03\%) nad \texttt{Pixel Warps} (9,36\%) wskazuje na znaczące wykorzystanie compute shaderów, prawdopodobnie do:
Dominacja \texttt{Compute Warps} (13,03\%) nad \texttt{Pixel Warps} (9,36\%) wskazuje na znaczące wykorzystanie compute shaderów, prawdopodobnie do:
\begin{itemize}
\item Culling (odrzucanie niewidocznych obiektów na GPU)
\item Post-processing i tone mapping
\item Symulacji cząsteczek lub fizyki na GPU
\item Culling (odrzucanie niewidocznych obiektów na GPU).
\item Post-processing i tone mapping.
\item Symulacji cząsteczek lub fizyki na GPU.
\end{itemize}
Niski udział \texttt{Vertex/Tess/Geometry Warps} (0,45\%) sugeruje prostą geometrię sceny bez intensywnego wykorzystania teselacji --
co jest zgodne z charakterystyką testowanej gry bullet-hell, gdzie większość efektów wizualnych to płaskie sprite'y i efekty cząsteczkowe.
\texttt{Unallocated Warps in Active SMs} (20,73\%) reprezentuje \\ niewykorzystaną pojemność
\texttt{Unallocated Warps in Active SMs} (20,73\%) reprezentuje niewykorzystaną pojemność
aktywnych multiprocesorów. Wartość ta wskazuje na
potencjał optymalizacji przez zwiększenie granularności pracy lub lepsze grupowanie operacji.
@ -672,7 +678,7 @@ wskazuje na konsystentną architekturę potoku renderowania niezależną od obci
W przeciwieństwie do Unity, gdzie dominującą funkcją był \texttt{vkWaitForFences},
w Unreal Engine \textbf{57--72\% czasu} Vulkan API
pochłonęły funkcje tworzenia potoków.
\\ Co istotne, liczba wywołań \texttt{vkCreateComputePipelines} i \\
Co istotne, liczba wywołań \texttt{vkCreateComputePipelines} i
\texttt{vkCreateGraphicsPipelines} jest
\textbf{niemal identyczna we wszystkich trzech fazach}, co wskazuje na strategię \textbf{ciągłej rekompilacji potoków} (Pipeline State Object)
przez cały czas działania gry.
@ -682,7 +688,7 @@ przez cały czas działania gry.
Średni czas tworzenia potoku compute (18,63--19,21 ms) jest ponad \textbf{14 razy dłuższy}
niż dla potoku graficznego (1,14--1,39 ms). Różnica ta
wynika z większej złożoności shaderów obliczeniowych używanych \\ przez Unreal Engine do culling, post-processingu i systemu Nanite.
wynika z większej złożoności shaderów obliczeniowych używanych przez Unreal Engine do culling, post-processingu i systemu Nanite.
Wywołanie \texttt{vkCreateDevice} pojawia się raz w każdej fazie z czasem 541--590 ms, co odpowiada momentowi startu gry w tej fazie -- narzędzie
Nsight Systems tworzy nową sesję dla każdej fazy.
@ -707,13 +713,13 @@ Nsight Systems tworzy nową sesję dla każdej fazy.
W ostrzym kontraście z Unity (gdzie \texttt{vkWaitForFences} stanowił 95,2\% czasu), w Unreal Engine funkcja ta pochłonęła zaledwie
\textbf{0,5\% czasu} ze średnim czasem oczekiwania 3,63 $\mu$s. Tak niski czas oczekiwania wskazuje na:
\begin{itemize}
\item Efektywne wykorzystanie wielokrotnego buforowania (triple buffering)
\item Asynchroniczne przesyłanie pracy do GPU bez blokowania
\item Lepsze rozłożenie pracy między CPU a GPU eliminujące przestoje
\item Efektywne wykorzystanie wielokrotnego buforowania (triple buffering).
\item Asynchroniczne przesyłanie pracy do GPU bez blokowania.
\item Lepsze rozłożenie pracy między CPU a GPU eliminujące przestoje.
\end{itemize}
Stosunek wywołań \texttt{vkQueueSubmit} (186\,589) do \\ \texttt{vkQueuePresentKHR} (11\,531)
wynosi \textbf{16,2:1}, co oznacza średnio \\ 16
Stosunek wywołań \texttt{vkQueueSubmit} (186\,589) do \texttt{vkQueuePresentKHR} (11\,531)
wynosi \textbf{16,2:1}, co oznacza średnio 16
przesyłek pracy na klatkę. Jest to znacznie więcej niż w Unity (2:1), odzwierciedlając
bardziej złożony potok renderowania Unreal Engine z
wieloma przebiegami (deferred rendering, post-processing, UI).
@ -735,13 +741,13 @@ wieloma przebiegami (deferred rendering, post-processing, UI).
\end{tabular}
\end{table}
Liczba wywołań \\ \texttt{vkCmdBindPipeline} (\textbf{5\,771\,642}
łącznie we wszystkich fazach) jest \\ ponad \textbf{213 razy większa} niż w
Unity (27\,027), \\ co odpowiada około 218 zmianom potoku na klatkę. Tak wysoka wartość wynika z:
Liczba wywołań \texttt{vkCmdBindPipeline} (\textbf{5\,771\,642}
łącznie we wszystkich fazach) jest ponad \textbf{213 razy większa} niż w
Unity (27\,027), co odpowiada około 218 zmianom potoku na klatkę. Tak wysoka wartość wynika z:
\begin{itemize}
\item Dynamicznego systemu materiałów Unreal Engine
\item Wielu wariantów shaderów dla różnych kombinacji oświetlenia
\item Złożonego potoku renderowania z wieloma przebiegami
\item Dynamicznego systemu materiałów Unreal Engine.
\item Wielu wariantów shaderów dla różnych kombinacji oświetlenia.
\item Złożonego potoku renderowania z wieloma przebiegami.
\end{itemize}
Funkcja \texttt{vkCmdPipelineBarrier2KHR} (4\,090\,071 wywołań) synchronizuje dostęp do zasobów w obrębie GPU -- wysoka liczba wywołań wskazuje
@ -750,9 +756,9 @@ na staranną kontrolę zależności między operacjami, typową dla nowoczesnych
Interesującą obserwacją jest obecność wywołań związanych z ray tracingiem we wszystkich fazach:
\begin{itemize}
\item \texttt{vkCreateAccelerationStructureKHR}: 23\,960 + 26\,275 + 11\,884 = 62\,119 wywołań
\item \texttt{vkDestroyAccelerationStructureKHR}: 20\,571 + 23\,063 + 9\,181 = 52\,815 wywołań
\item \texttt{vkGetAccelerationStructureBuildSizesKHR}: 41\,161 + 46\,147 + 18\,379 = 105\,687 wywołań
\item \texttt{vkCreateAccelerationStructureKHR}: 23\,960 + 26\,275 + 11\,884 = 62\,119 wywołań.
\item \texttt{vkDestroyAccelerationStructureKHR}: 20\,571 + 23\,063 + 9\,181 = 52\,815 wywołań.
\item \texttt{vkGetAccelerationStructureBuildSizesKHR}: 41\,161 + 46\,147 + 18\,379 = 105\,687 wywołań.
\end{itemize}
Pomimo że testowana gra nie wykorzystuje widocznych efektów ray tracingu, Unreal Engine przygotowuje struktury akceleracji BVH
@ -782,7 +788,7 @@ wielowątkowego Unreal Engine. Łącznie zarejestrowano ponad \textbf{9 milionó
\end{tabular}
\end{table}
Funkcja \texttt{pthread\_cond\_wait} \\ pochłonęła \textbf{64,6\% czasu} przy \textbf{3\,095\,188 wywołaniach} we wszystkich trzech fazach.
Funkcja \texttt{pthread\_cond\_wait} pochłonęła \textbf{64,6\% czasu} przy \textbf{3\,095\,188 wywołaniach} we wszystkich trzech fazach.
Jest to funkcja POSIX do oczekiwania na zmienną warunkową, używana gdy wątek musi czekać na spełnienie określonego warunku sygnalizowanego przez
inny wątek.
@ -790,10 +796,10 @@ Tak wysoka liczba wywołań (ponad 40 razy więcej niż dla Unity)
odzwierciedla architekturę wielowątkową Unreal Engine opartą na systemie
\textbf{TaskGraph}. System ten dekomponuje pracę renderowania na małe zadania (ang. \textit{tasks}),
które są wykonywane przez pulę wątków roboczych.
Każde zadanie po zakończeniu sygnalizuje swoją gotowość, a zależne zadania są budzone \\ poprzez
Każde zadanie po zakończeniu sygnalizuje swoją gotowość, a zależne zadania są budzone poprzez
\texttt{pthread\_cond\_signal}/\texttt{pthread\_cond\_broadcast}.
Średni czas pojedynczego oczekiwania (0,97 ms) jest krótki, co wskazuje \\ na częste, ale krótkotrwałe synchronizacje --
Średni czas pojedynczego oczekiwania (0,97 ms) jest krótki, co wskazuje na częste, ale krótkotrwałe synchronizacje --
typowe dla drobnoziarnistego paralelizmu. Maksymalny czas 22,23 sekundy odpowiada prawdopodobnie wywołaniu podczas długotrwałej operacji
inicjalizacyjnej w fazie 2.
@ -819,18 +825,18 @@ Tabela~\ref{tab:unreal-osrt-phases} pokazuje konsystencję wzorców wywołań mi
fazie 3 (zawierającej ekran zwycięstwa). Szczególnie interesująca jest wysoka liczba wywołań \texttt{backtrace} (ponad 5,5 miliona łącznie),
co sugeruje intensywne wykorzystanie mechanizmów debugowania lub profilowania wbudowanych w Unreal Engine nawet w konfiguracji DebugGame.
(19,2\%, 163\,783 \\ wywołań) różni się od
(19,2\%, 163\,783 wywołań) różni się od
\texttt{pthread\_cond\_wait} możliwością określenia maksymalnego czasu
oczekiwania. Użycie tej funkcji wskazuje na mechanizmy:
\begin{itemize}
\item Timeoutów zapobiegających zakleszczeniom (deadlock prevention)
\item Okresowego sprawdzania warunków (polling pattern)
\item Synchronizacji czasowej dla frame pacing
\item Timeoutów zapobiegających zakleszczeniom (deadlock prevention).
\item Okresowego sprawdzania warunków (polling pattern).
\item Synchronizacji czasowej dla frame pacing.
\end{itemize}
Średni czas 5,46 ms sugeruje użycie do synchronizacji między-klatkowej, \\
Średni czas 5,46 ms sugeruje użycie do synchronizacji między-klatkowej,
gdzie wątki oczekują na gotowość kolejnej klatki z timeout'em
\\ zapobiegającym nieskończonemu oczekiwaniu w przypadku błędu.
zapobiegającym nieskończonemu oczekiwaniu w przypadku błędu.
Funkcja \texttt{usleep} (4,7\%, 26\,062 wywołań, średnio 7,79 ms) wprowadza precyzyjne opóźnienia czasowe. Średni czas 7,79 ms jest zbliżony do
@ -857,21 +863,21 @@ Liczba próbek GPU (10 kHz) & -- & 1\,050\,555 \\
Tabela~\ref{tab:sync-comparison} ujawnia fundamentalną różnicę architektoniczną między silnikami:
\textbf{Unity} stosuje mechanizm \texttt{futex} z niewielką liczbą wywołań (247) \\ i
\textbf{Unity} stosuje mechanizm \texttt{futex} z niewielką liczbą wywołań (247) i
długim średnim czasem (444 ms). Wskazuje to na architekturę z
większymi, bardziej autonomicznymi jednostkami pracy i rzadszą synchronizacją między wątkami.
\textbf{Unreal Engine} używa \texttt{pthread\_cond\_wait} z ogromną liczbą wywołań
\\ (ponad 3 miliony w 90-sekundowym teście) \\ i bardzo krótkim średnim
(ponad 3 miliony w 90-sekundowym teście) i bardzo krótkim średnim
czasem (0,97 ms). Odzwierciedla to drobnoziarnisty paralelizm systemu TaskGraph, gdzie praca jest dzielona na małe zadania często komunikujące się ze
sobą.
Różnica ta ma implikacje praktyczne:
\begin{itemize}
\item \textbf{Skalowalność}: Drobnoziarnisty model Unreal lepiej skaluje się na procesory z wieloma rdzeniami
\item \textbf{Narzut synchronizacji}: Model Unity ma mniejszy narzut \\ z powodu rzadszych wywołań
\item \textbf{Responsywność}: Unreal może szybciej reagować na zmiany (np. przerwanie zadania)
\item \textbf{Debugowanie}: Model Unity jest łatwiejszy do analizy ze względu na prostszą strukturę
\item \textbf{Skalowalność}: Drobnoziarnisty model Unreal lepiej skaluje się na procesory z wieloma rdzeniami.
\item \textbf{Narzut synchronizacji}: Model Unity ma mniejszy narzut z powodu rzadszych wywołań.
\item \textbf{Responsywność}: Unreal może szybciej reagować na zmiany (np. przerwanie zadania).
\item \textbf{Debugowanie}: Model Unity jest łatwiejszy do analizy ze względu na prostszą strukturę.
\end{itemize}
@ -880,33 +886,33 @@ Zebrane dane z trzech faz profilowania pozwalają na charakterystykę architekto
Unreal Engine 5 stosuje zaawansowaną architekturę wielowątkową złożoną z:
\begin{itemize}
\item \textbf{Game Thread} -- główny wątek logiki gry
\item \textbf{Render Thread} -- wątek przygotowujący polecenia renderowania
\item \textbf{RHI Thread} (Render Hardware Interface) -- wątek komunikujący się z API graficznym
\item \textbf{Worker Threads} -- pula wątków roboczych systemu TaskGraph
\item \textbf{Game Thread} -- główny wątek logiki gry.
\item \textbf{Render Thread} -- wątek przygotowujący polecenia renderowania.
\item \textbf{RHI Thread} (Render Hardware Interface) -- wątek komunikujący się z API graficznym.
\item \textbf{Worker Threads} -- pula wątków roboczych systemu TaskGraph.
\end{itemize}
Obserwowana dominacja \texttt{pthread\_cond\_wait} (3+ miliony wywołań) \\ potwierdza intensywną
Obserwowana dominacja \texttt{pthread\_cond\_wait} (3+ miliony wywołań) potwierdza intensywną
komunikację między tymi wątkami.
\\ Wysokie wykorzystanie
Wysokie wykorzystanie
GPU (90,98\% w fazach aktywnej rozgrywki) przy jednoczesnej intensywnej synchronizacji CPU sugeruje efektywne wykorzystanie zasobów obu procesorów.
Na podstawie zebranych metryk można \\ scharakteryzować profil obciążenia GPU:
Na podstawie zebranych metryk można scharakteryzować profil obciążenia GPU:
\begin{itemize}
\item \textbf{Charakter pracy}: Mieszany graficzno-obliczeniowy (GR Active 85,59\%, Sync Compute 43,23\%)
\item \textbf{Wykorzystanie SM}: Umiarkowane (42,88\%), wskazujące na potencjał optymalizacji
\item \textbf{Przepustowość pamięci}: Niewysoka (10,30\% odczyt, 10,10\% zapis), nie jest wąskim gardłem
\item \textbf{Transfer PCIe}: Niski (1,50\% RX), dane pozostają w pamięci GPU
\item \textbf{Async Copy Engine}: Aktywny w 24--25\% czasu, wskazując na efektywne wykorzystanie asynchronicznych transferów
\item \textbf{Charakter pracy}: Mieszany graficzno-obliczeniowy (GR Active 85,59\%, Sync Compute 43,23\%).
\item \textbf{Wykorzystanie SM}: Umiarkowane (42,88\%), wskazujące na potencjał optymalizacji.
\item \textbf{Przepustowość pamięci}: Niewysoka (10,30\% odczyt, 10,10\% zapis), nie jest wąskim gardłem.
\item \textbf{Transfer PCIe}: Niski (1,50\% RX), dane pozostają w pamięci GPU.
\item \textbf{Async Copy Engine}: Aktywny w 24--25\% czasu, wskazując na efektywne wykorzystanie asynchronicznych transferów.
\end{itemize}
Porównanie faz 1 i 2 (tabela~\ref{tab:unreal-gpu-phases}) pokazuje niezwykłą stabilność metryk GPU:
\begin{itemize}
\item GPU Active: różnica 0,36 pp. (91,16\% vs 90,80\%)
\item GR Active: różnica 0,21 pp. (85,69\% vs 85,48\%)
\item SMs Active: różnica 0,18 pp. (42,79\% vs 42,97\%)
\item GPU Active: różnica 0,36 pp. (91,16\% vs 90,80\%).
\item GR Active: różnica 0,21 pp. (85,69\% vs 85,48\%).
\item SMs Active: różnica 0,18 pp. (42,79\% vs 42,97\%).
\end{itemize}
Ta konsystencja potwierdza poprawność metodologii fazowego profilowania i sugeruje deterministyczne zachowanie silnika renderującego niezależnie od
@ -967,11 +973,15 @@ vkCmdBindPipeline / klatkę & 2 & 218 \\
Analiza wywołań Vulkan API ujawnia fundamentalnie różne profile obciążenia (tabela~\ref{tab:gpu-comparison}):
Dominacja \texttt{vkWaitForFences} (95,2\% czasu) \\ wskazuje, że CPU efektywnie przygotowuje pracę i oczekuje na GPU.
Jest to pożądany wzorzec w aplikacjach graficznych, gdzie GPU wykonuje większość obliczeń. \\ Niski stosunek
\texttt{vkQueueSubmit}/klatkę (2:1) świadczy o prostym, dwuetapowym potoku renderowania.
Dominacja \texttt{vkWaitForFences} (95,2\% czasu) wskazuje, że CPU efektywnie
przygotowuje pracę i oczekuje na GPU.
Jest to pożądany wzorzec w aplikacjach graficznych, gdzie GPU wykonuje
większość obliczeń. Niski stosunek
\texttt{vkQueueSubmit}/klatkę (2:1) świadczy o prostym, dwuetapowym potoku
renderowania.
W Unreal Engine dominującymi operacjami były \texttt{vkCreateComputePipelines} \\ oraz \texttt{vkCreateGraphicsPipelines},
W Unreal Engine dominującymi operacjami były \texttt{vkCreateComputePipelines}
oraz \texttt{vkCreateGraphicsPipelines},
pochłaniające łącznie 57--72\% czasu Vulkan. Silnik tworzy około \textbf{1000 potoków w każdej 30-sekundowej fazie}
(vs 3 potoki w całym teście Unity), co wskazuje na strategię dynamicznej kompilacji shaderów.
@ -1003,6 +1013,7 @@ większe jednostki pracy autonomicznie, co minimalizuje narzut komunikacji.
\textbf{Unreal Engine} implementuje drobnoziarnisty paralelizm poprzez system TaskGraph. Praca jest dzielona na tysiące
małych zadań często komunikujących się ze sobą (ponad 3 miliony wywołań synchronizacji w 90 sekund).
\subsection{Podsumowanie wyników testów wydajności}
\label{subsec:podsumowanie-testow}
@ -1024,7 +1035,6 @@ Potoki graficzne utworzone & 3 & $\sim$2\,400 \\
\hline
\end{tabular}
\end{table}
\newpage
Przeprowadzone testy wydajnościowe pozwalają na sformułowanie następujących wniosków:
@ -1033,11 +1043,13 @@ Przeprowadzone testy wydajnościowe pozwalają na sformułowanie następujących
oba silniki osiągają zbliżoną wydajność: Unity 1\% low 132 FPS vs Unreal 162 FPS. Różnica
około 23\% na korzyść Unreal wynika częściowo z różnych konfiguracji V-Sync.
\item \textbf{Wykorzystanie GPU}: Unity wykorzystuje jedynie 23\% mocy GPU \\ (ograniczony V-Sync),
\item \textbf{Wykorzystanie GPU}: Unity wykorzystuje jedynie 23\% mocy GPU
\\ (ograniczony V-Sync),
podczas gdy Unreal Engine osiąga 91\% wykorzystania w fazach 1--2. Sugeruje to znaczny
zapas wydajności Unity przy wyłączonym V-Sync.
\item \textbf{Stabilność}: Unity wykazał stabilne czasy klatek dzięki V-Sync, \\ natomiast
\item \textbf{Stabilność}: Unity wykazał stabilne czasy klatek dzięki
V-Sync, natomiast
Unreal Engine pokazał dużą zmienność między fazami (332--339 FPS w fazach 1--2 vs 162 FPS
w fazie 3) -- spadek o ponad 50\%.
@ -1046,7 +1058,7 @@ Przeprowadzone testy wydajnościowe pozwalają na sformułowanie następujących
z rzadkimi synchronizacjami, podczas gdy Unreal stosuje drobnoziarnisty system TaskGraph
z milionami wywołań synchronizacyjnych.
\item \textbf{Narzut Unreal}: Dynamiczna kompilacja potoków \\ (ponad 1000 potoków na
30-sekundową fazę vs 3 w całym teście Unity) i 60-krotnie większa liczba wywołań Vulkan API
\item \textbf{Narzut Unreal}: Dynamiczna kompilacja potoków (ponad 1000 potoków na
\\ 30-sekundową fazę vs 3 w całym teście Unity) i 60-krotnie większa liczba wywołań Vulkan API
stanowią znaczący narzut, który może przyczyniać się do spadków wydajności w wymagających scenach.
\end{enumerate}

152
latex/tex/6-analiza-mozliwosci.tex
View File

@ -9,50 +9,50 @@ Niniejszy rozdział przedstawia porównanie kluczowych możliwości technicznych
Unity oferuje dwa główne pipeline'y renderowania: Built-in Render Pipeline (legacy), Universal Render Pipeline (URP) oraz High Definition Render Pipeline (HDRP). URP jest zoptymalizowany pod kątem wydajności i~kompatybilności między platformami, podczas gdy HDRP koncentruje się na~wysokiej jakości grafiki dla~platform o~dużej mocy obliczeniowej~\cite{gregory2018game}.
\begin{itemize}
\item \textbf{Forward rendering} -- domyślny tryb w~URP, efektywny dla~scen z~niewielką liczbą źródeł światła
\item \textbf{Deferred rendering} -- dostępny w~HDRP, umożliwia obsługę większej liczby świateł
\item \textbf{Ray tracing} -- wsparcie w~HDRP dla~kart graficznych NVIDIA RTX~\cite{parker2010optix}
\item \textbf{Forward rendering} -- domyślny tryb w~URP, efektywny dla~scen z~niewielką liczbą źródeł światła.
\item \textbf{Deferred rendering} -- dostępny w~HDRP, umożliwia obsługę większej liczby świateł.
\item \textbf{Ray tracing} -- wsparcie w~HDRP dla~kart graficznych NVIDIA RTX~\cite{parker2010optix}.
\end{itemize}
Unreal Engine wykorzystuje zaawansowany deferred rendering pipeline z~obsługą ray tracingu w~czasie rzeczywistym~\cite{unreal_docs}.
\begin{itemize}
\item \textbf{Deferred shading} -- standardowy pipeline dla~większości projektów~\cite{gregory2018game}
\item \textbf{Forward shading} -- opcjonalny tryb dla~projektów VR wymagających niskiej latencji~\cite{unreal_docs}
\item \textbf{Ray tracing} -- pełne wsparcie dla~Lumen (global illumination) i~ray-traced reflections
\item \textbf{Nanite} -- zwirtualizowana geometria pozwalająca na~renderowanie miliardów poligonów
\item \textbf{Deferred shading} -- standardowy pipeline dla~większości projektów~\cite{gregory2018game}.
\item \textbf{Forward shading} -- opcjonalny tryb dla~projektów VR wymagających niskiej latencji~\cite{unreal_docs}.
\item \textbf{Ray tracing} -- pełne wsparcie dla~Lumen (global illumination) i~ray-traced reflections.
\item \textbf{Nanite} -- zwirtualizowana geometria pozwalająca na~renderowanie miliardów poligonów.
\end{itemize}
Unity oferuje Shader Graph -- wizualny edytor do~tworzenia shaderów \\ bez~pisania kodu. Dodatkowo wspiera shadery pisane w~HLSL oraz~Cg~\cite{farina2013shader}.
Unity oferuje Shader Graph -- wizualny edytor do~tworzenia shaderów bez~pisania kodu. Dodatkowo wspiera shadery pisane w~HLSL oraz~Cg~\cite{farina2013shader}.
\begin{itemize}
\item \textbf{Shader Graph} -- intuicyjny, oparty na~węzłach interfejs
\item \textbf{HLSL/Cg} -- możliwość pisania custom shaderów~\cite{farina2013shader}
\item \textbf{Shader variants} -- system wariantów dla~optymalizacji
\item \textbf{Shader Graph} -- intuicyjny, oparty na~węzłach interfejs.
\item \textbf{HLSL/Cg} -- możliwość pisania custom shaderów~\cite{farina2013shader}.
\item \textbf{Shader variants} -- system wariantów dla~optymalizacji.
\end{itemize}
Unreal oferuje Material Editor -- zaawansowany system węzłowy do~tworzenia materiałów~\cite{unreal_docs}.
\begin{itemize}
\item \textbf{Material Editor} -- bogaty zestaw węzłów i~funkcji
\item \textbf{Material Functions} -- możliwość tworzenia wielokrotnego użytku komponentów
\item \textbf{Custom HLSL} -- integracja własnego kodu HLSL~\cite{farina2013shader}
\item \textbf{Material Editor} -- bogaty zestaw węzłów i~funkcji.
\item \textbf{Material Functions} -- możliwość tworzenia wielokrotnego użytku komponentów.
\item \textbf{Custom HLSL} -- integracja własnego kodu HLSL~\cite{farina2013shader}.
\end{itemize}
\begin{itemize}
\item \textbf{Real-time lighting} -- dynamiczne oświetlenie w~czasie rzeczywistym
\item \textbf{Baked lighting} -- przedkalkulowane mapy oświetlenia (lightmaps)
\item \textbf{Mixed lighting} -- połączenie światła dynamicznego i~baked
\item \textbf{Global Illumination} -- Progressive Lightmapper dla~światła odbitego~\cite{gregory2018game}
\item \textbf{Real-time lighting} -- dynamiczne oświetlenie w~czasie rzeczywistym.
\item \textbf{Baked lighting} -- przedkalkulowane mapy oświetlenia (lightmaps).
\item \textbf{Mixed lighting} -- połączenie światła dynamicznego i~baked.
\item \textbf{Global Illumination} -- Progressive Lightmapper dla~światła odbitego~\cite{gregory2018game}.
\end{itemize}
\begin{itemize}
\item \textbf{Lumen} -- dynamiczne global illumination w~czasie rzeczywistym
\item \textbf{Lightmass} -- high-quality baked lighting~\cite{gregory2018game}
\item \textbf{Ray-traced lighting} -- fizycznie dokładne oświetlenie~\cite{parker2010optix}
\item \textbf{Volumetric fog} -- zaawansowane efekty atmosferyczne
\item \textbf{Lumen} -- dynamiczne global illumination w~czasie rzeczywistym.
\item \textbf{Lightmass} -- high-quality baked lighting~\cite{gregory2018game}.
\item \textbf{Ray-traced lighting} -- fizycznie dokładne oświetlenie~\cite{parker2010optix}.
\item \textbf{Volumetric fog} -- zaawansowane efekty atmosferyczne.
\end{itemize}
\subsection{Systemy fizyki i symulacji}
@ -61,87 +61,87 @@ Unreal oferuje Material Editor -- zaawansowany system węzłowy do~tworzenia mat
Unity wykorzystuje NVIDIA PhysX jako~silnik fizyki~\cite{nvidia_physx}.
\begin{itemize}
\item \textbf{Rigidbody} -- komponent dla~obiektów fizycznych
\item \textbf{Colliders} -- różne typy koliderów (box, sphere, mesh, etc.)
\item \textbf{Joints} -- więzy i~połączenia (hinge, spring, fixed, etc.)
\item \textbf{Wydajność} -- efektywne dla~setek obiektów fizycznych~\cite{messaoudi2017performance}
\item \textbf{Rigidbody} -- komponent dla~obiektów fizycznych.
\item \textbf{Colliders} -- różne typy koliderów (box, sphere, mesh, etc.).
\item \textbf{Joints} -- więzy i~połączenia (hinge, spring, fixed, etc.).
\item \textbf{Wydajność} -- efektywne dla~setek obiektów fizycznych~\cite{messaoudi2017performance}.
\end{itemize}
Unreal przeszedł z~PhysX \\ na~Chaos Physics --
Unreal przeszedł z~PhysX na~Chaos Physics --
własny silnik fizyki~\cite{unreal_docs}.
\begin{itemize}
\item \textbf{Chaos Physics} -- nowy, zaawansowany system fizyki
\item \textbf{Destruction} -- wbudowane wsparcie dla~destrukcji obiektów
\item \textbf{Cloth simulation} -- symulacja tkanin
\item \textbf{Vehicles} -- zaawansowany system pojazdów~\cite{gregory2018game}
\item \textbf{Chaos Physics} -- nowy, zaawansowany system fizyki.
\item \textbf{Destruction} -- wbudowane wsparcie dla~destrukcji obiektów.
\item \textbf{Cloth simulation} -- symulacja tkanin.
\item \textbf{Vehicles} -- zaawansowany system pojazdów~\cite{gregory2018game}.
\end{itemize}
\begin{itemize}
\item \textbf{Shuriken Particle System} -- klasyczny system cząstek
\item \textbf{Visual Effect Graph} -- system cząstek GPU-based dla~milionów cząstek
\item \textbf{Shuriken Particle System} -- klasyczny system cząstek.
\item \textbf{Visual Effect Graph} -- system cząstek GPU-based dla~milionów cząstek.
\end{itemize}
\begin{itemize}
\item \textbf{Cascade} -- legacy system cząstek
\item \textbf{Niagara} -- zaawansowany, skalowalny system efektów wizualnych
\item \textbf{Cascade} -- legacy system cząstek.
\item \textbf{Niagara} -- zaawansowany, skalowalny system efektów wizualnych.
\end{itemize}
\subsection{Systemy audio}
\begin{itemize}
\item Obsługiwane formaty: WAV, MP3, OGG, AIFF
\item Kompresja: Vorbis, MP3, ADPCM
\item Audio middleware: integracja z~Wwise, FMOD~\cite{firat2022sound}
\item Obsługiwane formaty: WAV, MP3, OGG, AIFF.
\item Kompresja: Vorbis, MP3, ADPCM.
\item Audio middleware: integracja z~Wwise, FMOD~\cite{firat2022sound}.
\end{itemize}
\begin{itemize}
\item Obsługiwane formaty: WAV, OGG, FLAC
\item Natywna integracja z~MetaSounds
\item Wsparcie dla~Wwise, FMOD~\cite{firat2022sound}
\item Obsługiwane formaty: WAV, OGG, FLAC.
\item Natywna integracja z~MetaSounds.
\item Wsparcie dla~Wwise, FMOD~\cite{firat2022sound}.
\end{itemize}
Oba silniki oferują zaawansowane systemy dźwięku przestrzennego \\ z~obsługą~\cite{firat2022sound}:
Oba silniki oferują zaawansowane systemy dźwięku przestrzennego z~obsługą~\cite{firat2022sound}:
\begin{itemize}
\item Attenuation curves (krzywe tłumienia)
\item Occlusion i~obstruction (przesłanianie i~blokowanie)
\item Reverb zones (strefy pogłosu)
\item Doppler effect (efekt Dopplera)
\item Attenuation curves (krzywe tłumienia).
\item Occlusion i~obstruction (przesłanianie i~blokowanie).
\item Reverb zones (strefy pogłosu).
\item Doppler effect (efekt Dopplera).
\end{itemize}
\subsection{Narzędzia deweloperskie}
\begin{itemize}
\item \textbf{Scene View} -- intuicyjny edytor sceny 2D/3D
\item \textbf{Inspector} -- edycja właściwości komponentów
\item \textbf{Prefab Mode} -- izolowana edycja prefabrykatów
\item \textbf{UI Builder} -- wizualny edytor interfejsów użytkownika
\item \textbf{Scene View} -- intuicyjny edytor sceny 2D/3D.
\item \textbf{Inspector} -- edycja właściwości komponentów.
\item \textbf{Prefab Mode} -- izolowana edycja prefabrykatów.
\item \textbf{UI Builder} -- wizualny edytor interfejsów użytkownika.
\end{itemize}
\begin{itemize}
\item \textbf{Viewport} -- zaawansowany edytor poziomów
\item \textbf{Details Panel} -- szczegółowa konfiguracja aktorów
\item \textbf{Blueprint Editor} -- wizualne programowanie
\item \textbf{UMG Designer} -- projektowanie UI
\item \textbf{Viewport} -- zaawansowany edytor poziomów.
\item \textbf{Details Panel} -- szczegółowa konfiguracja aktorów.
\item \textbf{Blueprint Editor} -- wizualne programowanie.
\item \textbf{UMG Designer} -- projektowanie UI.
\end{itemize}
\begin{itemize}
\item Unity Profiler -- analiza wydajności CPU, GPU, pamięci
\item Console -- logi i~błędy w~czasie rzeczywistym
\item Frame Debugger -- analiza procesu renderowania klatka po~klatce
\item Memory Profiler -- szczegółowa analiza alokacji pamięci
\item Unity Profiler -- analiza wydajności CPU, GPU, pamięci.
\item Console -- logi i~błędy w~czasie rzeczywistym.
\item Frame Debugger -- analiza procesu renderowania klatka po~klatce.
\item Memory Profiler -- szczegółowa analiza alokacji pamięci.
\end{itemize}
\begin{itemize}
\item Unreal Insights -- kompleksowe narzędzie profilowania
\item Visual Logger -- wizualizacja logów w~kontekście gry
\item Session Frontend -- monitoring wielu instancji gry
\item GPU Visualizer -- analiza wydajności GPU
\item Unreal Insights -- kompleksowe narzędzie profilowania.
\item Visual Logger -- wizualizacja logów w~kontekście gry.
\item Session Frontend -- monitoring wielu instancji gry.
\item GPU Visualizer -- analiza wydajności GPU.
\end{itemize}
\subsection{Wsparcie dla platform docelowych}
@ -211,17 +211,17 @@ Oba silniki oferują wsparcie dla~głównych konsol (PlayStation 5, Xbox Series
\begin{itemize}
\item Ponad 100\,000 zasobów dostępnych
\item Modele 3D, tekstury, skrypty, narzędzia, kompletne projekty
\item Ceny od~darmowych do~kilkuset dolarów
\item System ocen i~recenzji
\item Ponad 100\,000 zasobów dostępnych.
\item Modele 3D, tekstury, skrypty, narzędzia, kompletne projekty.
\item Ceny od~darmowych do~kilkuset dolarów.
\item System ocen i~recenzji.
\end{itemize}
\begin{itemize}
\item Dziesiątki tysięcy zasobów wysokiej jakości
\item Miesięczne darmowe zasoby dla~subskrybentów
\item Integracja z~Quixel Megascans (biblioteka fotogrametryczna)
\item Często wyższa jakość, ale~mniejszy wybór niż~Unity
\item Dziesiątki tysięcy zasobów wysokiej jakości.
\item Miesięczne darmowe zasoby dla~subskrybentów.
\item Integracja z~Quixel Megascans (biblioteka fotogrametryczna).
\item Często wyższa jakość, ale~mniejszy wybór niż~Unity.
\end{itemize}
@ -250,13 +250,13 @@ Wielkość i~aktywność społeczności deweloperskiej jest istotnym czynnikiem
\begin{itemize}
\item \textbf{Dokumentacja oficjalna} -- ponad 5000 stron dokumentacji API
\item \textbf{Unity Learn} -- ponad 750 darmowych kursów i~tutoriali~\cite{christopoulou2017overview}
\item \textbf{Certyfikacje} -- 4 poziomy certyfikacji \\ (User, Associate, Professional, Expert)~\cite{barczak2019comparative}
\item \textbf{Dokumentacja oficjalna} -- ponad 5000 stron dokumentacji API.
\item \textbf{Unity Learn} -- ponad 750 darmowych kursów i~tutoriali~\cite{christopoulou2017overview}.
\item \textbf{Certyfikacje} -- 4 poziomy certyfikacji (User, Associate, Professional, Expert)~\cite{barczak2019comparative}.
\end{itemize}
\begin{itemize}
\item \textbf{Dokumentacja oficjalna} -- obszerna dokumentacja z~ponad 3000 stron
\item \textbf{Unreal Online Learning} -- ponad 200 darmowych kursów wideo~\cite{christopoulou2017overview}
\item \textbf{Epic Developer Community} -- oficjalne forum wsparcia~\cite{barczak2019comparative}
\item \textbf{Dokumentacja oficjalna} -- obszerna dokumentacja z~ponad 3000 stron.
\item \textbf{Unreal Online Learning} -- ponad 200 darmowych kursów wideo~\cite{christopoulou2017overview}.
\item \textbf{Epic Developer Community} -- oficjalne forum wsparcia~\cite{barczak2019comparative}.
\end{itemize}

108
latex/tex/7-porownanie-wynikow.tex
View File

@ -72,10 +72,10 @@ Analiza możliwości (rozdział~6) wykazała, że~oba silniki oferują bogate ze
Znaczenie poszczególnych kryteriów różni się w~zależności od~typu projektu:
\begin{itemize}
\item \textbf{Gry indie} -- priorytet: łatwość nauki, koszt, społeczność
\item \textbf{Gry mobilne} -- priorytet: wydajność, optymalizacja, wsparcie platform
\item \textbf{Gry AAA} -- priorytet: jakość grafiki, zaawansowane funkcje, skalowalność
\item \textbf{Gry edukacyjne} -- priorytet: prostota, dokumentacja, stabilność
\item \textbf{Gry indie} -- priorytet: łatwość nauki, koszt, społeczność.
\item \textbf{Gry mobilne} -- priorytet: wydajność, optymalizacja, wsparcie platform.
\item \textbf{Gry AAA} -- priorytet: jakość grafiki, zaawansowane funkcje, skalowalność.
\item \textbf{Gry edukacyjne} -- priorytet: prostota, dokumentacja, stabilność.
\end{itemize}
\subsection{Przypadki użycia}
@ -83,11 +83,11 @@ Znaczenie poszczególnych kryteriów różni się w~zależności od~typu projekt
\begin{itemize}
\item Niższy próg wejścia dla~początkujących deweloperów
\item Bogaty Asset Store z~dostępnymi cenowo zasobami
\item Większa społeczność -- łatwiej znaleźć pomoc
\item Szybsze prototypowanie
\item Mniejsze wymagania sprzętowe dla~deweloperów
\item Niższy próg wejścia dla~początkujących deweloperów.
\item Bogaty Asset Store z~dostępnymi cenowo zasobami.
\item Większa społeczność -- łatwiej znaleźć pomoc.
\item Szybsze prototypowanie.
\item Mniejsze wymagania sprzętowe dla~deweloperów.
\end{itemize}
Jeśli gra wymaga grafiki najwyższej jakości (photorealistic), rozważ Unreal Engine.
@ -95,11 +95,11 @@ Jeśli gra wymaga grafiki najwyższej jakości (photorealistic), rozważ Unreal
\begin{itemize}
\item Lepsza optymalizacja pod~platformy mobilne
\item Mniejsze rozmiary buildu
\item Lepsze wsparcie dla~starszych urządzeń
\item Więcej narzędzi i~assetów mobilnych
\item Większość gier mobilnych używa Unity (udowodniona skuteczność)
\item Lepsza optymalizacja pod~platformy mobilne.
\item Mniejsze rozmiary buildu.
\item Lepsze wsparcie dla~starszych urządzeń.
\item Więcej narzędzi i~assetów mobilnych.
\item Większość gier mobilnych używa Unity (udowodniona skuteczność).
\end{itemize}
Według danych z~2023 roku, około 70\% gier mobilnych na~iOS i~Android zostało stworzonych w~Unity~\cite{statista_unity_market, unity_gaming_report}.
@ -107,11 +107,11 @@ Według danych z~2023 roku, około 70\% gier mobilnych na~iOS i~Android zostało
\begin{itemize}
\item Wyższa jakość grafiki out-of-the-box
\item Nanite -- rendering miliardów poligonów
\item Lumen -- dynamiczne global illumination
\item Lepsze wsparcie dla~dużych zespołów
\item Sprawdzone w~produkcjach AAA (Fortnite, Gears of~War)
\item Wyższa jakość grafiki out-of-the-box.
\item Nanite -- rendering miliardów poligonów.
\item Lumen -- dynamiczne global illumination.
\item Lepsze wsparcie dla~dużych zespołów.
\item Sprawdzone w~produkcjach AAA (Fortnite, Gears of~War).
\end{itemize}
Unreal Engine wykorzystywano w~produkcjach takich jak: Final Fantasy VII Remake, Jedi: Fallen Order, Borderlands 3.
@ -119,15 +119,15 @@ Unreal Engine wykorzystywano w~produkcjach takich jak: Final Fantasy VII Remake,
\begin{itemize}
\item Aplikacje edukacyjne VR/AR
\item Mobilny AR (ARCore, ARKit)
\item Projekty wymagające szybkiego rozwoju
\item Aplikacje edukacyjne VR/AR.
\item Mobilny AR (ARCore, ARKit).
\item Projekty wymagające szybkiego rozwoju.
\end{itemize}
\begin{itemize}
\item High-end VR experiences
\item Architekturalna wizualizacja VR
\item Training simulations wymagające fotorealizmu
\item High-end VR experiences.
\item Architekturalna wizualizacja VR.
\item Training simulations wymagające fotorealizmu.
\end{itemize}
\subsection{Weryfikacja hipotez badawczych}
@ -148,10 +148,10 @@ Na~początku pracy (rozdział~\ref{sec:wstep}) postawiono następujące hipotezy
\textbf{Uzasadnienie}: Analiza wywiadów (rozdział~wywiady-analiza) wykazała, że~100\% respondentów z~doświadczeniem poniżej 2~lat oceniło Unity jako bardziej przystępne. Składają się na~to:
\begin{itemize}
\item Lepiej udokumentowane API
\item Większa dostępność tutoriali dla~początkujących
\item C\# jako język bardziej przyjazny niż~C++
\item Prostszy interfejs edytora
\item Lepiej udokumentowane API.
\item Większa dostępność tutoriali dla~początkujących.
\item C\# jako język bardziej przyjazny niż~C++.
\item Prostszy interfejs edytora.
\end{itemize}
@ -161,10 +161,10 @@ Na~początku pracy (rozdział~\ref{sec:wstep}) postawiono następujące hipotezy
\textbf{Uzasadnienie}:
\begin{itemize}
\item Mniejsze rozmiary buildów mobilnych w~Unity
\item Lepsza optymalizacja dla~urządzeń niskiej klasy
\item Większy ekosystem mobile-specific assetów
\item Dominacja na~rynku gier mobilnych (70\% udziału)
\item Mniejsze rozmiary buildów mobilnych w~Unity.
\item Lepsza optymalizacja dla~urządzeń niskiej klasy.
\item Większy ekosystem mobile-specific assetów.
\item Dominacja na~rynku gier mobilnych (70\% udziału).
\end{itemize}
@ -174,53 +174,53 @@ Na~początku pracy (rozdział~\ref{sec:wstep}) postawiono następujące hipotezy
\textbf{Uzasadnienie}:
\begin{itemize}
\item Technologie Nanite i~Lumen oferują funkcje niedostępne w~Unity
\item Lepsze domyślne materiały i~shadery
\item Zaawansowane efekty post-processingu out-of-the-box
\item Większość projektów wymagających fotorealizmu wykorzystuje Unreal
\item Technologie Nanite i~Lumen oferują funkcje niedostępne w~Unity.
\item Lepsze domyślne materiały i~shadery.
\item Zaawansowane efekty post-processingu out-of-the-box.
\item Większość projektów wymagających fotorealizmu wykorzystuje Unreal.
\end{itemize}
\subsection{Ograniczenia badań}
\begin{itemize}
\item \textbf{Ograniczona liczba scenariuszy testowych} -- skupiono się na~grze typu bullet-hell, co~nie~pokrywa wszystkich możliwych zastosowań silników
\item \textbf{Pojedyncza konfiguracja sprzętowa} -- testy przeprowadzono tylko na~jednym zestawie komputerowym
\item \textbf{Mała próba wywiadów} -- 8~respondentów może nie~reprezentować całej społeczności deweloperów
\item \textbf{Ograniczona liczba scenariuszy testowych} -- skupiono się na~grze typu bullet-hell, co~nie~pokrywa wszystkich możliwych zastosowań silników.
\item \textbf{Pojedyncza konfiguracja sprzętowa} -- testy przeprowadzono tylko na~jednym zestawie komputerowym.
\item \textbf{Mała próba wywiadów} -- 8~respondentów może nie~reprezentować całej społeczności deweloperów.
\end{itemize}
\begin{itemize}
\item \textbf{Wersje silników} -- wyniki dotyczą konkretnych wersji Unity i~Unreal; nowsze wersje mogą mieć odmienną wydajność
\item \textbf{Wpływ object poolingu} -- optymalizacja wpływa na~wyniki; bez~niej różnice mogłyby być większe
\item \textbf{Profilowanie} -- NVIDIA Nsight może wprowadzać własny narzut wydajnościowy
\item \textbf{Wersje silników} -- wyniki dotyczą konkretnych wersji Unity i~Unreal; nowsze wersje mogą mieć odmienną wydajność.
\item \textbf{Wpływ object poolingu} -- optymalizacja wpływa na~wyniki; bez~niej różnice mogłyby być większe.
\item \textbf{Profilowanie} -- NVIDIA Nsight może wprowadzać własny narzut wydajnościowy.
\end{itemize}
\begin{itemize}
\item Silniki gier rozwijają się dynamicznie -- wyniki mogą dezaktualizować się w~ciągu roku
\item Nie~testowano funkcji wprowadzonych w~najnowszych wersjach beta
\item Silniki gier rozwijają się dynamicznie -- wyniki mogą dezaktualizować się w~ciągu roku.
\item Nie~testowano funkcji wprowadzonych w~najnowszych wersjach beta.
\end{itemize}
\subsection{Implikacje praktyczne}
\begin{itemize}
\item Rozpoczynając naukę tworzenia gier, Unity stanowi bezpieczniejszy wybór
\item Dla projektów 2D, Unity jest jednoznacznie lepszym wyborem
\item Inwestycja w~naukę C++ może być wartościowa długoterminowo
\item Rozpoczynając naukę tworzenia gier, Unity stanowi bezpieczniejszy wybór.
\item Dla projektów 2D, Unity jest jednoznacznie lepszym wyborem.
\item Inwestycja w~naukę C++ może być wartościowa długoterminowo.
\end{itemize}
\begin{itemize}
\item Unity pozwala na~szybsze MVP i~iteracje
\item Unreal wymaga co~najmniej jednego doświadczonego programisty C++
\item Asset Store Unity oferuje więcej ready-to-use rozwiązań
\item Unity pozwala na~szybsze MVP i~iteracje.
\item Unreal wymaga co~najmniej jednego doświadczonego programisty C++.
\item Asset Store Unity oferuje więcej ready-to-use rozwiązań.
\end{itemize}
\begin{itemize}
\item Unreal Engine jest standardem przemysłowym dla~gier 3D wysokiej jakości
\item Wsparcie Epic Games dla~dużych projektów jest lepsze
\item Source code access w~Unreal daje większą kontrolę
\item Unreal Engine jest standardem przemysłowym dla~gier 3D wysokiej jakości.
\item Wsparcie Epic Games dla~dużych projektów jest lepsze.
\item Source code access w~Unreal daje większą kontrolę.
\end{itemize}

128
latex/tex/8-podsumowanie.tex
View File

@ -1,20 +1,21 @@
\clearpage
\raggedbottom
\section{Podsumowanie i wnioski}
Celem niniejszej pracy było porównanie wydajności i~możliwości dwóch wiodących silników gier komputerowych -- Unity oraz Unreal Engine -- ze~szczególnym uwzględnieniem ich wpływu na~proces tworzenia gier oraz~końcową jakość produktu. Cel ten został zrealizowany poprzez:
\begin{enumerate}
\item Przeprowadzenie szczegółowych testów wydajnościowych \\ z~wykorzystaniem niezależnego narzędzia NVIDIA Nsight Systems
\item Implementację identycznej gry typu bullet hell w~obu silnikach
\item Analizę porównawczą funkcjonalności i~możliwości obu silników
\item Przeprowadzenie wywiadów jakościowych z~ośmioma deweloperami gier
\item Przeprowadzenie szczegółowych testów wydajnościowych z~wykorzystaniem niezależnego narzędzia NVIDIA Nsight Systems.
\item Implementację identycznej gry typu bullet hell w~obu silnikach.
\item Analizę porównawczą funkcjonalności i~możliwości obu silników.
\item Przeprowadzenie wywiadów jakościowych z~ośmioma deweloperami gier.
\end{enumerate}
\subsection{Weryfikacja hipotezy badawczej}
Postawiona hipoteza badawcza brzmiała: \\ \textit{,,Silnik Unity, dzięki natywnemu wsparciu
Postawiona hipoteza badawcza brzmiała: \textit{,,Silnik Unity, dzięki natywnemu wsparciu
dla~grafiki 2D, osiągnie lepszą wydajność w~grze typu bullet hell niż Unreal Engine,
który jest zoptymalizowany \\ przede wszystkim pod~kątem aplikacji 3D.''}
który jest zoptymalizowany przede wszystkim pod~kątem aplikacji 3D.''}
Wyniki badań \textbf{częściowo potwierdzają} tę hipotezę, jednak obraz jest bardziej złożony niż początkowo zakładano:
@ -24,9 +25,9 @@ Unity wykorzystywał jedynie 23\% mocy obliczeniowej GPU (ograniczony przez V-Sy
Analiza wywołań Vulkan API ujawniła fundamentalne różnice architektoniczne:
\begin{itemize}
\item Unity: prosty, dwuetapowy potok renderowania \\ (2 wywołania \texttt{vkQueueSubmit} na~klatkę),
zdominowany przez \\ oczekiwanie na~GPU (\texttt{vkWaitForFences} -- 95,2\% czasu)
\item Unreal Engine: złożony potok z~16 wywołaniami \texttt{vkQueueSubmit} na~klatkę, zdominowany przez dynamiczną kompilację potoków (47--72\% czasu)
\item Unity: prosty, dwuetapowy potok renderowania (2 wywołania \\ \texttt{vkQueueSubmit} na~klatkę),
zdominowany przez oczekiwanie na~GPU \\ (\texttt{vkWaitForFences} -- 95,2\% czasu).
\item Unreal Engine: złożony potok z~16 wywołaniami \texttt{vkQueueSubmit} na~klatkę, zdominowany przez dynamiczną kompilację potoków (47--72\% czasu).
\end{itemize}
Unity wykazał większą stabilność czasów klatek (98,24\% klatek w~przedziale 5--10~ms), podczas gdy Unreal Engine doświadczył spadku wydajności o~ponad 50\% między fazami niskiego (332--339~FPS) a~wysokiego obciążenia (162~FPS).
@ -53,28 +54,28 @@ Potoki graficzne utworzone & 3 & $\sim$2\,400 \\
\end{table}
Praktyczna implementacja gry bullet hell potwierdziła przewagę Unity \\ dla~tego typu projektów:
Praktyczna implementacja gry bullet hell potwierdziła przewagę Unity dla~tego typu projektów:
\begin{itemize}
\item \textbf{Czas implementacji}: Unity wymagał około 60\% czasu potrzebnego na~implementację w~Unreal Engine
\item \textbf{Wsparcie 2D}: Unity oferuje natywne komponenty 2D \\ (\texttt{Rigidbody2D}, \texttt{Collider2D}), podczas gdy Unreal symuluje 2D w~środowisku 3D
\item \textbf{Object pooling}: Implementacja w~Unity jest prostsza \\
(pojedyncza metoda \texttt{SetActive}) vs Unreal (trzy osobne metody: \\
\item \textbf{Czas implementacji}: Unity wymagał około 60\% czasu potrzebnego na~implementację w~Unreal Engine.
\item \textbf{Wsparcie 2D}: Unity oferuje natywne komponenty 2D (\texttt{Rigidbody2D}, \texttt{Collider2D}), podczas gdy Unreal symuluje 2D w~środowisku 3D.
\item \textbf{Object pooling}: Implementacja w~Unity jest prostsza
(pojedyncza metoda \\ \texttt{SetActive}) vs Unreal (trzy osobne metody:
\texttt{SetActorHiddenInGame},
\texttt{SetActorEnableCollision},
\\ \texttt{SetActorTickEnabled})
\item \textbf{Instalacja na~Linux}: Unity -- około 30 minut, Unreal -- 2--4 godziny
\\ \texttt{SetActorEnableCollision},
\texttt{SetActorTickEnabled}).
\item \textbf{Instalacja na~Linux}: Unity -- około 30 minut, Unreal -- 2--4 godziny.
\end{itemize}
Badania jakościowe z~udziałem 8~deweloperów potwierdziły:
\begin{itemize}
\item Unity charakteryzuje się niższym progiem wejścia i~lepszą dokumentacją
\item Unreal Engine wymusza bardziej uporządkowaną strukturę projektu
\item System Blueprints ułatwia współpracę z~osobami nietechnicznymi
\item Problemy z~garbage collectorem w~Unity są znane, ale~rzadko doświadczane przy stosowaniu dobrych praktyk (object pooling)
\item Obie społeczności deweloperskie są aktywne, choć Unity ma~przewagę ilościową w~materiałach edukacyjnych
\item Unity charakteryzuje się niższym progiem wejścia i~lepszą dokumentacją.
\item Unreal Engine wymusza bardziej uporządkowaną strukturę projektu.
\item System Blueprints ułatwia współpracę z~osobami nietechnicznymi.
\item Problemy z~garbage collectorem w~Unity są znane, ale~rzadko doświadczane przy stosowaniu dobrych praktyk (object pooling).
\item Obie społeczności deweloperskie są aktywne, choć Unity ma~przewagę ilościową w~materiałach edukacyjnych.
\end{itemize}
\subsection{Rekomendacje praktyczne}
@ -83,22 +84,22 @@ Na~podstawie przeprowadzonych badań sformułowano następujące rekomendacje:
\begin{itemize}
\item Projekt dotyczy gry 2D lub mobilnej
\item Zespół składa się z~początkujących deweloperów
\item Wymagany jest szybki cykl iteracji (hot reload)
\item Projekt ma~ograniczony budżet czasowy na~naukę narzędzia
\item Preferowany jest język C\# nad C++
\item Wymagana jest dobra integracja z~Git (tekstowa serializacja scen)
\item Projekt dotyczy gry 2D lub mobilnej.
\item Zespół składa się z~początkujących deweloperów.
\item Wymagany jest szybki cykl iteracji (hot reload).
\item Projekt ma~ograniczony budżet czasowy na~naukę narzędzia.
\item Preferowany jest język C\# nad C++.
\item Wymagana jest dobra integracja z~Git (tekstowa serializacja scen).
\end{itemize}
\begin{itemize}
\item Projekt wymaga fotorealistycznej grafiki 3D
\item Zespół posiada doświadczenie w~C++
\item Projekt jest typu FPS lub AAA
\item W~zespole znajdują się osoby nietechniczne (designerzy, artyści)
\item Wymagane są zaawansowane funkcje wizualne (Nanite, Lumen)
\item Projekt wymaga dostępu do~kodu źródłowego silnika
\item Projekt wymaga fotorealistycznej grafiki 3D.
\item Zespół posiada doświadczenie w~C++.
\item Projekt jest typu FPS lub AAA.
\item W~zespole znajdują się osoby nietechniczne (designerzy, artyści).
\item Wymagane są zaawansowane funkcje wizualne (Nanite, Lumen).
\item Projekt wymaga dostępu do~kodu źródłowego silnika.
\end{itemize}
\begin{table}[H]
@ -131,19 +132,19 @@ Prototyp & Unity & Szybki cykl iteracji \\
Niniejsza praca wnosi następujące elementy do~dziedziny badań nad~silnikami gier:
\begin{enumerate}
\item \textbf{Zunifikowana metodyka pomiaru} -- wykorzystanie \\ NVIDIA Nsight Systems jako
niezależnego narzędzia profilowania \\ eliminuje różnice wynikające z~wbudowanych profilerów
silników, zapewniając porównywalność wyników
\item \textbf{Zunifikowana metodyka pomiaru} -- wykorzystanie NVIDIA Nsight Systems jako
niezależnego narzędzia profilowania eliminuje różnice wynikające z~wbudowanych profilerów
silników, zapewniając porównywalność wyników.
\item \textbf{Szczegółowa analiza wywołań API} -- dokumentacja ponad 32~milionów wywołań
Vulkan API dla~Unreal Engine i~0,5~miliona dla~Unity dostarcza wglądu w~architekturę
renderowania obu silników
renderowania obu silników.
\item \textbf{Triangulacja metod badawczych} -- połączenie testów wydajnościowych, analizy
funkcjonalności, doświadczeń implementacyjnych i~wywiadów jakościowych daje kompleksowy
obraz porównawczy
obraz porównawczy.
\item \textbf{Praktyczne przypadki użycia} -- konkretne rekomendacje oparte na~danych empirycznych mogą służyć jako przewodnik dla~deweloperów
\item \textbf{Praktyczne przypadki użycia} -- konkretne rekomendacje oparte na~danych empirycznych mogą służyć jako przewodnik dla~deweloperów.
\end{enumerate}
\subsection{Ograniczenia badań}
@ -151,16 +152,17 @@ Niniejsza praca wnosi następujące elementy do~dziedziny badań nad~silnikami g
Przeprowadzone badania posiadają następujące ograniczenia:
\begin{enumerate}
\item \textbf{Zakres gatunkowy} -- koncentracja na~grach typu bullet hell \\ nie~pokrywa
wszystkich możliwych zastosowań silników gier; \\ inne gatunki (RPG, RTS, puzzle)
mogą wykazywać odmienne charakterystyki wydajnościowe
\item \textbf{Zakres gatunkowy} -- koncentracja na~grach typu bullet hell
nie~pokrywa
wszystkich możliwych zastosowań silników gier; inne gatunki (RPG, RTS, puzzle)
mogą wykazywać odmienne charakterystyki wydajnościowe.
\item \textbf{Pojedyncza konfiguracja sprzętowa} -- testy na~wysokowydajnym sprzęcie (RTX 3090, Ryzen 9 7900X3D) nie~odzwierciedlają wydajności na~typowych konfiguracjach graczy
\item \textbf{Pojedyncza konfiguracja sprzętowa} -- testy na~wysokowydajnym sprzęcie (RTX 3090, Ryzen 9 7900X3D) nie~odzwierciedlają wydajności na~typowych konfiguracjach graczy.
\item \textbf{Próba badawcza} -- 8~wywiadów stanowi relatywnie małą próbę, choć~wystarczającą dla~badań jakościowych o~charakterze eksploracyjnym
\item \textbf{Próba badawcza} -- 8~wywiadów stanowi relatywnie małą próbę, choć~wystarczającą dla~badań jakościowych o~charakterze eksploracyjnym.
\item \textbf{Ewolucja silników} -- szybki rozwój obu silników może spowodować dezaktualizację wyników w~ciągu 12--24 miesięcy
\item \textbf{Ewolucja silników} -- szybki rozwój obu silników może spowodować dezaktualizację wyników w~ciągu 12--24 miesięcy.
\end{enumerate}
\subsection{Propozycje dalszych badań}
@ -168,48 +170,48 @@ Przeprowadzone badania posiadają następujące ograniczenia:
Na~podstawie zidentyfikowanych ograniczeń proponuje się następujące kierunki przyszłych badań:
Przeprowadzenie analogicznych testów
\\ dla~gier RPG (open world), strategii czasu rzeczywistego, gier puzzle oraz symulatorów
dla~gier RPG (open world), strategii czasu rzeczywistego, gier puzzle oraz symulatorów
pozwoliłoby na~bardziej kompleksową ocenę wydajności silników.
Porównanie wydajności na~różnych konfiguracjach \\ sprzętowych
(PC low-end, mid-range, high-end; urządzenia mobilne; konsole) dostarczyłoby
Porównanie wydajności na~różnych konfiguracjach sprzętowych
(PC low-end, \\ mid-range, high-end; urządzenia mobilne; konsole) dostarczyłoby
praktycznych informacji dla~deweloperów celujących w~różne platformy.
Badanie Total Cost of Ownership (TCO) uwzględniające \\ czas nauki zespołu,
Badanie Total Cost of Ownership (TCO) uwzględniające czas nauki zespołu,
koszty licencji, assetów, czas rozwoju i~koszty utrzymania projektu mogłoby
dostarczyć cennych informacji biznesowych.
Śledzenie wydajności obu silników przez~2--3 lata, dokumentując wpływ kolejnych aktualizacji, pozwoliłoby na~ocenę długoterminowej stabilności i~kierunków rozwoju.
Stworzenie frameworka \\ do~automatycznego uruchamiania i~profilowania scenariuszy testowych
Stworzenie frameworka do~automatycznego uruchamiania i~profilowania scenariuszy testowych
umożliwiłoby powtarzalne badania na~większą skalę.
\subsection{Refleksje końcowe}
Przeprowadzone badania potwierdzają, że~nie~istnieje jednoznaczna odpowiedź \\na~pytanie ,,
Przeprowadzone badania potwierdzają, że~nie~istnieje jednoznaczna odpowiedź na~pytanie ,,
który silnik jest lepszy''. Unity i~Unreal Engine reprezentują różne filozofie projektowe
i~są zoptymalizowane pod~odmienne przypadki użycia.
\textbf{Unity} wyróżnia się jako silnik oferujący:
\begin{itemize}
\item Niższy próg wejścia i~szybszą krzywą uczenia
\item Lepsze natywne wsparcie dla~grafiki 2D
\item Prostszy i~bardziej przewidywalny potok renderowania
\item Efektywniejszą pracę na~platformach mobilnych
\item Większą społeczność i~więcej materiałów edukacyjnych
\item Niższy próg wejścia i~szybszą krzywą uczenia.
\item Lepsze natywne wsparcie dla~grafiki 2D.
\item Prostszy i~bardziej przewidywalny potok renderowania.
\item Efektywniejszą pracę na~platformach mobilnych.
\item Większą społeczność i~więcej materiałów edukacyjnych.
\end{itemize}
\textbf{Unreal Engine} natomiast dominuje w~obszarach:
\begin{itemize}
\item Zaawansowanej grafiki 3D i~fotorealizmu
\item Produkcji wysokobudżetowych (AAA)
\item Współpracy z~osobami nietechnicznymi (Blueprints)
\item Dostępu do~kodu źródłowego silnika
\item Wbudowanych zaawansowanych funkcji (Nanite, Lumen)
\item Zaawansowanej grafiki 3D i~fotorealizmu.
\item Produkcji wysokobudżetowych (AAA).
\item Współpracy z~osobami nietechnicznymi (Blueprints).
\item Dostępu do~kodu źródłowego silnika.
\item Wbudowanych zaawansowanych funkcji (Nanite, Lumen).
\end{itemize}
\newpage
W~kontekście testowanej gry bullet hell hipoteza o~przewadze Unity została częściowo potwierdzona --
silnik oferuje prostszą architekturę renderowania, \\ stabilniejsze czasy klatek i~znacznie
silnik oferuje prostszą architekturę renderowania, stabilniejsze czasy klatek i~znacznie
łatwiejszy proces implementacji. Jednakże Unreal Engine wykazał zdolność do~osiągania porównywalnej
wydajności w~wymagających scenach, co~sugeruje, że~różnice wydajnościowe są mniejsze niż różnice
w~doświadczeniu deweloperskim.

85
latex/tex/implementacja-gry.tex
View File

@ -6,14 +6,14 @@ W~ramach pracy zaimplementowano identyczną grę typu bullet-hell w~obu silnikac
\subsection{Implementacja w Unity}
\label{subsec:impl-unity}
Projekt Unity został utworzony w~wersji LTS z~wykorzystaniem \\ standardowego renderera 2D. Instalacja
Projekt Unity został utworzony w~wersji LTS z~wykorzystaniem standardowego renderera 2D. Instalacja
silnika na systemie Linux przebiegła bezproblemowo dzięki Unity Hub
\cite{unity_hub} \cite{unity_hub_download_arch}, który zapewnia spójne
zarządzanie wersjami edytora i~projektami.
\begin{figure}[H]
\centering
\includegraphics[width=0.9\textwidth]{tex/img/unity_hub_default_screen.png}
\includegraphics[width=0.8\textwidth]{tex/img/unity_hub_default_screen.png}
\caption{Ekran powitalny Unity Hub.}
\label{fig:unity_hub_welcome}
\end{figure}
@ -34,8 +34,8 @@ zarządzanie wersjami edytora i~projektami.
Implementacja Unity wykorzystuje kilka kluczowych wzorców projektowych:
Klasa \texttt{GameBootstrap} wykorzystuje atrybut \\ \texttt{[Runtime\-Initialize\-OnLoad\-Method]}
do zapewnienia, że obiekt \\ \texttt{GameInitializer} istnieje w~scenie przed rozpoczęciem gry.
Klasa \texttt{GameBootstrap} wykorzystuje atrybut \texttt{[Runtime\-Initialize\-OnLoad\-Method]}
do zapewnienia, że obiekt \texttt{GameInitializer} istnieje w~scenie przed rozpoczęciem gry.
Jest to eleganckie rozwiązanie problemu inicjalizacji singletonów w~Unity.
System \texttt{BulletPool} stanowi rdzeń optymalizacji wydajnościowej. Zamiast ciągłego tworzenia i niszczenia obiektów pocisków (co generowałoby znaczące obciążenie garbage collectora), pociski są recyklingowane z puli:
@ -57,7 +57,8 @@ public Bullet Spawn(Vector2 position, Vector2 direction,
Pula jest wstępnie rozgrzewana (\textit{warm capacity}) podczas inicjalizacji, co eliminuje alokacje podczas rozgrywki.
Klasy \texttt{GameDirector} i~\texttt{EnemySpawner} wykorzystują \\ wzorzec Singleton z~właściwością \texttt{Instance}, zapewniając \\ globalny punkt dostępu do kluczowych systemów gry.
Klasy \texttt{GameDirector} i~\texttt{EnemySpawner} wykorzystują wzorzec Singleton z~właściwością \texttt{Instance},
zapewniając globalny punkt dostępu do kluczowych systemów gry.
\texttt{EnemySpawner} implementuje system eskalującej trudności poprzez interpolację czasu między spawnami:
@ -73,20 +74,20 @@ Przeciwnicy są definiowani przez strukturę \texttt{EnemyBlueprint}, która zaw
Podczas implementacji napotkano następujące wyzwania:
\begin{enumerate}
\item \textbf{Garbage Collection} -- początkowa implementacja bez \\ object poolingu powodowała zauważalne spadki klatek przy dużej liczbie pocisków
\item \textbf{Kolejność inicjalizacji} -- konieczność użycia wzorca Bootstrap wynikała z~nieprzewidywalnej kolejności wywoływania metod \texttt{Awake()} i~\texttt{Start()}
\item \textbf{Serializacja} -- atrybuty \texttt{[SerializeField]} wymagały \\ starannego rozplanowania, które pola powinny być edytowalne w~inspektorze
\item Interfejs użytkownika nie jest odświeżany po otwarciu menu \cite{linux_editor_does_not_redraw} -- wymagało to ręcznego wymuszenia odświeżenia inspektora
\item \textbf{Garbage Collection} -- początkowa implementacja bez object poolingu powodowała zauważalne spadki klatek przy dużej liczbie pocisków.
\item \textbf{Kolejność inicjalizacji} -- konieczność użycia wzorca Bootstrap wynikała z~nieprzewidywalnej kolejności wywoływania metod \texttt{Awake()} i~\texttt{Start()}.
\item \textbf{Serializacja} -- atrybuty \texttt{[SerializeField]} wymagały starannego rozplanowania, które pola powinny być edytowalne w~inspektorze.
\item Interfejs użytkownika nie jest odświeżany po otwarciu menu \cite{linux_editor_does_not_redraw} -- wymagało to ręcznego wymuszenia odświeżenia inspektora.
\end{enumerate}
\begin{itemize}
\item Natywne wsparcie dla 2D -- dedykowany tryb 2D z odpowiednimi komponentami fizyki (\texttt{Rigidbody2D}, \texttt{Collider2D})
\item Hot reload -- możliwość edycji kodu i natychmiastowego testowania zmian
\item Intuicyjny inspektor -- łatwa konfiguracja parametrów gry bez rekompilacji
\item Bogata dokumentacja C\# i społeczność
\item Skupienie się na kodzie -- większość logiki gry zaimplementowana została w kodzie źródłowym co przyśpieszyło proces tworzenia gry
\item Dobre wsparcie dla LLM -- unity posiada narzędzie mcp oferującą prostą integrację edytora i narzędzi AI \cite{unity_mcp}
\item Natywne wsparcie dla 2D -- dedykowany tryb 2D z odpowiednimi komponentami fizyki (\texttt{Rigidbody2D}, \texttt{Collider2D}).
\item Hot reload -- możliwość edycji kodu i natychmiastowego testowania zmian.
\item Intuicyjny inspektor -- łatwa konfiguracja parametrów gry bez rekompilacji.
\item Bogata dokumentacja C\# i społeczność.
\item Skupienie się na kodzie -- większość logiki gry zaimplementowana została w kodzie źródłowym co przyśpieszyło proces tworzenia gry.
\item Dobre wsparcie dla LLM -- unity posiada narzędzie mcp oferującą prostą integrację edytora i narzędzi AI \cite{unity_mcp}.
\end{itemize}
\newpage
\subsection{Implementacja w Unreal Engine}
@ -96,8 +97,8 @@ Podczas implementacji napotkano następujące wyzwania:
Instalacja Unreal Engine na systemie Linux okazała się znacznie bardziej skomplikowana niż w przypadku Unity. Dostępne są dwie ścieżki:
\begin{enumerate}
\item Uzyskanie dostępu do oficjalnego repozytorium GitHub Epic Games i samodzielna kompilacja silnika ze źródeł \cite{unreal_arch_installation_source}
\item Pobranie prekompilowanej wersji binarnej \cite{unreal_arch_installation_binary}
\item Uzyskanie dostępu do oficjalnego repozytorium GitHub Epic Games i samodzielna kompilacja silnika ze źródeł \cite{unreal_arch_installation_source}.
\item Pobranie prekompilowanej wersji binarnej \cite{unreal_arch_installation_binary}.
\end{enumerate}
\begin{figure}[H]
@ -127,9 +128,9 @@ tryb 2D z~wyspecjalizowanymi komponentami.
Ta różnica ma praktyczne konsekwencje:
\begin{itemize}
\item W Unreal konieczne jest ręczne konfigurowanie kamery ortograficznej
\item Fizyka 2D w~Unreal wykorzystuje te same komponenty co 3D, z~ograniczeniami na odpowiednich osiach
\item Sprite'y w Unreal są renderowane jako płaskie meshe w przestrzeni 3D
\item W Unreal konieczne jest ręczne konfigurowanie kamery ortograficznej.
\item Fizyka 2D w~Unreal wykorzystuje te same komponenty co 3D, z~ograniczeniami na odpowiednich osiach.
\item Sprite'y w Unreal są renderowane jako płaskie meshe w przestrzeni 3D.
\end{itemize}
@ -138,42 +139,42 @@ Unreal oferuje dwa podejścia do programowania logiki gry:
W praktyce korzystanie z nich dla osoby która zna tradycyjne programowanie okazazało się frustrujące ze względu na:
\begin{itemize}
\item Problemy z kontrolą wersji
\item Trudności w debugowaniu
\item Ograniczoną czytelność i skalowalność
\item Ograniczenie w funkcjach z którycj można korzytsać
\item Problemy z kontrolą wersji.
\item Trudności w debugowaniu.
\item Ograniczoną czytelność i skalowalność.
\item Ograniczenie w funkcjach z którycj można korzytsać.
\end{itemize}
użycie go ostatecznie okazało się bardziej intujcywne i prostsze dla projektu z uwagi na doświadczenie w pisaniu programów w
tradycyjny sposób
Implementacja object poolingu w~Unreal wymaga innego podejścia \\ niż w Unity.
Implementacja object poolingu w~Unreal wymaga innego podejścia niż w Unity.
Zamiast prostego \texttt{SetActive(true/\allowbreak false)}, Unreal wykorzystuje:
\begin{itemize}
\item \texttt{SetActorHiddenInGame()} -- kontrola widoczności
\item \texttt{SetActorEnableCollision()} -- kontrola kolizji
\item \texttt{SetActorTickEnabled()} -- kontrola aktualizacji logiki
\item \texttt{SetActorHiddenInGame()} -- kontrola widoczności.
\item \texttt{SetActorEnableCollision()} -- kontrola kolizji.
\item \texttt{SetActorTickEnabled()} -- kontrola aktualizacji logiki.
\end{itemize}
Ta granularność daje większą kontrolę, ale wymaga więcej kodu do osiągnięcia tego samego efektu.
\begin{enumerate}
\item \textbf{Brak natywnego 2D} -- konieczność ``symulowania'' środowiska 2D w silniku 3D
\item \textbf{Czas kompilacji} -- kompilacja projektów C++ jest znacznie wolniejsza niż kompilacja C\# w Unity
\item \textbf{Rozmiar projektu} -- nawet prosty projekt Unreal zajmuje wielokrotnie więcej miejsca na dysku
\item \textbf{Dokumentacja} -- dla mniej popularnych zastosowań (jak gry 2D) dokumentacja jest ograniczona
\item \textbf{Blueprinty i kontrola wersji} -- pliki Blueprintów są binarne, co \\ utrudnia merge'owanie i code review
\item \textbf{Brak natywnego 2D} -- konieczność ``symulowania'' środowiska 2D w silniku 3D.
\item \textbf{Czas kompilacji} -- kompilacja projektów C++ jest znacznie wolniejsza niż kompilacja C\# w Unity.
\item \textbf{Rozmiar projektu} -- nawet prosty projekt Unreal zajmuje wielokrotnie więcej miejsca na dysku.
\item \textbf{Dokumentacja} -- dla mniej popularnych zastosowań (jak gry 2D) dokumentacja jest ograniczona.
\item \textbf{Blueprinty i kontrola wersji} -- pliki Blueprintów są binarne, co utrudnia merge'owanie i code review.
\end{enumerate}
\begin{itemize}
\item Potężny system materiałów i efektów wizualnych
\item Wbudowane zaawansowane narzędzia profilowania
\item Blueprinty umożliwiają szybkie prototypowanie przez osoby nietechniczne
\item Doskonałe wsparcie dla grafiki 3D i fotorealizmu
\item Potężny system materiałów i efektów wizualnych.
\item Wbudowane zaawansowane narzędzia profilowania.
\item Blueprinty umożliwiają szybkie prototypowanie przez osoby nietechniczne.
\item Doskonałe wsparcie dla grafiki 3D i fotorealizmu.
\end{itemize}
\subsection{Porównanie doświadczeń implementacyjnych}
@ -210,11 +211,11 @@ Rozmiar projektu & Mały & Duży \\
Doświadczenia z implementacji gry bullet-hell potwierdzają, że wybór silnika powinien być uzależniony od typu projektu:
\begin{enumerate}
\item \textbf{Dla gier 2D} -- Unity oferuje znacznie lepsze wsparcie natywne, niższy próg wejścia i szybszy cykl iteracji
\item \textbf{Dla gier 3D AAA} -- Unreal Engine dysponuje lepszymi narzędziami do tworzenia fotorealistycznej grafiki
\item \textbf{Dla prototypowania} -- Unity pozwala na szybsze testowanie koncepcji dzięki hot reloadowi i prostszej konfiguracji
\item \textbf{Dla zespołów mieszanych} -- Blueprinty Unreal mogą być \\ wartościowe dla współpracy
z designerami, choć problemy \\ z kontrolą wersji stanowią wyzwanie
\item \textbf{Dla gier 2D} -- Unity oferuje znacznie lepsze wsparcie natywne, niższy próg wejścia i szybszy cykl iteracji.
\item \textbf{Dla gier 3D AAA} -- Unreal Engine dysponuje lepszymi narzędziami do tworzenia fotorealistycznej grafiki.
\item \textbf{Dla prototypowania} -- Unity pozwala na szybsze testowanie koncepcji dzięki hot reloadowi i prostszej konfiguracji.
\item \textbf{Dla zespołów mieszanych} -- Blueprinty Unreal mogą być wartościowe dla współpracy
z designerami, choć problemy z kontrolą wersji stanowią wyzwanie.
\end{enumerate}
Implementacja gry bullet-hell w~Unity zajęła około 60\% czasu

85
latex/tex/narzedzia-profilowania.tex
View File

@ -8,15 +8,16 @@
Zarówno Unity, jak i~Unreal Engine oferują własne, wbudowane narzędzia do analizy wydajności. Każde z~nich posiada unikalne cechy dostosowane do specyfiki danego silnika.
Unity dostarcza rozbudowany profiler dostępny bezpośrednio w~edytorze \\ (Window $\rightarrow$ Analysis $\rightarrow$ Profiler)~\cite{unity_profiler}. \\ Narzędzie to oferuje:
Unity dostarcza rozbudowany profiler dostępny bezpośrednio w~edytorze
(Window $\rightarrow$ Analysis $\rightarrow$ Profiler)~\cite{unity_profiler}. Narzędzie to oferuje:
\begin{itemize}
\item \textbf{CPU Profiler} -- analiza czasu wykonania poszczególnych funkcji, z podziałem na kategorie (rendering, skrypty, fizyka, animacje)
\item \textbf{GPU Profiler} -- pomiar czasu renderowania na karcie graficznej
\item \textbf{Memory Profiler} -- szczegółowa analiza alokacji pamięci, wykrywanie wycieków
\item \textbf{Audio Profiler} -- monitorowanie obciążenia systemu dźwiękowego
\item \textbf{Physics Profiler} -- analiza wydajności silnika fizyki
\item \textbf{Frame Debugger} -- krokowa analiza procesu renderowania \\ pojedynczej klatki
\item \textbf{CPU Profiler} -- analiza czasu wykonania poszczególnych funkcji, z podziałem na kategorie (rendering, skrypty, fizyka, animacje).
\item \textbf{GPU Profiler} -- pomiar czasu renderowania na karcie graficznej.
\item \textbf{Memory Profiler} -- szczegółowa analiza alokacji pamięci, wykrywanie wycieków.
\item \textbf{Audio Profiler} -- monitorowanie obciążenia systemu dźwiękowego.
\item \textbf{Physics Profiler} -- analiza wydajności silnika fizyki.
\item \textbf{Frame Debugger} -- krokowa analiza procesu renderowania pojedynczej klatki.
\end{itemize}
Unity Profiler umożliwia również zdalne profilowanie aplikacji uruchomionej na urządzeniu
@ -34,16 +35,16 @@ Unreal Engine oferuje narzędzie Unreal Insights, które zastąpiło starszy sys
Session Frontend~\cite{unreal_insights}. Kluczowe funkcjonalności obejmują:
\begin{itemize}
\item \textbf{Timing Insights} -- precyzyjny pomiar czasu wykonania poszczególnych systemów silnika
\item \textbf{Asset Loading Insights} -- analiza czasu ładowania zasobów
\item \textbf{Memory Insights} -- monitorowanie alokacji i~dealokacji pamięci
\item \textbf{Animation Insights} -- profilowanie systemu animacji
\item \textbf{Network Insights} -- analiza ruchu sieciowego w~grach multiplayer
\item \textbf{Timing Insights} -- precyzyjny pomiar czasu wykonania poszczególnych systemów silnika.
\item \textbf{Asset Loading Insights} -- analiza czasu ładowania zasobów.
\item \textbf{Memory Insights} -- monitorowanie alokacji i~dealokacji pamięci.
\item \textbf{Animation Insights} -- profilowanie systemu animacji.
\item \textbf{Network Insights} -- analiza ruchu sieciowego w~grach multiplayer.
\end{itemize}
Dodatkowo Unreal Engine udostępnia komendy konsolowe \\
(np.~\texttt{stat fps}, \texttt{stat unit}, \texttt{stat gpu}) pozwalające na szybki \\
podgląd podstawowych metryk wydajności podczas \\ rozgrywki~\cite{unreal_docs}.
Dodatkowo Unreal Engine udostępnia komendy konsolowe
(np.~\texttt{stat fps}, \texttt{stat unit}, \texttt{stat gpu}) pozwalające na szybki
podgląd podstawowych metryk wydajności podczas rozgrywki~\cite{unreal_docs}.
\begin{figure}[H]
\centering
@ -58,10 +59,10 @@ w~kontekście porównawczych badań wydajnościowych:
\begin{enumerate}
\item \textbf{Brak standaryzacji metryk} -- każdy silnik definiuje i~mierzy parametry
w~odmienny sposób, co utrudnia bezpośrednie porównania
\item \textbf{Różna granularność danych} -- poziom szczegółowości raportów różni się \\ między silnikami
\item \textbf{Narzut profilowania} -- wbudowane profilery same generują \\ obciążenie, które może być różne dla każdego silnika
\item \textbf{Nieporównywalność formatów wyjściowych} -- dane \\ eksportowane przez różne profilery mają odmienne struktury
w~odmienny sposób, co utrudnia bezpośrednie porównania.
\item \textbf{Różna granularność danych} -- poziom szczegółowości raportów różni się między silnikami.
\item \textbf{Narzut profilowania} -- wbudowane profilery same generują obciążenie, które może być różne dla każdego silnika.
\item \textbf{Nieporównywalność formatów wyjściowych} -- dane eksportowane przez różne profilery mają odmienne struktury.
\end{enumerate}
Z~powyższych powodów zdecydowano się na zastosowanie zewnętrznego, niezależnego od silnika narzędzia profilowania.
@ -85,37 +86,37 @@ Wybór NVIDIA Nsight jako głównego narzędzia pomiarowego podyktowany
był następującymi czynnikami:
\begin{itemize}
\item \textbf{Niezależność od silnika} -- Nsight analizuje aplikację na poziomie wywołań API graficznego (DirectX, Vulkan, OpenGL), co zapewnia porównywalność wyników między Unity a~Unreal Engine
\item \textbf{Standaryzowane metryki} -- narzędzie dostarcza zunifikowany zestaw metryk sprzętowych (GPU utilization, memory bandwidth, shader throughput)
\item \textbf{Minimalny narzut} -- profilowanie na poziomie sterownika generuje mniejsze zakłócenia niż profilery działające wewnątrz silnika
\item \textbf{Dostęp do danych niskopoziomowych} -- możliwość analizy \\ poszczególnych wywołań draw call, shaderów, transferów pamięci
\item \textbf{Spójny format danych} -- wyniki z~obu silników mają identyczną strukturę, co ułatwia automatyzację analizy
\item \textbf{Niezależność od silnika} -- Nsight analizuje aplikację na poziomie wywołań API graficznego (DirectX, Vulkan, OpenGL), co zapewnia porównywalność wyników między Unity a~Unreal Engine.
\item \textbf{Standaryzowane metryki} -- narzędzie dostarcza zunifikowany zestaw metryk sprzętowych (GPU utilization, memory bandwidth, shader throughput).
\item \textbf{Minimalny narzut} -- profilowanie na poziomie sterownika generuje mniejsze zakłócenia niż profilery działające wewnątrz silnika.
\item \textbf{Dostęp do danych niskopoziomowych} -- możliwość analizy poszczególnych wywołań draw call, shaderów, transferów pamięci.
\item \textbf{Spójny format danych} -- wyniki z~obu silników mają identyczną strukturę, co ułatwia automatyzację analizy.
\end{itemize}
NVIDIA Nsight Graphics oferuje szereg funkcjonalności istotnych dla badań wydajnościowych:
Główny moduł analizy wydajności, umożliwiający:
\begin{itemize}
\item Przechwycenie i~analizę pojedynczej klatki (frame capture)
\item Hierarchiczny widok wszystkich wywołań GPU
\item Pomiar czasu wykonania każdego etapu renderowania
\item Identyfikację wąskich gardeł (bottlenecks)
\item Analizę wykorzystania jednostek obliczeniowych GPU
\item Przechwycenie i~analizę pojedynczej klatki (frame capture).
\item Hierarchiczny widok wszystkich wywołań GPU.
\item Pomiar czasu wykonania każdego etapu renderowania.
\item Identyfikację wąskich gardeł (bottlenecks).
\item Analizę wykorzystania jednostek obliczeniowych GPU.
\end{itemize}
Moduł do długoterminowej analizy wydajności:
\begin{itemize}
\item Rejestrowanie metryk przez określony czas (nie tylko pojedyncza klatka)
\item Wykrywanie spadków wydajności i~ich przyczyn
\item Analiza zmienności czasów klatek (frame time variance)
\item Korelacja obciążenia GPU z~wydarzeniami w~grze
\item Rejestrowanie metryk przez określony czas (nie tylko pojedyncza klatka).
\item Wykrywanie spadków wydajności i~ich przyczyn.
\item Analiza zmienności czasów klatek (frame time variance).
\item Korelacja obciążenia GPU z~wydarzeniami w~grze.
\end{itemize}
Narzędzie do optymalizacji shaderów:
\begin{itemize}
\item Analiza wydajności poszczególnych shaderów
\item Identyfikacja nieefektywnych instrukcji
\item Pomiar occupancy (wykorzystania jednostek obliczeniowych)
\item Analiza wydajności poszczególnych shaderów.
\item Identyfikacja nieefektywnych instrukcji.
\item Pomiar occupancy (wykorzystania jednostek obliczeniowych).
\end{itemize}
\subsection{Przetwarzanie danych z~Nsight}
@ -126,9 +127,9 @@ Dane zebrane przez NVIDIA Nsight wymagają odpowiedniego przetworzenia w~celu uz
Nsight umożliwia eksport danych w~kilku formatach:
\begin{itemize}
\item \textbf{CSV} -- tabularyczne dane liczbowe
\item \textbf{JSON} -- strukturalne dane z~pełną hierarchią wywołań
\item \textbf{HTML Report} -- graficzny raport z~wykresami
\item \textbf{CSV} -- tabularyczne dane liczbowe.
\item \textbf{JSON} -- strukturalne dane z~pełną hierarchią wywołań.
\item \textbf{HTML Report} -- graficzny raport z~wykresami.
\end{itemize}
W~niniejszej pracy wykorzystano format CSV ze względu na łatwość importu do narzędzi analizy statystycznej.
@ -167,8 +168,8 @@ Memory Bandwidth & GB/s & Przepustowość pamięci GPU \\
Zastosowanie NVIDIA Nsight jako głównego narzędzia profilowania zapewnia:
\begin{enumerate}
\item \textbf{Obiektywność} -- pomiary wykonywane na tym samym poziomie abstrakcji dla obu silników
\item \textbf{Porównywalność} -- identyczne metryki i~format danych
\item \textbf{Powtarzalność} -- standaryzowana procedura pomiarowa
\item \textbf{Obiektywność} -- pomiary wykonywane na tym samym poziomie abstrakcji dla obu silników.
\item \textbf{Porównywalność} -- identyczne metryki i~format danych.
\item \textbf{Powtarzalność} -- standaryzowana procedura pomiarowa.
\end{enumerate}

108
latex/tex/wywiady-analiza.tex
View File

@ -10,14 +10,14 @@ W ramach badań jakościowych przeprowadzono osiem pogłębionych wywiadów z de
Respondenci zostali dobrani według kryterium posiadania co najmniej rocznego doświadczenia amatorskiego lub profesjonalnego w jednym z badanych silników. Profil uczestników przedstawia się następująco:
\begin{itemize}
\item \textbf{Respondent 1}: Około 6-10 lat doświadczenia amatorskiego w Unity, semestr zajęć z Unreal Engine, 10-20 projektów w Unity
\item \textbf{Respondent 2}: 7 lat doświadczenia amatorskiego w Unity, pół roku profesjonalnego, 15-20 projektów
\item \textbf{Respondent 3}: 1,5 roku amatorskiego doświadczenia w Unity, 4 projekty zakończone
\item \textbf{Respondent 4}: 2 lata profesjonalne w Unreal, 2 miesiące w Unity (z przerwami przez kilka lat), projekty w obu silnikach
\item \textbf{Respondent 5}: 9 lat doświadczenia zawodowego (od 2012 Unity amatorsko, od 2016 profesjonalnie; od 2019 Unreal profesjonalnie), 10-30 projektów w Unity, 5-6 w Unreal
\item \textbf{Respondent 6}: Dekada doświadczenia amatorskiego w Unity, kilka projektów game jamowych
\item \textbf{Respondent 7}: 9 lat hobbystycznego doświadczenia w Unity, 2 lata profesjonalnego; 1-1,5 roku amatorskiego w Unreal
\item \textbf{Respondent 8}: 2 lata amatorsko w Unity, 1,5 roku profesjonalnie + pół roku stażu w Unreal, kilkanaście projektów w obu silnikach
\item \textbf{Respondent 1}: Około 6-10 lat doświadczenia amatorskiego w Unity, semestr zajęć z Unreal Engine, 10-20 projektów w Unity.
\item \textbf{Respondent 2}: 7 lat doświadczenia amatorskiego w Unity, pół roku profesjonalnego, 15-20 projektów.
\item \textbf{Respondent 3}: 1,5 roku amatorskiego doświadczenia w Unity, 4 projekty zakończone.
\item \textbf{Respondent 4}: 2 lata profesjonalne w Unreal, 2 miesiące w Unity (z przerwami przez kilka lat), projekty w obu silnikach.
\item \textbf{Respondent 5}: 9 lat doświadczenia zawodowego (od 2012 Unity amatorsko, od 2016 profesjonalnie; od 2019 Unreal profesjonalnie), 10-30 projektów w Unity, 5-6 w Unreal.
\item \textbf{Respondent 6}: Dekada doświadczenia amatorskiego w Unity, kilka projektów game jamowych.
\item \textbf{Respondent 7}: 9 lat hobbystycznego doświadczenia w Unity, 2 lata profesjonalnego; 1-1,5 roku amatorskiego w Unreal.
\item \textbf{Respondent 8}: 2 lata amatorsko w Unity, 1,5 roku profesjonalnie + pół roku stażu w Unreal, kilkanaście projektów w obu silnikach.
\end{itemize}
@ -46,7 +46,7 @@ Wybór Unreal Engine często był podyktowany specyfiką projektu lub wymaganiam
W zakresie dokumentacji oficjalnej respondenci wyraźnie faworyzowali Unity. Dokumentacja tego silnika była opisywana jako dogłębna i szczegółowa -- praktycznie wszystkie klasy, metody i właściwości są dokładnie opisane, a dodatkowo często zawierają działające przykłady kodu, które można bezpośrednio skopiować i uruchomić w projekcie.
Dokumentacja Unreal Engine była oceniana znacznie gorzej. Respondenci
\\ określali ją jako szkieletową lub wręcz nieistniejącą w~praktycznym
określali ją jako szkieletową lub wręcz nieistniejącą w~praktycznym
sensie. Wiele stron dokumentacji zawiera jedynie nazwę funkcji i~nazwy
parametrów, bez jakiegokolwiek opisu działania. Jeden z~respondentów
porównał czytanie dokumentacji Unreal do przeglądania plików
@ -60,9 +60,9 @@ W przypadku materiałów nieoficjalnych (YouTube, blogi, fora) Unity również d
Poradniki do Unreal Engine były oceniane jako:
\begin{itemize}
\item Mniej liczne niż dla Unity
\item Często nieaktualne -- dotyczące starszych wersji silnika (np. Unreal 4), które mogą, ale nie muszą działać w nowszych wersjach
\item Zbyt skoncentrowane na systemie Blueprints kosztem programowania w C++
\item Mniej liczne niż dla Unity.
\item Często nieaktualne -- dotyczące starszych wersji silnika (np. Unreal 4), które mogą, ale nie muszą działać w nowszych wersjach.
\item Zbyt skoncentrowane na systemie Blueprints kosztem programowania w C++.
\end{itemize}
@ -79,7 +79,7 @@ Architektura Unity oparta na komponentach była oceniana pozytywnie pod względe
Jednocześnie wskazywano na problemy wynikające z długu technologicznego Unity. Silnik jest bardzo monolityczny, z głęboką hierarchią dziedziczenia podstawowych konceptów. Niektóre obiekty bazowe zajmują tak dużo pamięci, że nie mieszczą się w pojedynczej linii cache procesora, co na współczesny hardware stanowi istotny problem wydajnościowy.
Architektura Unreal Engine wymusza bardziej uporządkowany \\ styl pracy. Respondenci zauważali,
Architektura Unreal Engine wymusza bardziej uporządkowany styl pracy. Respondenci zauważali,
że nawet podstawowe projekty tworzone w Unreal mają tendencję do bycia lepiej zorganizowanymi,
ponieważ silnik narzuca określoną strukturę.
@ -94,14 +94,14 @@ Respondenci zauważyli, że Unreal Engine jest wyraźnie zoptymalizowany pod gry
Czas kompilacji w Unity był identyfikowany jako znaczący problem przy większych projektach. W miarę rozrastania się bazy kodu, czas potrzebny na rekompilację po każdej zmianie rośnie.
Unity oferuje mechanizm Assembly Definitions jako rozwiązanie tego \\
Unity oferuje mechanizm Assembly Definitions jako rozwiązanie tego
problemu. Bez podziału projektu na osobne assemblies każda zmiana w~kodzie powoduje rekompilację całego projektu. Podział na mniejsze moduły pozwala kompilować tylko zmienione fragmenty, znacząco skracając czas iteracji.
Istotną różnicą między silnikami jest obsługa błędów krytycznych. W Unity gra uruchomiona w edytorze działa jako osobny proces -- gdy wystąpi błąd krytyczny, zamyka się tylko ten proces, a edytor pozostaje stabilny. W Unreal Engine silnik i gra działają jako jeden proces, więc crash w grze powoduje utratę całego edytora wraz z ewentualnymi niezapisanymi zmianami.
Ta różnica architekturalna ma istotne konsekwencje dla produktywności, \\
szczególnie przy debugowaniu. Przy dużych projektach, gdzie uruchomienie \\
Ta różnica architekturalna ma istotne konsekwencje dla produktywności,
szczególnie przy debugowaniu. Przy dużych projektach, gdzie uruchomienie
silnika może trwać kilkanaście minut, każdy crash oznacza znaczną stratę czasu.
@ -113,8 +113,8 @@ Unreal Engine był krytykowany za problemy z kompatybilnością między wersjami
Współpraca z systemem Git była oceniana lepiej dla Unity ze względu na tekstową serializację assetów. Pliki scen i prefabów w Unity są zapisywane w formacie YAML, co teoretycznie umożliwia ich mergowanie. Nowoczesne narzędzia (np. merge w Rider) potrafią automatycznie rozwiązywać niektóre konflikty na scenach.
Pliki binarne w Unreal Engine stanowią znaczące wyzwanie. Respondenci \\
zwracali uwagę, że nawet pliki Blueprintów, które ewidentnie mają serializację \\
Pliki binarne w Unreal Engine stanowią znaczące wyzwanie. Respondenci
zwracali uwagę, że nawet pliki Blueprintów, które ewidentnie mają serializację
tekstową, są zapisywane na dysku jako binaria. To znacznie utrudnia współpracę wielu programistów nad tym samym projektem.
@ -131,27 +131,27 @@ Blueprinty w Unreal Engine były postrzegane jako skuteczne narzędzie ułatwiaj
Jednocześnie integracja Blueprintów z kodem C++ nie jest idealna. Przejście między oboma systemami wymaga dodatkowej pracy, a wystawianie funkcji C++ do Blueprintów nie zawsze działa bezproblemowo.
Unity wymaga więcej pracy przy tworzeniu narzędzi dla osób \\
nietechnicznych. Respondenci wskazywali, że w~Unreal Engine osoby \\
Unity wymaga więcej pracy przy tworzeniu narzędzi dla osób
nietechnicznych. Respondenci wskazywali, że w~Unreal Engine osoby
nietechniczne mają lepsze wsparcie ,,out of the box'', podczas gdy
w~Unity \\ zazwyczaj trzeba przeprowadzać szkolenia lub tworzyć
dedykowane \\ narzędzia edytorowe, aby umożliwić artystom
w~Unity zazwyczaj trzeba przeprowadzać szkolenia lub tworzyć
dedykowane narzędzia edytorowe, aby umożliwić artystom
i~designerom samodzielną pracę.
\subsection{Asset Store i zasoby zewnętrzne}
\label{subsec:asset-store}
Asset Store Unity był oceniany jako lepiej zarządzany i bogatszy. \\
Asset Store Unity był oceniany jako lepiej zarządzany i bogatszy.
Respondenci wskazywali na silniejsze wsparcie społeczności i większe szanse na
znalezienie potrzebnych zasobów.
Interesującą obserwacją było to, że najlepsze produkty z Asset Store mają tendencję do
opuszczania platformy -- twórcy zakładają własne \\ strony internetowe po osiągnięciu określonego
opuszczania platformy -- twórcy zakładają własne strony internetowe po osiągnięciu określonego
poziomu popularności.
Unreal Marketplace przeszedł niedawno transformację w~platformę Fab, \\
co według respondentów pogorszyło doświadczenie użytkownika \\
Unreal Marketplace przeszedł niedawno transformację w~platformę Fab,
co według respondentów pogorszyło doświadczenie użytkownika
i~zwiększyło liczbę kroków potrzebnych do pobrania darmowych zasobów.
@ -162,7 +162,7 @@ Assety były rekomendowane głównie do prototypowania, nie do produkcji komercy
Większość respondentów miała ograniczone doświadczenia
\\ z~wykorzystaniem AI w~pracy z~silnikami gier. Główna obserwacja
z~wykorzystaniem AI \\ w~pracy z~silnikami gier. Główna obserwacja
dotyczyła niskiej jakości generowanego kodu -- naprawianie błędów
w~kodzie wygenerowanym przez ChatGPT często zajmowało więcej czasu
niż napisanie rozwiązania od podstaw.
@ -178,7 +178,7 @@ Pozytywne doświadczenia zgłoszono w zakresie generowania placeholderów grafic
\label{subsec:optymalizacja}
Respondenci wskazywali, że Unity ma mniejszy narzut wydajnościowy niż \\
Respondenci wskazywali, że Unity ma mniejszy narzut wydajnościowy niż
Unreal dla prostych projektów. Czas ładowania projektów w~Unity jest znacznie krótszy, co respondenci przypisywali domyślnie niższym rozdzielczościom tekstur i~prostszym ustawieniom graficznym.
@ -191,8 +191,8 @@ Problem garbage collectora w Unity był wielokrotnie wspominany jako znany probl
\label{subsec:przyszlosc}
Nowy system DOTS/ECS w Unity był oczekiwaną funkcjonalnością, \\ która w momencie przeprowadzania
wywiadów została już oficjalnie wydana. \\ System ten pozwala na pisanie wysoce wydajnego,
Nowy system DOTS/ECS w Unity był oczekiwaną funkcjonalnością, która w momencie przeprowadzania
wywiadów została już oficjalnie wydana. System ten pozwala na pisanie wysoce wydajnego,
zorientowanego na dane kodu, kosztem większej złożoności programistycznej.
@ -201,13 +201,13 @@ Nowy system UI w Unity (UI Toolkit) był wskazywany jako obszar wymagający popr
Część respondentów wyraziła zainteresowanie silnikiem Godot jako alternatywą dla Unity i Unreal. Główne przyczyny to:
\begin{itemize}
\item Model licencyjny royalty-free (brak opłat od przychodów)
\item Otwarte źródła umożliwiające modyfikację silnika
\item Mniejsza złożoność ułatwiająca naukę
\item Kontrowersje związane z próbą zmiany modelu licencyjnego Unity w 2023 roku
\item Model licencyjny royalty-free (brak opłat od przychodów).
\item Otwarte źródła umożliwiające modyfikację silnika.
\item Mniejsza złożoność ułatwiająca naukę.
\item Kontrowersje związane z próbą zmiany modelu licencyjnego Unity w 2023 roku.
\end{itemize}
Respondenci przewidywali, że jeśli Unity nie poprawi swojego wizerunku \\
Respondenci przewidywali, że jeśli Unity nie poprawi swojego wizerunku
i~oferty, Godot może w~przyszłości stać się poważną konkurencją w~segmencie gier indie.
\newpage
\subsection{Podsumowanie wyników badań jakościowych}
@ -216,28 +216,28 @@ i~oferty, Godot może w~przyszłości stać się poważną konkurencją w~segmen
Na podstawie przeprowadzonych wywiadów można sformułować następujące wnioski:
\begin{itemize}
\item Wysoka jakość oficjalnej dokumentacji
\item Bogaty ekosystem materiałów edukacyjnych
\item Niższy próg wejścia dla początkujących
\item Lepsza integracja z systemami kontroli wersji (tekstowa serializacja)
\item Przystępny język programowania (C\#)
\item Elastyczna architektura komponentowa
\item Mniejszy narzut wydajnościowy dla prostych projektów
\item Wysoka jakość oficjalnej dokumentacji.
\item Bogaty ekosystem materiałów edukacyjnych.
\item Niższy próg wejścia dla początkujących.
\item Lepsza integracja z systemami kontroli wersji (tekstowa serializacja).
\item Przystępny język programowania (C\#).
\item Elastyczna architektura komponentowa.
\item Mniejszy narzut wydajnościowy dla prostych projektów.
\end{itemize}
\begin{itemize}
\item Wymuszona struktura projektu promująca dobre praktyki
\item System Blueprints ułatwiający współpracę z osobami \\ nietechnicznymi
\item Więcej gotowych funkcjonalności ,,out of the box''
\item Lepsze wsparcie dla projektów wysokobudżetowych (grafika, multiplayer)
\item Dostęp do kodu źródłowego silnika
\item Lepsza integracja z zewnętrznymi narzędziami graficznymi (np. Blender)
\item Wymuszona struktura projektu promująca dobre praktyki.
\item System Blueprints ułatwiający współpracę z osobami nietechnicznymi.
\item Więcej gotowych funkcjonalności ,,out of the box''.
\item Lepsze wsparcie dla projektów wysokobudżetowych (grafika, multiplayer).
\item Dostęp do kodu źródłowego silnika.
\item Lepsza integracja z zewnętrznymi narzędziami graficznymi (np. Blender).
\end{itemize}
\begin{itemize}
\item Trudności z mergowaniem assetów graficznych w systemach kontroli wersji
\item Poradniki koncentrujące się na implementacji kosztem dobrych praktyk
\item Problemy z kompatybilnością między wersjami silników
\item Trudności z mergowaniem assetów graficznych w systemach kontroli wersji.
\item Poradniki koncentrujące się na implementacji kosztem dobrych praktyk.
\item Problemy z kompatybilnością między wersjami silników.
\end{itemize}
Na podstawie wywiadów można zasugerować następujące kryteria wyboru silnika:
@ -263,6 +263,6 @@ Wymagania graficzne & Standardowe & Wysokie \\
\end{tabular}
\end{table}
Wyniki badań jakościowych uzupełniają obiektywne testy wydajnościowe \\
przedstawione w~rozdziale \ref{sec:testy-wydajnosci}, dostarczając \\
kontekstu praktycznego użytkowania obu silników w~rzeczywistych \\ projektach.
Wyniki badań jakościowych uzupełniają obiektywne testy wydajnościowe
przedstawione w~rozdziale \ref{sec:testy-wydajnosci}, dostarczając
kontekstu praktycznego użytkowania obu silników w~rzeczywistych projektach.

108
scripts/fix_item_dots.py Normal file
View File

@ -0,0 +1,108 @@
#!/usr/bin/env python3
"""Add missing periods at the end of \\item entries in LaTeX files."""
import re
import os
def process_file(filepath):
with open(filepath, 'r') as f:
lines = f.readlines()
modified = False
in_lstlisting = False
for i in range(len(lines)):
line = lines[i]
# Track lstlisting/verbatim environments
if re.search(r'\\begin\{(lstlisting|verbatim)\}', line):
in_lstlisting = True
if re.search(r'\\end\{(lstlisting|verbatim)\}', line):
in_lstlisting = False
continue
if in_lstlisting:
continue
# Check if this line is a boundary (start of next item or end of list)
is_boundary = (
bool(re.match(r'\s*\\item\b', line)) or
bool(re.match(r'\s*\\end\{(itemize|enumerate|description)\}', line.strip()))
)
if not is_boundary:
continue
# Find the previous non-empty line
j = i - 1
while j >= 0 and lines[j].strip() == '':
j -= 1
if j < 0:
continue
prev_stripped = lines[j].strip()
if not prev_stripped:
continue
# Skip structural/non-content lines
skip_patterns = [
r'^\\begin\{',
r'^\\end\{',
r'^\\hline',
r'^\\label',
r'^%',
r'^\\centering',
r'^\\caption',
r'^\\\\$', # bare line break
r'^\\clearpage',
r'^\\newpage',
r'^\\raggedbottom',
r'^\\small$',
r'^\\footnotesize$',
r'^\\endgroup',
r'^\\begingroup',
]
if any(re.match(p, prev_stripped) for p in skip_patterns):
continue
last_char = prev_stripped[-1]
if last_char not in '.?!':
lines[j] = lines[j].rstrip() + '.\n'
modified = True
display = prev_stripped[-70:] if len(prev_stripped) > 70 else prev_stripped
print(f" L{j+1}: {display} -> +dot")
if modified:
with open(filepath, 'w') as f:
f.writelines(lines)
return True
return False
tex_dir = '/home/kuhy/praca_magisterska/latex/tex'
files = [
'1-wstep.tex',
'2-przeglad-literatury.tex',
'3-silniki-gier.tex',
'4-metodologia.tex',
'5-testy-wydajnosci.tex',
'6-analiza-mozliwosci.tex',
'7-porownanie-wynikow.tex',
'8-podsumowanie.tex',
'narzedzia-profilowania.tex',
'implementacja-gry.tex',
'wywiady-analiza.tex',
]
changes = 0
for f in files:
path = os.path.join(tex_dir, f)
print(f"\n=== {f} ===")
if process_file(path):
changes += 1
else:
print(" No changes needed")
print(f"\n\nModified {changes} files")