“Ale żeby się parę godzin nie kompilowało!”

Pewna sytuacja zmusiła mnie ostatnio do zastanowienia się nad długością kompilacji kodu w C++ – z tego zastanawiania się najciekawsza okazała się kwestia zależności pomiędzy plikami.

Jak wiadomo, pisząc w C++ produkujemy pliki nagłówkowe (.h czy też .hpp) i pliki .cpp, w tych pierwszych trzymane są deklaracje funkcji, definicje klas czy szablonów. Pliki .cpp dołączają pliki nagłówkowe, które to często dołączają inne pliki nagłówkowe, itd. Przez to często zdarza się sytuacja, że drobna poprawka w pliku nagłówkowym skutkuje koniecznością kompilacji bardzo dużej liczby plików .cpp. W przypadku zmiany interfejsu nie ma w tym raczej nic dziwnego i niepotrzebnego – użytkownicy i tak musieliby się dostosować. Ale co z implementacją? Skoro z zewnątrz działa tak samo, to czemu trzeba rekompilować? Przydałoby się zatem tę implementację gdzieś schować, by jej zmiany nie wymuszały rekompilacji innych części programu. Definicję zadeklarowanej w pliku nagłówkowym funkcji możemy sobie schować do pliku .cpp, ale co z klasami? Tak, tak, definicje metod także możemy sobie schować, ale przecież definicje metod nie są całą implementacją – pozostają jeszcze atrybuty klasy. To właśnie trzymanie różnego rodzaju atrybutów pociąga za sobą konieczność dołączenia kolejnych plików nagłówkowych i je także trzeba schować. Jak?

