Import archiwum GG do Pidgin

Pidgin to całkiem przyjemny multikomunikator, obsługujący między innymi protokół znanego i nielubianego GG, dobra alternatywa dla oficjalnego klienta. Przy zmianie klienta nie chciałem jednak rozstać się ze swoim archiwum, do którego jestem mocno przywiązany, dlatego zacząłem googlować, i szybko dowiedziałem się, że do Pidgin "nie da się" zaimportować archiwum z GG. Skoro się nie da, to na szybko zobaczyłem jaki jest format archiwum w nowym kliencie, i napisałem konwerter. Ponieważ z braku czasu cała operacja nie mogła przekroczyć godziny, pogooglałem znowu i znalazłem fajny programik do zamiany archives.dat z GG na plik txt (i przy okazji dobry opis formatu archiwum) http://users.v-lo.krakow.pl/~anszom/ggarch/index.pl.shtml

Pomyślałem, że może konwerter się komuś przyda (może nie każdy będzie musiał pisać własny :P) więc udostępniam. Skąd wziąć archives.dat? Z "C:\Documents and Settings\NAZWA_KONTA\Gadu-Gadu\KONTO_GG". W wyniku działania konwertera wygeneruje się spora liczba plików (i mogą troszkę ważyć - mi z 18 megowego archiwum zrobiło się 30, przy czym "rozmiar na dysku" to aż 82. Ahh to wyrównanie... Gdzie je wrzucić? "C:\Documents and Settings\NAZWA_KONTA\Dane aplikacji\.purple\logs\gadu-gadu\TWOJ_NUMER_GG\". I tyle, po wrzuceniu wygenerowanych plików do tego folderu Pidgin sobie już poradzi.

[DOWNLOAD]

The kulkis

This is a simple 3D shooting game, created in one week from scratch in C++, OpenGL using ODE physics engine. There are some troops of yellow spheres flying around the city. The goal is to shoot them with red ones, but... when you shoot a troop, they start to panic and escape. The red ones become yellow after some time, so you have to shoot reasonably. Red ones have also an advantage - they pursuit yellow ones :)

[DOWNLOAD]

Widmo molocha...

Dzisiaj nietypowy post, mający stanowić antyreklamę firmy którą wszyscy dobrze znają - TPSA. Opowiem krótką bajkę o tym co mnie boli. Od jakiegoś czasu (będzie ze 2 miesiące) neostrada zrywa mi połączenie, średnio na 6h w ciągu dnia, w dodatku najczęściej w najmniej korzystnych godzinach (prawo Murphyego). Na początku podszedłem do sprawy bardzo spokojnie - zadzwoniłem do obsługi technicznej, przysłali technika, który stwierdził, że winę ponosi listwa antyprzepięciowa, przez którą połączony jest modem do gniazdka (bzdura, ale nvm). Odłączyłem listwę, żeby nie było, że robię coś wbrew zaleceniom. Połączenie nadal zrywało, więc kolejny telefon do obsługi. Dokładnie taka sama rozmowa - "a telefon jest połączony przez mikrofiltr? a kabel jest podłączony? a komputer to pan włączył?" No kurwa mać ;/ Zgłoszenie poszło do techników, którzy nawet nie raczyli się umówić, o przyjechaniu nie wspominam. Potem było kilka rozmów o tym "czy połączyłem telefon przez mikrofiltr" i wezwań techników którzy się nie pojawiali. W ostatniej rozmowie pan w słuchawce powiedział mi praktycznie wprost, że mogę go opieprzać jak chcę a to i tak nic nie da, bo on ma gówno do tego, i co najwyżej może wezwać do mnie techników. Technik zadzwonił w niedzielę o 9.00 przed świtem, umówił się na poniedziałek między 13 a 15. Zarezerwowałem czas, czekałem, nie pojawił się, najnormalniej w świecie, parszywie mnie olał.

