Nowy artykuł

W święta podobno się nie programuje, więc wziąłem się chwilowo za coś innego :) Postanowiłem więc zrealizować pomysł na artykuł, który przyszedł mi do głowy kilka dni temu – głównie pod wpływem kilku pytań o podobnej tematyce, jakie przewinęły się na forum Warsztatu.
Tak powstał tekst o nieco tajemniczym tytule Pętla czasu rzeczywistego, który w rzeczywistości jest prostym omówieniem prawidłowego sposobu konstrukcji głównej pętli gry i uaktualniania jej stanu zależnie od czasu – tak, by gra działała tak samo niezależnie od wydajności sprzętu. Sprawy to dość proste, ale ważne i najwyraźniej zbyt często pomijane. Myślę więc, że taki artykuł ma niezerową szansę, żeby komuś się przydać :)

Życzenia

Koniec grudnia to taki czas w roku, kiedy wszyscy składają sobie życzenia pomyślności i szczęścia. Nie będę gorszy :) Życzę więc wszystkim wesołych świąt i szczęśliwego nowego roku!

Warsztatowa tapeta

Na forum Warsztatu pojawił się pomysł stworzenia “firmowej” tapety serwisu i społeczności. Z dwóch propozycji forumowiczom przypadł do gustu bardziej projekt rAuma, który to wykorzystuje znany i lubiany motyw zębatki :) Do tego mamy w tle kod mitycznego i ciągle niedokończonego engine’u, jak również obowiązkową nazwę serwisu.
Oto trzy wersje kolorystyczne tej tapety w rozdzielczości 1280×800:

Kolorystykę można zresztą łatwo dopasować przy pomocy ustawień odcienia (hue) i nasycenia (saturation) każdego programu graficznego, który jest choć trochę bardziej zaawansowany od Painta :) Po inne rozmiary odsyłam zaś do oryginalnego wątku na forum.

CUDA ogłaszają

Mijający rok (jak zresztą kilka poprzednich) to czas zwiększającej się wydajności układów graficznych. Obecnie są one już nieporównywalnie szybsze niż tradycyjne procesory w komputerach. Charakteryzują się jednak o wiele mniejszą uniwersalnością (wyspecjalizowaniem we współbieżnych obliczeniach na złożonych danych), co jest oczywiście całkiem zrozumiałe – w końcu głównym zadaniem układów GPU jest, jak sama nazwa wskazuje, efektywne przetwarzanie grafiki.
Mimo tego pojawiają się coraz śmielsze pomysły, by zaprząc karty graficzne także do innych zadań. Od kiedy funkcjonalność shaderów, jakie można na nich uruchamiać, stała się stosunkowo dużo, jest to zupełnie możliwe. Zastosowania tzw. GPGPU – czyli wykonywania ogólnych (niekoniecznie graficznych) obliczeń na GPU obejmują przetwarzanie dźwięku, analizę sygnałów (np. szybką tranformatę Fouriera), sieci neuronowe czy nawet operacje na bazach danych.

Ten trend zdaje się być wspomagany przez głównych graczy na rynku. I tak nVidia na początku roku przedstawiła technologię o wdzięcznej nazwie CUDA (Compute Unified Device Architecture). W skrócie jest to zestaw narzędzi, które umożliwiają programowanie układów graficznych (jak na razie tylko kart nVidii serii 8) w języku C. Obejmuje on kompilatory, debuggery i biblioteki matematyczne, które mają na celu wspomaganie tego procesu. Wszystko to wygląda całkiem obiecująco, zwłaszcza w programowaniu gier (wydaje się np. całkiem możliwe liczenie fizyki wielu małych obiektów w sposób współbieżny na GPU), chociaż na razie jest to raczej melodia przyszłości.
Jeszcze bardziej mgliście wygląda sprawa z przyszłą wersją DirectX, oznaczoną numerem 11. Pojawiła się plotka, że pojawi się w niej nowy (czwarty już) typ shadera, czyli compute shader. Miałby on służyć właśnie do takich ogólnych obliczeń na GPU w sposób ustalony całkowicie przez programistę. Widać więc, że jeśli producenci kart chcą dotrzymywać kroku w zgodności z wiodącym graficznym API, takie CUDA jak u nVidii będą wkrótce nie cudowne, ale zupełnie zwyczajne :)

Granice

Bariery, granice, strefy rozdzielające i podobne twory potrafią często utrudniać życie i prowadzić do straty cennego czasu. Jednak w prawdziwym świecie jest możliwe, aby przynajmniej w pewnym obszarze je znieść lub uczynić niewidocznymi – tak jak to stanie się dzisiaj o północy z zachodnią i południową granicą Polski. Naturalnie jest to wielkie przedsięwzięcie logistyczne, organizacyjne i polityczne. Ale doprowadzono je do końca, nie pierwszy raz zresztą – widać więc, że to możliwe.
Podczas programowania też napotykamy na przeróżne granice. Tutaj sytuacja nie przedstawia się aż tak różowo. Nikt ich nie zniesie jakimś odgórnym traktatem i zawsze pozostanie nam ich mozolne przekraczanie…

Cóż to za bariery? Są one bardzo różnego rodzaju, mają jednak pewną wspólną cechę. Występują mianowicie tam, gdzie spotykają się takie okołoprogramistyczne twory, które nie są ze sobą do końca kompatybilne – a mimo to muszą ze sobą współpracować. Przykładów jest mnóstwo i zwykle każdy z nich wymaga osobnego rozwiązania. Oto kilka próbek:

• 
  Wzorzec Most pozwala przekraczać granicę
  między interfejsem a implementacją

  Pewne języki programowania (z C/C++ na czele) mienią się wieloplatformowymi. Teoretycznie więc granica między systemami operacyjnymi powinna być łatwo przekroczona poprzez ponowną kompilację. W praktyce pisanie programów działających na wielu systemach wymaga albo wielkiej dbałości o zgodność, albo napisania po prostu osobnych kodów dla fragmentów, które na różnych systemach implementuje się różnie.

• Programy do grafiki 3D zapisują stworzone modele w wielu różnych formatach. Niektóre odpowiadają naszym oczekiwaniom i możemy je odczytywać bezpośrednio (co aczkolwiek banalne nie jest, ale o tym kiedy indziej), ale jeśli chcemy zapisywać z modelem jakieś niestandardowe informacje albo robić to w nieprzewidziany sposób, potrzebujemy zwykle pluginu do edytora 3D. W tym przypadku wtyczka ta jest sposobem na przekroczenie granicy między wspomnianym edytorem a naszym silnikiem.
• Kiedy aplikacja zaczyna się komunikować przez sieć, owo przełamywanie barier (w tym przypadku jednej maszyny) jest od razu widoczne i, oczywiście, przysparza kłopotów :) Zależnie od tego, o jakim poziomie abstrakcji mówimy, możemy spotkać się z: taką obsługą odczytu i zapisu danych, by nie blokowało to reszty aplikacji; niedostatkami istniejących i nieco przestarzałych protokołów sieciowych (albo koniecznością tworzenia własnych) czy nawet inną kolejnością bajtów przy interpretowaniu danych liczbowych na maszynie źródłowej i docelowej.

Można by niemalże pomyśleć, że kodowanie polega przede wszystkim na godzeniu ze sobą takich niezgodnych platform, systemów, bibliotek, i tak dalej. Jednak wśród tych wszystkich granic tak naprawdę tą najważniejszą, którą powinniśmy nieustannie przekraczać, jest granica naszych własnych możliwości.

Spłaszczanie drzewa

Czasami przychodzi nam operować na strukturach drzewiastych. Drzewko, jak sama nazwa wskazuje, składa się z elementów połączonych relacjami nadrzędny-podrzędny . (OK, może nazwa tego nie wskazuje, ale wiadomo to skądinąd ;]). W językach programowania połączenia te realizujemy poprzez wskaźniki albo podobne mechanizmy, jak na przykład referencje.

Drzewa mogą być oczywiście ustalonego rzędu (jak choćby drzewa binarne) i wtedy ich przechowywanie nie nastręcza większych trudności. Nieco gorzej jest wtedy, gdy każdy węzeł może mieć dowolną liczbę węzłów podrzędnych. Wtedy często wygodnie jest przechowywać je w formie dynamicznej struktury danych: tablicy albo listy. Przynajmniej dopóty, dopóki nasze drzewo rezyduje wyłącznie w pamięci…
Może bowiem przyjść konieczność zapisania go w trwalszym miejscu. Pół biedy, jeśli docelowy format sam w sobie ma strukturę drzewiastą i umożliwia uporządkowanie danych w sposób hierarchiczny – tak jak chociażby XML. Ale nie zawsze mamy taki luksus. Weźmy na przykład wirtualny system plików (VFS), w którego archiwum chcemy zapisać (drzewiastą, rzecz jasna) strukturę katalogów – w formie binarnej. Podobnych sytuacji jest całkiem sporo, zwłaszcza gdy mamy do czynienia z relacyjnymi bazami danych.

Prawdopodobnie właśnie stamtąd wywodzi się najprostsze i chyba najczęściej stosowane rozwiązanie problemu. Polega ono na oznaczeniu każdego węzła drzewa unikalnym identyfikatorem (np. liczbą) i zapisaniu razem z węzłem (oprócz związanych z nim danych) także identyfikatora węzła nadrzędnego. W ten sposób zachowujemy wszystkie informacje o hierarchii. Metoda ta ma tę zaletę, że jest prosty i wymaga niewielkiej liczby dodatkowych danych.
Wadą mogłoby być to, iż w tej postaci nijak nie da się takiego drzewa przejść ani wyszukiwać w nim. Lecz to nie jest tak naprawdę ważne, gdyż dla potrzeb programu możemy na podstawie tej reprezentacji skonstruować normalne, “wskaźnikowe” drzewo. W tym celu wystarczy najpierw stworzyć wszystkie węzły (zapisując oba związane z nimi identyfikatory), a następnie odbudować powiązania między nimi, posługując się odwzorowaniem identyfikator -> węzeł, utworzonym podczas wczytywania. Bardzo przydaje się do tego struktura danych w rodzaju mapy (słownika).

Pośrodku podium

Ostatnio na stronie Warsztatu pojawiła się sonda (ponownie zresztą). Pierwsze pytanie było nader interesujące, bowiem dotyczyło tego, czy warsztatowicze… prowadza aktualnie blogi albo noszą się z takim zamiarem w przyszłości. Wyniki wskazywały, że piszący stanowią około jedną czwartą tego community.

Bardziej interesujący był mini-konkurs na najlepszego bloga, odbywający się poprzez mechanizm oceniania komentarzy do wspomnianej sondy. Okazało się, że strona z moimi wypocinami – mimo stosunkowo krótkiego czasu istnienia – zdołała zebrać na tyle dużo głosów, by ostatecznie uplasować się na drugim miejscu. To bardzo miłe i zaskakujące – zwłaszcza, jeśli spojrzymy, kto zajął miejsce trzecie ;)
Gratuluję też morituriusowi zwycięstwa i mam oczywiście nadzieję, że pisanie devlogów będzie zataczało coraz szersze kręgi, zwłaszcza na Warsztacie.