1. Tworzymy klasę definiującą interfejs, wykorzystując czysto wirtualne metody (w C# czy Javie można zrobić to ładniej, ale to jest C++ :[), a następnie właściwą klasę implementującą, która dziedziczy po tej od interfejsu. Teraz tylko jakaś fabryka i możemy korzystać z klasy mając tylko jej interfejs. Przykład:

   // Plik IFoo.h:
   class IFoo
   {
   public:
      virtual ~IFoo();
      virtual void doSomething1() = 0;
   };
   IFoo* createFoo();
   
   // Plik CFoo.h:
   #include "IFoo.h"
   class CFoo : public IFoo
   {
   public:
      void doSomething();
   private:
      std::string mBar;
   };
   
   // Plik CFoo.cpp:
   #include "CFoo.h"
   void CFoo::doSomething()
   {
      std::cout << mBar << std::endl;
   }
   IFoo* createFoo()
   {
      return (new CFoo());
   }

   Taka metoda pozwala także na rozwiązanie innych problemów, ma jednak pewną dużą wadę: możemy posługiwać się właściwie tylko wskaźnikami na “klasę interfejsu” – bo mamy tylko do niej dostęp. Z tego sposobu korzysta m.in. Irrlicht.

2. Tzw. pimpl idiom – w definicji klasy zawieramy interfejs, ale bez atrybutów – jedynie wskaźnik na ów “pimpl”, czyli klasę z właściwą implementacją. Definicję i implementację tej klasy wstawiamy w pliku .cpp:
   Przykład:

   // Plik Foo.h:
   class Foo_pimpl; // deklaracja zapowiadająca
   class Foo
   {
   public:
     Foo();
     ~Foo();
     void doSomething();
   private:
     Foo_pimpl* pimpl; // można też wpakować to w jakiś sprytny wskaźnik
   };
   
   // Plik Foo.cpp:
   #include "Foo.h"
   class Foo_pimpl
   {
   public:
     void doSomething()
     {
       std::cout << mBar <doSomething();
   }

   Możemy też z pimpl-a zrobić strukturę z publicznie dostępnymi atrybutami.

Pozostają jeszcze szablony – co właściwie jest z tym export?

Tak właściwie nie napisałem powyżej nic specjalnie odkrywczego ani innowacyjnego – tyle udało mi się wygrzebać. Zna ktoś jeszcze jakieś fajne sposoby?

Gry

Ano, ostatnio sporo gram. Sporo, w porównaniu do tego, co jeszcze całkiem niedawno (dla coniektórych granie 10 godzin w ciągu dwóch dni to granie casualowe ). Jakoś tak się złożyło, że nie za bardzo miałem ochotę na kodzienie. A przecież na siłę nie będę nic pisać! Ale czemu od razu piszę o tym graniu tutaj? Bo tak jakoś wyjątkowo po zagraniu w każdą z paru gier coś sobie pomyślałem…

•  Oblivion – uruchomiłem w zamierzeniu na parę minut, żeby sobie połazić po lasach, bo te wyglądają doskonale (Crysis się chowa, naprawdę! Odginanie gałązek jest obrzydliwe). Łaziłem dwie godziny. Gra już swoje lata ma, a nadal potrafi zachwycić grafiką… szkoda, że na dłuższą metę tylko grafiką
• Overlord – jakiś czas temu ściągnąłem demo tej gry przez Steam. Słyszałem i czytałem o tym sporo, ale właściwie nie wiedziałe, czego mogę się po tym spodziewać. Uruchomiłem, i… byłem zachwycony! Bardzo ładna grafika (tak cukierkowego i zbloomowanego świata nie ma nawet Oblivion) doskonale pasująca do minionów i naszego złego władcy. Eh, gdyby każda gra potrafiła dostarczyć tyle śmiechu…
• Icewind Dale – dałem sobie spokój z instalowaniem tego pod Vistą (po problemach z Baldur’s Gate – właściwie to jedyna rzecz, z którą Vista sobie nie radzi). Virtual PC, Windows 98 i… znowu zachwyt grafiką! Ta leciwa już produkcja ma najlepszą grafikę ze wszystkich wymienionych gier. Kilka jutrzejszych godzin też pewnie zejdzie na graniu w ID, bo teraz już nic nie widzę przez przesympatyczny ból głowy

Wesołych Świąt!

Właśnie mija okres przedświąteczny, dzisiaj wigilia świąt Bożego Narodzenia, jutro same święta się zaczynają. Zapewne każdy w ciągu ostatnich dni dostał tony maili, sms-ów, kartek, telefonów i innych form z życzeniami. Ja ograniczę się do życzeń na blogu – kto będzie chciał, to sobie przeczyta, nie popieram spamu, nawet uzasadnionego

A jakie życzenia? Wesołych świąt, wszystkiego najlepszego i smacznego! To tyle. Nigdy nie byłem dobry w układaniu życzeń

Klonujemy

Tak się złożyło, że wszedłem do projektu shadow clones (dziwna nazwa) jako programista. Tak właściwie nie wiem, po co, nie wiem także, dlaczego akurat do tego projektu. Może dlatego, że dowodzenie teamem jest bardzo denerwujące, frustrujące i stresogenne? Chciałem sobie po prostu pokodzić, ale nie miałem pomysłu, co. To znaczy, pomysł mam, ale na coś zdecydowanie zbyt dużego, jak na moje aktualne chęci. A skoro chciałem sobie po prostu pokodzić, to robienie za programistę w jakimś innym projekcie jest dobrym rozwiązaniem.

Nie mam nic wspólnego z projektowaniem gameplay’a ani z żadnymi innymi pracami niekodowymi. Natomiast, co będzie najpewniej moją robotą, to różnego rodzaju toole (co prawda dowiedziałem się, że żaden toolset nie jest na razie w planach, ale zobaczymy wkrótce – coś mi się wierzyć nie chce że wystarczy Notatnik ) i podłączenie jakichś skryptów do gry. Do robienia “misji” się przyda – a podobno na tym ma się rozgrywka opierać.

Coraz bardziej ciągnie mnie do kodowania tooli, coraz mniej bawi mnie pisanie samej gry. Znajduję specjalizację?

Ciemna strona… Visuala

Ostatecznie dzisiaj przekonałem się do ciemnych kolorów. Jakoś wcześniej nie mogłem znaleźć ani stworzyć takiego zestawu kolorów w Visualu, który byłby przyjemny dla oka i wygodny przy pisaniu. Używałem więc troszkę zmodyfikowanego zestawu standardowego, aż w końcu… znalazłem. Właściwie przez przypadek, bo nigdy tak naprawdę porządnie ciemnego zestawu nie szukałem (było mi dobrze na jasnym), dzisiaj wpadł mi w pasek adresu Firefoksa: http://www.codinghorror.com/blog/archives/000682.html. Tutaj także lekkie zmiany były potrzebne, ale jak zauważyłem po paru godzinach pisania – te kolory są lepsze niż standardowe i oczywiście lepsze od wielu innych, które widziałem wcześniej. Teraz tylko pozmieniać kolory okien w Windowsie i będzie się dużo lepiej kodzić

Sceny

Na początku zabawy z PhysXem jako mapki używałem kilku plane’ów wygenerowanych w kodzie poprzesuwanych i poobracanych odpowiednio. Dzisiaj jednak przestało mi już to wystarczać (dodawanie kolejnej ścianki było już strasznie uciążliwe) i uznałem, że czas zrobić jakąś scenkę w narzędziu lepiej się do tego nadającym.

Uruchomiłem 3ds maxa i po jakichś 2 godzinach pracy udało mi się stworzyć fajną, niewielką scenkę zawierającą najważniejsze elementy do testów – schodki, ściany, piętro i równia pochyła, wszystko ładnie pokolorowane (kolory standardowe, które nadaje max – nie udało mi się zmusić go do przypisania tekstury ). Skoro scenę już mam…

To trzeba ją jakoś wczytać w silniku. Dzięki eksporterowi dostępnemu na stronie OGRE mogę sobie ładnie wszystko poeksportować – zarówno samą scenę, jak i obiekty (do plików .mesh). Wyeksportowana scena jest przechowywana w pliku XML. Muszę się przyznać, że nigdy tego formatu nie lubiłem. Przerost formy nad treścią, moim zdaniem – skoro program wie, co po kolei chce wczytać, to po co dodatkowe etykietki w pliku? A skoro formatu nie lubię, to i go używać nie będę. Właśnie jestem w trakcie wymyślania nazwy dla toola wczytującego się w plik XML z wyeksportowana sceną, tworzącego dane kolizji i eksportującego to wszystko do jakiegoś pliku binarnego. Tak, to wydaje się być ciekawe. Lubię pisać toole ;]

Poniżej dwa screeny z maxa – grafików, jeśli jacyś to oglądają, uprzejmie proszę o nieśmianie się, to jest tylko scenka do testów

Co tam w kodzie?

W końcu jakiś post związany z kodzeniem

Od jakiegoś czasu bawię się z OGRE i PhysX, testując i dopisując różne rzeczy. W miarę upływu czasu i zwiększania wiedzy i umiejętności korzystania z tych dwóch silników, ukierunkowuję poznawanie i pisanie nowego kodu pod następny, planowany projekt.

Dzisiaj zająłem się character controllerami (jak to można na polski sensownie przetłumaczyć?). Demo z SDK PhysXa bardzo szybko pokazało, że PhysXowy character controller to nie to, czego potrzebuję – postanowiłem więc napisać własny, oparty o nieprzewracającą się kapsułę. Poruszanie się w poziomie załatwiam przez ustawianie prędkości liniowej, a skok przez podziałanie dużą siłą po naciśnięciu spacji. Słowem, nic specjalnego – ale w testach wychodzi dużo wygodniej niż rozwiązanie z SDK (oparte o ciało, na które nie działają żadne siły – zwłaszcza spadanie z wysokości wygląda beznadziejnie). Jutro zapewne opakuję to w jakąś ładną klasę, umożliwiając podczepianie pod kontroler różnych źródeł sterowania (w zasadzie tylko klawiatura i AI).

Wygląda na to, że będę miał pierwszy fragment użyty w nowej grze… Jeszcze się zobaczy