Konkluzja jest taka - jeszcze nie wiem jak to załatwić, ale albo pozwolą mi przedterminowo zerwać umowę, albo ich zaskarżę, bo to co robią, to najnormalniejsze w świecie świństwo. Zapomnieli, że już nie są monopolistą, i że mogę zmienić ich denną neostradę na inny "internet".

Efekty uboczne

Przy okazji robienia proceduralnego generatora teł do gry przypadkiem wygenerowałem całkiem ciekawe obrazki. Wprawdzie kompletnie bezużyteczne przy mojej aktualnej pracy, ale ruszyły moją wyobraźnię i myślę, że mogłyby mieć spore zastosowanie w demoscenie na przykład. Szczególnie, że generatorem jest zwykły atraktor pickover (kto nie zna, odsyłam do chaoscope) z drobną wariacją, ustalającą kolor na podstawie odległości od źródeł światła, czyli można to zaimplementować w "paru" bajtach dosłownie.

 

Takie efekty uboczne bardzo często są powodem powstawania nowych pomysłów, rozwiązań czy algorytmów. 

Re: Pola i akcesory wewnątrz klas

Do napisania tego posta sprowokował mnie Xion, swoją notką. Kiedyś sam o tym troszkę rozmyślałem, i doszedłem do wniosku, że zwykle wewnątrz klasy lepiej jest się odwołać bezpośrednio do składowych. Są jednak pewne wyjątki. I tutaj historia z życia wzięta, ale rozpisywać się nie będę, bo jak wiadomo jeden pseudokod znaczy więcej niż tysiąc słów :P

class Scene {

// trzy wskazniki na glowne macierze 
const Matrix4x4* modelMatrix;
const Matrix4x4* viewMatrix;
const Matrix4x4* projMatrix;

// od groma wyliczonych z nich macierzy 
Matrix4x4 modelViewMatrix, modelViewProjMatrix, invModel, (...), invModelViewProjMatrix;

bool /* w oryginale tu jest bitset */ modelChanged, (...), invModelViewProjChanged; 

public:

// tylko trzy metody set 
void setModelMatrix(const Matrix4x4* m) const;
void setViewMatrix(const Matrix4x4* m) const;
void setProjMatrix(const Matrix4x4* m) const;

// od groma metod get
const Matrix4x4& getModelMatrix() const; 
(...) 
const Matrix4x4& getInvModelViewProj() const;

};

Do tego dodajmy klasę ShaderManager, która pobiera sobie te macierze (i nie tylko, ale nie będę mieszać tutaj za bardzo, bo do puenty nie dojdę nigdy). I teraz - jak słusznie zauważył Xion użycie metod set na zewnątrz klasy Scene nie budzi (nie powinno!) wątpliwości. W tym przypadku jest to również konieczne wewnątrz. Przyczyna? Ktoś kto uważnie przeczytał pseudokod pewnie się domyśla, że liczenie (bądź co bądź kosztowne, szczególnie w przypadku inverse) macierzy jest odłożone do pierwszego get. Natomiast set aktualizuje odpowiednie wartości "changed". W przypadku nieużywania set trzeba te wartości zmienić ręcznie, co powoduje generalny syf w kodzie.

Pojawia się tutaj pytanie - co jeśli ktoś używa naszej klasy i o tym nie wie, i napisze gdzieś po prostu modelMatrix = identity4x4. Albo (o zgrozo :P) my sami mamy już tak rozdmuchaną klasę, że o tym zapominamy. Znalezienie błędu potem może być dosyć kosztowne. Moje rozwiązanie (które stosuję) polega na wywaleniu całej logiki związanej z macierzami do klasy SceneMatrix, gdzie macierze są w prywatnym obszarze a metody w publicznym, i dziedziczenie po niej. Zaleta jest taka, że w zależności od potrzeb możemy dziedziczyć publicznie lub prywatnie i w ten sposób udostępniać lub chować metody get / set na zewnątrz. Przy takim podejściu nie ma mowy o "zapomnieniu", że trzeba użyć set zamiast operatora=. Wadą jest to, że zwykle prowadzi to do wielodziedziczenia, ale moim zdaniem nie jest to ani błąd ani problem w takim przypadku.

