Wojciech Toman's devlog (Polish)

Strona tylko po angielsku - http://wtomandev.blogspot.com

2009-09-23T12:54:00.000+02:00

Niestety podjąłem decyzję. Zaprzestaję prowadzenia bloga w języku polskim. Wynika to z kilku rzeczy:

większość rzeczy, które opisuję jest związana pośrednio/bezpośrednio z nGENEm, a większość tych, którzy próbują z niego korzystać jest z zagranicy,
tłumaczenie postów zajmuje cenny czas (np. od ostatniego posta tutaj napisałem 2 na angielskiej wersji bloga, a dziś pewnie napiszę jeszcze 1), który wolę wykorzystać np. na poprawianie bugów,
jakakolwiek zmiana w strukturze, szablonie strony musi być wykonywana w dwóch miejscach (o czym zwykle zapominam).

Blog w angielskiej wersji dostępny jest pod adresem: http://wtomandev.blogspot.com .

Liczę, że czytelnicy mojego bloga przerzucą się na angielską wersję, zwłaszcza że dla programistów nie powinno mieć większego znaczenia czy czytają teksty napisane po polsku, czy po angielsku.

Pozdrawiam i liczę na zrozumienie :)

Kodowanie Huffmana

2009-09-20T10:41:00.005+02:00

Algorytm kodowania Huffmana to kolejna metoda, którą stosuję w nGENE Tech do kompresji plików zasobów (podobno w kodowaniu arytmetycznym, które daje lepsze wyniki łatwo nadziać się na jakiś patent). Wykorzystuję ją jako ostatni krok kompresji, zaraz po wykonaniu na danych wejściowych opisywanego ostatnio Run-Length Encoding.

Algorytm tu opisywany opiera się na częstotliwości występowania poszczególnych znaków w bloku danych.

Powiedzmy, że mamy jakiś ciąg znaków, w którym częstotliwości poszczególnych znaków przedstawiają się jak poniżej (dokładna postać ciągu jest nieistotna gdyż algorytm nie uwzględnia ich kolejności):
a: 10
b: 2
c: 21
d: 44
e: 78
f: 1

Jednocześnie nie występuje jakikolwiek inny znak.

Normalnie każdy z tych znaków byłby reprezentowany przy pomocy 1 bajtu (8 bitów). Ale łatwo zauważyć, że można by je reprezentować za pomocą binarnych kodów o różnej długości (>= 1 bit). Im częściej występuje dany znak, tym jego kod powinien być krótszy dzięki czemu wszystkie jego wystąpienia zajmą dużo mniej miejsca, co jest równoważne wyższemu stopniowi kompresji, np. znak 'e' (najczęściej występujący w przykładzie powyżej) mógłby być reprezentowany przez '1' tj. pojedynczy bit. Oznacza to, że wszystkie jego wystąpienia zajęłyby 78 bitów ~ 10 bajtów zamiast standardowych 78 bajtów!

Jak znaleźć kody dla znaków

Ale jak znaleźć kody dla każdego znaku (najlepiej, optymalne)? Tutaj do gry wchodzi algorytm Huffmana. Jeśli znamy już częstotliwości wszystkich znaków musimy zbudować specjalne drzewo binarne, które w prosty sposób pozwoli nam na ich znalezienie. Zanim przejdę do jego omawiania o to jak będzie ono wyglądało dla danych z wcześniejszego przykładu:

Mając drzewo w takiej postaci znalezienie kodów jest trywialne. Zwróćmy uwagę, że w liściach znajdują się poszczególne znaki z naszego alfabetu (są tam też podane ich częstotliwości). Jeśli chcemy znaleźć kod dla danego znaku, dla którego znamy już częstotliwość występowania, zaczynając w korzeniu z kodem "" idziemy w dół dodając do kodu '0' jeśli obieramy lewą krawędź i '1' jeśli prawą aż dotrzemy do docelowego znaku.

Dla przykładu dla znaku 'f' kod jest następujący: '00000' (uwaga! to nie jest 0!!!) ponieważ 5 razy obieramy lewą krawędź, dla 'c' - '001', dla 'd' - '01', a dla znaku 'e' - '1'. Jak widać im częściej dany znak występuje, tym krótszy ma kod (co chcieliśmy osiągnąć).

Budowanie drzewa kodów Huffmana

Budowanie drzewa kodów jest dosyć prostą sprawą. Mając listę elementów ('lista' jest tu użyta raczej w dowolny sposób. Zwykle wykorzystywaną strukturą jest bowiem kopiec), wybieramy w każdej iteracji algorytmu dwa o najmniejszych częstotliwościach występowania po czym łączymy je w drzewo w taki sposób, że stają się one liśćmi, a ich rodzic-korzeń ma częstotliwość będącą sumą ich częstotliwości występowania. W pierwszej iteracji łączymy w ten sposób znaki 'f' oraz 'b' (o częstotliwościach odpowiednio 1 i 2) i wpisujemy 3 jako częstotliwość ich rodzica.

To drzewo z powrotem wstawiamy na kopiec, przywracamy jego właściwości i wybieramy kolejne dwa elementy. Tym razem będzie to właśnie '3' i '10' (co odpowiada znakowi 'a'). Postępujemy tak dotąd aż liczba elementów kopca nie wyniesie 1. Gdy tak się stanie - znaleźliśmy drzewo kodów.

Mając to drzewo, kompresja (kodowanie) jest bardzo proste. Przechodząc przez kolejne znaki ciągu wejściowego musimy po prostu wyszukać odpowiadający im kod, i wypisać go na wyjście. Oczywiście należy pamiętać, żeby wypisywać bity, a nie całe bajty, co można zrobić np. tak jak pokazano w poniższym pseudokodzie:


unsigned char curr = 0;
usigned int currByte = 0;
usingned int bits = 0;
while(!data.eof())
{
// First get next character from the input
  curr = data.getNextCharacter();
// Look up its code in the table
  const char* code = huffmanCodes[curr];

  usingned char c = 0;
  while(code++)
  {
    c = code[i];
    currByte <<= 1;
// Write one in the least significant bit
    if(c == '1')
      currByte |= 1;
    ++bits;
// When whole byte has been filled write it to the output
    if(bits == 8)
    {
      result.write((char*)&currByte, 1);
      bits = 0;
      currByte = 0;
    }
  }
}

Oczywiście należy też zadbać o ewentualne wolne bity pod koniec, ale to już pomijam.

Dekompresja danych

Jak zdekodować dane skompresowane za pomocą tego algorytmu? Aby było to możliwe musimy na wyjście zapisać dodatkowe dane, które pozwolą nam na rekonstrukcję drzewa (nie jest możliwe znalezienie częstotliwości w oparciu o skompresowane dane :) ). Mianowicie musimy zapisać drzewo kodów. Dla każdego węzła rozpoczynając od korzenia zapisujemy takie dane:

0 - jeśli jest to wewnętrzny węzeł (1 bit),
1 + znak - jeśli jest to liść drzewa (9 bits). Znak to oczywiście znak, z którym dany kod jest powiązany, np. dla kodu '1' w naszym przypadku będzie to 'e'.

Oczywiście oznacza to pewne dodatkowe dane, ale w większości przypadków jest to niemal pomijalne. Za to dzięki temu rekonstrukcja drzewa jest trywialna, a tym samym dekodowanie znaków również. Wczytujemy dane bit po bicie i rozpoczynając w korzeniu idziemy w lewo jeśli wartość bitu wynosi 0 i w prawo jeśli 1, aż nie znajdziemy się w liściu, co oznacza, że powinniśmy wypisać znak w nim się znajdujący i znów zacząć od korzenia, bo kolejny bit należy już do innego znaku. Oczywiście kody są jednoznaczne, np. dla naszego przykładu kod:

111001101

zostanie odkodowany jako:

eeeced

Z innych rzeczy, zarejestrowałem się na Twitterze na fali jego popularności i dodałem odpowiedni widget do tej strony.

Run-Length Encoding

2009-09-15T10:09:00.003+02:00

W tym wpisie opiszę algorytm RLE (Run-Length Encoding), który jest jednym z najprostszych algorytmów do bezstratnej kompresji danych i często używany jest jako jeden z kroków w kompresji (inne mogą uwzględniać np. przekształcenie Borrowsa-Wheelera czy Move-to-Front, kodowanie arytmetyczne itd.). Istota działania algorytmu jest banalnie prosta. Przechodząc przez blok danych zlicza liczbę takich samych znaków występujących obok siebie i zapisuje ją (wraz ze znakiem, którego dotyczy) na wyjściu.

W swej najprostszej postaci dla ciągu znaków:

AAAAFFFBAAAAACCDCBBBBBBBB

Algorytm zwraca:

4A3F1B5A2C1D1C8B

Ponieważ najpierw w ciągu wejściowym występują 4 litery A, 3F, 1 B, 5 A itd. Widzimy, że algorytm faktycznie dokonuje kompresji. Ale teraz weźmy ciąg znaków:

ABABABABABABABABAB

Dla niego na wyjściu otrzymujemy:

1A1B1A1B1A1B1A1B1A1B1A1B1A1B1A1B1A1B

I po kompresji - wyjście jest dwa razy dłuższe niż ciąg wejściowy!

Trzeba trochę zmienić algorytm. Lepszym rozwiązaniem jest sprawdzanie przy przechodzeniu przez blok czy obok siebie występują dwa identyczne znaki. Jeśli tak zapisujemy oba znaki na wejściu i zliczamy liczbę takich znaków za nimi. Może być to dowolna wartość, również 0. Jednak dla poprzedniego przykładu gwarantuje to, że po wykonaniu algorytmu uzyskany ciąg będzie miał taką samą długość jak wejściowy (choć nie rozwiązuje problemu dla ciągu postaci AABBAABB..).

Natomiast dla ciągu:

AAAAFFFBAAAAACCDCBBBBBBBB

Zwraca:

AA2AFF1BAA3CCDCBB2

Nieco gorzej niż poprzednio, ale nadal jest to kompresja. Ponadto przekształcenia takie jak BWT (Burrows-Wheeler Transform) sprawiają, że dane lepiej podlegają kompresji Run-Length Encoding. Ale to przekształcenie wraz z innymi opiszę nieco później.

Ale po co w ogóle zajmuję się takimi algorytmami (dotychczas pisałem głównie o graficznych)? Cóż kończę właśnie implementację wirtualnego systemu plików (VFS) dla nGENE Tech, więc były mi one potrzebne by mieć możliwość kompresji archiwum.

EDIT:
Aha... i jeszcze jedna sprawa. Być może jest to jeden z ostatnich wpisów w języku polskim. Od pewnego czasu prowadzę też anglojęzyczną wersję bloga i niestety prowadzenie dwóch blogów jest nieco uciążliwe (2x więcej pisania :) ).

Light-shafty update

2009-09-11T18:33:00.001+02:00

Niedawno była notka o light-shaftach. Wówczas prezentowany filmik zawierał jednak denerwujący artefakt... jeśli komuś podobało się wtedy niech obejrzy teraz (powinno być DUŻO lepiej). Po komentarzu Rega, zmieniłem model testowy :)

nGENE Update

2009-09-10T20:26:00.004+02:00

Tym razem będą tylko obrazki... sporo poprawek, zachęcam do ściągania aktualnego kodu z repozytorium SVN :) Do ideału ciągle daleko, ale uwierzcie... poprawiłem tyle rzeczy w ostatnich tygodniach, że sam w to niemal nie wierzę :)

Renderowanie trawy

2009-09-06T22:37:00.003+02:00

Jak wszyscy wiemy renderowanie trawy nie jest łatwym zadaniem. Nawet zastosowanie najbardziej popularnej techniki tj. renderingu trawy jako billboardy mierzymy się z godnym przeciwnikiem - olbrzymim spadkiem wydajności jeśli chcemy trawy wyrenderować naprawdę dużo.

Są dwie rzeczy, które pomagają ten problem rozwiązać:

pierwsza jest w miarę naturalna. Batchujemy billboardy o tej samej teksturze i renderujemy razem. Często dobrym pomysłem jest zrobienie takich batchy jak rozmiar kratek terenu (bo pewnie na nim przyjdzie nam trawę umieścić). Wówczas jeśli kratka jest ukryta, to paczka źdźbeł trawy również.
nie używanie alpha blendingu. Zamiast tego stosujemy alpha testing + dissolving. Dissolving pomoże nam nadrobić niedostatki testu alfa. Polega to w uproszczeniu na tym, że wartość alfa mnożymy przez wartość pobraną z tekstury tego typu (losowe wartości, ale na tyle gładkie, żeby efekt był przyjemny dla oka):Dodatkowo jeśli stosujemy takie batche jak napisałem wcześniej warto zadbać o to, aby wartość referencyjna dla alpha testu była zmienna pomiędzy nimi w taki sposób, aby te będące dalej od kamery zanikały (inaczej uzyskamy bardzo niefajny efekt :) ).

W nGENE'ie wygląda to aktualnie tak:

Dodatkowo aby rozwiązać problem z prawidłowym oświetleniem trawy ustawiam normalną dla billboardów na normalną terenu w punkcie umieszczenia danego źdźbła. Wygląda to całkiem ok.

Nadal nienajlepiej, ale nie dysponuję teksturami trawy wyższej jakości :) Za to w powyższej scenie jest ich naprawdę sporo. Jeśli w ogóle chodzi o nGENE poprawiłem w ostatnim czasie całą masę rzeczy i usterek. Od mniejszych, po większe czy nawet dosyć poważne błędy. Od jutra kontynuuję przerwaną implementację animacji szkieletowej (przerwaną zgłoszeniami błędów):

Zdjęcia: makro, HDR, light graffiti

2009-09-02T11:45:00.006+02:00

Ostatni weekend spędziłem pod znakiem fotografii, daleko od komputera i programowania nGENE'u (ale dzięki temu teraz mam dużo energii i zapału :) i aktualnie kończę wrappować jointy z PhysXa, poprawiać GUI i różne bugi). Postanowiłem przećwiczyć kilka technik, o których dużo ostatnio czytałem, ale albo nie miałem okazji wcześniej ich przećwiczyć, albo poprzednie próby było średnio udane. Mam tu na myśli:

light graffiti,
makro fotografia,
HDR.

Miałem też zamiar znów porobić zdjęcia nocne, ale warunki były mocno niesprzyjające (duże zachmurzenie, deszcz, mało naturalnego światła).

Light graffiti

Light graffiti to ciekawa technika polegająca na tym, że w nocy (lub w bardzo ciemnym pomieszczeniu) stajemy naprzeciw obiektywu ubrani na czarno ze słabą latarką w dłoni. Czas naświetlania ustawiamy na dosyć długi (kilka sekund powinno wystarczyć), ISO na ok. 100 i jak najmniejszą przesłonę (oczywiście zależy to od warunków i mocy naszej latarki, ale chodzi o to, żeby mieć chwilę czasu na rysowanie) po czym rozpoczynamy "malowanie" światłem. A możemy narysować, napisać co tylko chcemy... Ja się np. podpisałem:

Oczywiście gdyby było jakieś tło byłoby dużo lepiej. Miały być gwiazdy, ale musiałbym dać jakiś potwornie długi czas ekspozycji przy zastanych warunkach, więc zrezygnowałem z tego pomysłu. Tutaj obraz jest w 1 płaszczyźnie, ale spokojnie można się pokusić o rysowanie w 3-wymiarach (wstęgi i inne cuda).

Jedyne o czym należy pamiętać to to, że obraz finalny będzie w lustrzanym odbiciu. Rozwiązania są dwa. Albo rysować w lustrzanym odbiciu, albo odwrócić zdjęcie w programie graficznym. Wbrew pozorom to pierwsze też jest po chwili treningu wykonalne :)

Makro fotografia

Następnego dnia zgodnie z prognozami pojawiły się opady deszczu. Ponieważ wiedziałem, że gwarantuje to ciekawe zdjęcia makro z niecierpliwością czekałem na koniec opadów. I doczekałem się. Poniżej pokaz slajdów z Picasy:

Do zrobienia zdjęć użyłem filtra, soczewki +10 dioptrii, ale teraz poważnie zastanawiam się nad zakupem odpowiedniego obiektywu, bo zabawa jest przednia. Obserwowanie makro świata jest fascynujące, aż trudno uwierzyć jak wiele szczegółów umyka naszej uwadze.

HDR

Robienie zdjęć HDR już kiedyś opisywałem. Tutaj ostatnie osiągnięcia w tej dziedzinie (również pokaz slajdów):

W skrócie zdjęcia robione z wykorzystaniem mechanizmu exposure bracketing (w przypadku mojego Canona EOS 400D oznacza to serię 3 zdjęć), czyli automatyczne zmienianie ustawień ekspozycji pomiędzy kolejnymi zdjęciami. Część zdjęć wykonana ze statywu, część z ręki. Zdjęcia nie są naturalne, ale po obejrzeniu iluś setek zdjeć HDR w internecie stwierdziłem, że mało kto się o to stara, a tak przynajmniej można osiągnąć ciekawe efekty.

Renderowanie light-shaftów

2009-08-27T20:40:00.002+02:00

Zrobiłem sobie chwilę przerwy w pracach nad animacją i usuwaniem bugów na zaprogramowanie light-shaftów. Efekt jest o tyle fajny, że jest stosunkowo prosty a jednocześnie pozwala na łatwe zbudowanie atmosfery tajemniczości czy grozy.

Technika, którą wykorzystuję to technika zaproponowana przez Jasona Mitchella w ShaderXach. Stara, prosta, ale w większości przypadków wystarczająca.

Light-shafty to po polsku promienie światła :) chodzi jednak o to, że są one widoczne gołym okiem, a to za sprawą cząsteczek w powietrzu (np. kurz), które odbijają i rozpraszają światło.

Ponieważ jest to efekt wolumetryczny, należy skorzystać do jego wyrenderowania z jednego ze sposobów renderingu tego typu efektów. Możliwości jest kilka, stosunkowo często wykorzystywana to rozbicie objętości na kilka (-naście, -dziesiąt) równoległych do siebie płaszczyzn, na które później nanoszone są różne tekstury z użyciem rzutowania. Oczywiście od liczby tych płaszczyzn zależy jakość oraz wydajność całego efektu. Płaszczyzny te, w tym przypadku renderowane są prostopadle do wektora patrzenia w taki sposób, aby wypełniały całą bryłę otaczającą stożka światła.

Najpierw tworzona jest kostka wierzchołków o wymiarach 1 x 1 x 1 (a dokładniej grupa płaszczyzn o wymiarach 1 x 1 w odległości 1 / (liczba_płaszczyzn - 1) od siebie). Następnie w vertex shaderze wierzchołki są przemieszczane w odpowiednie miejsce w następujący sposób:

float4 stretchedMaxBounds = float4(maxBounds, 0.0f);
float4 pos = float4(minBounds, 0.0f) * IN.position +
(stretchedMaxBounds * (1.0f - IN.position));

co sprawia, że wypełniają całą bryłę otaczającą stożka światła. W powyższym kodzie: minBounds i maxBounds opisują prostopadłościan otaczający stożek światła w przestrzeni widoku.

W pixel shaderze wykonywany jest cały scattering. Zanik światła to oczywiście standardowe 1 / (odległość * odległość).

Ponieważ na tym etapie light-shafty wyglądałyby nieco nienaturalnie w dalszej kolejności dodamy kilka ulepszeń:

Gobo/cookie - wzór nakładany na wszystkie płaszczyzny,
Animowany szum - sprawi, że uzyskamy efekt poruszającego się powietrza,
Cień - nałożenie shadow mapy sprawi, że light-shaft nie będzie widoczny w zacienionym miejscu.

Aha... polecam też stosować płaszczyzny przycinania, ponieważ w przeciwnym razie pixel shader będzie uruchamiany dla pikseli, które i tak powinny zostać odrzucone, bo leżą poza stożkiem światła. Najlepiej wykorzystać w tym celu płaszczyzny opisujące stożek światła.

Gobo, cookie

Jest to nic innego jak wzór nakładany na wszystkie płaszczyzny. Tam gdzie mamy kolor biały rysujemy piksele. Tam gdzie czarny - odrzucamy. W ten sposób można light-shaftowi nadać konkretny kształt i wygląd zamiast ograniczać się do zwykłego przekroju koła.

Przykładowe "ciasteczko":

Animowany szum

Animowany szum sprawi, że uzyskamy efekt poruszającego się powietrza. Wystarczy nałożyć jakąś teksturę szumu i wykorzystać zmieniające się w czasie współrzędne tekstury.

Cień

Wykorzystujemy shadow mapę wyrenderowaną dla jakiegoś światła. Następnie w pixel shaderze sprawdzamy czy dany piksel należący do płaszczyzny light-shafta jest dalej niż odpowiadający mu w shadow mapie. Jeśli jest większy tzn., że znajduje się on w cieniu, więc odrzucamy go.

A o to przykład działania z nGENE'a:

Jest jeszcze sporo niedoróbek i błędów, ale są proste do usunięcia, a chciałem jakoś zobrazować swój wywód. Na początku cookie jest włączone, od mniej więcej połowy - wyłączone.

Przyszłość nGENE

2009-07-31T09:22:00.002+02:00

W ostatnim czasie mam dużo przemyśleń na temat dalszej przyszłości nGENE'a a raczej celów jakie powinienm realizować. Poniżej wnioski z tych przemyśleń:

To czego nGENE'owi brakuje to gra na nim oparta. Ponieważ ciężko oczekiwać, że ktoś zaryzykuje jej stworzenie bez dowodu, że jest to możliwe postanowiłem sam coś takiego napisać. Nie będzie to nic skomplikowanego, ale będzie miało pewne elementy gameplayu. Dodatkową zaletą takiego podejścia będzie to, że postawię się w roli developera, więc będę miał lepszy wgląd w to co jest w nGENE'ie złe. Decyzja jakiego gatunku gra to będzie jeszcze nie zapadła. Prawdopodobnie jednak albo prosta gra wyścigowa, albo fps.
Aktualny status nGENE jest niezbyt dogodny dla programistów. Dlatego postanowiłem zmienić ten stan rzeczy. Wkrótce (prawdopodobnie za 2 tygodnie) update'y do repozytorium SVN staną się dużo częstsze, a jednocześnie zacznę korzystać w repo z branchy/tagów tak, żeby Ci którzy nie chcą ściągali tylko stabilną, przetestowaną wersję. Wkrótce pojawi się też wersja z wyższym numerkiem niż 0.1 (bo zmian od jej czasu jest tyle, że głupio taki numer utrzymywać).
Aktualnie pracuję nad systemem animacji i jest to dla mnie priorytet. Powinien być gotowy ze wszystkimi bajerami do końca września.
Zajmę się też ostatecznie problemem nie działania nGENE'a na niektórych lepszych GPU. Byłbym wdzięczny za wszystkie wskazówki, które mogłyby pomóc w rozwiązaniu tego problemu.

Pozostaje jednak jeszcze jeden problem, na który ciężko znaleźć mi dobre rozwiązanie. Chcę żeby nGENE był darmowy, wraz ze wszystkimi komponentami, shaderami, itd. Jednak powoduje to kilka komplikacji:

Muszę pracować gdzieś indziej, a przez to nie jestem w stanie na bieżąco rozwiązywać wszystkich problemów czy poświęcić tyle czasu ile należy na dalszy rozwój silnika.
Jest dużo ciężej zbudować zespół, mało kto chce się czymś takim zajmować za darmo.

