Netrix's devLog

Udało mi się wreszcie opanować kawałek kodu, który męczył mnie od 2 dni. Okazało się, że umieściłem w strukturze, która była agregatem, referencję. Następnie zainicjalizowałem obiekt takiej struktury jako agregat. Wszystko było ładnie, dopóki nie postanowiłem przestawić kompilacji z Debug na Release. Aplikacja zaczęła się sypać. Dzisiaj udało mi się wreszcie znaleźć ten błąd, który tkwił w referencji umieszczonej w agregacie, po jej usunięciu wszystko było ok.

Myślę, że jest to błąd kompilatora, który powinien przynajmniej ostrzegać o próbie inicjalizacji referencji w agregacie. Wynik takiej operacji jest niestety niezdefiniowany.

Ostatnio dowiedziałem się o bardzo fajnej funkcji jaką udostępnia biblioteka standardowa, czyli o funkcji Assert. Funkcja ta ma tę zaletę, że warunek, który jej przekazujemy jest sprawdzany tylko, gdy jest umieścimy definicje NDEBUG. Wtedy, gdy warunek zwróci fałsz, zostaje wyświetlone okienko, gdzie i kiedy miało zdarzenie. W przeciwnym wypadku, gdy nie zdefiniujemy NDEBUG, sprawdzanie warunku po prostu znika, dzięki czemu osiągamy większą wydajność.

Oczywiście standardowa makrodefinicja nie jest idealna, ponieważ wyświetla różne rodzaje okienka w zależności od tego, czy używamy main czy WinMain. Ale napisanie swojego odpowiednika tej funkcji nie nastręcza problemów, wystarczy się przyjrzeć makrodefinicji zawartej w pliku assert.h. Polecam również artykuł w książce Perełki Programowania Gier część pierwsza, rozdział 1.12. Są tam świetne porady na ten temat.

Postanowiłem napisać do mojego silnika moduł 2D, gdyż od jakiegoś czasu mnie nosiło, aby napisać symulacje rzutów fizycznych (głównie ukośnego – pewnie przez to, że zbliżają się matury). Po raz pierwszy jednak udało mi się napisać własny shader, co uważam za niebywałe osiągniecie, chociaż jedyną czynnością jaką on wykonuje jest wyświetlenie tekstur. Wracając do modułu. Jest on bardzo prosty, ponieważ składa się tylko z 2 klas: ImageBox oraz Image. Klasa ImageBox jest pojemnikiem na obiekty typu Image. Jej zadaniami są:

• Tworzenie i likwidacja obiektów Image
• Zarządzanie wewnętrznym Vertex Bufferem
• Zarządzanie shaderem (który służy tylko do próbkowania tekstury)
• Likwidacja i przywracanie zasobów na czas resetowania urządzenia

Funkcja rysująca i zestaw funkcji do manipulowania obrazkami są dostępne w klasie Image, dzięki czemu można samodzielnie kontrolować czy obrazek ma zostać narysowany oraz co zostanie zmienione. Z racji tego, że przed narysowaniem czegokolwiek, konieczne jest ustawienie shadera, rysowanie odbywa się w bloku BeginPainting() (…) EndPainting(). Podobnie jest z manipulacją obiektami, gdyż trzeba zablokować VertexBuffer.

Oto prosty przykład zastosowania tego modułu w “symulacji” rzutu ukośnego.

Download – wymaga sm 1.1

Postanowiłem, że należałoby wreszcie zrobić porządek z biblioteką NLib oraz z silnikiem NIne. Niestety jak się okazało przy projektowaniu gry (myślę nad klonem Tetrisa w 3D), aktualny stan silnika nie pozwala na jego rozbudowę i pisanie w oparciu o niego jakiejkolwiek gry. Dlatego stwierdziłem, że lepszym pomysłem byłoby zaprojektować grę, a następnie do niej odpowiedni interfejs, mając na uwadze ponowne użycie kodu do tworzenia innych gier.