Geometria w C++

Każdy kto pisze silnik graficzny, fizyczny, lub po prostu grę, potrzebuje często używać algorytmów geometrii obliczeniowej - triangulacji, liczenia otoczek wypukłych, operacji Boolowskich na wielokątach lub geometrii 3 wymiarowej, czy choćby prostym sprawdzaniu kolizji punktu z bryłą. Są to algorytmy używane w większości dziedzin związanych z kodowaniem gier i nie tylko, również ważne w CADach, robotyce, sofcie medycznym etc. Ponieważ odkrywanie koła po raz setny jest bezsensowne, postanowiłem znaleźć bibliotekę realizującą takie zadania za nas.

CGAL (Computational Geometry Algorithms Library) wydaje się być strzałem w dziesiątkę. Jest to bardzo dojrzały projekt, rozwijany od 97 roku o ile się nie mylę. Obecnie doczekał się już wersji 3.5. Udostępnia bardzo pokaźną liczbę struktur danych i algorytmów. Poszczególne biblioteki projektu są proste w użyciu i dobrze udokumentowane. Całość napisana jest z myślą o C++, ale z tego co wyczytałem jest również wsparcie dla Pythona (co może się przydać w pisaniu skryptów do AI). Szczegółowy przegląd ficzerów można znaleźć na stronie http://www.cgal.org/

Teraz licencja - do zastosowań niekomercyjnych CGAL jest darmowy (połowicznie na licencji LGPL i QPL). Natomiast w przypadku zastosowań komercyjnych tak różowo nie jest, trzeba zakupić licencję, niestety nie znalazłem ceny na ich stronie.

Wykobi jest dużo mniej rozwiniętym (obecnie wersja 0.0.4), ale również ciekawym i dobrze zapowiadającym się projektem na licencji GNU GPL w przypadku zastosowań niekomercyjnych oraz na płatnej licencji w przeciwnym przypadku. Warto zobaczyć co oferuje, na stronie http://www.wykobi.com/

VGL jest częścią większego pakietu VXL. Nie oferuje zbyt wiele, tak na prawdę jest to zbiór struktur danych oraz kilku podstawowych algorytmów, głównie do transformacji przestrzennych. Jednak uznałem, że warto go odnotować, choćby ze względu na możliwość używania za free po spełnieniu podstawowych warunków o dołączeniu licencji, nie używaniu TM i wyraźnym zaznaczeniu modyfikacji. Cały pakiet VXL oferuje już troszkę więcej - między innymi algorytmy algebry liniowej i operacje na obrazach. http://vxl.sourceforge.net/

Na koniec zostawiłem Generic Geometry Library (GGL), która nie oferuje wprawdzie tyle co CGAL, ale jest całkowicie darmowa. Jest to kandydat do wcielenia w zestaw libów Boost. Udostępnia kilka ciekawych funkcji jak liczenie otoczki wypukłej (algorytm Grahama), clipping czy proste testy kolizyjne (a raczej bazę do takich testów). http://geometrylibrary.geodan.nl/index.html

Muszę jednak wspomnieć o dokumentacji do GGL, która jest... tragiczna. Dobrym przykładem jest opis użycia klasy graham do liczenia otoczki wypukłej. Jest on wygenerowany przez doxygena, co bardzo lubię, ale brakuje tam choćby słowa komentarza od autora.

Na koniec dodam, że jeśli ktoś zna inne ciekawe liby (najlepiej free) to zachęcam do podzielenia się linkiem :)

SSequence, 4k intro sequencer

This small application purpose is to create sounds (like beat or hat) for 4k intros, that can be later composed into music. The sounds are exported directly into C++ header file (in the form of code that generates them). It was created using C++ and wxWidgets. The tool was never released due to lack of time to finish it. Anyway, it was kind of fun.