Jak mówiłem wielokrotnie nie chcę nGENE sprzedawać, zresztą nie wierzę by w aktualnej wersji znalazł zbyt wielu nabywców. Rozważam jednak system dotacji. Stąd moje pytanie, czy ktoś z Was ma jakieś doświadczenie z nimi, czy w ogóle opłaca się to brać pod uwagę? Jak wygląda np. kwestia podatków (znalazłem sporne opinie na ten temat)?

Dadaj, nocne zdjęcia

2009-07-14T16:52:00.002+02:00

Ostatnio nieco mniej pracuję nad nGENEm. Wkrótce sytuacja powinna ulec zmianie i moje ambitne plany na te wakacje nie powinny czuć się zagrożone.

Ale nie o nGENE'ie będzie tym razem, lecz o robieniu nocnych zdjęć. Na ten temat pisałem już w zeszłym roku w tym wpisie. Album na picasie można zobaczyć pod tym adresem:

http://picasaweb.google.com/tomanw/DadajNightPhotos#

Przykładowe zdjęcia z niego:

Choć może w pierwszej chwili ciężko w to uwierzyć wszystkie zdjęcia były naprawdę robione w środku nocy (pomiędzy 0 a 2 AM). Zresztą na części z nich widać gwiazdy. To że kolory są tak żywe zawdzięczam dość mocnemu światłu księżyca i kilkuminutowym ekspozycjom.

Robienie zdjęć w nocy jest o tyle fajne, że rezultaty są w pewien sposób surrealistyczne, a często mniej przewidywalne. Również kolory są bardziej plastyczne.

nGENE Tech Toolset download

2009-06-13T19:29:00.001+02:00

Udało mi się skończyć prostą wersję edytora. Poniżej filmik ją prezentujący (od ostatniego ubyło głównie bugów :) ):

Download dostępny jest tutaj.

Artykuł na gd.net

2009-06-05T09:43:00.003+02:00

Wczoraj wieczorem w serwisie gamedev.net pojawiła się angielska wersja mojego artykułu dotyczącego renderingu wody w przestrzeni ekranu. Od polskiej różni się wbrew pozorom dosyć znacząco: zarówną formą jak i nie zawiera kilku wpadek, których nie udało mi się uniknąć w oryginale. A do tego są obrazki :)

Obiecywałem udostępnienie edytora na przełomie maja i czerwca. Niestety znów przekładam termin. Zaliczenia na uczelni/projekty nie pozwalają mi skończyć kilku istotnych rzeczy.

Jeśli chodzi o nurkowanie. Mój rozwój w tej dziedzinie nabiera w ostatnim czasie tempa. Po pierwszym nurkowaniu jaskiniowym, w ostatni weekend udało mi się ukończyć kursy Advanced Nitrox i Deco Procedures w TDI. Kursy zacząłem już pod koniec marca, ale że nie wszystko szło na początku ok, kurs się trochę przeciągnął. Pragnę w tym miejscu podziękować gorąco Czarkowi Abramowskiemu i Andrzejowi Górnickiemu za poprowadzenie kursu i wszystkie niezliczone symulowane sytuacje awaryjne.

Pierwsze starcie z jaskiniami

2009-05-25T11:22:00.000+02:00

Zalane jaskinie - dla jednych bajka, dla innych sama nazwa wystarczy by pozostawać od nich możliwie daleko. W miniony weekend było mi dane zobaczyć z czym to się je, a wszystko za sprawą koleżanki, która w odpowiedzi na pytanie o kurs jaskiniowy zaklepała mi miejsce na tzw. warsztaty jaskiniowe. Cóż - trudno. Jak się powiedziało A należy powiedzieć i B :)

Piątek

Ostatnie gorączkowe przygotowania, żeby sprzęt był jak najbardziej bezpieczny dla mnie i innych (kask, latarki, kołowrotki itp.). Przypomnienie sobie wszystkich podstawowych procedur. Olbrzymi stres, ale też i mobilizacja. W końcu jutro i w niedzielę zmierzę się z czymś dotychczas praktycznie mi nieznanym - z nurkowaniem w przestrzeniach zamkniętych (czyli takich, w których droga do wyjścia jest zastawiona przez sufit i trzeba znaleźć wyjście często płynąc kilkaset metrów). Odkąd zacząłem nurkować niespełna 4 lata temu o tym marzyłem, pociągało mnie to, fascynowało, ale teraz gdy stoję przed szansą, żeby spróbować odczuwam niepokój. Czy już jestem na to gotowy? W końcu robiony przeze mnie inny kurs (wstęp do nurkowań technicznych) nie wygląda póki co najlepiej...

Sobota

Po nieprzespanej nocy docieramy do Krakowa na 9.00. Przez kolejnych kilka godzin ćwiczymy na sucho (na powierzchni): rozkładanie poręczówki, podróż wzdłuż niej bez widoczności (na oczach tzw. czarna maska - gumowa opaska, dzięki której nic nie widać), wycinanie się z poręczówki (również bez widoczności). Na powierzchni jest to trudne - pod wodą będzie tylko gorzej. Dalej konfiguracja sprzętu wg szkoły francuskiej (minimalistyczna, brak butli na plecach jedynie 2 małe butle boczne). I wejście do wody spróbować tego w praktyce.

Pierwsze nurkowanie w słynnym Zakrzówku jest przy ograniczonej widoczności (max. 1 metr - wiele ludzi, w tym kursów więc woda jest mocno zmącona). Próbujemy poręczować, idzie ciężko w takich warunkach, więc zrzucamy kołowrotki na dno i idziemy popływać w innej części akwenu. Znajdujemy platformę. Pomiędzy nią a dnem jest niewielki prześwit (bo ja wiem 0.5 metra, może mniej, może ciut więcej - strach wprowadza przekłamania :) ). Mamy pod nią przepłynąć. Luzik... do czasu. Wpłynąłem, dopływam do końca i lipa - nie przecisnę się. Dobra spróbuję się wycofać. Nie da się. Gdzieś się zahaczyłem. Lekki stresik, ale to tylko platforma - uspakajam się i z pomocą instruktora wychodzę. W drugą stronę przechodzę już bez problemu. Błędem było złe ułożenie butli. Jak to wszystko szybko wychodzi.

Kolejne nurkowanie to poręczowanie + wycinanie się z poręczówki. Kamienie poręczuje mi się nad wyraz trudno (zwłaszcza gdy robi się to pierwszy raz w życiu - tzn. w ogóle poręczuje, bo wcześniej praktycznie tego nie robiłem). Wycinanie też poszło nie najlepiej. Nie przygotowałem kołowrotka i walczyłem z nim pod wodą. W końcu jakoś tam się wyciąłem, ale trwało to potwornie długo. Ogólnie dużo błędów i refleksja - jak mało umiem.

Niedziela

Dziś mamy atakować prawdziwą "jaskinię" - zalany fort w całości wykuty w skale. Samochody zatrzymują się przy zakładzie, a dalej z buta. I nie byłoby problemu, gdyby nie sprzęt, który swoje waży i teren po jakim przyszło nam iść też nie jest najprostszy - 500 metrów: najpierw ścieżka (luz), później było gorzej - przez podmokły las, pełen komarów, lekkich wzniesień, wysokich krzaków itd.

Doszliśmy jednak szczęśliwie na miejsce. Jak się okazało najtrudniejsze dopiero przed nami :) przejście (a mówiąc precyzyjnie - przeczołganie się) bardzo niskim suchym korytarzem do wody. Tu już można było stanąć wyprostowanym i nawet 2 osoby mogły się minąć (z trudem ale jednak)! Woda była krystalicznie czysta, a light-shafty z naszych latarek przypominały stare filmy (zresztą super efekt - dużo lepszy niż w jakiejkolwiek grze :) ), których akcja rozgrywała się w kopalniach. Ostatnie sprawdzenie sprzętu i jazda na dół (tj. na jakiej 1.5 - 2 metry)! Pierwsze wrażenie - woda kryształ (przynajmniej na razie). Widać wszystko co pozostaje w zasięgu latarek na naszych kaskach. Wypas. Płyniemy wzdłuż poręczówki cały czas uważając by się w nią nie zaplątać. Wpływamy do bocznego korytarza i tu zaczyna się prawdziwa jazda. W drodze powrotnej widoczność wynosi 0 cm! Co z tego, że wiem że mam wyciągniętą przed siebie rękę skoro jej nie widzę. Przykładam ją do maski - z trudem rozróżniam poszczególne palce. Kurczowo trzymam poręczówkę - wiem, że z jej pomocą trafię do domu. Raz na jakiś czas pojawiają się skrzyżowania. Na każdym z nich umieszczony jest specjalny znacznik wskazujący kierunek do wyjścia - działa to niezwykle kojąco.

I tak (z krótkimi przerwami) nurkowanie wygląda już do końca. Co pewien czas do głowy przychodzą różne niepokojące myśli, ale w końcu poznaję korytarz w którym rozpoczęliśmy nurkowanie. Dopływam do jego końca... ufff powietrze :) Potem tylko wyczołgać się korytarzem wejściowym. Podróż w stronę samochodów jest nieco łatwiejsza - naładowany adrenaliną nie czuję ciężaru sprzętu, ani upału.

Wniosek

Wiem, że nic nie wiem. Żeby tak nurkować bardzo wiele się muszę nauczyć. Może to zająć lata, a być może nigdy nie dojdę do poziomu, żeby robić to bezpiecznie. Te warsztaty pokazały pewną możliwość w nurkowaniu, ale umiejętności mogą przyjść tylko jeśli będzie się je trenować setki razy.

Proceduralny teren - zrzucanie cząsteczek

2009-05-12T15:24:00.003+02:00

Programując samemu silnik nGENE często mam problem ze znalezieniem/stworzeniem assetów do użycia w demkach czy nawet przykładach/tutorialach. Rozwiązaniem jest poniekąd podejście proceduralne, tyle że ja nie jestem jakoś strasznie w tym mocny (wychodzi brak tła scenowego :) ). Jednak implementując nGENE Tech Toolset stwierdziłem, że fajnie byłoby dać użytkownikom możliwość prostego utworzenia height-map. Chwila pisania, poprawiania i udało się z grubsza zaimplementować algorytm upuszczania cząsteczek (wg Hayesa nie Schankela).

Idea jest prosta. Na płaszczyznę zrzucamy cząsteczkę i dopóki nie znajdzie się w stabilnym położeniu przesuwamy ją w dół. Stabilność oznacza tu, że żaden z jej sąsiadów nie znajduje się niżej niż ona. Problemem jest wybór miejsc, z których cząsteczki zrzucać. Podejście Schankela (losowość całkowita :) ) kończyło się tym, że algorytm nadawał się praktycznie tylko do wizualizacji terenów wulkanicznych. Sugestie Hayesa dają więcej możliwości.

Po pierwsze standardowo przy testowaniu warunku stabilności sprawdzane były tylko najbliższe otoczenia cząsteczki (sąsiedzi). Jednak dużo lepiej jest gdy możemy też sprawdzać cząsteczki bardziej odległe, np. gdy będziemy przeszukiwać do odległości 2 jednostek, to nawet jeśli sąsiedzi są na tym samym poziomie co cząsteczka to i tak musimy jeszcze sprawdzić, czy cząsteczki odległe o 2 jednostki nie są niżej. Jeśli tak - cząsteczka jest przesuwana w dół o tę odległość. Jeśli ten parametr będzie stały, to teren będzie tym łagodniejszy im większa jego wartość. Jeśli natomiast będzie losowy, to uzyskamy coś na kształt erozji. I dobrze :)

Kolejny parametr tzw. erosion_threshold to warunek, którego będziemy używali do określenia czy cząsteczka jest niżej. Jeśli ma wartość standardową (zależnie od implementacji 0 lub 1) to cząsteczka jest w niestabilnym położeniu, gdy którakolwiek z przeszukiwanych jest o 1 jednostkę niżej. Jeśli ustawimy go na 2 to o 2 cząsteczki, jeśli na 3 to o 3, ... Im wyższa jest ta wartość tym wyższe będą uzyskane formy terenu. Oczywiście i tu random okaże się pomocny, żeby jednocześnie mieć pionowe skały, ale i łagodniejsze przejścia (przydatne dla gór).

Jak mówiłem zamiast losowo wybierać miejsca do zrzucania cząsteczek, lepiej robić to z głową dzięki czemu możliwe jest uzyskanie różnych formacji. Poniżej opisuję kilka z nich.

Wulkan

Pierwszym krokiem jest określenie położenia stożka wulkanu. Następnie liczby strumieni lawy, ich długości i kierunku. W rzeczywistości lawa podobnie jak woda formuje strumienie, którymi spływa ze szczytu góry w dół. Ponieważ czasem zmienia kierunek w trakcie, do kierunku będziemy dodawać losową wartość.


For każdy ze strumieni
  Rozpocznij u stożka
    While aktualna długość strumienia < długości docelowej
      Idź zgodnie z kierunkiem strumienia i zmień go losowo
        Zrzuć cząsteczkę
        Przesuwaj cząsteczkę w dół dopóki niestabilna
        Zmień wysokość w docelowym punkcie

Aby osiągnąć wulkan o odpowiedniej charakterystyce powtórz kilkukrotnie powyższy proces.

Tworzenie krateru jest jeszcze prostsze. Wystarczy, znając wysokość na której się zaczyna h, odbić aktualną pozycję względem h.

Pasmo górskie

Pasma górskie są piękne: strome ściany, szczyty doliny, erozja. Aby je utworzyć Hayes zaproponował dodatkowy krok w fazie preprocessingu - utworzenie 2-wymiarowego brownian tree. A robi się to w sposób prosty (w takiej nieco brute force-owej formie):


Wyczyść tablicę na 0 
Wybierz losowy punkt z tablicy i ustaw go na 1 (będzie to ziarnem)
i = 0
While i < liczba iteracji 
  Wybierz losowy punkt z tablicy 
  found = false 
  while found = false 
    Przesuń się po tablicy w losowym kierunku 
    if aktualna pozycja sąsiaduje z elementem ustawionym na 1 
      found = true 
  Ustaw wartość dla aktualnej pozycji na 1

Przykładowe drzewo znajduje się poniżej (odwróciłem kolory, żeby było czytelniej):

Wyniku używamy przy tworzeniu gór. Dla każdej z pozycji, dla której wartość w tablicy wynosi 1 zrzucamy cząsteczkę. Powtarzamy kilka razy i mamy ładne góry!

Klify, kaniony

Tworzymy je tak samo jak pasma górskie. Jedyna różnica jest taka, że na końcu odwracamy wszystkie kolory.

nGENE - 100k LOC, czy gra jest warta świeczki

2009-05-08T16:10:00.004+02:00

Z okazji, że w końcu udało mi się w nGENE-ie przekroczyć magiczną barierę 100 tys. linii kodu postanowiłem napisać okolicznościową notkę. Będzie ona o tym czy na pewno warto pakować się w programowanie silników. Chciałbym także zauważyć, że 100k LOC jak na silnik to raczej mało, niemniej trzeba pamiętać, że kodzę go w przerwach między pracą, studiami a nurkowaniem ;)

Okazuje się, że programowanie silników jest dziś niezwykle popularne, niemal każdy chce mieć swój framework (nawet jeśli obejmuje on tylko ładowanie obrazków 2D to już jest dumnie nazywany silnikiem) o wspaniałych feature'ach i wpadającej w ucho nazwie. Wielu osobom wydaje się, że skoro jest to modne, to jest to również coś prostego, co każdy programista gier umieć powinien. Jednak w rzeczywistości jest to zajęcie trudne, niewdzięczne i niezwykle pracochłonne. Mało który domorosły silnik zostanie zauważony, nawet jeśli będzie Open-Source (jak to ktoś na gamedev.net skomentował moje screeny - "mało kto idzie dalej, niż spojrzenie na screeny").

O to więc mały bilans zysków i strat.

Co zyskujemy:

uczymy się nowych umiejętności, poznajemy algorytmy i techniki stosowane przez programistów w profesjonalnych silnikach (różne "Perełki" są tu bardzo pomocne :) ).
mamy możliwość stworzyć coś zupełnie od zera, zakodować wspaniałe efekty - jest to szczególnie pomocne gdy istniejący silnik jest czarną skrzynką i dopisać coś samemu jest trudno (a z takich silników też korzystałem)
satysfakcja, satysfakcja i jeszcze raz satysfakcja!

A oto, co tracimy:

nie mamy zwykle czasu na pisanie gier (przynajmniej jakichś bardziej ambitnych niż jakieś proste sample do silnika), bo inaczej będziemy musieli zrezygnować z implementacji jakiegoś super-wypasionego-algorytmu-zarządzania-pamięcią
szansa, że w przyszłości dostaniemy pracę jako programista silnika 3D jest dużo mniejsza niż na posadzie gameplayowca. Wynika to z kilku powodów. Po pierwsze większość firm woli kupić gotowe i sprawdzone komercyjnie rozwiązanie niż stracić kilka lat na rozwój swojego. Po drugie istniejące silniki zwykle nie są przepisywane od nowa lecz od wielu lat rozwijane (co jest powodem, że część kodu w nich to antyki), więc wielu elementów naszej wiedzy pewnie nigdy nie będziemy mieli szansy użyć.
Argument, że dzięki temu możemy przetestować jakieś efekty, shadery czy inne techniki też jest absurdalny. Poza całą masą silników (np. do darmowego Ogre'a istnieje i SSAO, i deferred shading i paging) istnieją takie narzędzia jak FX Composer, które pozwalają nam małym kosztem stworzyć nowy efekt i zobaczyć jak on się prezentuje.
W domu choćbyśmy się nie wiem jak starali, i tak nie napiszemy silnika dorównującego możliwościami CryEngine'owi 2. Ba! Nawet się do niego nie zbliżymy. Już nawet nie wspominając o tym, że legalnymi metodami nie napiszemy silnika prawdziwie cross-platformowego tj. działającego i na PC i na PS3, i na XBoxie (XNA to mimo wszystko znaczne uproszczenie).

Czy zatem jestem przeciwny pisaniu silników? Poniekąd tak, sam czasem żałuję, że wybrałem taką drogę a nie inną. Ale teraz nie chcę się już dać przekwalifować - zbyt wiele czasu na to straciłem. Oczywiście lubię to co robię, wystarczającym argumentem jest dla mnie ta wspomniana satysfakcja. Zresztą nGENE powoli przestaje być silnikiem anonimowym, więc jest za późno na zmianę decyzji - byłaby to oznaka słabości ;)

A następnym razem napiszę coś o proceduralnym generowaniu różnych formacji terenu.

nGENE Tech Toolset - co tam słychać?

2009-04-24T14:12:00.001+02:00

Edytor do silnika nGENE Tech miał być dostępny najpierw pod koniec marca, później kwietnia. Wygląda jednak na to, że znów będę musiał przesunąć datę jego wypuszczenia, ale mam nadzieję, że to czekanie się opłaci. Chcę bowiem, żeby już pierwsza jego wersja pozwalała na jak najwięcej, a nie tylko ładnie wyglądała.

Na pocieszenie filmik z aktualnej wersji. Jak zawsze zachęcam do zgłaszania uwag:

Już miesiąc jako moderator...

2009-04-11T17:18:00.003+02:00

Już miesiąc minął (no dobra minie jutro, ale jutro nie będę pisał) od momentu gdy zostałem mianowany moderatorem forum Gamedev.pl. To tak jabky ktoś nie wiedział ;) Pierwszy raz jest mi dane moderować tak duży serwis i po tym miesiącu mogę stwierdzić, że nie jest to wcale takie łatwe i przyjemne jak niektórym się wydaje:

Jest to dosyć absorbujące. Trzeba wiedzieć co się dzieje na forum i w miarę możliwości reagować. Nie zawsze użytkownicy zgłaszają niepożądane treści lub przejawy lamerstwa, a nawet jeśli, czasami jest już za późno - wątek zdążył się już przeistoczyć w małą prywatną wojnę. Interwencja powinna mieć miejsce możliwie jak najwcześniej, tak więc bez czytania wielu tematów (niektórych z mojego punktu widzenia nudnych) się nie obejdzie.
Nawet jeśli ktoś zgłosi naruszenie regulaminu, to nie zawsze oczywistym jest co z wątkiem/wiadomością zrobić. Czasem przejawy lamerstwa lub nieprzestrzegania elementarnych zasad kultury nie pozostawiają żadnych wątpliwości, ale czasem jest dużo ciężej nacisnąć przycisk 'Lock' czy 'Move Topic'. Dotyczy to szczególnie osób początkujących, bo z jednej strony nie zawsze przestrzegają one regulaminu, ale z drugiej nie każde pytanie o podstawy programowania musi być przejawem lamerstwa. Różnica jest taka, że jeśli ktoś umie sformułować pytanie i z szacunkiem traktuje pozostałych użytkowników to ja nie mam serca skazywać jego tematów na potępienie ;)

Tech Demo - download

2009-04-01T19:39:00.001+02:00

Zgodnie z obietnicą umieściłem w internecie demo - Tropical Island. Można je pobrać tutaj. Ma jedną podstawową wadę - niską wydajność (no i kilka bugów różnej maści). Mimo że ostatnio dużo profiluję i optymalizuję, to zdecydowałem się wrzucić starszą wersję z jednego prostego powodu - jest w niej mniej artefaktów graficznych. Ostra optymalizacja ma niestety to do siebie, że traci się trochę na jakości, więc zanim udostępnię bardziej wydajne binarki, to muszę jeszcze poszukać kompromisu pomiędzy jakością a prędkością działania. Natomiast na pewno wkrótce się one pojawią.

Materiały z IGK'2009 i nowy artykuł

2009-03-27T12:31:00.002+01:00

Reg wrzucił materiały z mojej prezentacji, z tegorocznego IGK, dotyczącej wody na Gamedev.pl, tak że nie będę ich tutaj dublował. Zachęcam do czytania, implementacji i wprowadzania usprawnień w podstawowej technice mojego autorstwa :) Wkrótce powinna też się pojawić wersja w .pdf, na której brak niektórzy już narzekają. Demko zgodnie z wcześniejszymi obietnicami będzie dostępne 1. kwietnia (BTW ostatnio mocno profiluję więc wydajność z dnia na dzień rośnie). Aha, wbrew obiegowej opinii na kilku serwisach - to nie jest żart (dowiedziałem się przy okazji, że Royal Air Force też powstało 1. kwietnia) ;)

Kilka dni temu dobiegła końca ankieta, w której prosiłem Was o wybór tematu artykułu, który chcielibyście przeczytać. Ku mojej radości padło na techniki animacji postaci. Prawdopodobnie opublikuję to jako serię kilku artykułów, jako że jest to bardzo szeroka i dosyć trudna dziedzina. Na pierwszy ogień pójdzie oczywiście animacja szkieletowa, później będą zagadnienia bardziej zaawansowane (jak blending, ragdoll, IK itd.).

Prawdopodobnie w przeciągu tygodnia napiszę też jakiś krótszy artykuł na temat profilowania gier za pomocą takich narzędzi jak AMD CodeAnalyst, PIX i PerfHUD, bo myślę, że może się to komuś przydać.

IGK'2009 - przemyślenia po konferencji

2009-03-22T13:50:00.006+01:00

