dreamscometrue.xt

Od kilku dni zbierałem się z tą notką i w końcu muszę napisać słów kilka o bibliotece (w zasadzie to całym frameworku) dla platformy .NET jakim jest XNA. Na początek może trochę technikaliów (wprost z Wikipedii):

Biblioteka XNA powstała w firmie Microsoft jako następca Managed DirectX. Struktura XNA przypomina właśnie Managed DirectX czyli znajdziemy tam część odpowiedzialną za grafikę 3D, część odpowiedzialną za odtwarzanie dźwięków itd. Ponieważ XNA opiera się na platformie .NET, gry z użyciem XNA można programować za pomocą dowolnego języka opartego o .NET czyli C#, C++/NET, VB.NET, IronPython i wiele innych. Kod jest kompilowany do postaci kodu zarządzanego a dopiero przy uruchomieniu jest kompilowany do wykonywalnego. Dzięki takiemu rozwiązaniu, gra może zostać uruchomiona zarówno na komputerze PC jak i np. na konsoli Xbox 360. Kod wykonywalny jest generowany przez optymalizator wspólny dla wszystkich kompilatorów Microsoftu czyli daje kod bardzo podobny do zwykłego kodu C++ dla Win32. Różnice wynikają jedynie z użycia platformy .NET. Ponadto biblioteki zawarte w XNA, np. część graficzna (odpowiednik Direct3D 9.0c) zostały pozbawione interfejsów COM i zreorganizowane specjalnie dla kodu managed dając wydajność większą niż w ich odpowiednikach w DirectX 9.0c.

Prościej mówiąc, jes to takie “coś”, co “siedzi” pomiędzy DirectX-em, sterownikami naszej karty graficznej a naszą aplikacją (konkretniej - naszym engine’m). No dobrze - ktoś może zapytać - “po co mi to, skoro mogę skorzystać z gotowych silników, które nie są aż tak trudne do nauki i dają niebotyczne efekty graficzne łącznie z obsługą fizyki, dźwięku, kontrolerów, sieci, itp. , a nie marnować czas na naukę kolejnej abstrakcyjnej nakładki na DirectX-a. Już spieszę z odpowiedzią. Po pierwsze, XNA wykorzystuje platformę .NET - wiąże się z tym kilka zależności:

- teoretycznie można pisać w każdym z języków .NET, które będą wykorzystywać kod frameworku,

- teoretycznie kod taki może być przenośny między platformami PC (Windows z .NET, Linux z Mono),

- praktycznie, przy niewielkich modyfikacjach można stworzyć grę, którą można bez problemu uruchomić zarówno na PC jak i na Xbox360,

- należy uwzględnić wszystkie “za i przeciw” programu napisanego w języku zarządzanym, jakim może być np. C#,

Jak widzicie, zgodnie ze starym porzekadłem, “nie ma nic za darmo” - tak i w tym wypadku zostajemy obarczeni kilkoma aspektami, które będą miały negatywny wpływ na wydajność naszej aplikacji. Dokładnie - wydajność - bo to ona jest przecież najważniejsza - stanowi poważny przedmiot rozważań, jeśli nie nad XNA, to nad C# w zupełności. Nie ukrywam, że i mnie początkowo odstraszały mity o ociężałych, wręcz interpretowanych programach, które w zasadzie można szybko pisać, jednak strach je uruchamiać Nic bardziej mylnego - kod XNA jest tak zoptymalizowany, że nawet w zestawieniu go z zarządzanym środowiskiem uruchomieniowym w jakim operuje nasz C#, spadek wydajności w porównaniu do analogicznej aplikacji napisanej w C++ z użyciem DirectX jest rzędu kilku, kilkunastu procent, przy założeniu intensywnego wykorzystania “wnętrzności” naszego PC. Dla prostych gier, produkcji 2D - różnicy praktycznie nie można zaobserwować.

