Gdy znajdziemy w sieci kawałek kodu, który chcemy przeanalizować, to nie zawsze jest on ładnie sformatowany czy pokolorowany. Wtedy możemy sobie pomóc, wklejając rzeczony kod do naszego środowiska programistycznego; w większości znajdzie się opcja pozwalająca np. wyrównać wcięcia (w Visual Studio jest to Edit | Advanced | Format Selection), że o kolorowaniu nie wspomnę ;]
O powyższym wiedzą pewnie wszyscy. Jednak czasami kopiujemy też kod w drugą stronę, z IDE. Jeśli korzystamy z Visual Studio, to możemy wykorzystać przy okazji fakt, że jest on kopiowany jako… tekst formatowany typu RTF.
Na pierwszy rzut oka może to wydawać się co najmniej dziwne. Przecież kod z założenia jest zwykłym tekstem, więc po co dodatkowe informacje o czcionkach czy wyglądzie znaków?… Otóż odpowiedź jest bardzo prosta: w ten sposób zachowana jest bowiem informacja o kolorowaniu składni. Jeśli teraz wkleimy nasz kod do dowolnego edytora tekstu formatowanego (czyli od WordPada wzwyż), to zobaczymy z słowami kluczowymi i innymi elementami zakolorowanych dokładnie w ten sam sposób, jak w środowisku programistycznym.
Do szczęścia brakowało by pewnie jest możliwości szybkiej konwersji takiego kodu do formatu HTML… ale cóż, nie można mieć wszystkiego ;-)
Uaktywnienie łączenia alfa w DirectX na pierwszy rzut oka wydaje się dość skomplikowana. Niby występuje tam oczywiste ustawienie stanu renderowania D3DRS_ALPHABLENDENABLE
na true
, jednak to nie wszystko. Potem zwykle od razu występują przynajmniej dwa inne stany: D3DRS_SRCBLEND
i D3DRS_DESTBLEND
, ustawiane na równie tajemnicze wartości. Wyjaśnimy sobie dzisiaj, co one oznaczają i jak można je wykorzystać.
Należy zacząć od tego, że ten zagadkowy alpha blending to nic innego, jak zwykła suma ważona:
SourceBlend * SourceColor + DestBlend * DestColor
(z dokładnością do tego, że dodawanie można zastąpić innym działaniem przy pomocy D3DRS_BLENDOP
, ale tę możliwość zostawimy w spokoju ;]). To, co jest tutaj sumowane, to dwa kolory: źródłowy – pochodzący od właśnie mającego się narysować piksela, oraz docelowy – będący już w danym miejscu bufora ramki (ekranu). Normalnie ten pierwszy zwyczajnie zastąpiłby ten drugi, ale dzięki łączeniu alfa można zamiast tego uzyskać jakąś kombinację ich obu – czyli na przykład symulację półprzezroczystości. Wagami dla sumy są SourceBlend i DestBlend, i to właśnie je ustawiamy przy pomocy stanów renderowania.
Możliwych wartości jest kilka i obejmują one zarówno tak proste jak zero czy jeden aż po same kolory: źródłowe i docelowe (podobnie jak one, współczynniki te są 4-elementowymi wektorami), wartości ich kanału alfa, specjalny globalny współczynnik blend factor – jak również negacje tych wszystkich wartości. Sporo tego, prawda? :) Zobaczmy więc kilka typowych kombinacji:
SourceBlend = SourceAlpha; DestBlend = InvSourceAlpha
To najbardziej typowy sposób osiągania przezroczystości. Używamy tutaj źródłowej wartości alfa, by określić, jak bardzo kolor źródłowy ma wpływać na wynikowy oraz jak bardzo ma być pominięty wpływ koloru docelowego – że tak spróbuje się “intuicyjnie” wyrazić :) Ostatecznie mamy wtedy równanie typu:
SourceAlpha * SourceColor + (1 – SourceAlpha) * DestColor
czyli tzw. kombinację liniową obu kolorów, która w wyniku daje wrażenie półprzezroczystości.
SourceBlend = One; DestBlend = One
Ustawienie obu wag na 1 sprawia, że nasza suma ważona stają się zwykłą sumą, więc kolory są po prostu dodawane. Taka konfiguracja jest stosowana na przykład do łączenia ze sobą efektów oświetlania sceny kilkoma różnymi światłami i nazywa się blendingiem addytywnym.
SourceBlend = DestColor; DestBlend = Zero
Takie dziwne ustawienie wag sprawia z kolei, że zamiast dodawania otrzymujemy w istocie mnożenie przez siebie kolorów – czyli blending multiplikatywny. Istnieje oczywiście jeszcze jedna konfiguracja współczynników dająca ten sam efekt, która jest symetryczna do powyższej.
Powyższe warianty nie są naturalnie wszystkimi możliwymi ani nawet wszystkimi praktycznie wykorzystywanymi. Widać z nich jednak, że tak zwany alpha blending nie służy tylko do przezroczystości i nierzadko wykorzystujemy go również wtedy, gdy wszystkie obiekty naszej sceny nie są ani trochę prześwitujące.
Wszyscy wiedzą jak, mając dane dwa punkty, wyznaczyć wektor kierunkowy od pierwszego punktu do drugiego. Niekiedy jednak nie chcemy, aby możliwe było uzyskanie dowolnego kierunku. Może tak być np. przy poruszaniu jednostkami na mapie, gdy z jakiegoś powodu chcemy dopuścić, powiedzmy, tylko 8 czy 16 podstawowych kierunków. W jaki sposób należy wtedy “zaokrąglić” nasz dowolny wektor, uzyskany jako różnica aktualnej pozycji jednostki i np. miejsca kliknięcia myszką przez gracza?
Pierwszym możliwym sposobem jest zamiana jego reprezentacji ze współrzędnych prostokątnych (x, y) na biegunowe (r – długość, theta – kąt między dodatnią półosią X a wektorem). Jest to możliwe przy pomocy obecnej w wielu językach funkcji atan2(y, x)
. Wystarczy potem sprawdzić, któremu wzorcowemu wektorowi jest najbliższy otrzymany kąt.
Swego czasu znalazłem jednak nieco inny sposób, który daje się zastosować bez zmiany reprezentacji wektora. Oryginalnie służył on do wyboru jednego z ośmiu podstawowych kierunków, ale nietrudno było zauważyć, że da się go trochę uogólnić:
Użyta tutaj funkcja Round(t)
oznacza zaokrąglenie w stronę najbliższej liczby całkowitej, czyli floor(t + 0.5)
. Współczynnik k
kontroluje natomiast, ile wektorów wzorcowych znajduje się w naszej “róży wiatrów”. Powyższa funkcja dzieli bowiem kąt pełny na dokładnie 2k+2 wycinków, dając tyle też możliwych wektorów wynikowych. Osiem kierunków otrzymamy więc dla k = 1, szesnaście dla k = 2, itd. Teoretycznie możliwe są też ułamkowe wartości współczynnika, co najprawdopodobniej pozwałoby kontrolować “czułość dopasowania” wektora do wzorca. Nie podjąłem się jednak opracowania jakiejś ścisłej zależności :) Jedyne co udało mi się zaobserwować to to, że dla k = 2/3 otrzymujemy dopasowanie do czterech podstawowych kierunków (N, S, W, E).
Ogólnie więc nie jest to może epokowe odkrycie w dziedzinie wektorologii stosowanej, ale istnieje szansa, że komuś do czegoś się przyda ;]
Niecały rok temu napisałem tutaj co nieco o tym, dlaczego nie podobają mi się różnego rodzaju “wynalazki statystyczne”, obecnie na forum Warsztatu. Wtedy pomysł usunięcia karmy i licznika postów nie spotkał się z jakimś szerokim poparciem. Pewnie było jeszcze na to za wcześnie. Musiało minąć te kilkanaście miesięcy, żeby pozostali moderatorzy zauważyli w końcu to, że obecność tych śmiesznych cyferek nie powoduje wcale podniesienia jakości forum – wręcz przeciwnie :)
No, ale lepiej późno niż wcale ;> Wczoraj – jako skutek głosowania w gronie moderatorów – zarówno karma, jak i licznik postów zostały usunięte z widoku. Ta pierwsza zniknęła całkowicie, zaś liczbę postów można wciąż obejrzeć w profilu użytkownika. Całkiem rozsądne wyjście, moim skromnym zdaniem.