Tegoroczna, już 6-ta, edycja konferencji IGK już się zakończyła. Przynajmniej dla mnie, bo chłopaki jeszcze biorą udział w compo. Ja zrezygnowałem ze startowania, bo aktualnie siedzenie w nocy i wymyślanie różnych rzeczy nie sprawia mi już takiej frajdy. Kodzenie w moim przypadku przypada na godziny 10.00 - 22.00 :) Fajnie było się ze wszystkimi spotkać i pogadać trochę o programowaniu gier, zwłaszcza że od zeszłego roku dużo więcej osób pracuje w branży gier.

Czas więc na małe podsumowanie tego co widziałem.

Organizacyjnie było całkiem nieźle. Jedyna wpadka to brak autokaru przez 30 min. podczas pierwszego dnia konferencji, ale później nie było już z tym problemów. Zresztą nieuczciwe byłoby zrzucanie tego w całości na organizatorów.

Jedzenie bardzo dobre :)

Sponsorzy dopisali, co może cieszyć: Farm 51, Seventhtear, Techland (fajnie że są jak zawsze) i zdaje się, że Mobica (była wymieniona podczas konferencji, brakuje jednak informacji na stronie konferencji).

Referaty. Poziom niestety niższy niż w roku ubiegłym, choć trafiło się na szczęście kilka perełek. Ogólnie było bardzo różnie dlatego powiem kilka słów o każdym z nich:

Projekt i implementacja trójwymiarowej gry zręcznościowej na telefon komórkowy. - przedstawiciele Akademii Podlaskiej opisali proces tworzenia gry na komórki. Może referat nie był profesjonalny merytorycznie. Ale po pierwsze autorzy byli świadomi braków w swojej wiedzy (a jest to lepsze niż udawanie, że się wszystko wie), a poza tym co dużo ważniejsze napisali kompletną, działającą grę, a to jest bardzo fajne. Gratuluję im tego i życzę, żeby był to początek przygody z programowaniem gier!
Projektowanie i implementacja silnika fizyki - wg mnie zdecydowanie najlepszy referat w trakcie konferencji! Seventhtear zaprezentował ogólnie jak powinien wyglądać silnik fizyki, opowiedział o typowych problemach w implementacji. Naprawdę bardzo fajne, zwłaszcza jeśli wcześniej nie miało się wielkiej styczności z implementacją silników fizyki, które (tu w pełni zgadzam się z autorem) są równie ważne i ciekawe co renderery. Poza tym fajnie było w końcu poznać człowieka, który poniekąd zachęcił mnie do próbowania dostania się do Metropolis Software (przypominam jednak, że ostatecznie tam nie pracuję).
Przegląd technik sztucznej inteligencji stosowanych w grach komputerowych. - temat niestety bardzo ogólny! W 40 minut ciężko powiedzieć tutaj coś sensownego, na każdą z omawianych technik można poświęcić wiele godzin. Szkoda zatem, że autor nie skupił się na konkretnym zagadnieniu.
Kopalnia pomysłów - wzorce dla projektowania gier komputerowych. - przyznam, że tutaj nie bardzo zrozumiałem intencję autorów. Referat w mojej opinii trochę zbyt chaotyczny, a i również do formy przekazu mam pewne zastrzeżenia.
Inżynieria oprogramowania w grach komputerowych w praktyce. - przyznam, że temat ten mnie bardzo zawiódł. Po Koshmaarze (Playlogic Games) oczekiwałem czegoś innego. Owszem było to ciekawe, ale z samą inżynierią nie miało wiele wspólnego. Spodziewałem się raczej czegoś o testach czy metodykach. A tak nie miałem, o czym z nim podyskutować (jakby było o Agile mogłoby być ciekawie :) ). Ponadto Koshmaar sorry, ale dlaczego slajdy były po angielsku?! Jesteśmy w Polsce, konferencja jest po polsku. Nawet mimo że znam ten język dość dobrze, za to ode mnie WIELKI minus.
Rola języków skryptowych w technologii gier. - języki skryptowe z punktu widzenia graczy. Całkiem przyjemny referat, mimo że wygłoszony przez laików w programowaniu. Udowodniło to jednak, że podstaw skryptowania może nauczyć się każdy. Trochę błędów było, ale większość można wybaczyć.
Rendering planet w czasie rzeczywistym. - kolejny referat, po którym wiele sobie obiecywałem. I wyszło bardzo fajnie. Co prawda znów zbyt ogólnie, bo o takim megatexturingu można wygłosić osobny referat, a zabrakło np. informacji o renderingu chmur czy atmosfery, ale i tak jeden z lepszych referatów tegorocznej edycji. Demka niestety zabrakło (te 100GB tekstur :) ).
Rendering realistycznej wody jako efekt post-process - a... to moje. Chyba się podobało, choć przez ograniczony obiadem czas nie powiedziałem tyle co bym chciał. Braki zostaną uzupełnione i w tekście referatu (jest dużo dłuższy) oraz w "reżyserskiej" wersji prezentacji.
NecroVisioN - ewolucja renderera i mechaniki gry. - firmowa prezentacja firmy Farm 51 dotycząca ich najnowszej gry. Powiem tak - po tej prezentacji zdecydowałem, że muszę w grę zagrać, bo wyszła naprawdę fajnie. Sama prezentacja, wygłoszona przez Wojciecha Pazdura (jeśli ktoś tego pana nie kojarzy, to jest on jednym z twórców Painkillera), prezentowała wysoki poziom merytoryczny. Pazdur nie bał się opowiadać o problemach z pierwotną wersją renderera, a nawet zdradził kilka cennych informacji dotyczących aktualnie używanej wersji. Powiem tak - deferred shading mają zaimplementowany praktycznie tak samo jak ja :) Fajne jest też to, że Farma jest bardzo często obecna na konferencji i odsłania zawsze trochę kart. Po prostu super sprawa!!!

EDIT: Jedna rzecz mi się odnośnie referatów nie podobała - niektóre pytania. Jeśli ktoś widział, że autor nie jest super zaawansowany, to po co pytania, na które na pewno nie będzie znał odpowiedzi? Po to żeby pytający pokazał jaki to on jest Pro, że jest lepszy od autora?! A może po to by ośmieszyć autora i wzbudzić uznanie sali. Sorry, ale takie zachowanie jest infantylne i żałosne. Pokazuje też, że nie każdy umie docenić wysiłek jaki trzeba włożyć w przygotowanie referatu.

I to ogólnie tyle. Po referacie dotyczącym Necrovision zabraliśmy się z kilkoma kolegami do domów. Tak więc moja relacja jest niepełna, bo był jeszcze konkurs wiedzy IT (sorry Reg, żałuję, że nie mogłem być obecny, ale zmęczenie było zbyt duże), wybór referatu oraz Compo.

Tak czy inaczej - do zobaczenia za rok!

EDIT2: materiały z konferencji (prezentacja, demko) pojawią się wkrótce.

nGENE - tech demo

2009-03-18T14:57:00.003+01:00

Tech demo z nGENE Tech miało być pokazane na IGK'2009 w ramach mojego referatu. Tak mówiłem od pewnego czasu. Nie będzie. Stwierdziłem, że wolę na nim pokazać krótki filmik prezentujący tylko wodę i jej różne aspekty. Natomiast tech demo będzie udostępnione osobno. Wynika to z faktu, że nie chcę żeby ludzie stwierdzili, że się przechwalam czymś co nijak ma się do referatu, bo sam tak bym pomyślał.

Tech demo do ściągnięcia będzie 1. kwietnia. Wynika to z faktu, że na pewno będzie udostępniane wraz z instalatorem, żeby uniknąć aktualnych problemów z różnicami między wersjami .dll-ek. Chcę zresztą wprowadzić jeszcze drobne optymalizacje w kodzie.

Na zachętę już teraz pokazuję "trailer":

HD dostępne do ściągnięcia tutaj.

Reference rasterizer - co to takiego?

2009-03-16T19:38:00.009+01:00

Jest w DirectXie coś takiego co nosi nazwę reference rasterizera (wczoraj musiałem po dłuższej przerwie z niego skorzystać). Mimo że nie jest to z pozoru nic szczególnie przyjemnego ani potrzebnego, to warto wiedzieć co to takiego i jak z tego skorzystać, bo czasem okaże się to ostatnią deską ratunku w sytuacji, gdy nasze efekty graficzne nie działają a wedle naszego mniemania i okna "Output" z debuggera - powinny. Zwykle jest tak, że u nas wszystko jest w porządku, ale problemy pojawiają się na innych komputerach. A to jakieś artefakty, a to pusty ekran. Możliwości jest całkiem sporo.

Ale do rzeczy. Reference rasterizer w skrócie pozwala na symulowanie referencyjnego urządzenia, czyli oderwanego całkowicie od producenta, wersji sterowników itp. Urządzenia, które spełnia wymogi danej wersji DirectXa. Jest to zatem swego rodzaju wzorzec. Działa sobie toto w całości na CPU więc nie należy oczekiwać zawrotnej wartości FPS (prędkość renderingu mogłaby momentami rywalizować z raytracerem działającym na CPU na jednordzeniowym procesorze; przy czym raytracer mógłby wygrać :) ).

Jeśli grafika prawidłowo wyświetla się na reference rasterizerze, to praktycznie na 100% będzie działała prawidłowo na wszystkich kartach o takiej konfiguracji. Na szczęście, bo pozwala to wyeliminować potencjalne błędy. Dzięki temu aktualnie usuwanie pewnego buga na kartach AMD-ATI nie stanowi dla mnie wielkiego problemu (sam mam GeForce'a). Bez tego musiałbym zgadywać tylko po objawach, co byłoby mniej efektywne i skuteczne. A że w logach wszystko jest ok, to nie ma innego wyboru.

Ale jak skorzystać z dobrodziejstw "Refa"?

Nic prostszego. W momencie tworzenia urządzenia w DirectXie w polu DeviceType należy podać D3DDEVTYPE_REF (zamiast D3DDEVTYPE_HAL). Wywołanie wygląda więc mniej więcej tak:

pD3D->CreateDevice(..., D3DDEVTYPE_REF, ..., ..., ..., ...);

Gdy już mamy ustawione odpowiednie urządzenie możemy uruchomić program w PIXie (swoją drogą w PIXie też istnieje możliwość wymuszenia przełączenia urządzenia w tryb referencyjny). Jednak jako, że nasze aplikacje będą działały raczej wolno to odpadają w zasadzie podstawowe zdefiniowane w PIXie Countery (i dobrze bo są potwornie ograniczone). Jeśli chcemy tylko zobaczyć jak nasza aplikacja wygląda to wystarczy zdefiniować dwa triggery. Ja np. zdefiniowałem sobie takie:

Pierwszy (uruchamiany w klatce nr 1) zbiera wszystkie dane, drugi (wywoływany w 2. klatce) zamyka aplikację (inaczej nie byłem jej w stanie zamknąć). Oczywiście często trzeba będzie to skonfigurować inaczej, ale mi było potrzebne akurat coś takiego.

BTW znów mam Screen Tygodnia na gamedev.pl. Policzyłem z ciekawości jedną rzecz i okazało się, że od 11.01.2009 jest to już 7. Screen Tygodnia dla moich screenów! Całkiem satysfakcjonujący wynik jak na fakt, że od tego czasu minęło 2.5 miesiąca ;)

Czy gry są sztuką?

2009-03-15T19:59:00.003+01:00

Pytanie w tytule jest aktualne. Opinia publiczna ciągle nie uznała gier za sztukę tak na 100% (dla wielu ciągle jest to tylko zabawa i nic więcej...). Środowisko twórców gier dopomina się o to co jakiś czas (choć nie wszyscy są tu zgodni).

Czy gry wideo powinny być traktowane jako sztuka? Moim zdaniem - tak. O to garść powodów, które wg mnie za tym przemawiają:

Kino już od wielu lat uznawane jest za sztukę, a arcydzieł wśród filmów jest naprawdę niewiele, większość to kiczowate produkcje o płytkiej fabule i przeciętnej grze aktorskiej. Z grami jest podobnie, nie każda gra jest dziełem ze wszech miar, niemniej perły też się zdarzają. Jednocześnie głębia doznań oferowanych przez gry jest dużo większa. W niejednym tytule gracz po kilkudziesięciu godzinach grania zaczyna się utożsamiać ze swoim cyfrowym alter ego, przeżywa jego klęski, cieszy się jego sukcesami, odczuwa strach, litość, współczucie. Pojawia się tu zatem coś na miarę katharsis. Tym którzy nie pamiętają już lekcji polskiego przypomnę, że katharsis było formą duchowego oczyszczenia, które towarzyszyć miało oglądaniu przedstawień teatralnych w starożytnej Grecji.
Niejednokrotnie fabuła prezentowana w grach może się równać z książkami. Całkowicie liniowe i przewidywalne fabuły to czasy minione bezpowrotnie. Dziś gry takie jak np. The Witcher czy Mass Effect stawiają przed graczem trudne wybory moralne, które zadecydują nie tylko o jego losach, ale o losach otoczenia, w którym się porusza. Liczne zwroty akcji jeszcze bardziej pomagają w budowie emocji.
Dalej - muzyka. Ona sama w sobie jest sztuką. Utwory takich artystów jak Jeremy Soul rozbrzmiewają w uszach jeszcze przez wiele godzin po zakończeniu rozgrywki. A że muzyka ta jest integralną częścią gry i stanowi do niej podkład...
Warstwa wizualna - niektóre modele/tekstury to arcydzieła same w sobie. Ale na grafikę w grze mają również wydatny wpływ programiści. Utworzenie efektów to jedno, ale utworzenie ich w taki sposób, żeby to stanowiło spójną całość i żeby wyglądało tak jak wynika z mętnych wyjaśnień designera to wcale nie taka łatwa sprawa. Zresztą nie wszystko opiera się na wzorach matematycznych, całkach i innych tablicach. Aby uzyskać piękny obraz nie opłaca się naśladować rzeczywistości, bo prawda jest taka, że jest ona bardzo szara i często nieciekawa. Obraz trzeba podrasować niczym grafik zdjęcie modelki w Photoshopie. A do tego potrzeba już jakiejś formy talentu.
Przede wszystkim jednak gry to zbiór wielu elementów, połączenie wielu gałęzi sztuki. Czy zatem sprawiedliwie jest odmawiać im samym takiego tytułu?

Na koniec taki screen malarski z nGENE'a:

IGK'2009 - agenda

2009-03-11T00:01:00.002+01:00

Organizatorzy konferencji IGK udostępnili dziś agendę. Moje odczucia nt. tematów, które w tym roku zostaną wygłoszone są nieco mieszane. Z jednej strony jest kilka mnie interesujących, czyli dotyczących silnika i technologii (silnik fizyki, rendering planet, Necrovision), a z drugiej wiele jest takich, które jakoś mnie nie specjalnie pociągają. Cóż nie jest to oczywiście SIGGRAPH i nie samą grafiką człowiek żyje, więc to zrozumiałe. Z drugiej strony w zeszłym roku było zagadnień silnikowych więcej - stąd pewnie niedosyt.

Szkoda też, że z roku na rok coraz mniej Warsztatowych wyjadaczy decyduje się opowiedzieć nam o czymś ciekawym. Brak referatów stałych bywalców takich jak Reg, mINA czy Krzysiek K. A że są to ludzie, którzy siedzą w branży więc ich głos byłby tu szczególnie cenny. Nie tylko z powodu merytorycznego, ale również podnosiłby prestiż konferencji (tak - chcę was zmotywować na przyszły rok :) ).

A tak to musi zabrać głos taki amator jak ja ;) I to do tego tuż przed przerwą obiadową (szykujcie się na brak obiadu w tym roku, bo o wodzie to mogę godzinami rozprawiać).

Z innej beczki. Po raz kolejny mój screen jest screenem tygodnia. Filmik, już to mogę powiedzieć został przyjęty dość ciepło. Co prawda są pewne zastrzeżenia (choć nie ze wszystkimi się zgadzam), ale ogólnie jest chyba na tak ;) To dobrze, bo przed IGK chyba nie zdążyłbym już kompletnie zmienić algorytmu renderowania wody. Ot był to taki ostatni sprawdzian.

nGENE - update

2009-03-09T19:56:00.011+01:00

Co prawda przed tegorocznym IGK miałem nie dokonywać żadnych update-ów do publicznego repozytorium SVN, jednak kilka bugów zmusiło mnie żeby zmienić zdanie. Lista zmian jest naprawdę duża, niemal wszystkie są bezpośrednio lub pośrednio powiązane z demem nad którym pracuję, ale prawda jest taka, że wiele rzeczy uległo zmianie. Aktualna wersja to również 5 przykładów (oprócz 6 tutoriali):

FurryBunny - było wcześniej
Tornado - pokazuje sposób użycia pól siłowych
NPR - pokazuje rendering z inną kamerą + NPR
SSAO - mówi wszystko
SwayingPalm - ta palma, do której filmik jakiś czas temu wrzuciłem

Wkrótce pojawi się też największe demo tj. VolcanicIsland.

Do tego czasu pokażę prostą scenę zawierającą wodę w ruchu. Wiele osób pytało jak to działa w ruchu, chciało to zobaczyć, więc taki szybki filmik z edytora (edytora na nim nie widać poza bounding boxem używanym do prezentacji zaznaczonych obiektów). Scena jest zmodyfikowaną sceną, którą prezentowałem do połowy ubiegłego roku. Aha i sorry za te zbyt ciemne obiekty - mają nieprawidłowo ustawione parametry materiału, więc silnik traktuje je jakby były baaardzo ciemne :)

Woda jest nieco mętna, pora dnia - 3 godziny po świcie. Patrzeć tylko na wodę reszta jak mówiłem jest mocno testowa :)

Ponieważ z niezrozumiałych powodów jakość filmu na YouTube jest katastrofalnie niska wrzucam też film w wyższej jakości.

SWA i petycja

2009-03-05T11:26:00.003+01:00

Nurkujesz, żeglujesz, uprawiasz surfing, lubisz poszaleć na skuterze wodnym albo po prostu lubisz wypoczynek nad wodą? Od niedawna na polskiej scenie sportów wodnych istnieje stowarzyszenie SWA (Safe Water Association), promujące bezpieczeństwo nad i pod wodą. Jako jego członek i osoba obecna przy jego narodzinach zachęcam wszystkich do zapoznania się z jego działalnością.

Na początek proponujemy zmiany w szkoleniu żeglarzy ponieważ standardowe szkolenie nie obejmuje procedur postępowania w przypadku bliskości nurków do jednostki pływającej (ba! nie ma często nawet słowa o znaczeniu nurkowych flag). List otwarty oraz petycję na ten temat można znaleźć pod tym adresem. Może wydawać się to drobnostką, ale uwierzcie mi - duży odsetek wypadków śmiertelnych w nurkowaniu jest spowodowany przez uderzenie głową nurka w przepływającą zbyt blisko jednostkę... Zbyt duży.

Ponadto w ubiegłym tygodniu w ramach SWA wraz z grupką przyjaciół przeszkoliliśmy się w zakresie udzielania pierwszej pomocy przedmedycznej (EFR) oraz tlenowej (DAN Oxygen Provider i DAN Advanced Oxygen Provider). Kurs zrealizowany został przez Centrum Nurkowe Crazy Shark i jest godny polecenia nawet dla osób nienurkujących. Mimo że jest to jedna z tych umiejętności, która ma się nadzieję nigdy nie będzie potrzebna, naprawdę powinno się ją nabyć.

Zmiany na stronie i ankieta

2009-03-03T14:10:00.002+01:00

Trochę podrasowałem stronę (oczywiście w zakresie w jakim na bloggerze jest to możliwe). Z widocznych rzeczy, nawigacja powinna być nieco łatwiejsza dzięki udostępnieniu chmury tagów.

Dodałem również ankietę nt. tematu artykułu, który chcielibyście przeczytać (jeśli ktoś ma inne propozycje, to zachęcam do ich zgłaszania). Tematy do wyboru są dosyć zaawansowane, ale wszystkie mają zastosowanie w programowaniu gier (no może poza ray-tracerem - ich epoka jeszcze nie nadeszła, ale myślę, że za 5 lat będą tym czym dzisiaj jest deferred shading, czyli czymś więcej niż tylko buzz-wordem).

Drakensang i Nebula

2009-02-28T14:01:00.007+01:00

W ostatnim czasie bez reszty pochłonęła mnie gra o nazwie Drakensang (nie licząc przerw na pisanie tech dema silnika i dopisywaniu różnych bugów do silnika :) ). Jest to cRPG naszych zachodnich sąsiadów, dla którego wyraźną inspiracją nie są gry takie jak ostatnie hity gatunku czyli The Witcher, Mass Effect, Fallout 3 czy Gothic 3. Jest to heroic fantasy cRPG w klasycznym wydaniu nawiązujący do takich gier jak Baldur's Gate czy Icewind Dale. Mamy więc sporą drużynę (4 osoby), sterowanie myszą, wiele umiejętności, czarów, mikstur, przeciwników, przedmiotów i dosłownie dziesiątki questów! Nie są to questy o rozmachu tych znanych z Fallouta 3, ale wiele radości daje zabijanie szczurów w piwnicy, czy polowanie na czarownice po stronie Inkwizycji.

Gra okazała się na tyle dużym sukcesem w Niemczech (zgarnia tam wszystkie możliwe nagrody), że choć premiera wersji angielskiej ma mieć miejsce dopiero wkrótce (polska już jakiś czas temu miała miejsce) to już zapowiedziano jej drugą część (prequel). Grę gorąco polecam!

Ale nie byłbym sobą gdybym na grę patrzył tylko jako na źródło rozrywki. Chwila przeczesywania różnych stron zaprowadziła mnie m.in. tutaj oraz tutaj. Okazuje się bowiem, że autorzy gry, firma Radon Labs, udostępnia swój engine Nebula napędzający m.in. Drakensanga na zasadzie Open-Source. I to nie tylko wersję 2 (właśnie na niej działa Drakensang), ale również najnowszą odsłonę oznaczoną numerem 3. A że jest to engine całkiem porządny i wydajny niech świadczy fakt, że gra o której tu piszę działa płynnie na bardzo wielu słabszych konfiguracjach, a mimo to wygląda naprawdę przyjemnie (ma taki fantasowy klimat).

Deferred shading a pakowanie

2009-02-25T14:25:00.003+01:00

Tę notkę bardziej można potraktować jako update do mojego zeszłorocznego referatu z IGK dotyczącego deferred shadingu niż pełnoprawny wpis, ale co tam.

Podobnie jak inni autorzy zajmujący się tym zagadnieniem w ubiegłym roku wychwalałem w referacie zalety pakowania danych przed umieszczeniem ich w G-Buforze. Jednak w przeciągu roku deferred shading pojawił się w bardzo wielu silnikach, karty graficzne znacznie się rozwinęły i okazało się, że pakowania już się prawie nie stosuje (albo w bardzo ograniczonym wymiarze)! DirectX 9.0 pozwala przy wykorzystaniu MRT na zastosowanie 4, DirectX 10.0 już 8 render targetów. Miejsca na dane jest więc wystarczająco dużo, nawet w przypadku tej starszej wersji DirectXa. Tak naprawdę w 90% przypadków będziemy chcieli w buforze przechować tylko pozycję (3 składowe), wektor normalny (3 składowe), dane o specularze (2 składowe), indeks materiału (1 składowa) i kolor (4 składowe). Daje to w sumie 13 pól. Tak więc jeśli korzystamy z zestawu 4 4-kanałowych tekstur, to mamy jeszcze wolne miejsce na dodatkowe ustawienia.