A jak to wygląda ze strony developerskiej? Cóż - trzeba stwierdzić oczywisty fakt - pisanie gier jeszcze nigdy nie było tak przyjemne W zasadzie wymagana jest elementarna wiedza z zakresu matematyki przestrzennej i podstaw projektowania graficznych aplikacji trójwymiarowych, i uzbrojeni w taką wiedzę możemy w bardzo krótkim czasie tworzyć pierwsze projekty. Oczywiście wykorzystujemy całą moc kart graficznych, korzystając z różnych technik świateł, cieniowania, wykorzystujemy shadery - jednak jest to bardzo intuicyjne - wiedza, którą pozyskaliśmy dzięki nauce DirectX-a nie pójdzie na marne i będziemy mogli ją wykorzystać. Wspominam tu o DirectX-ie, jednak jest to tylko częściowa prawda - jako że XNA z założenia ma być wieloplatformowy, a w Linuxie bibliotek DX nie uświadczymy, rozwiązano ten problem w inny sposób, mianowicie implementując renderer w OpenGL-u (oczywiście w ramach projektu Mono). Widzicie więc, że podejmowane są próby unifikacji co jest zjawiskiem pozytywnym, zarówno dla developerów (twórców), jak i użytkowników. Jak powiedział jeden z wykładowców na naszej grupie .NET - “w obecnych czasach nie liczą się (w znacznym stopniu) efekty, ważniejszy jest pomysł”. Stąd właśnie MS wyszedł z inicjatywą dla wszystkich koderów, dając im za darmo potężna narzędzia jakim są: Visual Express C# i XNA - można powiedzieć że kompletny pakiet do tworzenia w pełni profesjonalnych produkcji. Ważnym odnotowania jest fakt, że w internecie znajduje się mnóstwo koderów tworzących projekty w C# i XNA, którzy stanowią bardzo życzliwą społeczność i z chęcią pomagają “świeżym” twórcom w zgłębianiu tego framework’u, co jest niezmiernie potrzebne na samym starcie.

Nie pozostaje mi nic innego jak zabrać się za poznawanie XNA, wrażenia z nauki postaram się zamieszczać na blogu

P.S: W przyszłości, po dokładnym zgłębieniu XNA, możliwe że to ono stanie się bazą dla mojego engine’u

Dziś, po kolejnym spotkaniu grupy .NET, ostatecznie postanowiłem, że obok projektów wykonywanych w C++ (w tym mój przyszły engine ), jako punkt honoru stawiam sobie naukę języka C# i platformy .NET w całej swojej rozciągłości :)  Przyznam szczerze że gdy usłyszałem pierwszy raz o tym języku miałem okropnie mieszane uczucia - do tego stopnia, że rzuciłem kompilator C# w ciemny kąt moich talerzy dyskowych. Co wtedy wydawało mi się barierą nie do zaakceptowania - to oczywiście wydajność. Nie będę się tu powoływał na jakieś szczegółowe badania, ale nie trzeba mieć dużej wiedzy żeby rozpoznać różnice pomiędzy kodem wykonywanym przez wirtualną maszynę (w tym przypadku jest to cały tzw. framework, z CLI, CLR na czele) a fizyczny procesor. Tak naprawdę ta cała “wirtualizacja” to krok pośredni, stworzony po to żeby móc zaimplementować wieloplatformowość w środowisku .NET, które “teoretycznie” korzystając z CLI jako abstrakcyjnego kodu maszynowego, może z powodzeniem uruchamiać programy w różnych systemach operacyjnych. Tyle teorii - jak to się ma do rzeczywistości? Twórcy naszych Okienek stworzyli udaną implementację .NET ale oczywiście - wyjątkowo dla swojego sztandarowego systemu. Co więc mają zrobić Ci, którzy czczą Linux’owego pingwina lub inny OS skoro nasz “przenośny” .NET wcale taki przenośny być nie chce? Środowisko developerów Open-Source’owych wpadło na genialny pomysł: “Hej, stwórzmy darmową, otwartą implementację platformy .NET..” Tak narodziło się Mono, które stanowi bardzo ciekawą alternatywę i jest o niebo mniej restrykcyjne (otwarty kod) niż produkt Billa G. (na licencji Shared Source).

