Netrix's devLog

Właśnie opublikowałem paczkę dotychczasowej pracy. Nie jest tego dużo, ale zawsze coś. Muszę przyznać, że ostatnio pogrywam sobie w L2 więc czasu trochę mniej. Paczka zawiera prostą aplikację wykorzystującą mój menadżer scen, dzięki któremu można przełączać dowolnie między scenami. Więcej w pliku ReadMe.

Pobierz

Udało mi się napisać manager scen, na którym będę mógł oprzeć moją grę, dzięki temu sceny można przełączać (jak w grze). Ostatnio zająłem się efektami, które są w książce Programowanie gier w DirectX. Póki co mam efekt ognia i efekt wody, między którymi można się dowolnie przełączać. Postaram się zakodzić resztę i udostępnić.

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

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.