Co to daje? Poza zaoszczędzeniem kilku instrukcji shaderów wymaganych do pakowania i rozpakowywania danych, przede wszystkim nie ma strat jakości (mówię o buforze zmienno-przecinkowym, w którym na jeden RT przypadają 64 bity - bo aktualnie jest to najmodniejsza konfiguracja). A te były szczególnie wyraźne w przypadku niektórych metod pakowania wektorów normalnych i wektorów położenia, o czym zresztą już kiedyś wspominałem. Niby niedokładności były nieznaczące, ale potrafiły się objawiać od czasu do czasu w postaci artefaktów.

Kolejna sprawa. Cienie. O nich tylko napomknąłem. W przypadku deferred shadingu zwykle używa się tradycyjnego podejścia, to jest shadow mappingu. Dla świateł kierunkowych często nie są jednak wykorzystywane jakieś skomplikowane techniki , lecz tradycyjny rendering z rzutem ortogonalnym, bez żadnych dodatków! Dla świateł kierunkowych, które z punktu widzenia deferred shadingu są globalne stosuje się jednak większą shadow mapę (zwykle od 1024x1024 do 2048x2048), dzięki czemu cienie wyglądają całkiem przyzwoicie. Do tego rozmycie cieni i efekt zadowoli większość graczy. Bardzo fajny opis można znaleźć w GPU Gems 3, w rozdziale opisującym deferred shading w grze Tabula Rasa.

Ponadto znów mój screen został screenem tygodnia na gamedev.pl :) jest to dla mnie bardzo miłe. Również pozytywne komentarze, choć niektóre nieco na wyrost działają motywująco.

I ważna uwaga na koniec: chętnie napisałbym jakiś artykuł. Aktualnie nie mam jednak pomysłu na jaki temat. Jeśli ktoś ma jakiś pomysł jestem otwarty na sugestie (czy to dotyczące implementacji jakiejś techniki graficznej, czy czegoś dotyczącego silników, projektowania, inżynierii itd.).

nGENE - Update

2009-02-23T15:33:00.008+01:00

Po napisaniu poprzedniego shadera zacząłem wrzucać roślinność do dema:

Animacja roślin

2009-02-20T20:03:00.011+01:00

Rośliny są coraz częstszym składnikiem gier. O ile kiedyś drzewa wystarczyło wyrenderować jako billboardy, dziś takie rozwiązanie będzie uznane za archaiczne. Współcześnie istnieje nawet możliwość wyrenderowania gęstej dżungli (instancing + impostory + paging działa cuda), gdzie każde drzewo, paproć to osobny model. Jednak, aby rośliny wyglądały w miarę naturalnie nie tylko muszą być pokryte realistycznie wyglądającym materiałem, ale również poruszać się na wietrze, tzn. animować się.

Zaawansowane rozwiązanie tego zagadnienia, użyte w Crysisie, opisane jest szczegółowo w GPU Gems 3. Jednak okazuje się, że niezłe rezultaty da się osiągnąć dużo mniejszym nakładem pracy, i to tę technikę pokrótce opiszę w tej notce.

Najważniejsze w animacji roślin jest to, że wyższe partie roślin chwieją się bardziej od tych położonych niżej. Wynika to oczywiście z kierunku, w którym następuje przyrost rośliny. Najwyżej położone części rośliny są najmłodsze, najcieńsze i tym samym najbardziej giętkie.

Tym samym animacja będzie wyglądała tak:

float amplitude = IN.position.y * windStrength;
float3 wave = float3(sin(time + IN.position.x), 0.0f, cos(time + IN.position.z));
float3 pos = IN.position + amplitude * wave;

Co tu się dzieje? W pierwszym wierszu uwzględniamy wspomniany wcześniej fakt, i wyliczamy amplitudę wygięcia dla aktualnej siły wiatru. W kolejnym wierszu wyliczamy modyfikator pozycji. Animacja będzie następowała tylko w osiach x i z. time to oczywiście parametr wejściowy określający czas. Natomiast dodanie do niego odpowiednio IN.position.x i IN.position.z zapewnia pewien chaos, a tym samym większy realizm (jednocześnie zapewniając, że zaburzenia dla blisko leżących wierzchołków będą niewielkie). Dzięki temu wierzchołki będą się poruszały nieco inaczej. Ostatni wiersz to wyliczenie ostatecznej pozycji wierzchołków. Oczywiście potem należy przemnożyć wynik przez odpowiednie macierze.

Jako że obraz wart jest więcej niż 1000 słów, króciutki filmik sporządzony na szybko:

Mimo że shader w HLSLu ma zaledwie kilka linijek, znacząco ożywił demo, nad którym pracuję. Może nie jest to szczyt technologii, ale aktualnie nic bardziej zaawansowanego nie jest mi potrzebne.

NPR a PR

2009-02-16T13:59:00.004+01:00

SceNtriC swoim ostatnim wpisem sprowokował mnie do napisania tej notki. Pisze on w swym wpisie o "scenach naturalnych", czyli photorealistic rendering (rendering fotorealistyczny). Ja napiszę o czymś zupełnie przeciwnym, czyli o NPR (non-photorealistic rendering), czyli renderingu stylizowanym. Do tej kategorii zalicza się wiele znanych efektów takich jak cel shading (efekt kreskówki) czy water color filter (efekt farby olejnej). Poniżej przykład z tego drugiego zrobiony na szybko:

Może screen piękny nie jest, ale pokazuje ideę. Stylizowanie obrazu ma jedną wielką zaletę - obraz starzeje się bardzo wolno. To co widzimy dziś w Crysisie wydaje się nam niesamowite i ultra realistyczne. Jednak za kilka lat, wraz z postępem technologicznym, gry będą wyglądały dużo ładniej. Za 10 lat pewnie nikt w Crysisa nie zagra, bo będzie miał beznadziejną grafikę.

Natomiast sceny wyrenderowane z wykorzystaniem NPR jak powiedziałem, starzeją się wolno. Jeśli uzyskamy efekt farby olejnej, to będzie on tak samo aktualny za kilka ładnych lat. Jest to szczególnie istotne w przypadku gier, w które gracze mają grać latami. Dobrym przykładem są tu więc MMOG. Praktycznie większość korzysta z grafiki stylizowanej (w pewnym stopniu), np. tej z WoWa z pewnością fotorealistyczną nazwać nie można, ale dzięki temu gra po tych kilku latach bytności na rynku wygląda znośnie.

Ponadto w przypadku NPR często można stosować tekstury i modele o niższej szczegółowości, ponieważ końcowy obraz i tak maskuje niedostatki wejściowego. Dzięki temu często znika problem ilości zasobów i gra może działać nawet na słabszym sprzęcie. Ponadto aby zachować spójność warstwy wizualnej, często cała grafika jest utrzymana w tym tonie - modele i tekstury są przerysowane, karykaturalne.

Jednocześnie stosując NPR wcale nie musimy się ograniczać. Są to zwykłe efekty post-process tak więc możliwe jest stosowanie wszystkich innych technik, np. HDR czy SSAO. Wszystko zależy tylko od tego jaki efekt chcemy osiągnąć.

Czy clicki są złe?

2009-02-11T20:06:00.000+01:00

Ostatnio na Warsztacie (zarówno na forum jak i w samym serwisie) wybuchła kolejna bezsensowna "wojna". Tym razem poszło o to, czy dla tzw. klików (polska nazwa pochodzi pewnie od pierwszego, czyli Click'n'Play) i projektów w nich robionych, jest na Warsztacie miejsce. Padały różne argumenty, niektóre absurdalne, inne niosące ze sobą więcej treści. Sprawa nieco na szczęście przycichła, więc mogę się wypowiedzieć co na ten temat ogólnie myślę.
Uważam, że clicki są o tyle dobre, że pozwalają większemu gronu osób spróbować sił w tworzeniu gier. Na Warsztacie często zapomina się wg mnie o jednym. O tym, że nie każdy musi być programistą gier. Clicki, w których nie trzeba się martwić o takie aspekty jak prawidłowe zarządzanie pamięcią czy optymalizacje SSE, są więc doskonałym narzędziem dla designerów, którzy dzięki nim mogą szybko sprawdzić swoje pomysły. A bez dobrego pomysłu nasze gry będą tak naprawdę niczym, większymi techdemami naszych wypasionych frameworków. Wg mnie chorym byłoby wymagać od projektantów gier umiejętności w programowaniu. Jest to zbyt artystyczna dziedzina, aby zmuszać tych ludzi do technicznego myślenia. Co prawda nie raz i nie dwa, niektóre pomysły projektantom trzeba wyperswadować jako nierealne do zrealizowania na aktualnym sprzęcie, ale równie często są oni w stanie wymyśleć rzeczy, których ograniczający się często do fantasy RPG programista wymyślić nie zdoła. Ponadto widziałem już w życiu projekty (np. design doci) zrobione przez projektantów o programistycznych ambicjach - nigdy więcej... Ani nie był to dobry projekt, ani nie miał za wiele wspólnego z "prawdziwym" programowaniem.
Oczywiście można powiedzieć, że jest wiele innych sposobów prototypowania gier, choćby przygotowanie prostej gry karcianej albo planszowej. Jednak dopiero zobaczenie niektórych pomysłów na ekranie monitora pozwoli ocenić na ile były one trafione. Oczekiwanie na doprowadzenie silnika przez zespół programistów do stanu używalności jest demotywujące. Bo trwa zbyt długo. Wykorzystanie do prototypowania XNA mija się z celem, bo część przydatnych funkcji jest mocno zabugowana (i developerzy XNA tego nie ukrywają na forach). Są oczywiście komercyjne narzędzia, ale początkujący zwykle nie mają ochoty płacić za nie setek dolarów.

Modele nieba

2009-02-09T11:29:00.015+01:00

Swego czasu opisywałem dwa modele dziennego nieba autorstwa Preethama i Hoffmana. Od tamtego czasu niewiele się zmieniło, istniejące modele nie zostały jakoś dramatycznie usprawnione, nie pojawiły się żadne nowe innowacyjne. Dużą popularnością cieszy się aktualnie model Nishity, prosty i tani obliczeniowo (w porównaniu z wyżej wymienionymi) ale dający niezłe wyniki. Na nim też bazuje wiele innych (zdaje się, że i Preetham odwoływał się do jego prac). Dla nocnego modelu nieba najlepsze wyniki daje chyba model Shirleya (który notabene jest jednym z współtwórców modelu Preethama).

Ja ciągle zostaję przy modelu Preethama, który choć drogi obliczeniowo daje wg mnie i wielu innych programistów i grafików najładniejsze wyniki osiągalne w czasie rzeczywistym. Jednocześnie ma kilka wad, w tym jedną poważną, która dopóki nie wykorzystywałem HDR zbyt mi nie przeszkadzała. Jest nią bardzo słabe słońce, które w tym modelu jest tylko nieco jaśniejszym od nieba kołem (dla pewnych położeń słońca ciężko je w ogóle zlokalizować). W modelu Hoffmana słońce jest dużo jaśniejsze od reszty nieba (wręcz ta różnica jest zbyt duża). Po przeskalowaniu wynik powinien więc być dużo ładniejszy.

Na szczęście stosunkowo łatwo to obejść. Pamiętać należy jedynie o tym, że model Preethama jest w sumie funkcją położenia słońca na niebie (w zasadzie to kątów, ale do jednego to się sprowadza). Skoro tak, znamy kąt między kierunkiem światła a normalną nieboskłonu, gamma. Próbowałem wielu rozwiązań. Najlepsze słońce uzyskałem w następujący sposób:

float sunGlow = sunBrightness * skyLuminance;
sunGlow = lerp(1.0, sunGlow, 1 / gamma);,

gdzie:

sunBrightness - jasność słońca
skyLuminance - jasność nieba w danym punkcie
gamma - kąt między normalną nieba a wektorem światła

Następnie ów sunGlow wykorzystuję jako dane wejściowe do HDR. O to jak to wygląda w praktyce (kilka screenów dla tej samej pory dnia i różnych ustawień słońca i atmosfery):

I na koniec jeszcze screen z dema silnika, nad którym pracuję. Dodatkowo nieco stuningowane chmury (poprawniejszy zanik na horyzoncie i scattering) i woda:

nGENE - małe podsumowanie

2009-01-30T11:08:00.013+01:00

Nad swoim frameworkiem pracuję już przeszło 2 lata. Z tego tytułu małe podsumowanie. Na pokazanie pierwszych screenów zdecydowałem się dopiero rok temu i teraz mogę z całą stanowczością powiedzieć, że się ich wstydzę. Wówczas dało się już pisać proste efekty (i w gruncie rzeczy tylko takie). Niby moja wiedza od tamtego czasu jakoś potwornie nie wzrosła, ale jakość pierwszych obrazków była słaba. Choć z dnia na dzień nie widzę jakichś wielkich postępów, to gdy spojrzę czasem na te starsze screeny i na screeny sprzed zaledwie kilku dni, widzę że napisałem sporo fajnych efektów. Powiem więcej - ciężko mi uwierzyć, że jest to jeden i ten sam silnik. Zresztą, żeby nie było, że mówię coś dziwnego dwa screeny. Jeden ma ok. roku, drugi kilka dni:

Cieszę się, że mimo tak drastycznych zmian w kwestii wyglądu, przyjęte pierwotnie założenia nie blokują i nie ograniczają mnie w żaden sposób. Podjąłem kilka trafnych decyzji, w tym zastosowanie deferred shadingu, który gdy podejmowałem tę decyzję nie był jeszcze taki modny (dziś jest prawie wszędzie). Żałuję jedynie, że nie myślałem wtedy o nastawieniu na procesory wielordzeniowe... niestety duża część kodu będzie musiała zostać zrefaktoryzowana, aby naprawdę wspierać wielowątkowość, a nie od przypadku do przypadku traktować pozostałe procesory jako koprocesory ułatwiające policzenie bardziej skomplikowanych rzeczy.

W ostatnich dniach dodałem HDR, co powinienem zrobić wcześniej, ale nie mogłem znaleźć motywacji do zaimplementowania czegoś, co ma chyba u siebie każdy. Takie to mało odkrywcze :) Mówiąc inaczej - HDR nie pasował mi do końca do koncepcji systemu materiałów. Na szczęście jakoś udało się to rozwiązać. I dobrze, bo dopiero teraz używany przeze mnie model Preethama, nabrał rumieńców. Wschody i zachody Słońca po prostu rządzą! No i zwiększyłem też wydajność. Jakieś 2x razy dla większości aplikacji. Ale to dopiero początek optymalizacji. Zacząłem też na dobre pisać renderer pod DX10.1. W końcu.

Jednocześnie to, że idę w dobrym kierunku zdają się potwierdzać notowania moich screenów, które wykazują tendencję zwyżkową. Nie tylko trzy tygodnie z rzędu moje screeny zdobyły tytuł screena tygodnia na gamedev.pl, ale cieszą się zainteresowaniem również w innych, anglojęzycznych serwisach.

Na koniec kilka słów o edytorze. Dotychczas nie był mi potrzebny i stale odsuwałem zadania z nim związane na później. Jednak jako, że chcę zrobić demo, które posłuży mi jako proof of concept na tegorocznym IGK, zmotywowałem się i piszę go dosyć intensywnie. Chcę żeby był maksymalnie prosty w użyciu, tak aby każdy w przeciągu maksymalnie kilkudziesięciu minut mógł stworzyć świetnie wyglądającą mapę. Edytor będzie WYSIWYG tak więc będzie prezentował dokładnie to co się zobaczy w gotowej aplikacji i będzie pozwalał na interakcje ze światem 3D. Mam też przewidziane coś dla prawdziwych laików, ale o tym jak to zrobię ;)

nGENE Tech Toolset coraz bliżej

2009-01-22T15:09:00.004+01:00

Jednym z podstawowych założeń wersji 0.2 mojego silnika jest udostępnienie edytora typu WYSIWYG, który ułatwiłby znacznie tworzenie świata. Oto jak się aktualnie prezentuje. Pracy jeszcze sporo, ale powoli, powoli nabiera kształtu. Jednocześnie chciałbym zaznaczyć, że będzie to jedyna część SDK, której kod źródłowy nie zostanie przeze mnie udostępniony:

"To nie mój błąd"

2009-01-14T11:41:00.010+01:00

Dalszy ciąg wpisu nt. "czego nie należy zakładać przy programowaniu".

Bardzo często programiści przyjmują pewne proste i niestety błędne założenie. Kod nie działa, błędu na pierwszy rzut oka nie widać (a nawet w wyniku kilkugodzinnej sesji debugowania), więc wniosek jest prosty - błąd popełnił ktoś inny. Do tej kategorii zaliczają się następujące błędy w myśleniu:

program się nie kompiluje - błąd kompilatora lub środowiska
program działał poprawnie, ale po zainstalowaniu sterowników zaczęły się pojawiać artefakty - błąd w sterownikach karty graficznej
program w pewnych przypadkach kończy się blue screenem - błąd w systemie (w końcu to Windows, na Linuxie na pewno program działałby poprawnie)
po użyciu biblioteki pojawiają się dziwne błędy lub wyjątki - błąd w bibliotece
program przestał działać po aktualizacji wersji roboczej z SVNa - błąd w wersji w repozytorium

Co w takim myśleniu jest niepoprawne? Ano na tym, że w 99% przypadków to my jesteśmy autorami błędu, który powoduje dziwne zachowanie programu. Jest to podkreślane w wielu książkach dotyczących programowania, kursach a mimo to programiści zdają się o tym notorycznie zapominać.

Niestety takie myślenie nie jest domeną początkujących, również tym trochę bardziej zaawansowanym zdarza się tak myśleć, tyle że ci bardziej zaawansowani z większym prawdopodobieństwem faktycznie znaleźli błąd leżący poza granicami ich kodu. Ale o tym za chwilę.

Poniżej kilka błędów z mojego życiorysu, a mam się czym chwalić jeśli chodzi o błędy ;) . Zarówno obrazujących to, że nie miałem racji jak i przykłady leżące poza granicami pisanej przeze mnie aplikacji:

ponad 2 lata temu gdy zacząłem łączyć nGENE z PhysXem okazało się, że gdy dojdzie do kolizji pomiędzy static meshem a jakimkolwiek innym aktorem, program się wysypuje. Pierwsza myśl: static mesh jest przeze mnie wypełniany niepoprawnymi danymi. Niestety okazało się, że wszystko jest jak być powinno. Wówczas zacząłem podejrzewać Ageię, że coś popsuła w kodzie. Na szczęście ciężko mi było w to uwierzyć i w końcu znalazłem swój błąd - polegał on na tym, że kiedyś namieszałem trochę w nagłówkach z makrami i część kodu była niewidoczna (albo był widoczny ten, który działał nieco inaczej), o czym niestety zapomniałem.
Pewnego dnia po aktualizacji sterowników GeForce'a zauważyłem, że część render targetów zawiera dziwne dane. Tak jakby nie były czyszczone. Spędziłem wiele godzin szukając przyczyny błędu. Zacząłem podejrzewać nVidię, zwłaszcza że jak się okazało inni też mieli podobny problem z tą wersją sterowników. Już chciałem odpuścić, ale jednak okazało się że błąd był mój - nie należy lekceważyć pewnych warningów DirectXa, jakkolwiek bez znaczenia by się one nie wydawały.
Swego czasu korzystając z wczesnej wersji silnika Unigine, zauważyłem że odbicia są zawsze nieprawidłowe (a potrzebowaliśmy ich do zrobienia wody). Konkretnie zawierały zdecydowanie za mało geometrii (tak jakby kamera przy ich renderowaniu była skierowana w złą stronę, albo clipping plane był nieprawidłowy). Upewniwszy się, że błąd nie leży po mojej stronie napisałem maila do Unigine Corp. z prośbą o poprawienie tej usterki, i drugiego, i trzeciego... Upierali się, że to nie oni są winni. Jednak w końcu go poprawili. Ale wody już nie zdążyliśmy zrealizować
Innym razem już jako programista Ruby on Rails chciałem wykorzystać aplikację znaną jako Beast (forum napisane w Rails). Niestety działy się momentami dziwne rzeczy, aplikacja zwracała błędy w zasadzie bez powodu. Analiza kodu biblioteki zdradziła fakt, że pewne klasy są niezdefiniowane! Mail do autora biblioteki i po kilku dniach problem został rozwiązany.

Podsumowując. Nigdy nie należy zakładać, że błąd pochodzi z kodu kogoś innego, bo sprawia to, że nie analizujemy swojego kodu w należyty sposób. Stajemy się bardziej leniwi, a to może doprowadzić do obniżenia jakości naszego kodu i wprowadzenia dodatkowych błędów. Dopiero po dogłębnej analizie możemy dojść do takiego wniosku. Wówczas nie należy zwlekać i zgłosić błąd autorom tego kodu. Jeśli rzeczywiście on istnieje prawdopodobnie zostanie poprawiony, bo autorom na pewno będzie zależało na tym by ich produkt był jak najlepszy.

A poniżej drobny update z wody. Już jest w repozytorium SVN:

Woda raz jeszcze

2009-01-11T20:28:00.010+01:00

Jakiś czas temu (a dokładniej w pierwszej połowie listopada) pisałem, że zacząłem dodawać do nGENE'a efekt wody. W międzyczasie wiele nie robiłem (o tym było ostatnio), ale przez ostatnie kilkanaście dni ostro przysiadłem do roboty i powstało sporo kodu. Nie dość, że poprawiłem wiele błędów, dopisałem sporo przydatnych funkcji, to ponadto jestem bliski skończenia efektu, o którym mówiłem.

O to efekt:

Wg mnie wyszło całkiem dobrze. Przede wszystkim jestem zadowolony z elastyczności tego rozwiązania, możliwe jest stworzenie całkiem sporo różnych rodzajów akwenów: od jezior aż po lekko pofalowane morza. Na kolor wody ma wpływ wiele czynników, co powinno być lepiej widać na screenach. Część z nich była "robiona" na płytszej wodzie. Najbardziej w tej chwili można się przyczepić do siły odbicia, ale za to screeny są bardziej widowiskowe.

Nie będę jednak ukrywał, że potrzeba tu poświęcenia trochę czasu, aby osiągnąć pożądany efekt (chodzi mi o dobór wszystkich parametrów), ale wszystko powinno się dać zrobić.

Następnie w kolejności jest dokończenie HDR i animacja (wreszcie!), a woda i poprawki w przeciągu kilku dni znajdą się na SVNie (swoją drogą ostatnio był spory commit, który poprawiał wiele usterek).

"Mój program jest wolny od błędów"

2008-12-19T16:12:00.004+01:00

Czy zdarzyło wam się słyszeć (lub czytać) od jakichś programistów, całych zespołów, ich szefów, że tworzone przez nich oprogramowanie jest całkowicie pozbawione błędów? Pewnie tak. Czy to możliwe, żeby z programu wyeliminować WSZYSTKIE bugi? Oczywiście nie. Choć fajnie by było i należy zawsze dążyć do ograniczenia ich liczby (nawet systemy krytyczne nie są od nich wolne) - dla wygody użytkowników, a czasem również np. bezpieczeństwa danych.

Piszę o tym dlatego, że zauważyłem, iż część programistów stosując unit-testy lub inne metody testowania oprogramowania nabywa błędnego przeświadczenia, że dzięki temu uchronią się przed każdym bugiem w przyszłości i wyeliminują te, które w programie już są. Po pierwsze takie założenie możnaby przyjąć tylko przy dobrze napisanych testach (a różnie z tym bywa - niektóre są zakodzone conajmniej niechlujnie). Po drugie - nie jesteśmy w stanie przewidzieć wszystkich możliwych sytuacji interakcji użytkownika z aplikacją, ani całej specyfiki środowiska uruchomieniowego naszego programu. Do tego jeśli stosujemy intensywny refaktoring nowe bugi będą pojawiać się z olbrzymią częstotliwością.

