Ostatnimi czasy wszyscy widzimy pewną prawidłowość w grach - w ustawieniach graficznych mamy możliwość wyboru renderera. Jednak czym tak właściwie jest owy renderer?
Cóż wszystko pasuje zacząć od wytłumaczenia jak działają gry. Zaczynając więc od początku najpierw mamy nasz sprzęt. Niezależnie czy jest to konsola, komputer, telefon, czy lodówka o większej mocy obliczeniowej niż Apollo 11.
Później sprzęt komunikuje się z systemem przez sterowniki, a system to np. Windows lub któraś z popularnych dystrybucji linuxa.
No to z czystej informatyki zostałoby nam tyle, chętnych odsyłam do google i wikipedii - tam wszystko znajdziecie.
Teraz zaczyna się to co każdy chce odczytać - gra. Tutaj zaczyna się ciekawie, bo sprzęt, czyli zwłaszcza procesor graficzny dziś popularnie nazywany kartą graficzną musi jakoś wyświetlić to co w naszej grze się dzieje. Tak też gra składa się z kilku składników. Głównie są to silnik fizyczny, silnik graficzny oraz silnik dźwiękowy. Taka święta trójca gier. Oczywiście dawniej wszystko było robione w jednym toku myślenia, a o wydzielaniu pewnych funkcji nikt nie myślał.
Dziś w tym materiale skupię się zwłaszcza na silniku graficznym - inaczej nazywanym rendererem. Silnik graficzny odpowiada za wyświetlenie tego co się w naszej grze dzieje. Oczywiście nie sam renderer to robi a nasza karta graficzna.
Teraz zapewne rodzi się pytanie - Ale jak to karta graficzna? Przecież przed chwilą mówiliśmy o rendererze a teraz nagle znowu karta graficzna? - Już wyjaśniam!
Otóż renderer komunikuje się z kartą graficzną poprzez pewne zbiory funkcji (takie zbiory nazywać będziemy API). Gra zna nasze API ponieważ dobrzy ludzie, zwani producentami kart graficznych nie zapomnieli o nas i w swoich kartach graficznych dodali sprzętową obsługę tych API, chociaż i tak większość magii dzieje się w sterownikach (dlatego warto je aktualizować). Aktualnie trzy najpopularniejsze API to DirectX, OpenGL oraz Vulkan
Czym się różnią? Najbardziej to zespołem za nie odpowiedzialnym, później mamy różnice takie jak wydajność na danej konfiguracji sprzętowej czy też systemie operacyjnym, a na samym końcu mamy ich implementację w kodzie gry, co jest też dla programistów najtrudniejsze.
Zatem dochodzimy do całego sedna - trzy różne API, trzy różne podejścia. Trzy różne problemy.
Dosłownie każde API się od siebie różni, nie są ze sobą w żaden sposób zgodne.
Więc jak to jest, że nie są ze sobą zgodne, a jednak gra pozwala nam wybrać czasami nawet wszystkie trzy?
Otóż twórcy gier implementują w swoich silnikach dwa renderery, które są od siebie niezależne, jednak wykorzystują te same zasoby. W ten sposób możemy wybierać ten, który jest stabilniejszy lub szybszy na naszym sprzęcie, albo nawet wybierać jeden z nich zawsze (pomimo wad), ponieważ tak bardzo uwielbiamy ten jeden jedyny słuszny wybór.
Nie mnie oceniać co wybieracie, jednak warto zapoznać się z kilkoma informacjami o danych trybach graficznych, zwłaszcza że wielu z was wykorzystuje je błędnie.
Rozpocznę zatem od DirectX, ponieważ aktualnie jest chyba najbardziej rozpowszechniony.
W DirectX mamy kilka cech, które są jego zaletami:
Jak widać DirectX jest biblioteką najbardziej rozpowszechnioną, co nie zmienia faktu, że nadal ma swoje wady.
Dodatkowo wersja DirectX to zmora wszystkich graczy. Przez fakt, że nowsze wersje wspierają lepsze efekty oraz są wydajniejsze wielokrotnie można było natknąć się na dyskusję o jednej grze, lecz czytając wypowiedzi mieć wrażenie, że dyskusja toczy się tak na prawdę o dwóch grach.
DirectX aktualnie posiada wersję 12, która niestety działa tylko na komputerach z Windows 10 oraz z nowszymi kartami graficznymi. Wspierane do dziś są wersje 11, 10 oraz 9.
Każda nowsza wersja zawiera wiele poprawek wydajności, nowe funkcje, ale też wiele zmian, więc np. zmiana renderera z DirectX 9 na DirectX 11 jest wręcz niemożliwa bez ogromnego nakładu pracy, a nawet jeśli zostanie on zamieniony to gra w najlepszym przypadku zyska tylko kilka klatek na sekundę więcej.
Idąc dalej mamy OpenGL - bibliotekę OpenSource, która w porównaniu do DirectX nie wydaje się na pierwszy rzut oka taka zła. Jednak ona też ma wady.
Z zalet mamy:
Jak widać OpenGL w przypadku Windowsa wypada gorzej, jednak to nie wina samej biblioteki a jednak programistów, którzy swoje gry przygotowują pod platformę Windows, gdzie króluje DirectX. OpenGL także jest podzielony na wersje, co także nie pozwala nowszych gier na za starym sprzęcie uruchomić. Aktualnie jest to wersja 4.6. Jedyne co wiem o OpenGL jednak to fakt, że z racji prostszego licencjonowania oraz prostszego programowania wielu twórców decyduje się na jego wykorzystanie. Co więcej jest prosty do przerzucenia na inną platformę, więc daje to wygodę programistom.
O Vulkanie niestety sam za wiele nie wiem. Mogę tylko odpowiedzieć, że jest to nowoczesne API wydajnościowo sięgające poziomów DirectX. Jest to API stworzone przez ludzi odpowiedzialnych za OpenGL, jednak z tym poprzednim nie ma nic wspólnego.
Jedyne co wiem o Vulkan API to fakt, że faktycznie jest wydajny, a dodatkowo zachowuje wieloplatformowość, więc DirectX może niedługo zostać zdetronizowany.
Dlaczego o tym wszystkim piszę? Żeby pokazać, że to wszystko jest rendererem, jednak są to nadal trzy osobne rzeczy, a to oznacza, że gra musi to mieć zaimplementowane na trzy osobne sposoby żeby wspierać te wszystkie bilbioteki.
Aktualnie jeśli nic nie wskazuje na to, by tryb OpenGL lub Vulkan dawał przewagę wydajnościową bez kosztów stabilności w danej grze zalecałbym uruchamianie gier w trybie DirectX na Windows. Powód jest prosty - DirectX jest częścią Windowsa, więc najlepiej sobie radzi aktualnie. W przyszłości możliwe, że ulegnie to zmianie, jednak na to przyjdzie poczekać nie wiadomo ile.
(Jeśli podoba się wam taka doza wiedzy teoretycznej z działania gier dajcie znać, wtedy spróbuję rozpisać to lepiej oraz ująć inne tematy, takie jak silniki fizyczne, czy choćby licencjonowanie gier).
Cóż wszystko pasuje zacząć od wytłumaczenia jak działają gry. Zaczynając więc od początku najpierw mamy nasz sprzęt. Niezależnie czy jest to konsola, komputer, telefon, czy lodówka o większej mocy obliczeniowej niż Apollo 11.
Później sprzęt komunikuje się z systemem przez sterowniki, a system to np. Windows lub któraś z popularnych dystrybucji linuxa.
No to z czystej informatyki zostałoby nam tyle, chętnych odsyłam do google i wikipedii - tam wszystko znajdziecie.
Teraz zaczyna się to co każdy chce odczytać - gra. Tutaj zaczyna się ciekawie, bo sprzęt, czyli zwłaszcza procesor graficzny dziś popularnie nazywany kartą graficzną musi jakoś wyświetlić to co w naszej grze się dzieje. Tak też gra składa się z kilku składników. Głównie są to silnik fizyczny, silnik graficzny oraz silnik dźwiękowy. Taka święta trójca gier. Oczywiście dawniej wszystko było robione w jednym toku myślenia, a o wydzielaniu pewnych funkcji nikt nie myślał.
Dziś w tym materiale skupię się zwłaszcza na silniku graficznym - inaczej nazywanym rendererem. Silnik graficzny odpowiada za wyświetlenie tego co się w naszej grze dzieje. Oczywiście nie sam renderer to robi a nasza karta graficzna.
Teraz zapewne rodzi się pytanie - Ale jak to karta graficzna? Przecież przed chwilą mówiliśmy o rendererze a teraz nagle znowu karta graficzna? - Już wyjaśniam!
Otóż renderer komunikuje się z kartą graficzną poprzez pewne zbiory funkcji (takie zbiory nazywać będziemy API). Gra zna nasze API ponieważ dobrzy ludzie, zwani producentami kart graficznych nie zapomnieli o nas i w swoich kartach graficznych dodali sprzętową obsługę tych API, chociaż i tak większość magii dzieje się w sterownikach (dlatego warto je aktualizować). Aktualnie trzy najpopularniejsze API to DirectX, OpenGL oraz Vulkan
Czym się różnią? Najbardziej to zespołem za nie odpowiedzialnym, później mamy różnice takie jak wydajność na danej konfiguracji sprzętowej czy też systemie operacyjnym, a na samym końcu mamy ich implementację w kodzie gry, co jest też dla programistów najtrudniejsze.
Zatem dochodzimy do całego sedna - trzy różne API, trzy różne podejścia. Trzy różne problemy.
Dosłownie każde API się od siebie różni, nie są ze sobą w żaden sposób zgodne.
Więc jak to jest, że nie są ze sobą zgodne, a jednak gra pozwala nam wybrać czasami nawet wszystkie trzy?
Otóż twórcy gier implementują w swoich silnikach dwa renderery, które są od siebie niezależne, jednak wykorzystują te same zasoby. W ten sposób możemy wybierać ten, który jest stabilniejszy lub szybszy na naszym sprzęcie, albo nawet wybierać jeden z nich zawsze (pomimo wad), ponieważ tak bardzo uwielbiamy ten jeden jedyny słuszny wybór.
Nie mnie oceniać co wybieracie, jednak warto zapoznać się z kilkoma informacjami o danych trybach graficznych, zwłaszcza że wielu z was wykorzystuje je błędnie.
Rozpocznę zatem od DirectX, ponieważ aktualnie jest chyba najbardziej rozpowszechniony.
W DirectX mamy kilka cech, które są jego zaletami:
- Jest szybki na Windowsie
- Wspierany przez większość jak nie wszystkie gry
- Rozwijany przez Microsoft, więc i jakościowo mocno nie odstaje
- Problemy z licencjonowaniem
- Odwieczne problemy z wersją DirectX
- Trudny do zaprogramowania
Jak widać DirectX jest biblioteką najbardziej rozpowszechnioną, co nie zmienia faktu, że nadal ma swoje wady.
Dodatkowo wersja DirectX to zmora wszystkich graczy. Przez fakt, że nowsze wersje wspierają lepsze efekty oraz są wydajniejsze wielokrotnie można było natknąć się na dyskusję o jednej grze, lecz czytając wypowiedzi mieć wrażenie, że dyskusja toczy się tak na prawdę o dwóch grach.
DirectX aktualnie posiada wersję 12, która niestety działa tylko na komputerach z Windows 10 oraz z nowszymi kartami graficznymi. Wspierane do dziś są wersje 11, 10 oraz 9.
Każda nowsza wersja zawiera wiele poprawek wydajności, nowe funkcje, ale też wiele zmian, więc np. zmiana renderera z DirectX 9 na DirectX 11 jest wręcz niemożliwa bez ogromnego nakładu pracy, a nawet jeśli zostanie on zamieniony to gra w najlepszym przypadku zyska tylko kilka klatek na sekundę więcej.
Idąc dalej mamy OpenGL - bibliotekę OpenSource, która w porównaniu do DirectX nie wydaje się na pierwszy rzut oka taka zła. Jednak ona też ma wady.
Z zalet mamy:
- Otwartość kodu, każdy może przyczynić się do poprawienia działania OpenGL
- Możliwość prostego rozszerzenia funkcji biblioteki poprzez sterownik
- Stosunkowo prosty w licencjonowaniu
- Dotychczasowym gorszym wykorzystaniu zasobów
- Problemach z wydajnością na Windowsie
- Bardzo niskopoziomowa biblioteka wymagająca czegoś dodatkowego do działania
Jak widać OpenGL w przypadku Windowsa wypada gorzej, jednak to nie wina samej biblioteki a jednak programistów, którzy swoje gry przygotowują pod platformę Windows, gdzie króluje DirectX. OpenGL także jest podzielony na wersje, co także nie pozwala nowszych gier na za starym sprzęcie uruchomić. Aktualnie jest to wersja 4.6. Jedyne co wiem o OpenGL jednak to fakt, że z racji prostszego licencjonowania oraz prostszego programowania wielu twórców decyduje się na jego wykorzystanie. Co więcej jest prosty do przerzucenia na inną platformę, więc daje to wygodę programistom.
O Vulkanie niestety sam za wiele nie wiem. Mogę tylko odpowiedzieć, że jest to nowoczesne API wydajnościowo sięgające poziomów DirectX. Jest to API stworzone przez ludzi odpowiedzialnych za OpenGL, jednak z tym poprzednim nie ma nic wspólnego.
Jedyne co wiem o Vulkan API to fakt, że faktycznie jest wydajny, a dodatkowo zachowuje wieloplatformowość, więc DirectX może niedługo zostać zdetronizowany.
Dlaczego o tym wszystkim piszę? Żeby pokazać, że to wszystko jest rendererem, jednak są to nadal trzy osobne rzeczy, a to oznacza, że gra musi to mieć zaimplementowane na trzy osobne sposoby żeby wspierać te wszystkie bilbioteki.
Aktualnie jeśli nic nie wskazuje na to, by tryb OpenGL lub Vulkan dawał przewagę wydajnościową bez kosztów stabilności w danej grze zalecałbym uruchamianie gier w trybie DirectX na Windows. Powód jest prosty - DirectX jest częścią Windowsa, więc najlepiej sobie radzi aktualnie. W przyszłości możliwe, że ulegnie to zmianie, jednak na to przyjdzie poczekać nie wiadomo ile.
(Jeśli podoba się wam taka doza wiedzy teoretycznej z działania gier dajcie znać, wtedy spróbuję rozpisać to lepiej oraz ująć inne tematy, takie jak silniki fizyczne, czy choćby licencjonowanie gier).
![[Obrazek: 76561198052209192.png]](https://steamsignature.com/card/0/76561198052209192.png)
