All blog entries, ordered from most recent. Entry count: 1198.
# Binarny format logowania
Fri
10
Aug 2007
Pisząc coś dużego i działającego nieustannie - np. jakiś serwer - potrzebny jest mechanizm logowania do formatu, który zajmowałby mało miejsca i nadawałby się do prostego, automatycznego przetwarzania. Zwykły format tekstowy moim zdaniem nie spełnia tych wymagań zbyt dobrze.
Dlatego pomyślałem sobie, że gdybym kiedyś coś takiego pisał, zaprojektowałbym format binarny. Plik w takim formacie składałby się z komunikatów, a każdy z nich miałby rodzaj, czas oraz szereg parametrów w postaci "Klucz=Wartość". Zbiór parametrów i typy ich wartości mogłyby być ściśle określone dla każdego rodzaju komunikatu, dzięki czemu możnaby nazw parametrów w ogóle nie zapisywać, a dane wartości zapisywać binarnie - czy to będą liczby, daty, łańcuchy czy dowolne inne dane.
To wszystko oczywiście ma sens tylko pod warunkiem, że zgodzilibyśmy się poświęcić czytelność pliku tekstowego i podglądać logi wyłącznie z poziomu specjalnego narzędzia. Wówczas przykładowy zaprezentowany użytkownikowi komunikat mógłby wyglądać tak:
[2007-08-10 10:03:15] Connection: IP=83.30.195.89, Login="Zbyszek", Result=SUCCESS
# Parsowanie parametrów wiersza poleceń
Thu
09
Aug 2007
Wiele programów, nie tylko konsolowych, akceptuje jakieś parametry wiersza poleceń. Wbrew pozorom zagadnienie nie jest banalnie proste. Zależnie od tego czy program jest konsolowy czy okienkowy, kod wyposażamy w funkcję main lub WinMain. Skutkiem ubocznym jest, że w pierwszym przypadku dostajemy wiersz polecenia już rozłożony na poszczególne parametry (argc, argv), a w drugim przypadku jeden łańcuch ze wszystkimi parametrami.
Ponadto przydatny jest swego rodzaju parser, rozkładający parametry na poszczególne przełączniki i ich ewentualne dane. W Linuksie załatwia to funkcja systemowa getopt, a jej możliwości są imponujące. Nikogo, kto używa tego systemu nie dziwią kombinacje takie jak łączenie opcji typu -cvz zamiast -c -v -z czy sklejanie opcji z danymi typu -lpthread zamiast -l pthread. W Windowsie polecenia systemowe używają opcji zapisywanych w formie /Opcja, ale nie ma w systemie mechanizmu do ich parsowania.
Dlatego chciałbym tu pozachwalać moją klasę CmdLineParser, która załatwia wszystkie powyższe problemy. Jej napisanie poprzedziłem dokładnymi badaniami, jak w Windows i w Linux zachowują się parametry wiersza poleceń. Klasa działa zarówno z parametrami funkcji main, jak i WinMain. Akceptuje opcje zarówno w formie Windowsa, jak i Linuksa, zarówno długie jak i krótkie. Jest przy tym prosta w użyciu i przenośna. Wchodzi w skład modułu Base mojej biblioteki CommonLib 6.1. Szczegóły:
Comments | #productions #algorithms Share
# Swobodne drzewo ósemkowe
Tue
07
Aug 2007
Technik podziału przestrzeni jest wiele. Ostatecznie chyba zdecyduję się na drzewo ósemkowe (Octree) + Frustum Culling + Occlusion Query. To powinno wystarczyć do względnie szybkiego działania i być proste do napisania - dużo prostsze niż portale, które planowałem wcześniej.
W "Perełkach programowania gier", tom 1, znajduje się artykuł poświęcony swobodnym drzewom ósemkowym. To dobry sposób na pozbycie się problemu "lepkich płaszczyzn" i tym samym polepszenie działania całej techniki. Polega na rozszerzeniu obszarów obejmowanych przez poszczególne węzły drzewa tak, że nachodzą na siebie. To nachodzenie nie stanowi problemu, a dzięki niemu obiekty przecinające środek węzła mają szanse trafić w całości do jego podwęzłów.
Moją uwagę zwrócił w artykule jeden szczegół. Nie rozumiem otóż, po co zwiększać obszar w kierunku wystającym poza obszar węzła nadrzędnego? Przecież obiekty, które do niego trafiły i tak zawierają się w obszarze węzła nadrzędnego. Dlatego ja zrobiłem to trochę inaczej. Czyżbym się gdzieś pomylił w swoim myśleniu?

Comments | #rendering #algorithms Share
# Układanie map
Mon
06
Aug 2007
Każdy, kto planuje wyświetlać mapy Indoor (wnętrza budynków czy jaskiń) staje przed decyzją, jak układać te mapy. Przeszukując fora można dojść do wniosku, że problem jest powszechny. Z tego, co udało mi się ustalić, wyjścia są takie:
# Dwa przydatne programy
Sun
05
Aug 2007
Moi koledzy napisali ostatnio w C# dwa przydatne programy.
SendFile (autor: Krystian D.) to program do przesyłania plików - coś jak mój pomysł o nazwie JustSendIt. Wyróżnia go fakt, że zarówno nadawca, jak i odbiorca może być za NAT-em, ponieważ transmisja odbywa się za pośrednictwem... skryptu PHP umieszczonego na wybranym koncie WWW.
ScreenUp (autor: Spax) służy do łapania zrzutów ekranu. Wyróżnia go fakt, że program działa w tle, reaguje na wciśnięcie klawisza zbierając kolejne zrzuty, a potem pozwala łatwo wysłać je na serwer i otrzymać adres URL do screenów udostępnionych już w Sieci.
Comments | #tools #warsztat Share
# Rozwiązania dla relacji zawierania
Sat
04
Aug 2007
Innym problemem projektowym jest realizacja wszelkiego rodzaju kontenerów przechowujących jakieś elementy, np. Scena przechowuje Encje, Światła, Materiały, Manager Zasobów przechowuje Zasoby itp.

Autor diagramu: Xion
# BlizzCon
Sat
04
Aug 2007

Trwa właśnie BlizzCon - konferencja firmy Blizzard. Warto śledzić stronę, chociażby żeby zobaczyć galerię zdjęć, kiedy już się pojawi.
# Problem silnika
Fri
03
Aug 2007
Kiedy człowiek uczy się Direct3D, wszystko wydaje się takie proste. Kiedy chce przejść na wyższy poziom abstrakcji, wszystko się komplikuje. Chciałoby się zamknąć abstrakcyjne pojęcia w eleganckie klasy, ale w końcu ich dane muszą się spotkać w jednym miejscu, aby ustawić (w moim przypadku także skompilować) odpowiedni shader, jego stałe oraz inne ustawienia Direct3D. Te dane pochodzą z różnych miejsc:
Jak to zrealizować w kodzie? U siebie dotychczas miałem tak, że kompletowana była struktura RENDER_DESC. To do obiektu trafiały pozostałe dane, a obiekt dodawał swoje dane i wysyłał strukturę do obiektu klasy ShaderManager. W Sieci znalazłem z kolei taki pomysł, w którym to materiał dostaje dane, uzupełnia je swoimi i wysyła do ustawienia. No i co tu zrobić? :)