Ostatnio rozbawił mnie kolega, który stwierdził, że u niego w jakimś programie nie było ani jednego buga. To, że zespół nie potrafi ich wylistować na bug-liście świadczy tylko o zaistnieniu jednej z kilku sytuacji:

zespół jest bardzo niedoświadczony, a tym samym szukanie błędów sprawia mu trudności
zespołowi brakuje odwagi, umiejętności samokrytyki - często sprawdza zachowanie aplikacji tylko dla typowych danych, i udaje że wpisanie w polu nazwisko "1454" jest tylko błędem użytkownika
programiści są po prostu słabi, a tym samym nie powinno się ich dopuszczać do wykonywania tej pracy

Ktoś mógłby zapytać: jaki jest zatem stosowania testów jak i tak stoimy w punkcie, w którym wiemy, że są w naszym kodzie błędy. Otóż po to, żeby wyłapać jak najwięcej błędów, a tym samym dać sobie szansę na ich wyeliminowanie.

Podsumowując: NIGDY NIE WOLNO przyjmować, że w naszym programie nie ma błędów, nawet jeśli wszystko na to wskazuje. Prędzej czy później ktoś je znajdzie. A jeśli nie... cóż oznacza to tylko, że nikt z naszej aplikacji nie korzysta.

Z innej beczki - dawno nic nie pisałem, gdyż nie miałem zbyt dużo czasu ani ochoty na programowanie. Pisanie silnika zatrzymało się na etapie kodzenia efektu wody. Próby znalezienia sobie tematu do napisania gierki spełzły na niczym. Poddałem się na razie co do poszukiwań pracy w GD (mam nadzieję, że po studiach inżynierskich się uda). Do silnika zamierzam coś dopisać w święta. Może uda mi się również znaleźć jakiś sensowny pomysł na projekt własnej gry.

Przy okazji chciałbym pogratulować chłopakom od C.O.R.E.-a. Wedle publicznie dostępnych informacji gra ma wkrótce wreszcie trafić do sprzedaży!

Woda - pierwsze przymiarki

2008-11-12T14:20:00.008+01:00

Jakiś czas temu zacząłem prace nad wodą do swojego frameworka. Ot tak w ramach odpoczynku od nudniejszych koderskich zadań. Rozpoczynając owe prace postawiłem sobie tylko jeden cel - zrobić ją tak realistyczną jak tylko się da (a jak wiemy nie istnieje nawet dotychczas prawidłowy model matematyczny ją opisujący...). Większość programistów 3D zapomina bowiem o kilku rzeczach:

z głębokością występuje zanik koloru. Dla każdej składowej szybkość zaniku jest inna! Najszybciej zanika składowa czerwona, później zielona, a najwolniej niebieska.
światło przechodząc przez powierzchnię wody tworzy lightshafty
na kolor wody wpływ ma skład wody, obecność w niej różnorodnego mułu, tzw. kwitnienie wody (kwitnienie wody - oznacza kwitnienie glonów i innych roślin w okresie wiosenno - letnim) itd.

Choć na razie nie spełniłem sam jeszcze tych punktów to jestem zdeterminowany, aby to zrobić.

Co więcej wodę realizuję w dosyć nietypowy sposób. Aby moje rozważania łatwiej zrozumieć, przypomnę że używam domyślnie deferred renderingu, a zatem mam łatwy dostęp do danych na temat głębokości i pozycji sceny (dane te trzymam w G-Bufferze) na każdym etapie poza wypełnianiem G-Buffera.

Ok. Tradycyjnie istnieją dwie techniki renderingu wody:

technika dla mórz i oceanów - którą ewentualnie można by podzielić na: środek oceanu i wybrzeże, ale tego nie zrobię. W tej technice zwykle wykorzystuje się prostokątną siatkę o dużej gęstości wierzchołków. Dzięki ich przekształcaniu w oparciu o różne modele matematyczne można uzyskać piękne i realistyczne fale.
technika dla jezior - tu pomija się geometrię. Na płaszczyznę nakładana jest scrollowana normal mapa. Do tego dokłada się odbicie, refrakcję oraz specular.

Technika, którą ja stosuję różni się tym od wymienionych, że jest wykonywana w CAŁOŚCI jako efekt post-process, a nie jak można by przypuszczać w fazie geometrii. Mając położenie każdego z widocznych z punktu położenia obserwatora pikseli mogę z łatwością stwierdzić, czy punkt ten jest pod, czy nad wodą. Jednocześnie mogę łatwo stwierdzić jak głęboko pod powierzchnią się znajduje. Ale to jeszcze nic. Wykorzystując height-mapę przeprowadzam coś na kształt paralax mappingu. Z tą różnicą, że efekt jest dużo lepszy, gdyż fale faktycznie mogą przysłaniać geometrię (po wyliczeniu wysokości fali znów sprawdzam czy punkt, który analizuję nie jest pod wodą), a nawet jakby się uprzeć wchodzić z nią w pewną ograniczoną interakcję.

Mimo że do końcowego efektu jeszcze długa droga, to wstępnie jestem całkiem zadowolony. Udało mi się nawet stworzyć refrakcję w oparciu o zawartość G-Buffera. Odbicie też, choć mam tu jeszcze jeden problem. I nie chodzi mi wcale o oczywistą nieprawidłowość odbić, przy wykorzystaniu G-Buffera. Takie drobne błędy i tak w większości przypadków łatwo jest zamaskować.

Nieprzewidywalność jest zła

2008-11-11T10:30:00.007+01:00

Trafiłem ostatnio na interesujący wpis na tej stronie . Porusza on ciekawe zagadnienie. Mianowicie czy nieprzewidywalność w grach osiągana za pomocą nieoskryptowanej AI (np. sieci neuronowych czy algorytmów genetycznych, albo innej formy świadomości/pamięci/uczenia się) jest dobra? Konkluzją z wypowiedzi 4 specjalistów jest, że nie. Przynajmniej nie w czystej postaci. Według niektórych rozwiązaniem jest połączenie metod "nieprzewidywalnych" ze skryptami tam gdzie są one potrzebne.

Pytanie jest na tyle ciekawe, że sam postanowiłem powiedzieć, co na ten temat myślę. Dawniej, gdy zaczynałem swoją przygodę z programowaniem gier celem było dla mnie osiągnięcie jak największej nieliniowości rozgrywki i autonomii oraz nieprzewidywalności agentów AI. Czyż nie wspaniale byłoby grać za każdym razem w kompletnie inny sposób, kończyć grę na dziesiątki różnych sposobów, za każdym razem obserwować unikalne zachowania powstałe w oparciu o obserwacje poczynań gracza i uczenie się jego taktyki? Tak - wtedy myślałem, że jest to wspaniałe. I uważam, że z punktu widzenia zaawansowania technologicznego jest to nadal wspaniałe i na swój sposób pociągające.

Niestety. Gracze nie są osobami, które zwykle doceniają stopień zaawansowania naszych algorytmów, lecz to jak dużą przyjemność daje im gra.

A prawda jest tak, że jeśli AI będzie zbyt inteligentna stanie się powodem frustracji. Gra powinna być wyzwaniem, ale nie jest to równoważne temu, że ma być piekielnie trudna lub niemal niemożliwa do ukończenia. Powiedzmy, że agenci AI w grze FPS znają dokładnie topografię terenu gdzieś w Indonezji, a do tego bacznie obserwują taktykę gracza (śledzą go), ucząc się w jaki sposób walczy (np. analizując swoje i gracza błędy). Na tej podstawie AI może określić idealne miejsca na zastawienie śmiertelnej pułapki, albo sposób na wyeliminowanie WSZYSTKICH swoich potknięć. Gra wówczas będzie polegała na metodzie save & load, bo agenci AI będą od pewnego momentu nie do pokonania. Kilka kroków - headshot. Load - agenci teraz zachowują się nieco inaczej. Jeden krok - headshot. Load - od razu headshot. Znowu load - kilka kroków... quicksave i znów headshot. Taka sytuacja może mieć miejsce nawet jeśli AI będzie trochę niecelne, czy będzie popełniało inne ludzkie błędy.

Do tego jak nieprzewidywalnością sterować, żeby osiągnąć zamierzony efekt fabularny? Cóż - nie da się. Agenci AI mogą stwierdzić, że bardziej cenią swoje życie niż postępowanie w sposób przewidziany przez designera. Niech pewna postać w grze RPG posiada ważny przedmiot pod kątem głównego wątku. Jeśli tę postać zranimy, może stwierdzić, że nie zamierza ryzykować i zacznie uciekać przez całą planszę. Pewnie kiedyś gracz ją dopadnie, ale zmarnowanie nawet kilku minut na bezsensowną pogoń nie jest najlepszym sposobem na wykorzystanie czasu. Kolejnym problemem związanym z fabułą jest to, że jeśli gra za każdym razem będzie wyglądała inaczej to jak zbudować napięcie? Jak dbać o zwroty akcji, jeśli dialogi/rozwiązania questów za każdym razem mogą dać inny skutek w zależności od całej dotychczasowej rozgrywki i widzimisię agenta?

Ponadto jak nieprzewidywalną grę testować? Jeśli mamy rzeczywiście do czynienia z dużą nieprzewidywalnością to co nam da przetestowanie kilku scenariuszy? Co jeśli w większości przypadków gry nie będzie się dało po prostu ukończyć, bo NPC z którym na końcu mamy porozmawiać zginie zabity przez swoich kompanów, którzy uznają, że współpracuje z graczem, który ma chaotyczny zły charakter?

Jednak, że by nie było, że jestem całkowicie temu przeciwny - uważam, że kontrolowana nieprzewidywalność (np. w ograniczonym stopniu dla postaci nieistotnych pod względem fabularnym - ale też np. nie dla kupców - głupio byłoby gdyby po okradzeniu jednego z nich, żaden nie chciał nam sprzedać swoich przedmiotów) może podnieść jakość rozgrywki. Jednak jest to temat na inny wpis.

Futro i poprawki we frameworku

2008-11-01T16:11:00.012+01:00

Ostatnio nie pisałem nic o progresie w swoim frameworku. Prawda jest taka, że nie bardzo mam się czym pochwalić, bo skupiam się na poprawieniu bugów/ulepszaniu tego co jest już zrobione. Roboty z tym jest cała masa. Do tego dochodzi konieczność napisania różnych klas pomocniczych.

Niemniej potrzebowałem do pewnych zastosowań shadera futra (dosyć prostego, więc olałem "finsy", czyli dodatkowe trójkąty na wszystkich krawędziach). Toteż prezentuję wynik tych prac. Model królika jest bardzo stary, ma coś nie tak z UV-kami, ale prezentuje mniej więcej działanie techniki. Do tego widać miękkie cienie (też pisane na szybko jako proof-of-concept i światło reflektorowe, którego brak w wersji 0.1 był karygodnym błędem).

Technika tworzenia futra stosowana powszechnie (dobra powszechnie jak powszechnie...) to shells and fins texturing. Mimo że jest dobrze znana i lubiana opiszę ją, bo może uchował się ktoś, kto jej nie zna. Opiera się ona na bardziej złożonej obliczeniowo technice wolumetrycznej. W niej futro reprezentowane jest jako tekstura 3D, której każdy poziom głębokości zawiera dane o kolorze i przezroczystości futra oraz o oświetleniu. Następnie futro tworzy się wykorzystując ray marching. Jak można się domyśleć jest to raczej kosztowne obliczeniowo. Shells and fins texturing jest pewnym uproszczeniem.

Shells to kolejne warstwy futra tworzone poprzez wytłaczanie pozycji wierzchołków wzdłuż ich normalnych o odległość będącą ułamkiem długości futra (im mniejszy ułamek na każdą "skorupkę" tym lepszy efekt i niższa wydajność; liczba ułamków = liczba skorupek). Na każdą skorupkę nakładana jest 2-wymiarowa tekstura. Włosy są tam gdzie alpha jest większa od 0. Skorupki renderujemy z włączynym alpha blendingiem.

Wszystko działa dobrze dopóki na futro patrzymy z góry (tzn. kąt między kątem patrzenia a normalną wierzchołka jest niewielki) albo z daleka. Gdy patrzymy z boku efekt jest koszmarny, chyba że użyjemy dużo skorupek (choć od pewnego momentu nic zdaje się szczególnie nie pomagać). Widać bowiem poszczególne warstwy futra. Przykład na obrazku poniżej:

I tu do gry wchodzą finsy, czyli po polsku - żeberka. Jak powiedziałem są to po prostu dodatkowe trójkąty na każdej krawędzi (leżące prostopadle do powierzchni). Żeby miało to ręce i nogi, na każdą krawędź muszą przypadać 2 trójkąty tworzące czworokąt. Żeberka mają własną teksturę, ukazującą futro z boku. Następnie w shaderze możemy zadbać o to, żeby były one widoczne tylko przy odpowiednich kątach.

Jeśli wpadniemy na głupi pomysł renderowania wielu futrzaków (powiedzmy animowane stado wilków) na scenie, to musimy konieczne zadbać o jakiś LOD, aby samo futro nie zabiło nam wydajności. Tu wielkiego problemu nie ma, bo odległe obiekty mogą być renderowane bez użycia finsów i z małą liczbą skorupek. Ostatecznie powyżej pewnej odległości od obserwatora futra i tak nie będzie widać, więc spokojnie będzie można użyć jednej tekstury - diffuse.

Technika ta nie nadaje się do tworzenia włosów. Można ją stosować jedynie do krótkiego futra bądź np. krótkiej trawy (zdaje się, że tak jest to zrobione w Fifie 09, bo właśnie momentami widać poszczególne warstwy :) ).

Prawie się udało...

2008-10-29T17:07:00.002+01:00

Osoby śledzące mojego bloga pewnie wiedzą, że poszukiwałem w ostatnim czasie pracy w polskim gamedevie (mimo pewnych głosów, że nie warto). Wygląda na to, że więcej niż osiągnąłem na razie nie zdziałam. Czas zatem na małe podsumowanie.

Rozmowa w CDPR, o czym wspominałem, delikatnie (bardzo delikatnie...) mówiąc wyszła fatalnie w moim wykonaniu. Złożyło się na to kilka czynników, ale głupio się tłumaczyć z tak prostych błędów jakie popełniłem, więc tego nie zrobię.

Jakiś czas temu wziąłem też udział w rekrutacji do Metropolis (notabene chciałem ją rozpocząć wcześniej, ale jakoś się to przeciągnęło). Tu poszło już dużo lepiej. Rozmowę jakoś przebrnąłem, otrzymane zadanie testowe jakoś zrobiłem (mimo że było z zakresu AI, czyli nie tego w czym teoretycznie jestem najmocniejszy i w czym z pewnością mam spore braki). Moje rozwiązanie zostało przyjęte... i nie będę pracował w Metropolis... A wszystko przez to, że mam fatalnie ułożony plan na uczelni (mówię o laborkach, bo na wykłady i tak nie chodzę), co sprawia, że nie mam możliwości wyrobienia niezbędnego minimum w tygodniu.

Szczerze mówiąc nie wiem, która sytuacja jest gorsza. Czy pierwsza, czy druga. Rekrutacja do Metropolis na pewno pozwoliła mi uwierzyć, że nie jest ze mną tak źle jak to wyglądało po spotkaniu z ludźmi z CDPR (a naprawdę miałem poważne wątpliwości co do swojego stanu wiedzy i umiejętności) i z tego powodu była potrzebna. Natomiast jeśli skończyłaby się tak jak w CDPR mógłbym tylko powiedzieć - trudno, muszę jeszcze sporo popracować...

Jako że nie mam ochoty rezygnować ze studiów wychodzi na to, że poważniejszą pracą będę mógł się zająć dopiero po ich zakończeniu. Liczę, że poniżej aktualnego swojego poziomu w tym czasie nie zejdę. A do tego czasu (chyba, że uda mi się jeszcze coś wykombinować w najbliższych miesiącach/tygodniach na co po cichu liczę) pozostaje mi rozwijanie swojego frameworka i swoich umiejętności. Co prawda jest to momentami nieco nużące (co innego robić grę w doświadczonym zespole, a co innego klepać sobie bez końca swój silniczek), ale innej opcji nie widzę.

Tak bywa - po prostu pech.

Wysyp symulacji piłki nożnej

2008-10-20T12:45:00.003+02:00

Jako że jestem zagorzałym kibicem piłkarskim cieszę się, że symulacji piłki nożnej wychodzi coraz więcej a jakość tych gier stale rośnie. W tym roku mamy do czynienia z:

Fifa 09
PES 2009
Football Superstars - pierwsze piłkarskie MMO (do tego w pełni darmowe)! Niestety aktualna wersja nie uruchamia się na moim komputerze, więc jeszcze muszę trochę poczekać na oficjalny release.

Z serią Fifa jestem od początku tej serii, więc postanowiłem znów dać jej szansę. Pamiętam te dwuwymiarowe Fifa Soccer 94 i 95, i rywalizację z kolegami kto szybciej strzeli bramkę. Mój rekord to 2. sekunda meczu :). Później przeskok w 3D w Fifa 96, a później zakres zmian z części na część był coraz mniejszy, grywalność na przemian spadała i rosła. Fifa 2008 była pierwszą (nie licząc Euro), którą pominąłem - oceny i recenzje były bardzo niepochlebne, a zmiany w stosunku do 2007 były chyba nawet na niekorzyść.

Jednak niedawno pojawiła się rzeczona Fifa 09 i od niedawna ją w wolnym czasie męczę (gram na PC, czyli w tą "gorszą wersję"). Mimo, że gra nie wygląda najlepiej (ach te trybuny w postaci tekstur w niskiej rozdzielczości) gra się w nią nad wyraz przyjemnie. Dzięki nowemu sposobowi sterowania (mysz + klawiatura) w końcu można wypracować akcje i bramki znane z prawdziwych meczów piłkarskich. Idea jest prosta - wskaźnik myszy jest celownikiem. Wszystkie podania i strzały idą w kierunku przez niego wskazywanym (oczywiście czy tak faktycznie będzie zależy od umiejętności strzelca i warunków na murawie). Na początku ciężko jest się przestawić, ale po krótkim czasie docenia się ten nowy sposób sterowania.

Dużą zaletą Fifa od zawsze była masa licencji. Mamy dostępnych bodaj 30 różnych lig, reprezentacje, kilkadziesiąt stadionów i całą masę oficjalnych piłek! Najlepsi piłkarze są odwzorowani w sposób niemal realistyczny.

To co podoba mi się od dawna w Fifa to błędy arbitrów. Niezbyt częste, ale jednak się zdarzają (zwykle w najmniej dogodnym momencie), czyli np. uznanie bramki ze spalonego :)

Ogólnie długo można by pisać. Ale krótko - w mojej ocenie Fifa 09 jest najlepszą częścią dostępną na PC-ty i czymś co umila mi oczekiwanie na Football Superstars (ciekawe czy będzie ono grywalne?).

Mała katastrofa

2008-10-11T13:39:00.001+02:00

Wczoraj przez swoją nieuwagę wykasowałem wszystkie newsy ze swojej poprzedniej strony. Stwierdziłem, że PHP w moich rękach nie jest zbyt bezpieczny, więc przeniosłem się na Bloggera - tu jest mniejsza szansa, że coś popsuję.

Choć udało mi się odzyskać wszystkie posty, komentarze niestety przepadły :/ Natomiast resztę contentu zacznę przenosić w wolnej chwili.

Morał: nie korzystać z narzędzi, których się nie zna.

Dlaczego nurkujemy?

2008-10-06T17:17:00.001+02:00

Gdy rozmawiam z ludźmi, którzy nie mają bladego pojęcia o nurkowaniu zwykle pojawia się jedno z dwóch pytań: "na ile starcza butla?" oraz "dlaczego nurkujesz?". Oba pytania są z pozoru proste, ale w praktyce odpowiedzieć na nie jest niezwykle trudno. Na pierwsze poprawnej odpowiedzi nie ma - zależy ona od wielu czynników, jak profil nurkowania (w skrócie - głębokość osiągnięta w każdym momencie nurkowania), samopoczucie w danym dniu, siła prądu i dziesiątki innych. Żeby zbyt nie komplikować wielu nurków odpowiada - na ok. godzinę (co jest prawdziwe tylko dla pewnego podzbioru nurkowań). Drugie też nie należy do najłatwiejszych pytań, ale mimo to postaram się na nie odpowiedzieć.

Nurków generalnie podzieliłbym na 3 kategorie:

nurkujących dla szpanu
nurkujących po to by coś zobaczyć (czy to rafę, czy wrak)
nurkujących by pokonać samego siebie, swoje ograniczenia (wcale niekoniecznie rekord świata wynoszący 318/330 metrów - w zależności który uznamy za jedyny słuszny)

Pierwszą grupą nie będę się zajmował, bo wg mnie nie jest to esencją nurkowania :) - mimo, że "każdy nurek był w poprzednim wcieleniu pawiem, musi imponować" (cytat z pamięci z magazynu "Nurkowanie"). Jak widać jednak z powyższej listy motywacja dla nurków jest bardzo różna i nie sposób odpowiedzieć za wszystkich jednocześnie. Dlatego odpowiem za siebie.

Dla mnie nurkowanie jest swego rodzaju spełnieniem marzeń o eksploracji, sięganiu tam, gdzie niewielu mogło sięgnąć. Jest zaspokojeniem tej ludzkiej ciekawości, która jednym kazała opływać ziemię, a innym próbować latać. Widzimy świat, w świecie, niezbadany, pełny stworzeń niespotykanych nigdzie indziej, nic nie robiących sobie z naszej obecności. Możemy dotknąć żywej historii nurkując na wrakach. Pełna swoboda ruchów niespotykana nigdzie indziej (no może poza przestrzenią kosmiczną - nie na darmo astronauci NASA trenują też pod wodą), niesamowita cisza i spokój pozwalające na chwilę oderwać się od zgiełku dzisiejszego życia, od rozdzwonionych telefonów komórkowych, czy szumu samochodów na ulicach miast.

To dlatego właśnie nurkuję...

Nocne zdjęcia

2008-09-26T17:21:00.005+02:00

Ok. pół roku temu przeczytałem bardzo fajny artykuł na temat robienia zdjęć nocą w warunkach braku sztucznego oświetlenia. Długi czas naświetlania w warunkach prawie kompletnej ciemności sprawia, że uzyskane fotografie mają nieco surrealistyczny (a niektóre wręcz apokaliptyczny) wygląd. Barwy są obce niczym nie z tego świata. Tak jak z artami nVidii czy ATI, po których przeczytaniu od razu chcę zaimplementować omawiane techniki, tak i tu napadła mnie chęć posiedzenia w nocy i "popstrykania" zdjęć. Na okazję przyszło mi trochę czekać, ale gdy już się pojawiła, postanowiłem ją wykorzystać.

Pierwsza noc spędzona samotnie w ciemnościach, gdy wokół słychać było tylko ruch jakichś małych zwierząt, nie była zbyt owocna. Zdjęcia były albo fatalnie wykadrowane, albo kompletnie niedoświetlone. Później było już trochę lepiej. Zrobiłem kilka ładnych zdjęć (jak na moje możliwości), choć niestety przez spore ustawienie ISO, na co lepszych monitorach widać szum (natomiast na dużych telewizorach zdjęcia oglądało mi się bardzo miło).