Miałem jednak wrócić do sprawy wydajności w C#. Jak się okazuje aplikacje w nim napisane są wyjątkowo szybkie aby mogły zasługiwać na miano “interpretowanych”. W czym więc tkwi magiczny trik? Przy uruchamianiu aplikacji, środowisko CLR kompiluje kod CIL zaszyty w naszej aplikacji do kodu natywnego danego procesora - mechanizm ten, nazywany JIT - Just-In-Time, sprawia, że nasza aplikacja po załadowaniu do pamięci zachowuje się tak, jak program pisany dla konkretnego zestawu instrukcji konkretnego procesora - a więc tak jak powinna. Ponadto, na etapie JIT mogą być dokonywane różne optymalizacje, które mogą jeszcze bardziej przyspieszyć nasz program. Niestety, wciąż jednak będziemy doświadczali spadku wydajności, gdyż razem z aplikacją, chcąc czy nie, zostaje uruchamiana część środowiska .NET odpowiedzialna za m.in: zarządzanie pamięcią, wątkami, obsługą wyjątków, odśmiecaniem pamięci, sprawami bezpieczeństwa. To jest to przysłowiowe “coś za coś” które otrzymujemy pisząc aplikację w C#. Co dostajemy w zamian? Hmm… W tym miejscu powinien pojawić się kilkustronicowy poemat traktujący o zaletach tego języka, jednak ograniczę się tylko do jednego stwierdzenia: programowanie w C# przypomina bardziej zabawę, budowanie całości (aplikacji), to tak naprawdę układanie we właściwej kolejności odpowiednich elementów tego języka (klas) i odpowiednie wiązanie ich ze sobą - niczym małe dzieci, które bawią się klockami, tak i tu, dostarcza to tak wiele frajdy a jest przy tym tak łatwe; pokuszę się nawet o stwierdzenie, iż nie trzeba być wyjątkowo innowacyjnym żeby coś stworzyć, gdyż - tu ujawnia się największa zaleta C# - lwia część naszej pracy została już wykonana Jak to możliwe? Sekret kryje się w bibliotekach (Assemblies), z których może korzystać nasz program. Zawarte są w nich dzisiątki, tysiące klas z których możemy w łatwy i intuicyjny sposób korzystać, a w którcyh może być ukryta duża część funkcjonalności naszej aplikacji.. To stanowi o potędze tego języka: za pomocą DOSŁOWNIE kilku lnijek kodu możemy połączyć się z bazą danych i wykonać na niej operacje, możemy w łatwy sposób korzystać z zasobów internetu, multimediów, współpracować z urządzeniami zewnętrznymi, tworzyć profesjonalne rozwiązania biznesowe, programy narzędziowe, gry; możemy tworzyć aplikacje okienkowe korzystając z kontrolek (podobnie jak “za czasów” Delphi ), usługi sieciowe, dynamiczne strony internetowe - słowem - możliwości tego języka są praktycznie nieograniczone.

Koniec “ery Syzyfa”? Koniec opracowywania kodu, który i tak już powstał, a skupienie się tylko i wyłącznie na logice aplikacji? Koniec problemów z zewnętrznymi bibliotekami dzięki potędze .NET Runtime? Mam nadzieję że po poznaniu możliwości tego języka w praktyce będę mógł tak powiedzieć

Po wielu miesiącach przemyśleń, opracowywania bilansu zysków i strat zdecydowałem, że z dniem dzisiejszym rozpoczynam pracę nad swoim (jak dotychczas) największym programistycznym projektem, a mianowicie silnikiem (engine’m) gry. Na samym początku musze zrobić małe zastrzeżenie dla wszystkich tych, którzy uważają że to zabawa dla dzieci i niepotrzebna strata czasu. Otóż moi mili - nie ma w tym nic z prawdy. Produkcja engine’u to tak naprawdę wyzwanie, które w praktyce wiąże się z ogromnym nakładem pracy i sprawnym wykorzystaniem umiejętności koderskich. Pisząc engine dotykamy praktycznie każdego aspektu inżynierii oprogramowania, gdyż już same założenia co do projektu wymuszają to na nas. Nie obędzie się bez tych mniej i tych bardziej zaawansowanych algorytmów, umiętności zoptymalizowania kodu, opracowania hierarchii projektu, zależności pomiędzy klasami, obiektami… Projekt, najlepiej gdyby był zmodularyzowany, tak, by łatwiej pracowało się nad poszczególnymi blokami wchodzącymi w skład engine’u a nie nad zawiłym “tworem” pokaźnych rozmiarów. Moduły muszą mieć jasną specyfikę, najlepiej gdyby były niezależne, lecz jednocześnie muszą ze sobą w 100% współgrać. Do tego dochodzi opracowanie renderera, modułów odpowiedzialnych za oblicznanie fizyki, do zarządzania sceną i jej obiektami, do obsługi muzyki i dźwięków, obsługi wejścia (klawiatura, mysz, itp…) użytkownika, zarządzania połączeniami sieciowymi, komunikacji z użytkownikiem za pomocą GUI, obsługi skryptów (mod-ów), kontrolowania sztuczną inteligencją komputerowych postaci, efektywnego zarządzania pamięcią, systemem plików i jeszcze wieloma, wieloma innym aspektami. Jak widzicie jest (będzie) to proces niesamowicie czasochłonny, jednak spoglądając na ostateczną produkcję dochodzi się do wniosków że “warto było”… Oby

Jako że projekt ten tworzy jednoosobowy zespół złożony…ze mnie prace nad nim nie będą szły w jakimś zastraszającym tempie, jednak mam nadzieję że uda mi się doprowadzić tę produkcję do końca. Na blogu postaram się publikować informacje o postępach w kodowaniu. Trzymajcie kciuki ;D