Nowy tool – znów troszkę pokodziłem

Dzisiaj uświadomiłem sobie, jak dawno nie skodziłem nic nowego – o ile pamiętam, od gdzieś tak 25 lipca moje kodzenie polegało głównie na poprawianiu tego, co zrobiłem wcześniej, debugowaniu i testowaniu różnych fragmentów z coraz to nowymi danymi (wyniki prac reszty teamu). Jakie to jest nudne…

Wczoraj jednak pojawiła się potrzeba napisania czegoś nowego – prostego narzędzia, które zliczy całkowitą ilość trójkątów, które są wyświetlane w danej scenie (nie uwzględniając frustum cullingu). Z powodów zdrowotnych, skodzić mogłem to dopiero dzisiaj. I przypomniałem sobie, jaka to przyjemność napisać coś dobrze działającego w ciągu krótkiego czasu, bez potrzeby żmudnego szukania ew. błędów. Znalazłem nawet siły żeby rozbudować programik o zliczanie innych elementów sceny

Powrót

Co do buga z migotaniem, to już w grze nie występuje. Ale w Irrlichcie nadal jest – tyle, że w wersjach 1.3.1 w górę. Po dłuższych testach okazało się, że ładowanie mesha przed ładowaniem sceny nic tak naprawdę nie zmienia – straciłem więc ostatni punkt, w którym moglem się zaczepić. Wróciłem więc do wersji 1.3, która wydaje się w miarę wolna od bugów, przynajmniej tych poważniejszych. Mam tylko nadzieję, że nic nowego nie wyskoczy…

Niestety, dużym problemem jest wydajność. Kiedy chciałem brać się za optymalizację kodu gry, myślałem, że dużo zdziałam – dobrze, że najpierw przetestowałem, co ile trwa. Wyniki zaskoczyły mnie – obsługa fizyki jest praktycznie niezauważalna (aktualizacja świata zajmuje < 2% czasu generowania klatki, testowanie przecięć promieni z podłożem < 1%), sprawy gameplay’owe także trwają bardzo krótko. Natomiast średnio 85% czasu generowania klatki zajmuje rysowanie, czyli narysowanie sceny i huda. Wydaje mi się, że z narysowaniem bądź co bądź prostej sceny nie powinien mieć większego problemu – bo czym jest 40k trójkątów z paroma nałożonymi teksturami? Cóż, tego się już nie zmieni. Ale wymagania sprzętowe Wyprawa Rysia będzie miała “nowoczesne” ;]

Dobijające, owszem. Ale nie z mojej winy.

Bug wspomniany w poprzedniej notce nie znajduje się w kodzie gry ani nie wynika z modyfikacji silnika wykonanych przeze mnie. Na 100%. A skąd to wiem? Otóż, został wydany preview irrEdita 1.4alpha, który używa Irrlichta w najnowszej wersji (1.4alpha) – poprzedni irrEdit używał Irrlichta w wersji 1.3 i w nim bug nie występował, a pojawiał się dopiero w grze (Irrlicht 1.3.1). Było parę możliwości:

• bug jest w moim kodzie i niezależny od silnika – występuje tylko w grze
• bug jest w wersji 1.3.1 Irrlichta, ale został zlikwidowany w wersji 1.4alpha – w irrEditcie nie ma buga
• bug jest tak w wersji 1.3.1, jak i w wersji 1.4alpha   – w irrEditcie też widać buga

Prawidłowa jest odpowiedź numer 3. Błąd jest w Irrlichcie, jest zatem niezależny ode mnie i wcale mnie to nie cieszy – własny kod bardzo dobrze znam i zdecydowanie łatwiej go się debuguje, a kod Irrlichta, oprócz tego, że nie mój, to jeszcze ciągle podlega zmianom.

Ale jest jeszcze jedna dziwna i ciekawa kwestia, która może pomóc ominąć buga. Mianowicie, gdy otworzy się scenę z levelem zaraz po otwarciu irrEdita, to błąd występuje. Można otwierać scenę ponownie ile się chce razy, miganie dalej jest widoczne. Natomiast gdy uruchomi się irrEdita, otworzy dowolny plik .X i wstawi go jako mesh scene node, następnie się go usunie i otworzy scenę z levelem, to nic nie migocze. Sprawdzone kilkakrotnie. Może to jest jakaś bramka – trzeba będzie się zastanowić…

Niektóre rzeczy naprawdę dobijają