Oto kilka z nich:

Jakby ktoś chciał zobaczyć więcej, to są dostępne w moim albumie na Picasie.

Jeszcze małe sprostowanie: jednak zostałem zaproszony na rozmowę do firmy z gd, ale szczerze mówiąc wolę o tej rozmowie jak najszybciej zapomnieć. Ogólnie mówiąc - zawaliłem na całej linii.

Scripting - w czym?

2008-09-22T17:35:00.001+02:00

Od kilku dobrych lat jednym z trendów w tworzeniu gier jest rozdzielenie logiki od danych poprzez zastosowanie języków skryptowych. W części gier stosuje się je do opisania parametrów broni czy pojazdów (proste skrypty typu: "klucz : wartość"), w innych wykorzystuje się języki podobne funkcjonalnością i składnią do C/C++ czy Javy i opisuje się przy ich pomocy cały świat gry (a przede wszystkim AI, questy itd.). Wielu twórców oprogramowania tworzy własne języki (np. Unigine, który system skryptów ma akurat dosyć fajny i rozbudowany), inni stawiają na sprawdzane rozwiązania i wykorzystują modną Lua, Pythona czy np. AngelScripta (czy jeden z innych 100 języków...).

Ja zdecydowałem się pójść tą drugą drogą. Nie dlatego, że brak mi ambicji stworzenia własnego języka skryptowego. Jest to bowiem z pewnością niezwykle ciekawe przedsięwzięcie, ale na tyle wymagające i pracochłonne, że mógłbym sobie spokojnie odpuścić silnik :) i wykorzystać to jako temat przyszłej pracy magisterskiej ;) . W nGENE zdecywałem się na użycie domyślnie dwóch języków skryptowych: Lua i... Ruby. Dlatego dwóch, że Ruby ma być bardziej dodatkiem, swoistą ciekawostką pokazującą, że i do tego ten język się nadaje. Jego elastyczność i piękna składnia powinny przemawiać do każdego. Dla mnie jest to absolutny numer wśród istniejących języków oprogramowania, a dzięki istniejącym już kompilatorom do kodu maszynowego zyskuje tylko na wartości. Z ciekawostek dodam, że ostatnio znalazłem Ogre.rb - port Ogre'a dla Ruby'ego :) Żaden inny język nie jest tak "self-commenting" jak Ruby właśnie: "5.times {|message| print message}". Takie coś będzie jasne nawet dla nieprogramującego designera :) Embedding Ruby'ego w C++ jest niestety nieco trudniejszy niż Lua, bo liczba istniejących i działających bibliotek jest mniejsza (niby jest odpowiednik LuaBind [Rice], ale podobno w VS może być z nim pewien problem).

Powrót nieudany...

2008-09-19T17:36:00.001+02:00

Mogę to już chyba powiedzieć bez obaw, że zaraz sytuacja się zmieni. W ostatnich miesiącach podejmowałem kilka prób ponownego dostania się do pracy w gamedevie (i nie tylko, ale to nie to jest tematem tego wpisu). Do jakiejś większej firmy. Dlaczego? Dlatego, że robienie gier amatorsko już mnie nie bawi, wiem że większość tego typu projektów upada, więc nie potrafię w sobie znaleźć wystarczająco dużo motywacji. Niestety bezskutecznie. Próbowałem zarówno dostać się do pracy w polskich firmach (kompletny brak odzewu po wysłaniu zgłoszenia) jak i jednej zagranicznej. Paradoksalnie to właśnie do tej pracy za granicą miałem największe szanse, mimo że aplikowałem na stanowisko starszego programisty (!!!)... I to nie sam z siebie, lecz zostałem znaleziony przez firmę zajmującą się rekrutacją. Po wstępnej rozmowie z głównym programistą szanse tylko wzrosły, aby po teście kompetencji spaść do zera. Test był w gruncie rzeczy prosty i mogę powiedzieć, że go zawaliłem. Cóż - bywa. W każdym bądź razie nauczka na przyszłość: nigdy więcej rozmów o pracy/testów zaraz po trudnym/głębokim nurkowaniu ;) A najlepiej jakichkolwiek poważnych rozmów. Ogólnie szkoda, bo gość był zafascynowany Agile i może udałoby się je tam wprowadzić :P
W polsce bardzo chciałbym pracować, ale zdaję sobie doskonale sprawę, że przekreśla mnie w większości firm to, że studiuję dziennie*, a zatem na pracę nie mógłbym poświęcić tych 40h tygodniowo. Co w naszych warunkach (czy ogólnie warunkach panujących w GD) jest niekorzystne. Przy notorycznym braku odpowiednich ludzi nieobecność kogokolwiek może wstrzymać prace (bo autor kodu coś np. namotał i dzięki temu wszystko się elegancko wysypuje ;) a nie ma nikogo kto wie jak to dokładnie działa - oczywiście przesadzam :) ). Zresztą mam wrażenie, że na polskim rynku konkurencja jest wyższa. Firmy statystycznie zatrudniają mniej ludzi niż firmy zagraniczne (porównanie creditsów robi swoje...), a zatem o dobrą pracę trudniej. Trzeba mieć bardzo wysokie umiejętności - moje są pewnie gdzieś tak na średnim poziomie. Do scenowców, którzy budowali polski gamedev jest mi nadal bardzo daleko.
Pozostaje mi tylko mieć nadzieję, że dostać do GD uda mi się za kilka lat...
* Jest to chyba jakiś polski paradoks. I to ogólnie nie tylko w GD, ale całego rynku pracy. Mimo że jeszcze kilka lat temu mówiło się, że studia zaoczne są gorsze z perspektywy pracodawcy, to teraz gdy wiele młodych osób chce pracować okazuje się że jest inaczej.

EDITED: świat jest piękny, bo jest nieprzewidywalny. Nawet jeśli nie w GD, to wiele wskazuje na to, że będę robił to co lubię (czyli tematy około silnikowo-niskopoziomowo-graficzne ;) ).

Extreme Programming - zło w czystej postaci?

2008-09-17T17:38:00.001+02:00

Być może wiele osób zastanawia się, co ten tytuł ma znaczyć? Przecież od dłuższego czasu przy każdej możliwej okazji wychwalam zalety tej metody Agile, a tu nagle poddaję to wszystko w wątpliwość. Za każdym razem zachęcam do jej stosowania twierdząc, że idealnie nadaje się do gamedevu.

Na stosujących XP czeka jednak jedna "mała" pułapka, o której dotychczas nie wspominałem, a której konsekwencje mogą być katastrofalne. Otóż stosując XP należy stosować je albo w całości... albo wcale. W praktyce stosowanie XP przez programistów (szczególnie początkujących/niedoświadczonych) wygląda często tak, że wybierają jedynie te elementy XP, które sprawią, że będą mieli mniej pracy (np. ograniczenie dokumentacji czy brak planowania) bądź koszty pracy będą niższe. Jednocześnie zapominają o tym, że pozostałe praktyki (jak np. unit-testing czy częsty refaktoring) są powodem, dla którego planowania nie trzeba prowadzić, że są one pewnego rodzaju zabezpieczeniem. Programowanie ekstremalne to bowiem łańcuch, w którym stosowanie jednej praktyki jest uzależnione od stosowania innej. Wyjęcie któregokolwiek z ogniw powoduje, że całość przestaje byś spójna, tym samym bezpieczna. W ten sposób XP przestaje pełnić swoją rolę...

Więcej na ten temat w dosyć starym, ale bardzo ciekawym artykule autorstwa Matta Stephensa. A dla tych, którzy chcą spróbować Agile, a brakuje im samodyscypliny potrzebnej do stosowania XP zawsze pozostaje Scrum. Innym, choć trudniejszym, rozwiązaniem jest opracowanie swojej wersji XP, która nie będzie miała wszystkich elementów określonych przez jej autorów, ale pozostałe będą tak zmodyfikowane, że wszystko nadal będzie działać.

Garść screenów z demka

2008-08-29T17:39:00.008+02:00

Część osób miała już pewnie przyjemność obejrzeć filmik z poprzedniej notki, a pozostałych zachęcam do oglądania i komentarzy (co jest źle, co poprawić itd.). Trochę się pokręciłem wczoraj po tej testowej mapce i zrzuciłem kilka screenów. To co mnie niezmiernie cieszy to fakt, że jeden z nich w zaledwie dobę uzyskał status najlepszego screena na Gamedev.pl. Niby nic takiego, a jednak cieszy i motywuje do dalszej pracy. Cieszy mnie to tym bardziej, że podobny status mój inny screen osiągnął chyba kilkanaście miesięcy temu (a może to już więcej upłynęło?), gdy projektów było dużo mniej.

Więcej oczywiście w galerii. Jednocześnie jest to na razie koniec wrzucania screenów, gdyż teraz zabieram się za wersję 0.2 silnika, a konkretnie GUI. Czekam też na opublikowanie mojego posta na gamedev.net dzięki czemu mam nadzieję dotrzeć do szerszego grona (na kilkadziesiąt ściągnięć silnika jedynie kilka osób wypowiedziało się na jego temat :/).

Proste demko

2008-08-27T17:47:00.001+02:00

Dziś w ramach odpoczynku przygotowałem taki o to filmik z mojego silnika. Pokazuje on kilka jego cech. Modele są to darmowe modele znalezione w sieci, więc scena jest raczej pustawa, nudnawa i niespójna. Ot i filmik na YouTubie:

Film w lepszej jakości można znaleźć tutaj.

Pair programming

2008-08-26T17:49:00.001+02:00

Pair programming, czyli po polsku programowanie w parach jest jedną z najbardziej rozpoznawalnych cech programowania ekstremalnego. Ba, część osób je z tym błędnie utożsamia. Jednocześnie jest to ta właściwość XP, którą chyba najłatwiej wykorzystać w gamedevie. W telegraficznym skrócie polega ona na tym, że nad fragmentem kodu pracuje jednocześnie dwóch programistów siedząc przy jednym biurku. Podejścia do tego są różne: jeden myśli drugi zapisuje to jako kod (co pewien czas role się zmieniają), jeden pisze kod ale obaj nad nim dyskutują, jeden pisze kod a drugi testy, itd. Zyski z pair programmingu mogą być różne, np.:

wyższa jakość kodu - jeśli nad jego fragmentem skupia się dwóch programistów, to wyłapują oni więcej błędów. Ponadto gdy programuje się z kimś czuje się swego rodzaju presję (zwłaszcza, gdy jest to teoretycznie osoba o wyższych umiejętnościach), która nie pozwala pisać brzydkiego kodu.
szybsze uczenie się - w wielu firmach po przyjściu do pracy programista dostaje dokumentację i kod do przejrzenia i ma się wszystkiego nauczyć sam. Oczywiście - uda się to, ale chwilę potrwa. Programując w parach nauka jest dużo szybsza.
wyższy poziom koncentracji - gdy pisze się w pojedynkę niejednokrotnie błahostka potrafi wytrącić człowieka z transu (ktoś przejdzie obok naszego biurka, komuś coś upadnie, ktoś się odezwie tuż obok), a tym samym obniżyć poziom jego koncentacji akurat w momencie gdy był bliski znalezienia rozwiązania na palący problem. Gdy programistów jest dwóch szansa na taką dekoncentację obu jednocześnie jest mniejsza.

Zaraz ktoś powie, że to się nie nadaje do gamedevu, że bez sensu, że takie rzeczy to do oprogramowania dla banków*... A jednak. Kiedyś w pewnym stopniu wykorzystywałem to. Zresztą nie tak dawno temu odbyłem miłą konwersację z głównym programistą pewnej sporej firmy z gamedevu z zachodniej Europy. W trakcie jej trwania okazało się, że podobnie jak ja jest on zwolennikiem Agile. Powodem, dla którego nie wprowadza on XP nie było wg niego to, że się on nie nadaje jak wiele osób twierdzi, lecz to, że programiści się go boją, bo wydaje im się, że będą się musieli dużo nauczyć! Co jest w ogóle zabawne i paradoksalne zważywszy na fakt ile przeciętnie programista poświęca czasu na samorozwój. Ja również uważam, że programiści boją się XP, a szczególnie pair programmingu. Czasem mam wrażenie, że programiści z gamedevu uważając się za niewiadomo-jakich-wymiataczy są przekonani, że ONI błędu na pewno nie popełnią, a tym samym nie potrzebują nikogo patrzącego w ich monitor... A później co pół godziny gra wywala się do Windowsa...

* Agile nigdy nie został stworzony dla dużych zespołów tworzących oprogramowanie wysokiego ryzyka. Wiele osób tak uważa, ale w praktyce metodyki lekkie (powinni powiesić autora tego tłumaczenia!) sprawdzają się w zespołach liczących kilku do kilkunastu developerów, gdyż umożliwiają pewną spontaniczność tworzenia oprogramowania!

100...

2008-08-25T17:53:00.001+02:00

Tytuł nie jest bynajmniej związany z systemem binarnym jak można by się spodziewać po programiście. Oznacza on liczbę nurkowań, którą wczoraj po wielu bojach udało mi się osiągnąć :) 2 dosyć łatwe i płytkie nurkowania, które wczoraj wykonaliśmy miały miejsce w wyrobisku żwiru koło Łowicza (ach ta widoczność na poziomie 0.5 metra i chłód mimo pływania w suchym skafandrze :) ). Pierwsza 100 jest dla każdego nurka niezwykle istotna (podobnie jak pierwsze 50 m, które to z kolei zrobiłem na początku lipca na wraku Franceski w Chorwacji). Jest to jakieś podsumowanie wysiłku włożonego w kursy (jestem nurkiem ze średnim stopniem i 4 specjalizacjami) i niemałych przecież funduszy wyłożonych na sprzęt i wyjazdy. Jednocześnie jest to ciągle początek długiej drogi w karierze nurka (ci bardziej doświadczeni mają nawet po kilka tysięcy nurkowań...). Ba, ja ciągle nie uważam się za pełnoprawnego nurka! Myślę, że do tego "poziomu" dochodzi się latami... Cóż kolejny cel to również 100... ale tym razem metrów :)

A z innych rzeczy, silnik nie okazał się póki co wielkim sukcesem, ale dzięki opinii i pomocy kilku osób (pozdrawiam!) udało się go uruchomić na systemie XP (choć jeszcze nie u wszystkich...). Wkrótce powinienem też opublikować dane o nim na zagranicznych serwisach (gamedev.net i devmaster.net). Zresztą takiej sytuacji trochę się spodziewałem, bo póki co silnik nie może być konkurencją dla popularnego na Warsztacie silnika Esenthel, czy niestety nierozwijanego już silnika autorstwa Rega (który jest kompletny).

Download jest dostępny!

2008-08-22T17:56:00.002+02:00

Yes, yes, yes! - mógłbym zakrzyknąć. Wykonałem pierwszy mały kroczek na długiej drodze pracy nad swoim silnikiem. Aktualną wersję (0.1) można ściągnąć ze strony http://ngene.wikidot.com/download. Paczka jest całkiem spora (ok. 80 MB), ale zawiera pełny kod źródłowy, wszystkie shadery i bibliotekę materiałów która trochę waży. Na tejże stronie znajduje się też m.in. ogół informacji o frameworku.

Uwaga: obecna wersja może zawierać błędy i jest bardzo niewydajna. Ponadto wiele materiałów wymaga sprzętu wspierającego conajmniej SM 3.0. Większość znanych usterek i zwiększenie wydajności jest celem wersji 0.2.

Pisanie dokumentacji jest trudne!

2008-08-19T17:57:00.002+02:00

Pisanie dokumentacji to coś, czego bardzo, bardzo nie lubię. Wbrew pozorom jest to bardzo trudna rzecz i trzeba mieć do tego niezwykły talent. Wydawać by się mogło, że skoro jest się autorem kodu to zna się go na wylot i napisanie kilku stron tekstu nie powinno sprawiać problemów. W reczywistości przez tą dogłębną znajomość źródeł ciężko jest postawić się w sytuacji osoby, która nie miała z nim jeszcze styczności, z użytkownikiem. Ciężko jest poczuć się jak "początkujący" i wytłumaczyć dlaczego różne kwestie są rozwiązane tak, a nie inaczej. Jednocześnie dokumentacja nie powinna zawierać wiele więcej poza suchymi faktami, dzięki czemu będzie konkretna, a tym samym znalezienie w niej szukanych informacji będzie łatwiejsze. Powinna też pokazywać rozwiązania typowych problemów (co znowu wymaga przemyślenia co nimi będzie).

Dla mnie ideałem pod wieloma względami jest dokumentacja DirectX SDK. Jest napisana tak, że znalezienie szukanych informacji to kwestia chwili. Zawiera wiele przykładów, tutoriali, tak że i początkujący łatwo mogą zacząć przygodę z DirectXem.

Ja tego poziomu nie osiągnę pewnie nigdy, ale cóż - staram się aby dokumentacja nGENE SDK była jak najbardziej pomocna. Oczywiście nie będzie ona na początku kompletna (nie licząc tej wygenerowanej przez DoxyGena), ale będę ją w miarę upływu czasu uzupełniał.

Cieszy mnie też niezmiernie fakt, że w końcu po długim czasie moje 2 screeny spotkały się z dosyć dobrym przyjęciem na Gamedev.pl, co może oznaczać, że obrany przeze mnie kierunek rozwoju silnika był dobry. Na pewno działa to też mobilizująco.

nGENE 0.1 - ostateczna data publikacji

2008-08-17T18:00:00.001+02:00

W poprzedniej notce napisałem, że nie podałem dotychczas daty publikacji. Teraz to naprawiam: 31.08.2008. Prawdopodobnie sporo wcześniej, ale nie chcę zapeszać. Muszę napisać, bowiem trochę dokumentacji. Kodu już od kilku dni nie dotykam, bo zrobiłem niemal tyle co zaplanowałem. Jedyne czego nie udało mi się zaimplementować to GUI (jest bardzo szczątkowe). Będzie to jednak pierwszy feature, nad którym będę pracował w ramach wersji 0.2.

nGENE - kolejny krok

2008-08-14T18:05:00.007+02:00

Żeby nie było, że jest znowu pewne opóźnienie z publikacją silnika (ale precyzyjnej daty przecież nie podałem, hehe) zamieszczam na zachętę kolejne obrazki. Pokazują one:

poprawione chmury oraz lekko podrasowany teren,
jeden z wielu prostych efektów post-process (sepia)

Na screenach nie ma jeszcze cieni (bo są na tyle proste, że nie ma się czym chwalić...). Pracuję też nad demem (trochę za sugestią Rega), które pokaże przynajmniej część feature-ów.

Deferred shading - pakowanie danych jest złe?

2008-08-13T18:12:00.001+02:00

Stosując deferred shading powszechną taktyką jest tzw. pakowanie danych, czyli umieszczanie kilku atrybutów zajmujących więcej niż jedno pole (tak jak np. pozycja czy wektory normalne aż trzy - x, y, z) w mniejszej ich liczbie. W przypadku pozycji bardzo często wystarczy tylko 1 współrzędna! Tak duże spakowanie uzyskuje się poprzez zapisanie w buforze geometrii długości wektora położenia umieszczonego w przestrzeni widoku.

Tak to miałem rozwiązane również u siebie. Do wczoraj. Boleśnie się bowiem przekonałem, co nie jest odkryciem, że taka kompresja połączona z interpolacją wektora obserwatora w pixel-shaderze musi generować pewne minimalne niedokładności. Zwykle są one niezauważalne. Zwykle. Wczoraj bowiem potrzebowałem pewnej precyzji i okazało się, że to rozwiązanie nie wystarcza. Należy być więc tego świadomym.

Co tam u mnie?

2008-07-30T18:16:00.002+02:00

W ostatnim czasie skupiam się na przygotowaniach do "wypuszczenia" swojego silnika (trochę to trwa...) - poprawiam bugi, wprowadzam drobne optymalizacje (na większe przyjdzie czas w kolejnej wersji), zaczynam pisać tutoriale, pracuję nad GUI. Przygotowuję też wiki, która będzie zawierała istotne informacje na jego temat. Trochę tego jest. Prawdopodobnie wypuszczę jakąś wersję za kilka, kilkanaście dni. Poniżej kilka screenów z aktualnej wersji (więcej w galerii):

Ponadto wziąłem się za pisanie kursu dot. programowania gier, tłumaczę na angielski swoje artykuły zgodnie z sugestią pewnego głównego programisty, rozpocząłem pisanie małej gierki na komórki w ramach relaksu ;)

Projekt amatorski = Projekt bez szans?

2008-07-25T11:26:00.004+02:00

Panuje dziś powszechne przekonanie, że gry mogą być tworzone tylko przez profesjonalne studia developerskie, że amatorzy mogą próbować zrobić tylko coś do swojego portfolio, bo i tak niemal na pewno tego nie ukończą. A nawet jeśli ukończą, to żaden wydawca ani gracz nie zainteresują się tym tytułem, że zginie w czeluściach portali oferujących gry Freeware bądź Shareware. Cóż może wynika to z faktu, że jakieś 50% amatorskich produkcji to cRPG bądź MMORPG...?

Są jednak wyjątki od tej reguły, a najnowszym z nich jest World War 2, gra tworzona przez ten sam zespół co Bitter Glory (od pewnego czasu już beze mnie). World War 2 Road To Victory (bo tak brzmi jej pełny tytuł) jest klasyczną do bólu strategią turową osadzoną w realiach II WŚ. Grą reprezentującą wymierający dzisiaj niestety gatunek, i dlatego też może odnieść jakiś sukces. Gra nie dość, że została ukończona, to trafiła na sklepowe półki! Nabyć ją można w Matrix Games oraz GamersGate.

Więcej o tym "precedensie" można poczytać w odpowiednim wątku na forum Warsztatu.

Moje gratulacje chłopaki! Mam nadzieję, że wkrótce i Bitter Glory będzie można kupić, a także że coraz więcej amatorskich zespołów ukończy swe produkcje.

C.O.R.E. - trailer

2008-07-09T11:35:00.001+02:00

Piszę o tym ze sporym poślizgiem (z drugiej strony - lepiej późno niż wcale), ale gra C.O.R.E. doczekała się wreszcie oficjalnego trailera.

Według mnie prezentuje się całkiem nieźle zważywszy na możliwości konsoli DS.

Jestem już płetwonurkiem P2!!!

2008-07-07T11:40:00.000+02:00

Przez ponad miesiąc nic tu nie napisałem. Dziś też nie będzie jeszcze o programowaniu, na które mam ostatnio mniej czasu (niedawna sesja, praca). Chcę się tylko pochwalić, że od kilku dni legitymuję się uprawnieniami płetwonurka P2 (CMAS 2 Stars Diver). Pozwala mi to m.in. na nurkowanie na głębokość 40 metrów z użyciem powietrza. Jednak przez zakres kursu spoczywa na mnie większa odpowiedzialność za mniej doświadczonych ludzi, z którymi schodził będę pod wodę. Płetwonurek P2 musi umieć pomóc partnerom w opałach, zaplanować im nurkowanie i ten plan zrealizować.

Sam kurs odbyłem w Chorwacji na wyspie Murter. Organizatorem kursu była Moana (baza Nautilusa) i muszę powiedzieć, że poziom oferowanych przez nich usług stoi na bardzo dobrym poziomie. Muszę przyznać, że miałem spore obawy, czy w tak doskonałych warunkach (ciepła i przejrzysta woda) kurs ma jakikolwiek sens. Instruktorzy Moany udowodnili, że kurs da się rzetelnie poprowadzić bez względu na klimat. Jeszcze raz dzięki!