Na początek zająłem się biblioteką NLib. Zamierzam kompletnie uniezależnić się od wyjątków, ponieważ uważam, że są one dobre do zwykłych programów, w których występuje wiele sytuacji wyjątkowych. W grze są niepotrzebne, gdyż jeżeli nastąpi sytuacja wyjątkowa, to grę i tak należy zamknąć, a poza tym podobno obsługa wyjątków spowalnia kod. Zamiast tego błędami będzie sie zajmował Logger, do którego będą trafiać wszystkie komunikaty (nawet te najmniej ważne), dzięki temu będzie wiadomo co i kiedy poszło nie tak. Dlatego będzie wymagany do używania jakiegokolwiek modułu z biblioteki.
Ważną zmianą jest też wprowadzenie obsługi Unicode. Niestety standardowe strumienie zapisujące do plików, nie zapisują ich w tym kodowaniu, dlatego zacząłem pisać własny strumień oparty na funkcjach WinApi. Z początku będzie obsługiwał tylko Little Endian, ale myślę nad dodaniem obsługi plików zapisanych jako Big Endian i ANSI (w trybie Unicode projektu). Z tego strumienia będzie korzystał również Logger. Oczywiście Unicode będzie obsługiwany tylko wtedy, gdy w ustawieniach projektu kodowanie będzie w tym trybie. W trybie ANSI, strumień będzie zapisywał tylko w ANSI.

Uważam, że należy iść z duchem czasu, a nie pozostawać w epoce kamienia łupanego :D.

Mała porada dla tych, którzy chcą otworzyć stare projekty, które zawierają pliki *.rc.
Przy próbie kompilacji takich projektów, może wyskoczyć błąd, który oznajmia, że nie mamy plików podanych w tytule.

Rozwiązanie jest proste, wystarczy nazwę tego pliku podmienić na windows.h. Dzięki temu można korzystać z zasobów ładowanych do pliku *.exe. (Sprawdzałem tylko na prostym projekcie z książki Programowanie w DirectX Masona McCuskey’a).

W Visualu C++ EE, zablokowana jest możliwość otwierania plików *.rc, jednak nie tak do końca, albowiem wystarczy kliknąć na takim pliku prawym przyciskiem myszy, a następnie wybrać Open with… i w oknie wybrać Source Code (Text) Editor. Według mnie zawsze jest to jakieś rozwiązanie.
EDIT: wystarczy kliknąć na takim pliku prawym przyciskiem myszy i opcję View Code. Thx Tarains.

Spotkałem się również z takim problemem, jak brak zdefiniowanej stałej IDC_STATIC (używanej do tworzenia szablonów okien dialogowych).
Kod błędu:
error RC2104 : undefined keyword or key name: IDC_STATIC

W takim przypadku należy do pliku resources.h dodać następujący kod:

#ifdef IDC_STATIC
#undef IDC_STATIC
#endif
#define IDC_STATIC (-1)

Wpadłem na pomysł prostego serializer’a, który by potrafił czytać dane z pliku podzielonego na sekcje i zapisywać je do prostej struktury – agregata. Miał być to szablon funkcji, który pobierałby jako jeden z argumentów wskaźnik do tej struktury, następnie wyliczał miejsce zmiennej w strukturze, na podstawie tablicy z typami (enum) i w końcu zapisywał przeczytane dane odpowiednio, sformatowane przez bibliotekę standardową. Niestety jak się okazało (czego do tej pory nie wiedziałem) miedzy składnikami klasy, struktury są przerwy, więc nie można skorzystać z wskaźnika, którego chciałem przesuwać o rozmiar przeczytanego typu, gdyż spowoduje to błędy zapisu.
Na szczęście rozwiązanie tego problemu okazało się bardzo proste i jest o wiele bardziej uniwersalne, otóż zamiast wskaźnika na obiekt struktury, przekazuję funkcji (ponieważ szablon jest już niepotrzebny) tablicę wskaźników do zmiennych i jej rozmiar. Dzięki niej wiem gdzie w pamięci znajduje się dana zmienna. Rozwiązanie to ma też inna zaletę, ponieważ do funkcji mogę przekazać nie tylko obiekty struktury, ale również dowolne obiekty nienależące do struktury.

Oto przykładowy plik cfg:

1
2
3
4
5
6
7
8

Sekcja1{
   // Komentarz
}
// Komentarz 2
Sekcja2
{
   zmienna1 = 3.14;     // Komentarz np. opisuje jaki to typ, tu float
}

Jak widać schemat jest prosty:

1. Sekcje oznaczamy nazwą i klamerkami
2. Komentarze tylko po //, są ważne do końca linii
3. Nazwy zmiennych nie są brane pod uwagę, liczy się znak ‘=’ i ‘;’, pierwszy rozpoczyna czytanie wartości, drugi kończy.

PS. Schemat pliku zmyślony z Regedit’a :).

W kodzie wygląda to tak:

1
2
3
4
5
6
7
8
9
10
11

// Tworzymy tablicę z typami
int types[] = { TYPE_FLOAT };        // Przykładowo float
 
// Zmienna
float temp;
 
// Tablica ze wskaźnikami
void* pointers = { &temp };
 
// Odczyt z pliku
FillUpStruct("nazwa_pliku_jako_string", types, sizeof(types),  "Sekcja2", pointers, sizeof(pointers));

