Zastanówmy się, w jaki sposób można wykorzystać preprocessor bardziej po cwaniacku. Weźmy pierwszą lepszą konstrukcję, która może się wydawać przydatna przy pisaniu kodu:

Obj *obj = getObj();
if(obj!=NULL){
    obj->doSomething();
}

Sprawa jest bardzo prosta, można by zautomatyzować odrobinę to sprawdzenie przez napisanie prostego makra:

#define ifNotNull(p) if(p)p

Od tej pory możemy napisać:

ifNotNull(getObj())->doSomething();

A teraz zastanówmy się nad potencjalnymi problemami. Oczywiście dobrą praktyką jest branie wszystkiego w nawiasy, chodź w tym przypadku trudno jest wykorzystać makro nieprawidłowo. Jest jednak większy problem. Co z sytuacją, gdy programista uwielbia konstrukcje anty-RISC i spróbuje podać bardziej skomplikowane wyrażenie jako parametr makra? Kod zostanie wykonany tyle razy, ile razy się pojawia w makrodefinicji, tj. w naszym przypadku 2.

Otóż dochodzimy do cwaniackiego rozwiązania. Wykorzystamy nieco bardziej egzotyczne elementy języka, mianowicie aktualną linię (__LINE__), operator sklejania (##) i automatyczne dobieranie typu zmiennej (auto) będące częścią nowego standardu C++. Definicja __LINE__ jest zastępowana aktualnym wierszem w kodzie, a więc możemy ją wykorzystać do zadeklarowania dowolnej zmiennej o dosyć bezpiecznym identyfikatorze. Bezpiecznym, tj. unikatowym w najbliższej okolicy. Dopóki jesteśmy w tym samym wierszu, możemy swobodnie używać tak stworzonego identyfikatora do naszych potrzeb. Najważniejszą potrzebą jest zapisanie wyniku potencjalnych obliczeń przekazanych jako argument:

#define ifNotNull(p) auto *s##__LINE__=p;if(s##__LINE__)s##__LINE__

Co się dzieje? Oczywiście nie działa. A dlaczego? Bo operator sklejania bierze __LINE__ jako tekst o treści ‘__LINE__’ i dokleja go do ‘s’ tworząc ‘s__LINE__’.  Winny jest operator sklejania, a do obejścia tego problemu trzeba wprowadzić dwa dodatkowe makra opakowujące konkatenację. Uprzedzając pytanie – jedno nie wystarcza. Teraz mamy tak:

#define CONCATENATE(x,y) x##y
#define CONCATENATE2(x,y) CONCATENATE(x,y)
#define ifNotNull(p) auto *CONCATENATE2(s,__LINE__)=p; if(CONCATENATE2(s,__LINE__)) CONCATENATE2(s,__LINE__)

Uff, wreszcie działa. Makro wygląda fatalnie, pewnie ma jakiś trudny do znalezienia błąd, a już na pewno nie jest idiotoodporne, ale przecież nie o to chodzi. Chodzi o zasady i cwaniactwo.

Edit:

Spróbujmy jeszcze naprawić sytuację podaną przez Xiona. Jeśli ktoś spróbuje użyć naszego makra w warunku, albo pętli bez nawiasów, to oczywiście drugi wiersz wypada poza warunkiem i się nie skompiluje ze względu na brak zmiennej w zakresie. Dadawanie nawiasów klamrowych nie rozwiązuje problemu ze względu na wystawianie zmiennej poza makro. Na szczęście poprawka jest bardzo prosta:

#define CONCATENATE(x,y) x##y
#define CONCATENATE2(x,y) CONCATENATE(x,y)
#define ifNotNull(p) if(auto *CONCATENATE2(s,__LINE__)=p) CONCATENATE2(s,__LINE__)

Co mądrzejsze narzędzie oczywiście zwróci nam uwagę, że w warunku mamy przypisanie zamiast porównania. Jeszcze jakieś pomysły na zepsucie makra?

Przede wszystkim chciałem, żeby podmiana zasobów nie pauzowała całego programu. W momencie, gdy zmieniany jest duży zasób, jego czas ładowania może być znaczący, a wtedy użytkownik zobaczy nieprzyjemną ścinkę. To oznacza, że zasoby powinny być ładowane w tle w oddzielnym wątku. A to z kolei oznacza konieczność synchronizacji. Sam moment przeładowywania zasobu można w głównym wątku obsłużyć np. przez zastąpienie zasobu domyślnym, albo jego pominięcie.

Po drugie wszystkie zasoby są trzymane przez inteligentne wskaźniki. Co prawda ich inteligencja miałaby równe szanse w zawodach z gąbkami, ale swoje zadanie spełniają – każdy zasób jest ładowany tylko raz. Podmiana wskaźnika w miejscu renderowania nic nie daje, bo poprzednia wersja zasobu jest widoczna, dopóki w programie znajduje się choć jedno odwołanie. To sprawia, że konieczne jest przeładowywanie obecnych zasobów. A to z kolei oznacza, że każdy moduł oprócz uzyskania dostępu do zasobu musi również sprawdzić, czy zasób jest gotowy do użytku.

Trzecia rzecz, to uruchamianie przeładowywania. Moim celem było zautomatuzowanie całego procesu od początku do końca, a więc również wykrywanie modyfikacji dokonywanych w plikach przez programy zewnętrzne. Do tego celu użyłem zdarzeń systemowych pozwalających na wykrycie działań użytkownika na plikach w określonym folderze. Mimo że nazwa ‘zdarzenia’ sugeruje informowanie asynchroniczne, trzeba sobie ten mechanizm napisać samemu używając kolejnego wątku. Uff.

Mechanizm edycji zasobów na gorąco wymaga bardzo dokładnego przemyślenia ze względu na liczne problemy, które mogą wystąpić po drodze:

• Co, jeśli użytkownik w ogóle usunie zasób? W moim przypadku zasób jest ustawiany na nieprawidłowy i czeka w systemie na ponowne wczytanie. Takie zachowanie było najszybsze do napisania ze względu na budowę zasobów w Ghurund. Poza tym pozwala na częściowe działanie większych zasobów, których część zostanie usunięta.
• Co, jeśli struktura zasobu zostanie zmieniona na tyle, że logika programu nie będzie w stanie go obsłużyć? Wtedy program powinien przestać działać. Po prostu. Jeśli zmieniamy model gracza tak, że nie ma on już broni, z której może strzelać, to program może albo zabronić strzelania w ogóle, albo strzelać z innego miejsca. Ważne, żeby sprawdzać błedy i starać się odpowiednio reagować. Poza tym część zmian można przewidzieć, np. materiały w Ghurund mają część parametrów zapewnionych automatycznie i zostaną dodane, gdy tylko będą potrzebne.
• Co, jeśli od przeładowywanego zasobu zależy inny? To ma miejsce np. w przypadku fizyki, gdzie bryła fizyczna jest generowana z siatki modeu. Tu należałoby stworzyć system powiadomień, ale to przedsięwzięcie jest dosyć duże.

Oczywiście należy się zastanowić, na jak dużą ingerencję pozwalamy. Jeśli zmiana będzie naprawdę poważna, program może się też po prostu wywalić. Przecież nie chodzi o to, by gra sprawdzała każdą możliwą sytuację, a użytkownik silnika powinien być tego świadom. Edycja istotnych elementów świata może wymagać zrestartowania całej aplikacji.

Edycja zasobów na gorąco to świetna sprawa i znacznie przyspiesza testowanie zasobów, ale jej poprawne napisanie, to straszny ból. Dokumentacja do funkcji sprawdzania zmian w folderach jest kiepska, synchronizacja utrudnia debugowanie i spowalnia program, a samo wczytywanie nagle staje się bardzo rozdmuchane i trudno się połapać we własnym kodzie.

Obecny użytkownik komputera i komórki jest tylko trochę inteligentniejszy od krzesła na którym siedzi. Co prawda to założenie jest dosyć odważne, bo oczywiście ludzi inteligentnych jeszcze zupełnie nie zabrakło, ale okazuje się, że i do nich da się zastosować takie podejście. Zacznijmy od początku. Na pewno każdy z nas słyszał o ustawianiu produktów w sklepach, tak, żebyśmy kupili jak najwięcej i jak najdrożej. Albo reklamy. Na jednym obrazku łączy się wybitnie męskiego mężczyznę, małe pieski, drogi zegarek i browar. Po obejrzeniu takiej reklamy w mózgu kobiety podobno pojawia się przekonanie, że facet pijący ten właśnie gatunek piwa jest męski, delikatny, oraz ma kasę i styl.

Pewne podświadome zależności zachodzą w mózgu również podczas używania komórki, internetu, czy komputera. Po pierwsze, jeśli produktu używa się swobodnie, bez zastanawiania się nad przeznaczeniem elementów interfejsu, to automatycznie bardziej doceniamy produkt. Zwłaszcza, że jeśli umiemy używać czegoś bez instrukcji, to czujemy się mądrzejsi i szybko zaczyna się nam to podobać. Z drugiej strony, nawet jeśli najnowsza gra ma fotorealistyczną grafikę, wciągającą fabułę, głęboki dźwięk, a przerywniki filmowe wciskają w fotel, a podczas gry postać cały czas się ślizga po terenie zamiast chodzić, albo ptaki latają po łamanej zamiast po krzywej, to mózg nam podświadomie zgłasza, że coś jest nie tak. Taka gra nigdy nie dostanie najwyższej noty, bo subiektywna ocena, jaką jest przyjemność z grania, wychodzi zbyt niska.

Teraz, gdy rynek podbijają komórki z ekranem dotykowym, a producenci konsol prześcigają się w tworzeniu różnych kinectów, dążenie do tego, by obsługa produktu była jak najbardziej naturalna, jest jeszcze ważniejsze. Jeśli użytkownik może pociągnąć za listę palcem, to spodziewa się reszty interakcji, którą może spotkać w świecie rzeczywistym, czyli chwytu, rzutu, oraz tarcia i odbicia przy zatrzymywaniu się listy. Do tego dochodzą różnego rodzaju losowe ruchy, drgania, a także szereg efektów graficznych, takich jak cień rzucany przez kontrolkę leżącą nad inną, czy gradient oznaczający wypukłość. Oczywiście to są drobiazgi, ale ich właściwe zastosowanie decyduje o odczuciach użytkownika, a więc o sukcesie produktu i wielkich zyskach ze sprzedaży.

W grach coraz trudniej zauważyć takie braki, ponieważ z coraz szerszym wykorzystaniem silników fizycznych i coraz lepszą grafiką gry po prostu stają się żywe i cały świat jest dobrze rozpoznawalny. Poza tym twórcy gier mogą sobie pozwolić na umieszczenie tutoriala i wyjaśnić wszystkie niejasności. W świecie flashowych reklam i aplikacji mobilnych nie ma tych luksusów. Gry na konsole też zwykle są robione tak, by tutorial był zbędny ze względu na odbiorców.

Na prezentacji można było zobaczyć kilka przykładów dobrego i złego designu, oraz poznać sposoby obsługi użytkownika (tak, tak, to nie użytkownik obsługuje urządzenie, a raczej producent obsługuje użytkownika przy użyciu urządzenia). Jej treść można pobrać tutaj.

Swoją drogą ciekawi mnie, ile osób zwróciło uwagę na to, że sama treść prezentacji zawierała kilka elementów sprawiających, że jej odbiór teoretycznie powinien być lepszy. Wygląd był prosty i nie rozpraszał animacjami, czy kolorystyką. Nie było agendy, ani całkowitej ilości slajdów. Animacje były zrobione tak, by odbiorca nie zaczynał czytać reszty slajdu, zamiast słuchać. Screenshoty miały dodany cień i nakładały się w odpowiedni sposób sugerując ważność i nadając pewną wypukłość. Ciekawym takich zagrywek polecam przedmiot Techniki Prezentacji na EiTI.

Najpierw oczywiście trzeba się zastanowić, dlaczego goto może być złe. Jak to się mówi ładnie, przyjaciół trzymaj blisko, a wrogów jeszcze bliżej (żeby móc ich powstrzymać, rzecz jasna), a tu przecież mówimy o wymyśle z czeluści piekieł. Narzędziu do tego stopnia  złym, że funkcjonuje w Javie jako słowo kluczowe bez implementacji, tj. jest zastrzeżone, ale nie da się go do niczego użyć.

Przede wszystkim skoki z użyciem goto mogą być znacznie swobodniejsze, niż break/continue, czy zwykłe zakończenie pętli. Dzięki temu możemy wyskoczyć z kilku pętli, czy cofnąć się w wykonaniu programu. To sprawia, że bardzo łatwo przeoczyć istotny fragment kodu i przeskoczyć inicjalizację, bądź deinicjalizację jakiejś zmiennej. Oczywiście to najczęściej powoduje wysypanie się programu, a piekielni twórcy goto śmieją się wtedy z programisty ile mają tchu w płucach.

Druga sprawa, to czytelność kodu. Goto pozwala na swobodne skoki, więc wykonanie programu może nagle pójść zupełnie inaczej. Dla procesora to i tak wszystko jedno, czy skok wykona w wyniku użycia break, czy goto, ale programista czytający kod nagle staje przed niebanalnym zadaniem. Wszystko, czego się nauczył o możliwościach sterowania przepływem programu może wsadzić sobie w… do śmietnika, bo tu jest wolna amerykanka. Skok nie kończy się na następnej klamrze, w poziomie wyżej, czy w następnej metodzie, ale w dowolnym miejscu kodu oznaczonym etykietą.

Oczywiście puryści i znawcy C++ poprawiliby mnie, jeśli chodzi o zasady działania goto, albo wymienili rzeczy, które dzieją się, lub mogłyby się dziać przy przeskakiwaniu nawiasów klamrowych. Wymieniłem raczej idee, którymi kierują się hejterzy, niż dokładne zasady działania. A teraz do czego goto może być przydatne?

Przede wszystkim do kończenia pętli, najczęściej wielopoziomowych. Ciekawym przykładem jest wykonywanie operacji, jeśli warunek nie zostanie spełniony dla żadnej z iteracji. Poniżej przykład dla jednopoziomowej pętli, która wykonuje operację tylko, jeśli obiekt nie został znaleziony w kolekcji.

for (int i=0; i<list.size; i++) {
    if(list[i]==value)
        goto found;
}
list.add(value);
found:

Przykład jest banalny i można go obejść na dziesiątki sposobów. Najprostsze dwa to użycie flagi, albo napisanie metody listy do szukania elementu. Jeśli jednak warunek się skomplikuje, użycie goto może być znacznie bardziej przejrzyste i ograniczyć ilość kodu potrzebną do uzyskania właściwego rezultatu. Przykład drugi:

if(!initGraphics(buffers))
    goto cleanUp;
if(!initInput(buffers2))
    goto cleanUp;
print("initialization done");
cleanUp:
delete[] buffers;
delete[] buffers2;

Drugi przykład jest wzorowany na przykładach do DirectX. Tam większość inicjalizacji wygląda w ten sposób – sprzątanie, które jest wykonywane niezależnie od rezultatu wywoływanych metod, jest wykonywane na końcu po etykiecie, do której można skoczyć, gdy wiadomo, że już nie uda się zainicjalizować tego fragmentu aplikacji. Oczywiście można się uprzeć, że i tu da się obejść goto, np. z użyciem RAII. Niemniej jednak okazuje się, że są miejsca, gdzie goto jest użyteczne i można się pokusić o jego użycie. Trzeba tylko pamiętać o zasłonieniu klawiatury i monitora łokciem.

Swoją drogą warto zauważyć ciekawą implikację, która się urodziła po drodze. Goto jest wymysłem i narzędziem piekielnym, a Microsoft go używa. Wiadomo więc, skąd pochodzą.

Buforowanie danych nie jest niczym nowym. Dysk buforuje zapisy i odczyty, procesor ma cache, uczeń trzyma najczęściej używane przybory w plecaku, a zakochany facet ma swoją wybrankę wpisaną pod ‘aaaa’+imię, żeby było ją łatwo wybrać. Generalnie każdy buforuje wszystko, co się tylko da, czasem nieświadom tego ciekawego działania. Pisząc silnik graficzny oczywiście chce się zmieścić jak najwięcej w pamięci karty, a najlepiej w ogóle wszystko w jednej teksturze, czy innym buforze, żeby nie przełączać nawet pojedynczego wskaźnika niepotrzebnie.

Drugą rzeczą oczywistą dla twórców silników jest wstępne przetwarzanie danych. Dane duże przygotowywuje się w zewnętrznym programie, a mniejsze podczas wczytywania. Każdy model ma mieć od razu policzone normalne i styczne, a każda tekstura ma być sparowana z odpowiednią mapą przemieszczeń. Do tego PRT, lightmapy i skompilowane shadery. Podczas wykonywania głównej pętli nie robi się nic niepotrzebnego. Najszybsze operacje, to takie, których nie trzeba wykonać podczas wykonania programu, a więc również te, które udało nam się wykonać wcześniej i zapisać częściowy rezultat.

Jednym z popularniejszych efektów ubocznych obu tych idei jest zrzucanie pamięci GPU na dysk. Taki format danych jest najlepszy, bo jego wczytanie jest banalne, dane nie wymagają przetworzenia przed wykorzystaniem przez kartę graficzną, a przy okazji nikt nam nie grzebie w plikach, bo to w końcu nie xml. Oczywiście przy okazji pojawia się pośrednie buforowanie, tj. w pamięci RAM trzymana jest kopia w razie braku pamięci GPU. Dzięki tej właśnie sprytnej idei zdziałałem ostatnio galerię na wymieniony wcześniej system – Androida.

Pomysł jest dosyć karkołomny, jeśli chodzi o typowe podejście androidowca. Otóż pamięci na stercie aplikacji jest za mało, żeby trzemać w niej wszystkie obrazki, a wczytywanie podczas działania powoduje poważne opóźnienia, nawet, jeśli wczytujemy w oddzielnym wątku. Większość urządzeń ma znaczną ilość wolnej pamięci RAM, która jest niedostępna z poziomu Javy, ale można ją zaalokować z poziomu biblioteki natywnej i tam trzymać bufor danych, które nie mieszczą się na stercie aplikacji. Widać analogię? Dane trzymane w cache wczytuje się znacznie szybciej, a sam bufor jest na tyle duży, że pomieści kilkukrotnie więcej danych. Wczytujemy do bufora pliki i w ten sposób uzyskujemy superszybki, wielowątkowy system plików.

Dalej oczywiście można dane wstępnie przetworzyć, tak, by przeniesienie interesującego nas fragmentu bufora do pamięci aplikacji było jak najmniej obciążające. W przypadku galerii będą to poszczególne piksele. Zysk jest o tyle widoczny, że obrazki zwykle trzymamy w formie skompresowanej ze względu na rozmiar, a standardowe metody rysujące nie są w stanie posługiwać się bezpośrednio formatem innym niż RGBA8. Szczęśliwie bitmapa trzyma piksele w postaci natywnej, więc przeniesienie danych między pamięcią aplikacji a buforem to kwestia jednego memcpy.

W ten sposób trafiliśmy do domu. Jeśli ktoś się porywa na tworzenie dużych, wybajerzonych aplikacji na urządzenie, które ma 16 MB pamięci, to musi się spodziewać pewnych nieczystych zagrań i kombinacji. A kto się na tym lepiej zna, niż programiści gier?

Bardzo prosto. Najważniejszy jest jeden trik. Wartości ustawiane w wierzchołkach są interpolowane przed wejściem do pixel shadera. Jeśli zmienna będzie miała tę samą wartość dla dwóch wierzchołków (np. 1), a inną dla trzeciego wierzchołka (np. 0), to łatwo można stwierdzić, czy rysujemy właśnie piksel należący do odcinka łączącego pierwsze dwa wierzchołki porównując odczytaną wartość z zapisaną dla tych wierzchołków.

Mamy trzy odcinki i do ich oznaczenia możemy wykorzystać trzy składowe jakiegoś wektora przekazywanego do pixel shadera. Wartości dla wierzchołków można wygenerować w locie. Geometry shader dysponuje informacjami o trójkątach, więc bez problemu jest w stanie stworzyć trzy pary i dodać wymagane informacje.

Do sprawdzenia wartości piksela używamy funkcji any(float3). Jeśli wektor zawiera choć jedną wartość niezerową, zwraca true, tj. właśnie rysujemy krawędź. Oczywiście wartości trzeba sobie odpowiednio sprogować. I pikczer na koniec.

Przetwarzanie obrazu cierpi na szereg ułomności związanych ze złą jakością grafiki źródłowej, teksturami, szumem, czy głębią ostrości. Dla przykładu rozpoznawanie krawędzi postaci ludzkiej ubranej w koszulę w kratę jest zajęciem dla zaawansowanego masochisty mieszkającego za kręgiem polarnym. Otóż wstępnie taki obraz należy przetworzyć (wzmocnić, wyostrzyć, usunąć szum), następnie zastosować algorytm segmentacji świadomy istnienia tekstur, a następnie przetworzyć segmenty na krawędzie obrysu. Większość zastosowanych tu algorytmów może być podstawą pracy magisterskiej.

Przetwarzanie obrazu zajmuje się też mniejszymi krokami, tj. produkcją i zastosowaniem rozmaitych filtrów służących np. do poprawy jakości zdjęć. Obraz można wzmacniać, wyostrzać, rozmywać, zmieniać kontrast i jasność, zmieniać kolory, oraz robić masę ciekawych rzeczy prowadzących do zupełnie nierealistycznych rezultatów. Wszystko to pięknie wygląda w teorii, ale w praktyce mało który filtr daje naprawdę dobre wyniki dla różnych przypadków. Przykładowo wyostrzanie zupełnie nie nadaje się do poprawy ostrości zdjęć zawierających elementy o różnej ostrości. Powód jest bardzo prosty – przetwarzane obrazy zawierają niewielką ilość informacji. W zasadzie nie wiadomo nic o głębi, granicach między obiektami, elementach zasłoniętych, oświetleniu, położeniu obiektywu, czy scenie. Dokładnie znane są tylko kolory poszczególnych pikseli. Dlatego też można zmienić jasność, ale nie można zmienić oświetlenia. Można wyostrzyć i rozmyć obraz, ale nie można zmienić odległości na którą skupiony jest obiektyw. Można zmienić kolory, ale nie można zmienić właściwości optycznych materiałów. Jednym słowem lipa.

Dlatego właśnie przetwarzacze lekko nie mają. A kto ma lekko? Oczywiście ten, kto przetwarza obraz, którego jest autorem. Mowa oczywiście o programistach grafiki i efektach przetwarzania końcowego (ang. postprocess) służących do rozmaitych operacji na obrazie generowanym przez wszelkie silniki, frameworki, devkity i inne mądre kawałki kodu. Obraz generowany przez komputer najczęściej jest idealnej jakości w sensie przydatności do przetwarzania. Wszystkie kolory, krawędzie, tekstury, czy jasności są dokładnie takie, jakich życzył sobie autor, a więc nie ma potrzeby wstępnego przygotowania obrazu. Dodatkowo programista dysponuje informacjami o scenie, parametrach światła, głębi, geometrii, teksturach, czy parametrach urządzenia rejestrującego obraz. Dzięki temu zamiast rozpoznawać krawędzie w obrazie wynikowym można to zrobić z użyciem geometrii sceny, albo bufora głębokości. Te informacje są zupełnie niezależne od tekstur i oswietlenia, oraz można z nich usunąć niepotrzebne elementy, więc wynik działania filtru, czy algorytmu jest praktycznie idealny. Koszt takiej operacji jest niższy, niż w przypadku klasycznego przetwarzania obrazu, bo nie trzeba przygotowywać danych, a ich rozdzielczość może być znacznie niższa przy jednakowych, bądź lepszych wynikach. Rzućmy okiem na przykładowy wynik rozpoznawania krawędzi w obrazie z użyciem laplasjanu na buforze głębokości:

Oczywiście przetwarzanie obrazu komputerowego może być równie dobrze uznane za generowanie, więc tradycyjni przetwarzacze nie powinni się czuć w żaden sposób gorsi (w końcu wyniki ich pracy zwykle wyglądają chałowo). Poza tym niedawno czytałem o aparacie, który zapisuje dodatkowe informacje o scenie, więc być może niedługo tradycyjne przetwarzanie obrazu spotka los dinozaurów.

W sieci można znaleźć przykłady pokazujące, w jaki sposób korzystając z ładowania poszczególnych próbek wygenerować ładny, wygładzony obraz. W zasadzie wszystkie sumują w pętli wszystkie próbki i generują wyjście z uśrednionych wartości. Można też iść o krok dalej i policzyć wynikowy kolor per próbka i uśrednić na końcu.

Oczywiście próbki można wykorzystywać w znacznie bardziej kreatywny sposób. Z punktu widzenia programu tekstura z wieloma próbkami na piksel, to tablica tekstur. Próbki indeksuje się z użyciem trzech intów. W związku z tym można taką teksturę wykorzystywać np. do zapisywania kilku warstw obiektów przezroczystych w algorytmie uzyskiwania przezroczystości niezależnej od kolejności obiektów.

Oprócz czytania dowolnej próbki dostajemy możliwość generowania wybranej próbki (SV_SampleIndex), określania położenia próbki w pikselu (GetRenderTargetSamplePosition, GetSamplePosition), czy odczytywania i ustawiania maski pokrycia piksela (SV_Coverage). Część zmiennych jest zapewniana automatycznie wprost w shaderach. Wystarczy zadeklarować dodatkowy parametr, a DirectX uzupełni go odpowiednią wartością.

Te dodatki są o tyle ważne, że w przypadku bardziej złożonych potoków (jak w przypadku metody light pre-pass) istnieją przebiegi multisample -> multisample. Generowanie obrazu metodą uśrednienia próbek powoduje artefakty na krawędziach obiektów w wynikowym obrazie. Poza tym multisampling w przypadku bufora geometrii jest ważny głównie na krawędziach, więc dla pozostałych pikseli można go wyłączyć z użyciem pokrycia zyskując na wydajności.

Shader obliczający oświetlenie per próbka w HLSL wygląda tak:

float4 pixelMain(Geometry2Pixel psIn,uint sampleIndex : SV_SampleIndex):SV_Target{ // automatyczny parametr włączający renderowanie per próbka
    float4 geom = geometryBuffer.Load(psIn.position.xy,sampleIndex);

    ... // standardowe obliczenia oświetlenia

    return color;
}

Okazuje się, że w większości przypadków magii nie ma. Trzeba za to mieć świadomość istnienia nowych możliwości i nauczyć się je wykorzystywać. Potem zostaje tylko cieszyć się z ładnie wygładzonego obrazu.

Otóż postanowiłem dopisać obsługę ładnego, wygładzonego tekstu. Oczywiście tekst z atlasu, a atlas z literkami i innymi znakami renderowanymi po trochu przez bardziej złożony mechanizm. Na pierwszy problem natrafiłem przy generacji mip map. Okazuje się, że jest metoda D3D11DeviceContext::GenerateMipmaps(), która generuje wszystkie poziomy na GPU. Wystarczy do tego zadeklarowanie tekstury jako dostępnej do zapisu dla GPU i ustawienie poziomów mipmap na trochę więcej niż 1 (najlepiej na 0). Przy tworzeniu zasobu podajemy deskryptor, dane i wskaźnik do obiektu. Tu zaczyna się problem. Jakie dane? Przecież chcę, żeby to GPU je dla mnie wygenerowało. Jak więc mogę je podać? Metoda tworząca tekstury nie potrafi przyjąć jednego poziomu mip map. Rozwiązań jest kilka, ale wszystkie opierają się na stworzeniu pustej tekstury i uzupełnieniu jej danymi z innego źródła, np. z innej tekstury. Dosyć karkołomne.

Lecimy dalej – generacja znaków. Użyję WinAPI i narysuję znaki sztuka po sztuce do jakiegoś systemowego bufora. Potem skopiuję je do tekstury. Nawet pasuje, skoro i tak muszę tworzyć teksturę na raty. Znalazłem prostą funkcję, wprost opisaną jako renderującą wygładzony tekst do bitmapy – idealnie. Okazuje się, że nie może to być dowolna bitmapa, bo tekst zupełnie się nie wygładza. Rysowanie na ekran działa, nie działa natomiast rysowanie do DIBa. Na jednej ze stron MSDN można znaleźć informację, że jest to działanie zamierzone i świadome. Szkoda tylko, że zupełnie nieintuicyjne i nie ma o nim żadnych informacji w dokumentacji. Za to przy opisie na MSDN podane jest obejście tej decyzji projektowej, oraz przyczyna problemu. Chodzi o inną decyzję – zgodność bitmap. Wygładzanie jest dostępne, ale tylko na bitmapach DDB, czyli w założeniu dedykowanych do jednego konkretnego celu, np. wyświetlania na ekranie, czy drukowania. Ilość stworzonych obiektów potrzebnych do właściwego wyrenderowania jednego znaku tak, by system nie miał mi tego za złe, jest zatrważająca. Na szczęście całość działa.

Na szczęście pisanie silnika równolegle z grą i edytorem ma to do siebie, że błędne decyzje projektowe są zauważane i poprawiane wcześnie, więc o większości z nich użytkownik nawet się nie dowie. Można spać spokojnie.

DOD stara się walczyć z fanatyzmem obiektowym przez lepsze wykorzystanie i organizację danych zamiast polimorfizmu, dziedziczenia i tym podobnych zabawek z krainy OOP. Między innymi projektowanie zorientowane na dane proponuje rozwiązanie popularnego problemu rysowania różnego rodzaju modeli. Zamiast klasycznego napisania metody wirtualnej draw dla każdego rodzaju modelu tworzymy pewne porcje danych, które rysuje się zawsze tak samo. Oszczędzamy więc na skokach przy wołaniu metod wirtualnych, oraz nie musimy pisać dużej ilości klas modeli i metod rysujących.

Zastanówmy się, czy sprawa rzeczywiście wygląda tak różowo. W zasadzie do napisania mamy tyle samo kodu, bo zamiast metody draw mamy metodę generateBuffer, czy coś w ten deseń, a do przechowywania różnych rodzajów modeli nadal wygodnie jest mieć kilka klas. Oczywiście nie warto mieć klasy wroga, czołgu i pocisku, jeśli wszystkie zawierają tylko statyczną siatkę wierzchołków. Mowa raczej o rozróżnieniu na model statyczny, ze szkieletem, cząsteczkowy, itp. Wygląda więc na to, że jedynym dużym zyskiem z przekształcenia metod wirtualnych w dane jest lepsze wykorzystanie cache, predykcji i bufora instrukcji dzięki pozbyciu się skoków do tablic metod wirtualnych.

A czy dałoby się wyeliminować skoki zachowując korzyści płynące ze stosowania metod wirtualnych? Jak to zwykle bywa w takich sytuacjach, odpowiedź brzmi - prawie. Najpierw przypomnijmy sobie pewną interesującą konstrukcję:

drawable->ParticleDrawable::draw();

Co w niej jest takiego interesującego? Ano to, że wymusza ona pominięcie skoku do tablicy metod wirtualnych dla metody wirtualnej draw. Oczywiście musimy być pewni typu danego obiektu, więc w tym wypadku nie ma mowy o polimorfiźmie. Rysując obiekty spodziewamy się, że możemy trafić na kilka określonych typów, więc wystarczy zamiast jednej listy z typem ogólnym trzymać kilka list z obiektami określonego typu, oraz wołać metodę rysującą z wymuszeniem typu. To przypomina wyjmowanie specyficznych przypadków przed pętlę i w zasadzie działa bardzo podobnie. Zysk z takiego przekształcenia dla kilku typów i setek wywołań jest oczywisty, a implementacja takiego podejścia zajmuje chwilę.

Pojawia się tylko jedno proste pytanie – czy nie lepiej zupełnie zrezygnować z metod wirtualnych? Chyba nie, bo wtedy tracimy możliwość obsługi klas dodanych przez użytkownika, czy wymuszania implementacji przez metody abstrakcyjne. Poza tym nie zawsze chcemy zupełnie omijać funkcjonalność metod wirtualnych. Jak np. podczas pisania edytora, który może być odrobinę prostszy z użyciem konstrukcji generycznych.

Oczywiście nie ma tu mowy o rozwiązaniu lepszym, czy gorszym. Ważne, żeby programista znał umiar i pisał tak, by sam się czuł dobrze ze swoim kodem.