Chmury - jak z 2D zrobić 2.5D?

2008-05-13T11:41:00.004+02:00

W dniu wczorajszym obiecałem, że powiem kilka słów o tym jak uzyskać takie chmury jak mi się udało. Nie są może one rewelacyjne, ale moim zdaniem i tak wyglądają całkiem nieźle. Nie są płaskie, dają pewne drobne wrażenie głębi, a jednocześnie nie są wolumetryczne.

Kluczem jak łatwo się domyśleć jest wykorzystanie 2-wymiarowego szumu Perlina, który pozwala nam na wygenerowania podstawowej struktury chmur. Oczywiście robimy to w tradycyjny sposób zgodnie z tym co napisał Ken Perlin w swojej prezentacji, czyli sumujemy pewną liczbę oktaw szumu z odpowiednimi wagami i częstotliwościami. Im więcej oktaw, tym lepiej. Przynajmniej do pewnego momentu, bo potem okazuje się, że choć wydajność zaczyna nam spadać, tak jakość obrazu w zasadzie nie ulega zmianie.

Niemniej stosowanie szumu Perlina bez jakiejkolwiek obróbki ma jedną podstawową wadę, która dla wielu zastosowań może być dyskwalifikująca - uzyskane chmury są kompletnie płaskie! Nijak oddać za ich pomocą chmur burzowych, czy ogólnie, czegokolwiek poza najdelikatniejszymi obłokami. Na dowód obrazek:

Swego czasu, aby to obejść do tekstury uzyskanej za pomocą szumu Perlina dodawałem (ale dokładnie w jaki sposób - nie pamiętam) wartości kolorów z tekstury będącej zdjęciem prawdziwej chmury, co w pewien sposób pozwalało mi symulować różne typy chmur. Nawet jakoś tam działało.

Na szczęście istnieją lepsze sposoby, które pozwalają nam także na uwzględnienie rozchodzenia się światła w chmurze, a tym samym jej oświetlenie. W rzeczywistości chmura jest skupiskiem wody w różnej postaci (od ciekłej po stałą). Promień światła przechodząc przez każdą z kropel odbija się i rozprasza pod najróżniejszymi kątami, trafia do innej kropli, odbija się, trafia do innej kropli, itd. Promieni jest dużo, kropel jest dużo, więc widać, że nie będzie się tego dało zrobić poprzez implementację stanu faktycznego. Dokonamy bardzo zgrubnego przybliżenia tego scatteringu. Spójrzmy na poniższy rysunek:

Idąc od punktu, w którym umieszczone jest Słońce w kierunku dolnego punktu na chmurze (punkt P) sprawdzamy, czy w danym momencie promień znajduje się wewnątrz chmury (oczywiście przesuwamy się w pętli o jakąś ustaloną jednostkę w każdej iteracji). Zatem nie uwzględniamy faktycznych zjawisk zachodzących w chmurze, a jedynie uwzględniamy jej gęstość w danym punkcie, co pozwala nam oszacować ile światła przejdzie dalej. Aby to uczynić sprawdzamy czy aktualna współrzędna y wektora położenia, jest większa od wartości zapisanej w teksturze wygenerowanej za pomocą szumu Perlina (ale o tym jeszcze za chwilę). Jeśli tak to dodajemy pewną wartość do aktualnej wartości oświetlenia (scatteringu). Wartość ta powinna być pomnożona przez aktualną gęstość chmury (odczytaną z tekstury) dla nieco lepszego efektu. Po dojściu do dolnego punktu promień bezpowrotnie opuszcza chmurę (w uproszczeniu), a tym samym na pewno nic nie wpłynie już na jej kolor. Po zebraniu wszystkich próbek musimy jeszcze jakoś zamienić zebrane dane o oświetleniu na rzeczywisty scattering. Ja robię to za pomocą następującej linii kodu: scattering = 1.0f / exp(scattering * 0.4f);

Jak widać takie podejście jest podobne do wielu efektów operujących na mapie wysokości. W rzeczywistości aproksymujemy w ten sposób jakąś całkę. Jeszcze jedna sprawa, aby uniknąć problemów z aliasingiem ta mapa wysokości (tekstura chmur z szumem Perlina, na której operujemy) powinna składać się tylko z kilku pierwszych oktaw. U mnie jest to 4. Ale zaraz... 4 oktawy to trochę mało i efekt będzie mierny... Zgadza się, dlatego te 4 oktawy należy np. zapisać do render targeta a po ich przetworzeniu dodać do nich pozostałe. I gotowe - do tego wystarczy dodać kolor nieba i mamy fajne chmury.

Dynamiczne chmury

2008-05-12T11:49:00.005+02:00

Dziś skończyłem pisać dynamiczne chmury w oparciu o artykuł z Game Programming Gems 5 oraz o swoje inne z tym doświadczenia. Jutro postaram się wyjaśnić jak coś takiego osiągnąć (a da się jeszcze lepiej), dziś nie mam na to czasu. Poniżej film oraz garść screenów:

Pierwsze próby z HDR

2008-05-11T11:54:00.004+02:00

Zaraz, zaraz... uważam się za człowieka mającego pojęcie o grafice komputerowej i dopiero teraz podjąłem próby wykorzystania tej powszechnej dziś techniki?! I tak, i nie. Nie, bo nie chodzi o programowanie grafiki. Tak, bo poświęciłem kilka godzin wczoraj i dziś na przygotowanie zdjęć z wykorzystaniem właśnie HDR.

O tym, że jest to możliwe pisał też jakiś czas temu Reg na swoim blogu. Pokazał on też w skrócie proces tworzenia tego zdjęcia i przedstawił darmowy programik, z którego sam skorzystałem - Qtpfsgui. Program jest bardzo fajny, pozwala na stworzenie zdjęcia HDR i jego tone-mapping do LDR w bardzo prosty i przejrzysty nawet dla laików sposób. Większość efektów da się osiągnąć zmieniając kilka wartości za pomocą pasków, ale jeśli ktoś wie, co robi ma dużo większe pole manewru - z definiowaniem swoich profili włącznie.

Aby ze zdjęcia można zrobić wersję HDR trzeba tak naprawdę przygotować serię zdjęć różniących się między sobą czasem ekspozycji i pokazujących dokładnie to samo (bez statywu praktycznie nie da razy). Później wystarczy je wczytać, trochę poczekać, od czasu do czasu coś kliknąć i otrzymać rezultat... Poniżej to co ja zrobiłem przez ten weekend:

Brak refaktoringu, refaktoring, a refaktoring pusty

2008-05-05T12:01:00.000+02:00

Natknąłem się dziś na całkiem interesującą (choć dosyć starą) notkę na pewnym blogu. Niestety teraz nie mogę ustalić jego adresu. Otóż jej autor, zwolennik agile development, wprowadził pojęcie null refactoring. Z braku lepszego odpowiednika nazwałem go właśnie tytułowym refaktoringiem pustym.

Cóż to jest za twór? Ano jest to refaktoring, który nie wprowadza żadnych zmian w kodzie. Brzmi dziwnie? W pierwszej chwili - być może tak. Ale po chwili zastanowienia nie powinno to wydawać się już aż tak głupie.

Chodzi bowiem o to, że Agile (szczególnie programowanie ekstremalne) zaleca refaktoring zawsze wtedy, gdy jest to KONIECZNE. Podkreślam słowo konieczne - nie ma potrzeby przerabiania kodu, który jest dobry. Ale co jeśli nie wiemy czy kod jest dobry i czy wymaga refaktoryzacji? Teoretycznie powinniśmy to wiedzieć zawsze, ale teoria nie często w 100% pokrywa się z praktyką. W rzeczywistości często mamy do czynienia np. z sytuacją, że mamy nieczytelny kod, ale za to niesamowicie wydajny. Z jednej strony wskazane byłoby jego przepisanie ze względu na czytelność, ale czy wydajność na tym nie ucierpi? Prawdopodobnie tak. Dlatego programiści przed dokonaniem refaktoryzacji powinni się zastanowić, czy rzeczywiście jest ona niezbędna, wziąć pod uwagę wszelkie za i przeciw (przy czym nie mogą to być rzeczy typu: "lepiej nie będę dotykać tego kodu... na razie działa", czy "nie rozumiem tego kodu i nie mam ochoty się w niego zagłębiać"). Jeśli po takim skomplikowanym procesie myślowym okaże się, że refaktoring w chwili obecnej jest zbędny, to mamy właśnie do czynienia z refaktoringiem pustym. Od kompletnego braku refaktoringu różni się on tym, że dogłębnie przeanalizowaliśmy kod pod każdym kątem i poważnie rozważaliśmy jego refaktoring.

Dla wielu osób to pewnie rzeczy oczywiste, ale dla wielu nie. Zwykle wśród programistów mamy według mnie dwa typy:

tych, co refaktoryzują wszystko, nawet "na siłę"
tych co nie refaktoryzują wcale swojego kodu

Pamiętajmy, więc że optymalne podejście jak zawsze leży pomiędzy dwoma skrajnościami.

Materiały z IGK'2008

2008-04-13T12:03:00.003+02:00

Być może komuś się to przyda. Jest to moja prezentacja z IGK'2008 dotycząca deferred shadingu:

w formacie Power Pointa 2007 lub dla starszych wersji Power Pointa.

Gorąco polecam tę technikę :)

SSAO - wersja 0.99

2008-04-07T12:13:00.003+02:00

Zainspirowany referatami Charibo i Krzyśka K. wygłoszonymi podczas tegorocznego IGK postanowiłem raz jeszcze przyjrzeć się shaderowi odpowiedzialnemu za ten efekt i wyeliminować coś co denerwowało mnie od dawna. Udało się. Poniżej kilka screenów z poprawionej wersji:

IGK 2008 - już po

2008-04-06T12:18:00.001+02:00

Tegoroczna edycja konferencji IGK zapowiadała się szczególnie ciekawie. W końcu to już 5., a zatem jubileuoszowa edycja tej imprezy. Tematy referatów prezentowały się nader ciekawie, co tylko podkręcało atmosferę. Trochę niepokoił fakt, że w agendzie poza CD Projekt Red, nie była wymieniona żadna firma z branży. I nie bez przyczyny. CDPR było bowiem jedyną w tym roku firmą, która na imprezie się zaprezentowała z prezentacją. Nie było ani Microsoftu, ani innych firm z naszego podwórka. Co prawda wśród uczestników byli ludzie i z The Farm 51, Techlandu i NoWay Studio (a no i z nowo powstającego studia Intoxicate Nicolas Games, które jest kontynuacją Intoxicate Interactive i będzie odpowiadać za Afterfalla), ale to jakby nie to samo.

Na szczęcie i bez firm daliśmy radę (choć liczę że za rok będzie inaczej). Większość referatów prezentowała, bowiem dosyć wysoki poziom merytoryczny, można się było dowiedzieć z nich wielu ciekawych rzeczy. Według mnie poziom referatów w tym roku był nawet na wyższym poziomie niż w roku ubiegłym. Było co prawda trochę wpadek merytorycznych (jednostka normal-mapująca rozpaliła wyobraźnię słuchaczy), ale ich liczba była stosunkowo niewysoka. Jestem też w miarę zadowolony ze swojego referatu, choć oczywiście jest nadal kilka rzeczy, które muszę poprawić. Liczę tylko, że wystrzegłem się poważniejszych błędów merytorycznych, no i że prezentacja się na coś komuś przyda. Co do swojego referatu udało mi się zamienić kilka zdań z panem Wojciechem Pazdurem z The Farm 51.

Prezentacja człowieka z Wiedźmina i jego kompanów, też wbrew moim obawom była dosyć ciekawa. O ile nie dowiedziałem się z niej niczego nowego, to podobał mi się jej styl. Nie było wcale aż tak dużo chwalenia się (jedynie kilka ogólnie znanych filmików :) ) i ogólnie fajnie.

Innowacją w tym roku był quiz zorganizowany przez Rega w sobotę wieczorem na wzór Programmers Challange z konferencji GDC. Uczestnicy (Charibo, Koshmar, Ayufan, Artpoz oraz kolega którego nicka niestety nie pamiętam) odpowiadali kolejno na testowe pytania dotyczące programowania (od języków programowania, przez programowanie współbieżne, a na grafice 3D kończąc). Mieli też 2 koła ratunkowe (pytanie do publiczności i pół na pół, które jak się okazało miało w przygotowanej aplikacji dosyć ciekawy feature nieco ułatwiający znalezienie tej poprawnej odpowiedzi :) ). Konkurs rozbawił wszystkich do łez również za sprawą niektórych dosyć humorystycznych odpowiedzi (np. pyt: "Logo jakiej firmy znajduje się na okładce książek z serii GPU Gems?" odp: Coca-cola). Ogólnie mówiąc: dzięki Reg! Szkoda tylko, że to nie orgranizatorzy wychodzą z inicjatywami mającymi na celu ożywić tę imprezę.

Później tego samego dnia odbyło się jeszcze głosowanie nad tematem na compo (wygrał temat: EDITED: "Kanały - raj pod ziemią") i wyprawa do pokojów, gdzie każdy zespół przez większą część nocy prowadził wytężone prace projektowe swojej produkcji.

Niedziela to tradycyjnie compo właśnie. Niestety ja w tym roku nie wziąłem udziału, czego bardzo żałuję. Mam nadzieję, że powstały fajne gierki, które wkrótce będzie można ściągnąć.

Do zobaczenia za rok!

Mam tylko nadzieję, że firm następnym razem będzie więcej. Może poszukajmy też za granicami naszego państwa?

IGK - wreszcie jest agenda

2008-03-31T12:20:00.000+02:00

To co w tym roku zrobili organizatorzy konferencji IGK'2008 można nazwać komedią. Agenda nie była znana do wczoraj, a konferencja zaczyna się już w najbliższy piątek. O ile dla słuchaczy nie ma to aż tak wielkiego znaczenia, tak dla prelegentów już ma olbrzymie - dylemat: robić prezentację, czy nie? Sam o zaakceptowaniu swojego referatu nt. deferred shadingu dowiedziałem się dopiero wczoraj późnym wieczorem... Na szczęście zaryzykowałem i wszystkie potrzebne materiały przygotowałem nieco wcześniej, ale wiem, że niektórzy koledzy nie są jeszcze w pełni gotowi. Szczególnie ciekawie zapowiadają się referaty o optymalizacji pixel shaderów, efektach wolumetrycznych, mechanice płynów, SSAO. Jak widać w tym roku imprezę zdominują silnikowcy (hurra!). Szkoda tylko, że z ekipy Wiedźmina długi referat wygłosi projektant, a nie programista. Może się mylę, ale mam złe przeczucie (poparte innym wykładem człowieka z CDPR odpowiedzialnego za produkcję), że potraktuje to całkowicie od podstaw, z perspektywy graczy.

Niemniej agenda jest dostępna pod następującym adresem.

WMag - ciekawa inicjatywa?

2008-03-29T12:22:00.002+01:00

Przez ostatnie kilka tygodni nie zaglądałem praktycznie na forum gamedev.pl. A tam dzieje się całkiem sporo. Jednym z ciekawszych tematów jest ten dotyczący WMaga - ciekawej inicjatywy autorstwa k_b polegającej na stworzeniu elektronicznego magazynu powiązanego z Warsztatem. Pomysł jest o tyle ciekawy, że po pierwsze podnosi prestiż naszego community, a po drugie dla osób które nie przeglądają go regularnie jest to potencjalnie doskonałe źródło newsów.

Pierwszy numer opisuje Bitter Glory (co prawda dość lakonicznie i do technicznego opisu miałbym pewne zastrzeżenia), Chocritter (never heard of), prezentuje garść nowych screenów (choć myślę, że ostatnio pojawiły się lepsze) i rozmowę z Regiem.

Wszystko fajnie? Nie bardzo. Pierwszy numer zderzył się z pewną krytyką. Według mnie zasłużoną. Na nieprzychylne słowa szczególnie zasługuje słaby layout, marnej jakości screeny (te z projektów Rega są tak niskiej jakości, że na niektórych nie bardzo wiadomo co jest pokazane). Objętość też mogłaby być nieco większa (zwłaszcza, że stron z tekstem jest raptem 5, z czego 1 to wstęp). Ale nie od razu Kraków zbudowano. Liczę, że k_b nie porzuci tej inicjatywy i dostarczy nam kolejne numery, które będą dużo lepsze.

Na koniec link do WMaga.

Wspomnienia - Warsztat

2008-03-03T12:24:00.000+01:00

Swego czasu (rok 2001), gdy dostęp do globalnej sieci w tym kraju nie był zbyt powszechny istniało czasopismo o odkrywczej i wiele mówiącej nazwie "Internet". Tam w jednym z numerów (4/2001, z którego to płytkę dziś "odkopałem") znalazłem zrzucony obraz serwisu, który na swój sposób wychował mnie jako programistę gier: Warsztat (ówczesna oficjalna nazwa to Game Design PL, teraz - gamedev.pl). Sam wówczas dopiero stawiałem pierwsze kroki w programowaniu gier (i w programowaniu w ogóle), niemniej ten serwis zmotywował mnie w jakimś stopniu do dalszej nauki. Oficjalnie należę do community od bodaj 2002 lub 2003 roku (z pewnymi przerwami) - wcześniej tylko czytałem.

Charakterystyczny layout, artykuły dla początkujących i zaawansowanych (a wśród nich te odpowiadające na ponadczasowe pytanie: w czym pisać? jaki język wybrać?), recenzje książek, projekty użytkowników (robiły wrażenie), dział "ludzie", no i wreszcie proste forum... Tak... to były czasy ;) Taki styl na Game Design PL utrzymał się jeszcze przez kilka lat.

Patrząc na Warsztat wtedy i Warsztat teraz, widać jak ogromny postęp dokonał się przez te lata. Zarówno dzięki autorom serwisu, jak i naszemu community. Dzisiejsze community to już nie tylko zapaleńcy, ale także spora grupa zawodowych game developerów, łącznie z naprawdę doświadczonymi i zasłużonymi dla polskiego gamedevu (i niektórymi równie kontrowersyjnymi). Ponadto osobiście uważam, że w ostatnim czasie pojawiło się bardzo dużo uzdolnionych ludzi (niektórych projektów na stronie serwisu nie możnaby się wstydzić nawet na gamedev.net).

Niemniej jakby ktoś był zainteresowany to mogę, ten obraz gdzieś wrzucić (choć przypuszczam, że autorzy serwisu będą mieli nawet późniejsze wersje, w których było już więcej ciekawych rzeczy).

Z innej beczki: ciekawi mnie też rozpiętość opinii na temat wrzucanych przeze mnie tu i ówdzie screenów. Rozrzut opinii jest od pozytywnych po skrajnie negatywne. I nie jest to jednorazowe - poza jednym moim starym screenem (z 2006 roku) jest to w zasadzie normalne zjawisko. Szkoda tylko, że ci co ostro krytykują rzadko podają argumenty przez co nie bardzo wiem, co mam zmieniać na przyszłość.

To tyle... wracam do pracy nad silnikiem ;)

Niebo - wyniki

2008-02-24T12:26:00.002+01:00

Poniżej prezentuję wyniki jakie udało mi się osiągnąć wykorzystując omawiane ostatnio modele oświetlenia.

Teraz biorę na warsztat chmury, później roślinność i w końcu clip-mapping. Jednocześnie biorę się solidnie za optymalizację silnika.

Renderowanie nieba

2008-02-20T12:28:00.001+01:00

Renderowanie nieba i światła rozchodzącego się w atmosferze jest sztuką samą w sobie. Aby realistycznie odwzorować niebo potrzeba uwzględnić dziesiątki najróżniejszych czynników (w tym jak zawsze wszędobylskie cząsteczki, pyły które wszytko komplikują i sprawiają, że światło rozchodzi się nieco inaczej, co doskonale można zaobserwować na przykładzie horyzontu). W związku z tym większość istniejących modeli ma jedynie zastosowanie naukowe. Istnieje jednak kilka takich, które można stosowaś w grach komputerowych, wśród nich dwa szczególnie istotne:

Preethama
Hoffmana

Oba niepozbawione wad (albo mniej eufemistycznie mówiąc - pełne wad). Pierwszy pozwala na uzyskanie w miarę przekonywującego nieba (nielicząc np. wczesnej fazy zachodu słońca, która wygląda nieco sztucznie), ale już kompletnie nie radzi sobie z fenomenem określanym jako aerial perspective (wbrew pozorom bardzo złożone zjawisko; dla znających angielski, czym to jest - haze, taka jakby mgła, zmiana barwy odległych obiektów). Model Hoffmana z kolei daje bardzo dobre aerial perspective natomiast praktycznie nie nadaje się do renderingu nieba (dużą jego część zajmuje jakaś gwiazda-nadolbrzym... to chyba miało być Słońce?). Cóż rozwiązaniem jest oczywiście połączenie obu tych technik.

Ja jednak zastanawiam się czy gra jest w ogóle warta świeczki. Dość dawno temu zaimplementowałem "scattering" nieba w sposób bazujący że tak powiem jedynie na doświadczeniu. Wykorzystując fotografie nieba i terenu stworzyłem 2-wymiarowa tablicę przeglądową zawierającą kolory nieba (na ich podstawie liczyłem z kolei haze) dla różnych pór dnia i punktów nieba (zenit, horyzont i pośrednie). Nie jest to rozwiązanie idealne (ba! jest od niego dalekie), ale jego koszt był praktycznie zerowy (modyfikacja współrzędnych uv co klatkę to naprawdę niewiele). Porównując to z omawianymi wcześniej modelami, wydaje się, że jest to ciekawa alternatywa (w aerial perspective modelu Preethama przekroczyłem liczbę rejestrów dla modelu SM 3.0)...

Ostatnio mam trochę więcej czasu, więc wprowadzam poprawki w silniku przygotowując go tym samym do upublicznienia. Jeszcze trochę ich zostało, ale jest na pewno bliżej niż dalej.

Game Developers Choice Awards a The Witcher

2008-01-31T12:30:00.000+01:00

Dziś oddałem swój głos w plebiscycie Game Developers Choice Awards organizowanym już po raz 8 przez serwis poświęcony branży - Gamasutra. Według autorów tego plebiscytu jest to jedna z najbardziej prestiżowych nagród dla twórców gier...

Ale nie o tym chciałem tak naprawdę pisać. Jako że nie śledziłem wcześniej nominacji zaskoczyła mnie tylko 1 nominacja dla naszego produktu eksportowego, czyli Wiedźmina. Został on nominowany "jedynie" w kategorii Debiut Roku, choć moim skromnym zdaniem zasługuje na nominację jeszcze w kilku innych kategoriach (zwłaszcza Best Writing i Best Game Design, a może również Game of the Year. Czyżby ocenzurowana wersja była aż tak mniej ciekawa ;) ?).

Czy BioShock, Call of Duty 4 czy Mass Effect są rzeczywiście tak dużo lepsze od The Witchera (wszystkie zgarnęły po kilka nominacji - BioShock aż 5)? Nie wydaje mi się. Nawet osławiony Crysis wypadł na tym tle dość blado ("jedynie" 2 nominacje - choć on zasługuje według mnie jeszcze tylko na GOTY). Wszystkie te nominacje dziwią tym bardziej, że plebiscyty graczy w różnych kategoriach wyglądają często jednak inaczej. Czyżby developerzy oceniali gry pod zupełnie innym kątem?