Dzisiaj zauważyliśmy z Cvenim dziwnego i bardzo nieprzyjemnego buga związanego z wyświetlaniem levelu w specyficznych sytuacjach. Wsadziliśmy najnowszą wersję levelu do gry, przy czym głównie zwiększyła się liczba poly kolizji – wzrosła z ok. 6k do 32k, ale to, jak myślałem, niewiele – z przeprowadzonych jakiś czas temu testów wynikało, że gra jest w stanie uciągnąć 200k do wyświetlania i 200k do kolizji przy fps ~5 na moim leciwym już raczej sprzęcie. Ale, do rzeczy – uruchomiliśmy z zamiarem zobaczenia, jak wygląda oświetlony level, a naszym oczom ukazało się… w tym problem, że prawie nic się nie ukazało. W zależności od kąta patrzenia kamery znikały różne, zapewne losowe węzły sceny (w całości) oraz poszczególne trójkąty. Miganie bardzo denerwujące i praktycznie uniemożliwiające grę. Kolizje chodziły bardzo ładnie, bez żadnych przekłamań, i właściwie jedyny problem stanowił właśnie ów bug z losowy znikaniem części levelu.

Wstawiliśmy na level wodę. Uruchomiliśmy, i… hurra, działa. Nic nie znika! Dopiero kolejne parę minut pozwoliło odkryć, że działa tylko w przypadku włączenia wody “tej lepszej”, w której widoczne są odbicia – w przypadku tej przeznaczonej na słabsze komputery (animowane tekstury) problem dalej był tak samo widoczny. Po następnych kilku minutach udało się zauważyć, że w przypadku “lepszej” wody problem dalej występuje. Tyle, że w odbiciu, a nie na całym ekranie.

Woda jest renderowana w następujący sposób:

• ustawienie render targeta na “refraction map” (heh, jak to będzie po polsku? “mapa refrakcji”?)
• wyrenderowanie sceny
• ustawienie render targeta na “reflection map” (“mapa odbić”?)
• ustawienie kamery “od wody”
• wyrenderowanie sceny
• ustawienie starej kamery i standardowego render targeta

Woda jest renderowana jako pierwszy węzeł sceny, i to w odbiciu w wodzie widać “znikanie” losowych węzłów sceny. Wszystkie elementy sceny są rysowane 2 razy dla wody i raz na ekran. Przy ustawianiu rendertargeta czyszczone są backbuffer i zbuffer. To naprawdę nie jest śmieszne, naprawdę. Bo niby jak mam naprawić tego buga, skoro nawet nie wiem, o co w nim chodzi?

Aktualizacja:

Przetestowałem teraz ten level u siebie – jeszcze jedna ciekawostka. Teraz niezależnie do tego, czy woda jest, czy jej nie ma, miga zawsze. Fajnie. Przynajmniej jakaś konsekwencja jest.

Aktualizacja 2:

Zmieniłem kolor, którym czyszczony jest backbuffer podczas ustawiania rendertargeta. Było (255, 255, 255, 255) [RGBA], zmieniłem na (0, 0, 0, 255). Testowałem dwukrotnie, i w obu testach nic nie migocze. To jest podejrzane, bo to jest wartość, która była także przy wykryciu buga. Czyżby bug się ukrywał? Pff…

Aktualizacja 3:

Test 3, warunki identyczne jak przy poprzednich testach – jednak miga ;/ Z bardzo dużą częstotliwością, gdy wody nie widać (frustum culling), z dużo mniejszą, gdy wodę widać, ale dalej miga. Będzie parę dni zabawy…

Problemu z animacją już nie ma ;]

Wróciłem do Irrlichta 1.3.1 (swoją drogą to wersja starsza od ostatniej działającej z SVN, ale głupi ja, głupi, nie zrobiłem backupa przed pobraniem nowej wersji a numeru rewizji nie pamiętałem). Trochę czasu potrzebowałem na zorientowanie się w tym, jak wygląda animacja “od środka” w Irrlichcie, jakiś czas potem rozgryzłem, w którym momencie uaktualniane są pozycje bezwzględne jointów dla aktualnej klatki animacji. Wstawiłem tam napisany parę dni temu kod i działa – dopiero teraz sobie uświadomiłem, że to pierwszy raz, kiedy udaje mi się w końcu zlikwidować jakiegoś buga, którym zajmowałem się więcej niż 4 dni (człowiek bardzo szczęśliwy po jest ). Rysio już się nie trzęsie podczas biegu ;]