Według mnie wygląda to ładnie, i jest proste w użyciu, szczególnie przydatne przy zapisie ustawień np. urządzenia DX.

Ostatnio wymyśliłem dość prosty TextureManager (Resource był w planie, ale nie wiem wszystkiego o zasobach DX, które trzeba zwalniać, a o teksturach wiem wystarczająco). Właściwie to nazwanie go jest lekką przesadą, ponieważ składa się on ze struktury, vector’a i 2 funkcji.  Vector zawiera obiekty struktury, która składa się ze adresu tekstury, licznika użyć oraz wskaźnika na interfejs tekstury. Vector’em zarządzają 2 funkcje:

LoadTexture
DeleteTexture

Pierwsza sprawdza czy nie ma już załadowanej takiej tekstury jeżeli jest to zwiększa jej licznik i zwraca interfejs. W przeciwnym przypadku tworzy i dodaje do vector’a

Druga sprawdza po wskaźniku czy jest, jeżeli tak to dekrementuje po czym sprawdza licznik, jeżeli spadł do 0 to zwalnia teksturę, kasuje z vector’a.

Składniki zawierają się w sekcji prywatnej klasy Mesh, przy czym vector jest statyczny, dzięki czemu dostępny dla wszystkich potomków klasy abstrakcyjnej Mesh.

Dziś na przedmiocie o nazwie “Język Polski” (tak, to idealna pora), projektowałem klasę obsługującą wierzchołki. Stwierdziłem, że do obsługi wierzchołków typu FVF oraz tych dla Vertex Declaration potrzebne będą różne klasy, a ponieważ lubię jak wszystko jest OO (lub dąży do tego), postanowiłem, że napiszę klasę abstrakcyjną Mesh, zawierającą (aktualnie) 4 funkcje:

• virtual void Draw() = 0;
• virtual void InvalidateResources() = 0;
• virtual void RestoreResources() =0;
• void AddDevicePtr(LPDIRECT3DDEVICE9);

Te funkcje pozostaną niezmienne, przy czym wirtualne będą używane przez klasę Render. Która je będzie w odpowiednich momentach wywoływała. Następnie pomyślałem o klasie dziedziczonej dla typu FVF (aktualnie mi taka potrzebna), ale szybko doszedłem do wniosku, że nie ma ona sensu, ponieważ nie będzie zbyt elastyczna, gdyż za każdym razem potrzeba jest ustawić inne stany, a przecież to samo można zyskać bez niej, dlatego porzuciłem ją. Klasa Mesh jako abstrakcyjna będzie dziedziczona przez różne klasy obiektów, które będę mógł dodać do vector’a w klasie Render, a ta będzie wywoływać odpowiednie funkcje, które będą odpowiednio zdefiniowane dla danego obiektu.

Dość niedawno rozpocząłem pracę nad moim kolejnym projektem, który nazywa się on NIne. W zamiarze ma być to silnik składający się z podstawowych modułów, czyli obsługi grafiki, dźwięku, eventów, planuję również napisać własny VFS. Projekt jest duży i na pewno zajmie mi sporo czasu, jednak jest on jednocześnie okazją do napisania sobie własnych narzędzi, z których będę mógł korzystać w przyszłości. Oczywiście projekt zamieszczam w osobnym wątku, więc jeżeli trafi się okazja lub potrzeba będę pisał również inne.

Czas nadszedł, jak obiecałem (przynajmniej sobie w myślach), umieszczam prezentacje wraz z kodem źródłowym silnika prezentacji. Prezentacja była robiona w grupie, ja zająłem się silnikiem, kolega Konrad Polak dopieścił grafikę, a reszta dbała o informacje :).

Teraz troszkę o silniku. Silnik bazuje na SDL, filmiki wyświetlam z pomocą DirectShow, muzykę odtwarzam dzięki IrrKlang (Nie DS, ponieważ z IrrKlang miałem gotowe). Silnik składa się z 3 części:

• Core: odpowiedzialny za obsługę scen, obsługę zdarzeń
• Scene: układa scenę z poszczególnych kontrolek
• Controls: klasa bazowa, z której dziedziczą poszczególne kontrolki

Ogólnie uważam, że dość dobrze zaprojektowałem ten silnik, jeśli ktoś miałby rady to chętnie wysłucham ( lub przeczytam).

Jak mówiłem z projektem zamieszczam kod, jeśli ktoś jest zainteresowany.

Download

PS. W lewym i prawym dolnym rogu są strzałki, wystarczy najechać :).

// Download się zagubił ;(