C.O.R.E. - klasyczny FPS na Nintendo DS

2008-01-30T12:43:00.000+01:00

Dziś, po raz pierwszy od dłuższegu czasu odwiedziłem stronę gry C.O.R.E. przeznaczonej na platformę Nintendo DS. Stronka prezentuje się ciekiawie, w tle leci miła dla uszu muzyka, a po screenach widać, że chłopaki wycisnęli z tej niepozornej konsolki więcej niż to możliwe (a w momencie gdy odchodziłem z NoWay Studio gra już wyciskała z konsolki siódme poty). Tak trzymać! Liczę, że gra w końcu ukaże się na półkach i odniesie komercyjny sukces (choć Mario i tego typu "hitów" chyba nie przebije ;) ). Nintendo DS jest ciekawą platformą, na której tego typu gier z pewnością brakuje (podobnie sprawa wygląda ze strategiami i klasycznymi cRPGami).

OpenSource a silnik

2008-01-15T12:46:00.000+01:00

Coraz poważniej biorę pod uwagę opublikowanie aktualnej wersji mojego frameworka na jakiejś otwartej licencji. Na razie raczej ciżko będzie zmodzić na tym jakąkolwiek grę, bo:

zgodnie z zasadą "make it work, make it right, make it fast" optymalizacją się prawie wcale na razie nie przejmuję (czyż Programowanie Ekstremalne nie jest wspaniałe?) :) Dotyczy to zarówno kodu shaderów jak i niektórych rozwiązań w samym silniku. Niemniej chyba w końcu będę musiał do tego przysiąść, bo scenka z kilkoma efektami post-process (w ten sposób są też rozwiązane cząsteczki) i deferred shadingiem potrafi się czasem przycinać nawet na moim nie takim złym sprzęcie (GeForce 8800 GTS, Core 2 DUO 2.33 Ghz i 4GB RAMu).
część rzeczy jest zrobiona na zasadzie wytrychów (co sobie skrzętnie odnotowuję w kodzie). Dość powiedzieć, że rzeczy rozwiązanych inaczej niż docelowo jest w silniku zaznaczonych ponad 100.
w zasadzie na razie skupiłem się na rendererze (jest jeszcze zalążek fizyki opartej o PhysXa) pomijając takie drobiazgi jak dźwięk, obsługa wejścia (jest tylko klawiatura), gui, sieć, skrypty itd.

Z drugiej strony opublikowanie tak wcześnie release'a byłoby w zgodzie z zasadą "make small releases" będącą częścią Extreme Programming. Liczę, że pozwoliłoby mi to na zyskanie pewnego feedbacku ze strony community, co z kolei przyczyniłoby się do polepszenia jakości przyszłych release'ów (chyba tak to się odmieniało Xion?). Dla tych, których ta wiadomość choć trochę ucieszyła jest też trochę gorsza - framework wspiera jedynie karty z minimum SM 3.0 :) (mówiłem już o braku optymalizacji?). Cóż prawda jest taka, że pisząc sobie samemu i to w przerwach miedzy pracą a studiami (albo na odwrót) wielu rzeczy po prostu nie ma czasu zrobić. Najgorsze jest to, że wiele jest dokładnie zaprojektowanych i czeka na lepsze czasy...

Agile - na wesoło

2008-01-12T12:47:00.001+01:00

Czym jest Agile mam nadzieję wszyscy wiedzą z moich wywodów (arty i wypowiedzi na Warsztacie), to że jestem jego entuzjastą też jest wiadome. Chciałbym znów coś o tym napisać, tym razem jednak na wesoło. W związku z tym kilka linków, które szczególnie mi się podobają:

Developer Abuse

AgileAdvert Video Winners 2007 (szczególnie polecam argumentację szefa High Moon Studios ;) )

The Traditional Way

Definicja programowania ekstremalnego

Oczywiście powyższe przerysowują nieco faktyczny stan, jednak nie można im odmówić, że sporo o Agile mówią.

Teksturowanie terenu

2007-12-27T12:49:00.000+01:00

Technik teksturowania terenu jest całe zatrzęsienie, ale większość jest odmianą jednej z następujących (lub ich kombinacji):

diffuse + detail texture - stara i odchodząca dziś w zapomnienie technika polegająca na tym, że cały teren (lub jego fragment) był pokrywany jedną dużą teksturą z pliku graficznego. Aby dobrze to wyglądało tekstura musiałaby mieć olbrzymią rozdzielczość (dużo większą niż było to ówcześnie możliwe). W związku z tym stosowało się teksturę detalu, która była niczym innym jak teksturą szumu.
texture splatting - bardzo popularna w ostatnich kilku latach technika polegająca na tym, że fragmenty terenu pokrywamy jednocześnie kilkoma teksturami, a poziom wymieszania między nimi ustalamy poprzez stosowanie alpha map.
teksturowanie proceduralne - technika o olbrzymim potencjale, coraz częściej stosowana. Przykładowo dla terenu ustalamy kilka tekstur: skał, piasku i trawy. Występowanie danej tekstury można przykładowo uzależnić od wspórzędnej y wierzchołków, od stromizny zbocza, poziomu zerodowania itd. Praktycznie bez ingerencji człowieka (poza doborem parametrów wejściowych) możemy otrzymać zapierający dech w piersiach teren.
clip-mapping - technika autorstwa ludzi z Silicon Graphics, spopularyzowana ostatnio przez Johna Carmacka pod nazwą mega texturing (Quake Wars i Rage). Pozwala na stosowanie wirtualnych tekstur, przez co możliwe jest stosowanie tekstur o rozdzielczości 30k x 30k pikseli, a nawet większych. Sama w sobie jest dość prosta (dla mnie to nic innego jak ewolucja texture atlasów i mip-mappingu), przy czym manualne stworzenie tak wielkich tekstur wydaje się być dość pracochłonne i poza zasięgiem zwykłych śmiertelników. Dlatego najlepiej stosować ją w połączeniu z teksturowaniem proceduralnym (tak zrobił sam Carmack w Tech5). Problemem jest tu na pewno kompresja. Bez niej możemy skończyć z jedną mapą ważącą kilka GB.

Mi osobiście odpowiada tandem clip-mapping + teksturowanie proceduralne i to tę technikę zamierzam zaimplementować w swoim silniku. Uważam, że stosowanie wytartych już technik (do niedawna byłem zwolennikiem texture-splattingu + teksturowanie proceduralne) jest dziś bez sensu, skoro i tak zakładam, że silnik skończę dopiero za kilka lat.

Potęga .NET

2007-12-23T12:50:00.000+01:00

Przez długi czas dzielnie broniłem się przed stosowaniem technologii .NET uważając, że poza C++ niewiele mi potrzeba (zwłaszcza, że .NET demonem prędkości nie jest). Jednak gdy przyszło do pisania poważniejszych narzędzi okienkowych (choćby ostatnio edytor do silnika), stwierdziłem, że średnio nadaje się on do tego celu i zacząłem szukać innego rozwiązania. Tym sposobem zapoznałem się z .NET właśnie. I jestem bardzo zadowolony. Mimo, że połączenie kodu natywnego (.dll z silnika) z zarządzanym (sam edytor) niekoniecznie się Visualowi podoba, wszystko działa bardzo fajnie, a proces tworzenia jest dużo szybszy niż przy użyciu tylko czystego C/C++. Polecam.

nGENE - krótki film

2007-12-01T12:52:00.000+01:00

Dwa wpisy jednego dnia?! Niemożliwe? A jednak ;) Wrzucam króciutki film z mojego silnika. Widać na nim nadal sporo bugów, ale że i tak byłem zmuszony taki filmik wyprodukować więc go upubliczniam:

Artykuł o testowaniu - w końcu!

2007-12-01T11:53:00.001+01:00

Upłynęło sporo czasu od momentu, w którym obiecałem napisać artykuł o testowaniu (dokładnie o unit-testach). W końcu jednak udało mi się go skończyć - jest dostępny tutaj. Mam nadzieję, że jego treść wynagrodzi długi czas oczekiwania (przy okazji dziękuję wszystkim, którzy mnie o ten artykuł nękali - zmotywowaliście mnie do jego ukończenia).

Nowe uprawnienia

2007-11-18T12:56:00.000+01:00

Co prawda wpis w żaden sposób nie związany z programowaniem... ale co tam ;)

Jestem nienormalny... normalny człowiek przecież nie wstaje w weekend o 5 rano, nie bierze ze sobą 30 kg oprzyrządowania i nie jedzie z tym nad jezioro na nurkowanie (temperatura wody i powietrza są zbliżone - i bardzo niskie...). Wykonaliśmy 2 nurkowania i mogę się pochwalić nowymi uprawnieniami: od dziś mogę nurkować z wykorzystaniem Nitroxu (zwyczajowo mieszanina tlenu i azotu o frakcji tego pierwszego powyżej 0.21) oraz suchego skafandra.

Bitter Glory

2007-11-02T12:57:00.000+01:00

Jakiś czas temu zastanawiałem się jak długo wytrzymam bez wykonywania projektu jakiejkolwiek gry (silnik jest jednak czymś zupełnie odmiennym, choćby ze względu na czas realizacji, który niebezpiecznie zmierza do nieskończoności). Moje wątpliwości zostały ostatnio rozwiane. Anraz (szef projektu Bitter Glory) zaproponował mi współpracę, na którą przystałem. W związku z tym w najbliższych dniach przejmę obowiązki głównego programisty tego projektu. Projekt ten jest dla mnie o tyle ważny, że będzie kolejnym dużym przedsięwzięciem (po Kemi-Ambaron, Afterfallu i C.O.R.E.), a także reprezentuje jeden z moich ulubionych gatunków gier. Tym razem zamierzam jednak doprowadzić kod do pomyślnego końca (którym będzie opublikowanie gry - nieistotne jest na razie dla mnie w jakiej formie).

Zatem do zobaczenia na polach bitew II Wojny Światowej!

Zmęczenie

2007-10-11T13:18:00.000+02:00

Niestety w ostatnim czasie zaczął się kolejny rok akademicki (jeszcze tylko 4.5 - na mojej uczelni nauka trwa o semestr dłużej), więc wszystkie moje prace uległy znacznemu spowolnieniu: artykuł o testowaniu jest gotowy w mniej więcej 75% (w zasadzie został jeden rozdział i całkiem liczne poprawki), do silnika dopisałem trochę efektów (wczoraj wziąłem się za Parallax Occlusion Mapping), wprowadziłem w nim wiele poprawek oraz wymyśliłem jak zrobić bez-szwowe przejścia pomiędzy różnymi typami sceny (np. indoor czy outdoor, choć akurat u mnie takie pojęcia nie funkcjonują). Jeśli do tego dodać prace nad Imagine Cup i pracę zawodową... cóż przydałoby się żeby doba miała tak z 48 godzin...

Swoją drogą ostatnio coraz częściej odczuwam pewne zmęczenie programowaniem, często nie sprawia mi to już takiej radości jak to było np. 7 lat temu, gdy pisałem jakieś banalne aplikacje (kalkulator ;) ), ale było to formą niezobowiązującej zabawy. Może po tylu latach spędzonych z kodem jest to normalny objaw (nie wiem jak mają inni), ale jest to jednak z mojej perspektywy dość niepokojące.

Walka o dym

2007-09-29T13:21:00.001+02:00

Coraz bardziej się przekonuję, że od ustawiania parametrów efektów wolę je programować. Około dwa dni walczyłem z ustawieniem parametrów swojego particle systemu, żeby osiągnąć coś co choć trochę przypominałoby dym + ogień (albo odwrotnie). A to dawałem za dużą prędkość cząsteczek, a to za małą. A to za duże przyśpieszenie na jednej z osi, czy zbyt mały spawn rate... Poniżej prezentuję efekty tych zmagań. Gdyby ktoś chciał mnie zapytać czy jestem zadowolony z rezultatów odpowiedziałbym - nie. Na szczęście jeszcze tech dema nie robię, więc efekty nie muszą być powalające. Ponadto w oczy rzuca się kompletny brak oświetlenia na cząsteczkach (dopiero niedługo wezmę się za ich scattering). Nie mówiąc o tym, że widać iż "scenę" przygotowywał niezbyt uzdolniony artystycznie (i bez poczucia estetyki) programista :) Ale żeby nie było, że ten PS jest beznadziejny - nie jest. Pozwala na bardzo wiele (przez przypadek w trakcie walki z dymem stworzyłem wolumetryczne chmury, które całkiem nieźle wyglądały). Choć do jego skończenia nadal potrzebuję kilku dni (ale to już głównie prace wykończeniowe).

Soft Particles

2007-09-14T13:25:00.000+02:00

W ostatnim czasie zrobiłem sobie ponad tygodniową przerwę w kodzeniu mego silniczka. W tym czasie szukałem inspiracji w innych grach, głównie GTA: San Andreas - genialna gierka, mimo nienajlepszej dziś grafiki potrafi przykuć na wiele godzin dziennie.

Dziś powróciłem jednak do programowania i kontynuuję pracę nad systemem cząsteczek. Zdecydowałem się na użycie soft particles (później zamierzam napisać jeszcze soft mega-particles) i powoli zbliżam się do końca tego zadania. Denerwujących przekłamań na krawędziach obiektów sceny już nie ma - pozostaje jedynie danie użytkownikowi większej kontroli nad zachowaniem się cząsteczek (np. siły, obrót).

Dla zainteresowanych - art o testowaniu powstaje, staram się jakoś pogodzić wszystkie sugestie (podstawy i bardziej zaawansowane rzeczy). Mam nadzieję że ta hybryda będzie do strawienia.

Testy, testy i jeszcze raz testy

2007-08-20T13:26:00.000+02:00

W ostatnich dniach do swojego mozolnie powstającego silnika dopisałem masę unit-testów. Choć ich stosowaniu ku mojemu zdumieniu są przeciwni nawet uznani specjaliści naszej branży, to nie potrafię zrozumieć - dlaczego? Testy pozwalają na eliminację potencjalnych bugów w bardzo wczesnym stadium. Tym samym czas przeznaczony na ich napisanie zwróci się z nawiązką w fazie alfa czy beta-testów - pozwoli zaoszczędzić czas wielu osób, które zamiast szukać przyczyny często błahego problemu, będą mogły zająć się szlifowaniem elementów gameplayu czy silnika. Sam dzięki testom wyeliminowałem kilka błędów, które choć teoretycznie nie należały do najbardziej druzgocących, z pewnością przyczyniłyby się do powstania trudno wytłumaczalnych artefaktów.

Ponadto za namową kolegi zdecydowałem się wziąć udział w Imagine Cup 2008 w drużynie startującej w kategorii Software Design. A co - trzeba próbować nowych wyzwań ;)

Deferred shading - problematyczny?

2007-08-04T13:28:00.000+02:00

W ostatnim czasie implementowałem w swoim silniku deferred shading (albo lighting, jeśli ktoś woli taką nazwę, albo rendering :) ). Do wczoraj byłem święcie przekonany, że jest to powszechnie stosowana technika, jednak wątek zachwiał moją wiarę w tę tezę. Prawda, że momentami może być problematyczny (zasobożerność, fill-rate bound, problematyczny AA), jednak nadal sądzę, że oferuje on dużo dobrego jeśli tylko dać mu szansę (wydajność i jakość oświetlenia, nie burzy fazy post-processingu). Swoją drogą coraz częciej podejrzewam, że Reg celowo rozpoczyna takie tematy, byle podnieść poziom dyskusji na forum ;)

Magia refaktoringu...

2007-07-20T13:29:00.000+02:00

Każdy chyba programista wie, że w niektórych sytuacjach refaktoring jest konieczny. Mimo to bardzo wiele osób boi się go jak ognia, wykorzystując każdą sytuację, aby go nie wykonać. Po co zmieniać kod, który działa? Nieważne jak (a może tylko dla pewnych określonych danych?), ale działa... A dzięki refaktoringowi nasz kod nie dość, że staje się bardziej czytelny, to z dużym prawdopodobieństwem usuniemy z niego przynajmniej część bugów. Ja jakiś czas temu tego typu obaw się wyzbyłem, dzięki czemu pewien fragment swojego silnika refaktoryzuję 3. raz w ciągu kilku ostatnich tygodni. Cóż - patrząc na road-mapę będę to przerabiać jeszcze conajmniej 2 razy ;)

Engine

2007-07-19T17:12:00.001+02:00

Tworzona przeze mnie w ostatnich miesiącach biblioteka powoli nabiera cech, które wkrótce pozwolą ją nazwać pełnoprawnym enginem (liczę, że jeszcze w tym roku ;) )... nie, nie rendererem - jest to znacznie więcej. Screenów oczywiście jeszcze brak (bo kogo obchodzi kilka testowych brył z przypisanymi pierwszymi lepszymi teksturami?) i pewnie szybko się to nie zmieni.

W ostatnich tygodniach podjąłem pracę w webdevie (programuję w Ruby on Rails) i muszę przyznać, że spodobało mi się to na tyle, że czasem zapominam sobie pokodzić grafiki. No, ale język (Ruby) i framework (Rails) sprawiają, że development jest niezwykle prosty, efektywny, a przez to przyjemny. Dużo przyjemniejszy niż w C++, który pozostaje coraz bardziej w tyle za nowoczesnymi językami programowania, co ta praca mi uzmysłowiła.

Pracowite wakacje

2007-06-18T17:11:00.001+02:00

Tegoroczne wakacje zapowiadają się na jeszcze bardziej pracowite niż zeszłoroczne, kiedy to ostro pracowałem nad Afterfallem i designem swego nowego silnika. W tym roku poza regularną pracą mam zamiar dalej pracować nad implementacją swojego engine'a. Do tego dochodzi całowakacyjne Compo - niekomercyjny konkurs dla programistów gier skupionych wokół Warsztatu. Konkurs startuje już na dniach, a ja ciągle nie mogę się zdecydować jaki projekt wykonam. Mam nadzieję, że wybiorę ten właściwy.

Ostatnio zacząłem też pisać kolejny tekst. Ten jako pierwszy będzie dotyczył tego, co lubię najbardziej - programowania grafiki. Omówię w nim technikę znaną jako shell and fin texturing powszechnie wykorzystywaną do tworzenia futra, ale którą z powodzeniem można też wykorzystać np. do stworzenia realistycznie wyglądającej trawy.

Artykuł o programowaniu ekstremalnym

2007-06-10T17:09:00.001+02:00

Czym jest programowanie ekstremalne, jakie płyną z niego korzyści i jak je stosować przeczytasz w finalnej wersji mojego artykułu dotyczącego tej metodologii.

Ponadto sesja, więc czasu na kodzenie zbyt wiele nie mam, ale wkrótce sobie odbiję.

Koniec z gamedevem?

2007-06-02T17:07:00.001+02:00

Ten tydzień przyniósł dość zasadniczą zmianę w moim życiu i karierze programistycznej. Wraz z 1. czerwca przestałem pracować jako programista gier w QubicGames (a raczej w formowanym podstudiu o nieco odmiennej nazwie). Co więcej był to mój świadomy wybór, umotywowany powodami, których tu nie ma na razie sensu zdradzać. Wiem, że dla wielu osób praca w branży to już cel sam w sobie. Tym bardziej dziwić może je moje postępowanie.

Moje odejście z firmy nie oznacza oczywiście, że zrywam z gamedevem całkowicie. Nie. Nadal z pewnością będę pisał jakieś amatorskie gry i rozwijał swój silnik z zamysłem powrotu do branży w tej czy innej roli w przyszłości.

Z tego miejsca chciałbym również podziękować za wspópracę całej ekipie QC, w tym przede wszystkim osobom, z którymi pracowałem od roku - najpierw nad Afterfallem, a później w QubicGames właśnie. Była to fajna zabawa i liczę, że kiedyś jeszcze się w branży zetkniemy (ale mam nadzieję, że nie będę wówczas gameplayowcem ;) ).

Depth of Field

2007-05-26T16:59:00.001+02:00

Ostatnio wiele czynników sprawiło, że nie miałem zbyt wiele czasu na zajmowanie się stroną, a nawet na programowanie swego silnika (nie mówiąc o dokończeniu arta). Nie oznacza to jednak, że przez te dni nie powstało nic nowego - biblioteka materiałów i obsługa shaderów w silniku są już niemal ukończone.

Ponadto w ostatnich dniach napisałem efekt, do którego zakodowania przymierzałem się od dawna - Depth of Field. Prosty, a zwiększa wrażenia wizualne i skupia uwagę na konkretnym elemencie sceny. Piękno mojej implementacji polega na tym, że jest wykonywana całkowicie jako efekt post-process (w odróżnieniu od większości implementacji wykonujących ten efekt per object/surface), dzięki czemu jego wydajność jest bardzo duża. Poniżej załączam screen:

Dalsze poprawki i nowy artykuł

2007-05-04T16:55:00.002+02:00

W dalszym ciągu pracuję w ostatnich dniach nad kodem strony. Jako, że niezbyt się na tym znam, idzie średnio. Grunt, że jakoś działa ;)

W wolnej chwili zacząłem też pisać nowy artykuł, dotyczący programowania ekstremalnego. Jego wstępną wersję można znaleźć tutaj.

Jednak największym osiągnieciem tego długiego weekendu jest dodanie serializacji obiektów do tworzonego przeze mnie silnika, a także rozpoczęcie prac nad edytorem typu WYSIWYG do niego.

Poprawki

2007-04-22T16:53:00.003+02:00

W kodzie strony poprawiłem sporo mniejszych bugów. Ponadto poprawiłem kilka rzeczy na stronie, które podniosły jej estetykę.

Start mojej strony

2007-04-18T16:47:00.002+02:00

Po wielu nieudanych próbach... w końcu jest - moja strona domowa. Na razie nie ma tu wiele materiałów, ale postaram się sukcesywnie zwiększać ich liczbę. Ponadto wiele rzeczy wymaga poprawienia.

Nurkowanie

2001-01-01T20:24:00.012+01:00

Moja przygoda z nurkowaniem rozpoczęła się niespełna 4 lata temu, ale więcej nurkować zacząłem dopiero w ostatnich dwóch latach (zasługa w tym bardzo fajnej ekipy).

Trochę danych:

Organizacja macierzysta: KDP CMAS/TDI
Aktualne uprawnienia:
Advanced Nitrox TDI
Decompression Procedures TDI

KDP CMAS P2 (odpowiednik AOWD + Deep + Rescue + Nawigacja z innych federacji)
PL1 - płetwonurek podlodowy
PN1 - płetwonurek nitroksowy
WM1 - płetwonurek wrakowy
SS1 - płetwonurek uprawniony do nurkowań w suchych skafandrach
Ratownik EFR (pierwszej i dalszej pomocy przedmedycznej)
Zaawansowany ratownik tlenowy DAN

Ulubione miejsce nurkowe: Bałtyk
Ulubione nurkowisko: wrak Thistlegorm, Egipt
Ulubiona forma nurkowania: nurkowania wrakowe
Wykonanych nurkowań: ok. 130
Członek Safe Water Association (SWA)
O zdjęciu: zdjęcie wykonane po skończonym nurkowaniu w zalanym forcie w pobliżu Krakowa w ramach warsztatów jaskiniowych wg szkoły francuskiej, które prowadzone były przez Michała "Majkiego" Winka z XDiversTeam

Aktualnie staram się podnieść swoje kwalifikacje nurkowe nieco powyżej standardów typowo rekreacyjnych. Zobaczymy jak to wyjdzie :)