Teraz została tylko korekcja obrotów Rysia przy obracaniu kamery – ale z tym nie powinno być problemów, z prostego względu – prawie identyczny przypadek miałem przy pisaniu killerów wahadłowych

Jedno tylko mnie martwi – rozwiązanie tego buga wydaje mi się być kompletnie nieelegenckie – niestety, nie mogłem wymyślić innego, który można by wstawić. Ale działa i jest dosyć przejrzyste. A to jest dla mnie ważne

Postoję?

Najnowsza wersja Irrlichta z SVN ma problemy z plikami X – a ja akurat chciałem silnik uaktualnić… W każdym razie, dostałem odpowiedź na mojego posta z opisem problemu:

Yes, due to the new animation system thre are some problems with .x files currently. We are working on this and will have it fixed before the next release

Nie, na to nie ma czasu – wracam do ostatniej stabilnej wersji, najwyżej będę później zmieniał kolejną wersję.

Animacja

Ostatnie parę godzin dziś, i wczorajsze popołudnie zajmowałem (i dalej się zajmuję) przystosowaniem posiadanego modelu z animacją do gry. Dokładniej, chodzi o to, że gra pisana była pod model, który mimo, że animowany, to stoi w miejscu, a poruszanie jest zrobione za pomocą przesuwania węzła sceny. Takie podejście się jednak niezbyt sprawdziło z aktualnym modelem, który podczas animacji przemieszcza się, nie chcąc stać w miejscu i spokojnie poddać się przesunięciu węzła sceny.

Model jest w pliku X – więc najprostszy chyba sposób, tj. znalezienia przesunięcia pomiędzy punktem (0, 0, 0) modelu a głównym jointem (COM) modelu i skorygowania pozycji tak, żeby animowany model był dokładnie w punkcie patrzenia kamery, już dawno wymyśliłem i zaimplementowałem. I działa. Problem w tym, że źle… Podczas przesuwania model trochę się trzęsie, a przy przeskoku (zapętleniu) animacji, na jedną klatkę gry model przeskakuje tak, jakby korekcja pozycji nie zachodziła. I nie, nie jest to zwykły irrlichtowy błąd typu “brak updateAbsolutePosition” – już to sprawdzałem na wszystkie możliwe strony.

Skoro już rozpisałem się na czym polega błąd to może łatwiej mi będzie teraz go szukać.

Koniec!

A tak, koniec. Konkretnie z pisaniem notek niezwiązanych w żaden sposób z programowaniem/grami/mną – myślę, że w ten sposób ten blog będzie ładniejszy

Co do Wyprawy Rysia, to dzisiaj poświęciłem jakąś godzinkę na różnego rodzaju poprawki – wymagania sprzętowe powinny się już zmniejszyć do okolic GeForce 3, a sterowanie jest trochę łatwiejsze. Do tego niewielka zmiana w gameplay’u – reakcja Rysia na zniszczenie przeciwnika przy pomocy naskoku jest teraz podobna do tej z Mario – wyskok. Nawet fajne to ;]

Zaczęło się…

Dzisiaj przeżyłem pierwszy dzień w I LO w Miliczu, w klasie mat-fiz…  I tyle. Najbliższe 3 lata spędzę w tej klasie (która liczy 32 osoby – tłum!). Nie czuję potrzeby uzewnętrzniania się, więc na tych paru słowach kończę tę żałobną notkę.

Pozdrawiam wszystkich uczniów i życzę studentom, żeby im się wakacje szybko skończyły ;p

Bojownicy o wolność oprogramowania

Nie wiem, czemu mnie denerwują tak ci wszyscy bojownicy nachalnie promujący Open Source, linuksy i inne podobne. Może dlatego, że próbują mi wmówić, że oprogramowanie Microsoftu jest bardzo zabugowane, niewygodne i nieekologiczne? Może dlatego, że ciągle gadają o tym, że Microsoft jest zły? Może w końcu dlatego, że przypominają mi świadków Jehowy?

Nie mam nic przeciwko samemu oprogramowaniu o otwartych źródłach – sam często z takiego korzystam (przez ostatnie miesiące głównie Irrlicht), nie mam nic przeciwko ludziom, którzy po prostu tego używają. Denerwują mnie tylko ci krzykacze, fanatycy wpieprzający się ze swoim świętym przesłaniem wszędzie – aż czasem boję się otworzyć lodówkę (jeszcze jakiegoś pingwina znajdę).

To tyle w ramach przemyśleń noworocznych.