dreamscometrue.xt

Dziś, taki właśnie komunikat zaskoczył mnie gdy próbowałem dostać się do mojego bloga. Co gorsza, nie działała zarówno strona główna (ta, którą teraz oglądasz), jak i część panelu administracyjnego - zdawałoby się że jestem odcięty na amen. Najdziwniejsze w tym wszystkim było to, że jeszcze wczoraj wszystko było OK, więc miałem uzasadnione powody do niepokoju. Zaczałem więc analizę treści strony pod kątem odwołań do strony “chanchoi.cn”, bo mechanizmy Google wskazywały na nią jako na potencjalno źródło niebezpieczeństwa. Wyłączenie wtyczek WordPressa, wyczyszczenie nieużywanych tablic bazy danych i analiza plików na serwerze nic nie dała - wciąż pojawiało się odstraszające, czerwone okno wzbraniające mi dostępu. Wtedy poszedłem po rozum do głowy i zastanowiłem się jak przeglądarka analizuje kod strony gdy wysyłamy żądanie jej otworzenia? Oczywiście pierwsze co robi to szuka pliku “index.php” lub “index.htm(l)” w katalogu głównym na serwerze. Przeskoczyłem więc szybko na “public_html/index.php”. Co się okazało? W kodzie strony głównej, na samym końcu była dopisana jedna jedyna linijka (nie będę jej przytaczał żeby nie wykorzystywać w niecnych celach), napisana w zwykłym HTML-u, w której zakodowane w kodzie szesnastkowym było odwołanie do wspomnianej, złośliwej strony. Nie mam absolutnie pojęcia w jaki sposób ona się tam znalazła, tym bardziej że hosting, stojąc na serwerze U(L)nixowym operuje prawami dostępu i nikt “z zewnątrz” nie miał praw do takiego zapisu… No cóż, najważniejsze że strona funkcjonuje już tak jak należy

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ś byłem świadkiem dziwnego zdarzenia. Jak obowiązek religijny nakazuje (wiem, wiem - piszę “obowiązek”, jednak tak naprawdę to były moje szczere chęci ), poszedłem na niedzielną mszę. Nic w tym dziwnego by nie było, gdyby nie pewna dziewczyna, która klęczała przed wejściem do sanktuarium i najwidoczniej zbierała pieniądze na jakiś cel. Spotkała się z moją obojętnością, podobnie jak i rzeszą ludzi którzy spieszyli się, by zająć pewnie jak najlepsze miejsce. Jednak myśl o niej nie dawała mi potem spokoju, przez całą godzinę myślałem o tym jak postąpiłem - wiadomo, tu niby do kościoła a tu takie zachowanie. Przy wyjściu postanowiłem więc że naprawię swój błąd. Już zbliżałem się do naszej bohaterki, gdy z całkiem przeciwnego kierunku szła kobieta. Nie mogłem dokładnie dostrzec jak to się wszystko zaczęło, jednak w chwili gdy mijałem obie Panie, wywiązała się pomiędzy nimi kłótnia, z której zrozumiałem tyle że Bogu ducha winna kobieta została zaczepiona przez tą młodą dziewczynę, która próbowała widocznie wyłudzić od niej pieniądze. Zrobiło się dużo krzyku, złości, jak się okazało, Nasza Potrzebująca nie była Polką więc Panie jedynie się “pozdrowiły” a mój misterny plan naprawy sumienia, będąc świadkiem takich wydarzeń, spalił na panewce :/

Jak zawsze wieczorem, zbieram myśli z całego dnia i zastanawiam się, kto w tej całej historii jest najbardziej winny. Widzimy każdego dnia podobnych ludzi na ulicach, mijamy ich, wciąż gdzieś spieszymy, jednak nigdy nie zastanawiamy się co oni czują, z jakimi problemami się borykają, jaki los ich spotyka. Nie myślimy o tym, bo mamy dokąd wracać, mamy co zjeść, mamy bliskich którzy są…bliscy - cieszymy się że nas nie spotyka taki los. Gdy ktoś taki pojawi się przed nami najczęściej błądzimy gdzieś wzrokiem bądź uśmiechamy się pobłażliwie i odchodzimy. Ludzie są zgorszeni ich widokiem i zachowaniem i do tego święcie przekonani, że najczęściej ich ofiara zostanie spożytkowana w inny sposób niż zamierzony (”dałem 5 złotych temu obdartusowi żeby się wreszcie ode mnie odczepił, ale i tak wiem, że od obiadu, o który mnie prosił wybierze tani alkohol). Niestety - taki stereotyp.  A gdybyśmy tak spróbowali porozumieć się, nawiązać kontakt z człowiekiem, który najczęściej, bardziej od materialnej pomocy potrzebuje bliskości, chwili rozmowy, dostrzeżenia go pośród dziesiątek mijanych osób? Tak właśnie myślę, że obok fizycznego cierpienia (głód, choroby) o wiele bardziej dotkliwa jest ludzka obojętność. A przecież to też jest człowiek, podobnie jak my myśli i czuje, pragnie być szanowany, pragnie usłyszeć kilka ciepłych słów, dzięki którym poczuje, że świat go jednak tak do końca nie odtrącił. Czemu więc nie potrafimy wykonać tak prostego gestu jak uśmiech? Czy przez to że posiadamy więcej - znaczymy więcej? Pamiętaj że w jednej chwili i Ty możesz trafić na ulicę z pustymi rękoma… Jeśli rak, AIDS i inne straszne choroby atakują nasze ciało, to moim osobistym zdaniem - znieczulica to najgorsza choroba jaka dotyka nasze poczucie przynależności do takiego tworu jakim jest społeczeństwo - choć jesteśmy istotami myślącymi, czasem nie potrafimy być ludźmi.

5 złotych które masz w kieszeni z łatwością wydasz, jednak czy nie będziesz czuł się szczęśliwszy, wiedząc że za te 5 złotych mogłeś dać komuś zupełnie obcemu obiad, kto nie miał nic w ustach od kilku dni?

P.S: Nie będę się tłumaczył za takie refleksje; od kilku dni patrzę na świat pod trochę innym kątem (dokładnie 180 stopni) i powoli zaczynam dostrzegać rzeczy, które kiedyś wydawały mi się obce, bądź nie warte zainteresowania (bądź nie chciałem się nad nimi zatrzymywać…)

P.S.2: Muszę uciekać bo są masowo zorganizowane urodziny koleżanki na korytarzu w akademiku %-)

Dobranocnie

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