Danny MacAskill - "Way Back Home"

Dziś nieco inaczej niż zwykle, link: Danny MacAskill - "Way Back Home". Jestem pod ogromnym wrażeniem.

Remont silnika odpowiedź

Anonimowy użytkownik zapytał czemu w poście Remont silnika wyraziłem nie chęć do stosowania rozwiązań typu singleton "Czemu zero rozwiązań typu singleton? Globalny, jednolity stan w jakiejkolwiek formie (monostate, singleton, zwykła klasa statyczna), jest bardzo naturalny i nie ma sensu unikać go na siłę w imię jakichś pustycznych idei."

Odpowiedź jest dość obszerna, także umieszczę to w nowym wpisie.

Moim zdaniem największym problemem z wszelkiej maści obiektami o dostępie globalnym są zależności jakie powstają pomiędzy różnymi modułami oprogramowania.
Pisząc swój silnik graficzny byłem bardzo pozytywnie nastawiony do tego typu rozwiązań, bo "ułatwiały" mi życie. Dzięki nim mogłem zmniejszyć ilość parametrów przekazywanych do metod. Unikałem również przekazywania obiektów w głąb hierarchii wywołań. (chcemy zasób, więc przekazujemy managerowi obiekt api, ten przekazuje go fabryce, ta przekazuje go konkretnej metodzie). Kto potrzebuje singletona ten sam może go sobie wziąć. I tak właśnie powstają zależności pomiędzy jednym modułem, a drugim. Przykładowo klasa tekstury potrzebowała rozmiar okna dla którego będzie render targetem. Bach, okno jest singletonem, wszyscy maja do niego dostęp. To był chyba największy błąd projektowy jaki popełniłem.

Zależności się nie skalują. Zmiana w jednym module często pociąga ogromne zmiany w całym systemie.
Zależności się bardzo szybko rozrastają. Ja w końcu się pogubiłem w kolejności otwierania i zamykania modułów. We własnym kodzie straciłem orientację.
Zależności się nie skalują. Jak zapewnić rozsądny dostęp do globalnych obiektów w środowisku wielowątkowym?
Obiekty globalne gryzą się z raii. Obiekt globalny jakim jest std::clog jest bardzo wygodny kiedy potrzebujemy coś logować. Osobiście bardzo często z niego korzystam, w taki sposób, że podpinam pod niego plik.
W main robie sobie taki trick:
fstream log("log.log" fstream::out);
clog.rdbuf(log.rdbuf());
Potem w dowolnym miejscu kodu wystarczy zapisać do std::clog i wszystko trafi do pliku.
Informacją, którą szczególnie warto logować jest moment otwierania i zamykania poszczególnych modułów. Obiekt zarządzający modułem powstanie już po otwarciu pliku, więc log powstanie poprawnie. Jeżeli jednak pozwolimy istnieć takiemu obiektowi poza czas trwania maina to mamy problem. Ja nie raz popełniłem taki błąd, nie tylko przy projekcie tego silnika. Niby wiem, że tak jest, a i tak wciąż popełniam ten błąd.

Remont silnika

Dawno nic nie napisałem, nie mam czasu. Chcemy się przeprowadzić i aktualnie robimy dość poważny remont mieszkania. Oczywiście oboje z żoną jesteśmy zatrudnieni i wszystkie prace remontowe odbywają się po zakończeniu obowiązków zawodowych (długo myślałem jak usunąć 3 razy praca z tego zdania). Generalnie jest masakra :)

Pochwalę się tylko, że wznowiłem prace nad swoim silnikiem. Podczas pierwszego podejścia sporo się nauczyłem. Postanowiłem wykorzystać to doświadczenie i rozpocząć wszystko od nowa.

• zmienię strukturę projektu. Poprzednio zrobiłem sobie straszną krzywdę i wszystko zamknąłem w jednym projekcie. Tym razem rozbije całość na sporą ilość małych projektów. Ułatwi to zarządzanie i testowanie kodu.
  
• ograniczę idioto odporność na korzyść możliwości. Poprzednie rozwiązanie zakładało, że użytkownik jest głupi i broniłem dostępu do rzeczy takich jak zasoby czy directx.
  
• zero automagiczności. Uważałem, że jeżeli silnik potrzebuje okna to powinien je umieć sobie otworzyć sam. Dzięki temu użytkowanie było banalne, o ile użytkownik chciał mieć dokładnie jedno okna o takich i takich właściwościach. Teraz uważam, że jeżeli użytkownik chce mieć okno to je sobie zrobi, jeżeli chce aby silnik coś w nim wyrenderował to powie o tym silnikowi.
  
• mam zamiar zastosować model warstwowy. Poprzednio podzieliłem system na moduły i wyszedł mi z tego straszny galimatias.
  
• zero rozwiązań w stylu singleton. Wszystkie niezbędne dane są przekazywane przez parametry wywołania.
  
• wciąż trzymam się rozwiązań obiektowych.
  
• DirectX 10. Im dłużej patrzę na wersję 10 tym mniej podoba mi się 9. OpenGL nigdy nie był obiektem mojego uwielbienia.

Rysowanie map

Ostatnio pracowałem nad aplikacją która pozwoli na wyznaczenie jakiegoś obszaru na mapie. Dane mapy pobieram za pomocą biblioteki OGDI z VMAP'y, rysowanie odbywa się poprzez OpenGL, obsługa okien dzięki SDL.

To był mój pierwszy kontakt z mapami w formie elektronicznej, tzn. wiem co to googlemaps, ale nigdy wcześniej nie próbowałem wydobyć i wykorzystać takich informacji „własnoręcznie”. Nigdy też nie zastanawiałem się jak to jest robione. Także:
- VMAP to bardzo skomplikowana struktura, mapa Europy i Północnej Azji na poziomie 0, czyli największej skali i najmniejszej precyzji, to 509 megabajtów danych w blisko 4 tysiącach plików !!!
- Nie wyobrażam sobie samemu zrobić obsługę takiego molocha w żadnym sensownym czasie,
- OGDI pozwala na obsługę danych geograficznych podobnie do bazy danych, podajemy kryteria (obszar geograficzny) oraz tabelę (warstwę), w wyniku otrzymujemy zbiór rekordów spełniających zapytanie,
- Dane mogą przyjąć formę punktów (miasta), linii (drogi), obszarów (lasy), bądź tekstu. OGDI dopuszcza jeszcze parę innych, ale ja się z nimi nie spotkałem,
- Obszary to tak naprawdę zamknięte linie i żeby je narysować trzeba najpierw zamienić dane w coś co jest akceptowalne przez OpenGL. Tak, tak, na trójkąty,
- Zamiana obszaru, który nie jest wypukły i ma w sobie otwory, z formy konturów na trójkąty nie jest zadaniem trywialnym,
- Na szczęście istnieje OpenGL ze swoim zestawem funkcji do teselacji (gluBeginPolygon i spółka).


Przetworzenie danych z obszaru Polski na formę, którą można w miarę wydajnie renderować trwa dość długo (parędziesiąt sekund), a aplikacji rysujących mapy będzie jeszcze kilka i wszystkie będą używane naprzemiennie. Nie ma takiej możliwości aby pracowały równocześnie i nie ma takiej możliwości aby włączały się tak długo. Uznałem więc za sensowne opracowanie pomocniczego procesu, który przygotuje te dane raz i udostępni je w formie pamięci współdzielonej. W tym celu wykorzystałem boost::interprocess::shared_memory_object.

Screeny (przedstawiają Łódź):

Ciekawy błąd

Przy aktualnym projekcie korzystam z biblioteki ogdi. Ma ona formę plików .dll oraz .lib. Aplikacja skompilowała się oraz zbudowała bez problemu, jednak jej uruchomienie zakończyło się pojawieniem komunikatu o błędzie: "An application has made an attempt to load the C runtime library incorrectly." o kodzie R6034.

Tutaj jest link do opisu problemu na stronie Microsoftu: link.

Gdyby ktoś trafił na podobny problem i nie od razu załapał o co chodzi z tym manifestem, to służę wyjaśnieniem. Domyślnie VS zamieszcza manifest wewnątrz aplikacji, dzięki temu system potrafi załadować niezbędne biblioteki. W tym wypadku mechanizm zawiódł, ponieważ najwyraźniej plik ogdi.dll potrzebuje załadować dodatkowe zależności, ale sam nie zawiera manifestu. Trzeba, więc dodać manifest pliku ogdi.dll do naszej aplikacji.

Urlop

Na przełomie czerwca i lipca pojechaliśmy z żoną do Krynicy Morskiej. Trafiła nam się cudowna pogoda. Przez te 8 dni padało raz i to wieczorem. Oczywiście taki wypad zaowocował masą zdjęć, szczególnie plaży i morza podczas zachodu słońca.






Wspomniany deszcz także dał okazję do „cyknięcia” kilku ujęć:



Niestety wyjazd ujawnił też parę ciemnych stron. Po pierwsze, niesamowita wręcz ilość wodorostów (czyżby efekt uboczny powodzi?). Przy brzegu było ich tyle, że tłumiły fale! Mało przyjemnie wchodzi się do takiej wody. Oczywiście fale wyrzucają te wodorosty na brzeg, gdzie zwyczajnie gniją. Smród i brud. Po drugie remont dróg. Akurat obok naszego noclegu i po drodze nad morze kładli asfalt. Smród i brud.

"Tylko dwie rzeczy są nieskończone: Wszechświat ..."

Dzisiaj nie będzie ani o programowaniu, ani o fotografii. Dzisiaj chciałbym napisać o obserwacji jaką poczyniłem wczoraj, a do której wyjątkowo dobrze pasuje ten cytat:

"Tylko dwie rzeczy są nieskończone: Wszechświat oraz ludzka głupota, choć nie jestem pewien co do tej pierwszej." - Albert Einstein.

Wczoraj, to jest w niedzielę 13 czerwca 2010 roku, byłem w teatrze, gdzie byłem świadkiem dość szokującego dla mnie zachowania. Otóż obok nas siedziała dziewczyna w taki sposób, że podeszwa lewego buta znajdowała się na jej fotelu. Nie wiem jak to opisać, istotne jest to, że pobrudziła fotel na którym sama jeszcze siedziała. Dziewczyna moim zdaniem w wieku licealnym.

To, że nie wiedziała, że do teatru nie wypada przyjść w tenisówkach mnie nie zaskoczyło. To, że pobrudziła fotel też nie zrobiłoby na mnie wrażenia, wandalizm jest niestety dość codziennym zjawiskiem. To co mnie poruszyło w tej sytuacji to kompletna, bezkresna wręcz, bezmyślność naszej bohaterki.

Ludzie używajcie mózgu!

"Ciepło jest, chodźmy na spacer ..."

Tak to właśnie się zaczęło. Trzeciego czerwca rano było pochmurnie, ale ciepło. Postanowiliśmy z żoną pójść pod lotnisko i tam z aparatem polować na lądujące samoloty. Wychodząc trochę z obawą patrzyłem na pozostawiony na miejscu parasol. Na szczęście nie padało, w gruncie rzeczy słońce wyszło zza chmur jeszcze zanim doszliśmy na miejsce.

Nad lotniskiem krążyły dwa samoloty. Piloci najwyraźniej trenowali lądowanie, bo zaraz po dotknięciu ziemi maszyny podrywały się do dalszego lotu.


Po powrocie do domu zaczęło mi się kręcić w głowie, przed oczami ciemno. Długi pobyt na mocnym słońcu bez czapki skończył się udarem. Bardzo nieprzyjemne przeżycie i bardzo niebezpieczne.


W sobotę pojechaliśmy zjeść rybę w Sereczynie. Świetne miejsce i dają naprawdę smaczne ryby.

A na kolację gril w ogrodzie.

OpenGL i koordynaty pikseli

Aktualnie pracuję nad prościutką biblioteką do robienia graficznego interfejsu użytkownika. Potrzebna mi będzie do tworzenia kilku współpracujących ze sobą aplikacji. Jest to rozwiązanie "Immediate Mode", rysowanie odbywa się za pomocą OpenGL, natomiast świadomość urządzeń wejściowych uzyskana dzięki SDL.

No i jak to zwykle bywa natknąłem się na pewien problem. Otóż ramka rysowana wokół guzika była nie domknięta, brakowało lewego dolnego piksela.

Kod rysujacy ramkę:
glBegin(GL_LINE_LOOP);
    glVertex3f(vertexACoordX, vertexACoordY, 0.0f);
    glVertex3f(vertexBCoordX, vertexBCoordY, 0.0f);
    glVertex3f(vertexCCoordX, vertexCCoordY, 0.0f);
    glVertex3f(vertexDCoordX, vertexDCoordY, 0.0f);
glEnd();

Rozwiązanie znalazłem tutaj: link. Przy okazji wyszedł kolejny problem, faktycznie rozmiar ramki nie pokrywa się z tłem. Wychodzi na to, że trzeba sobie ręcznie poprzesuwać wierzchołki aby wszystko się ze sobą ładnie zgrało.

Wracając jednak do problemu, co jest przyczyną ? Podanie całkowitych wartości dla współrzędnych punktów sprawia, że rysujemy dokładnie pomiędzy dwoma pikselami. W celu uniknięcia tego problemu należy przesunąć współrzędne o wartość 0.5, alternatywnie możemy włączyć wygładzanie linii:

glEnable(GL_LINE_SMOOTH);

To drugie podejście owocuje niestety pogrubieniem naszej ramki.


Odkryłem też pewien zaskakujący brak w SDL, nie daje możliwości zmian położenia i rozmiaru okna. Znaczy da się to zrobić, ale wymaga samodzielnego wykonania czynności specyficznych dla danego OSu.

Majowe fotki

Trochę mi się uzbierało fotografii przez ostatni miesiąc. Wczoraj udało mi się te najfajniejsze zamieścić na Picasie. Niektórzy już nawet zdążyli je tam skomentować ;)

Najstarsze są zdjęcia ruchu ulicznego zrobione nocą. Przy ich robieniu powstała również ogromna panorama, 180 stopni, 18 x 1 zdjęć, o wymiarach ~27 tysięcy na ~4 tysiące pikseli.
Najfajniejsze wychodzą zdjęcia autobusów. Te wszystkie boczne/górne światła, wyświetlacze LED dają super efekty. Myślę o wybraniu się na jakiś punkt znajdujący się nad ruchliwą drogą (most, kładka etc.) tak aby uzyskać zdjęcia bardziej na wprost.


Kolejny album to zdjęcia zrobione w ogrodzie. Małe kociaki są urocze, zabawne, wszechobecne i koszmarnie ruchliwe. Tego dnia zrobiliśmy im dobrze ponad 200 fotek, i prawie na wszystkich są rozmazane :) Ta roślina, której zdjęcie tu podlinkowałem to Rododendron.



Dwudziestego drugiego maja późnym wieczorem niedaleko Łodzi przeszła burza. Zdjęcia robione ze statywu z automatycznym wyzwalaniem przez interwalometr (czuję się trochę mniej zdradzony :) ). Jak zauważył Wojciech Toman bardzo zaszumione. Winny jest, jak sądzę, przede wszystkim bardzo długi czas naświetlania. Drugim winowajcom jest Picasa, która nieco przesadziła z dodaniem ekspozycji, przy konwersji z raw do jpg.


Na koniec fotografie przyrody, które robiliśmy przez cały maj. Są to głównie ujęcia z Łodzi, okolice naszego mieszkania oraz park Poniatowskiego.

Fusów ciąg dalszy

Dotychczasowa wersja linuxowego demona montującego budowane przez nas urządzenie (pisałem o tym: link) w formie systemu plików była napisana w Pythonie i miała bardziej charakteru "proof of concept", zbadania czy to ma sens. Nadszedł jednak dzień w którym zapadła decyzja o przepisaniu demona w Cpp.

Oczywiście postanowiłem skorzystać z biblioteki libfuse. Pomyślana jest ona bardzo podobnie do biblioteki dokan, czy może raczej dokan jest opracowany na podobieństwo libfuse.

Wydawało mi się, że ze względu na to podobieństwo zadanie powinno być dość proste. Okazało się jednak, że biblioteka jest dość kiepsko udokumentowana. W zasadzie co by się nie chciało zrobić, to trzeba najpierw przekopać się przez kod biblioteki.

Jednym z pierwszych problemów na jakie się natknąłem było to, że uruchomienie libfuse poprzez funkcję fuse_main startuje demona i zamyka proces. W efekcie o normalnym debugowaniu możemy zapomnieć. Pod Windowsem też się nie dało, ale tam chociaż można było robić logi w konsoli. Niestety zamknięcie procesu oznacza utratę dostępu do uchwytów konsol.
Wujek google zapytany o "debug fuse" poradził mi aby użyć opcji -d. Przełącznik ten sprawia, że fuse_main nie zamyka procesu i zaczyna wypisywać logi. Daje to również dostęp do konsoli naszym funkcjom.

Drugim dość poważnym problemem jest to, że Linux po jakimś czasie głupieje. Objawia się to tym, że nasz system plików nagle przestaje działać, a naszym oczom ukazuje się niewiele mówiący komunikat o błędzie. Zdezorientowani dodajemy logowanie w podejrzanych miejscach, cofamy ostanie zmiany, zaczynamy szukać na oślep co może być przyczyną. Pół dnia później resetujemy system i wszystko działa jak należy :(


Przy okazji tego "projektu" musiałem przenieść, część kodu z Winodwsa na Linux. Jak na razie odkryłem, że obsługa socketów nie wiele różni się pod tymi systemami. Zobaczymy co będzie z portem szeregowym.

Fotografie

Reg zasugerował abym podzielił się fotkami, za pomocą Picasa Web Albums. Tadam tadam, oto zdjęcia:

Jedne z pierwszych zdjęć jakie zrobiliśmy, a także ujęcia z wizyty na lotnisku.



Nasze próby z makro w ogrodzie i nad stawem.



Pojechaliśmy do zoo.

Nikon d5000

Jakiś czas temu postanowiliśmy z żoną kupić sobie cyfrową lustrzankę. Żadne z nas nie miało w tej kwestii żadnych doświadczeń, więc sprawa wcale nie była prosta. Po zapoznaniu się z opinią znajomego profesjonalnego fotografa, przewertowaniu dziesiątek recenzji oraz cenników, zdecydowaliśmy się na tytułowego Nikona d5000.

Pierwsze wrażenie: Skomplikowany. Miałem w swoim życiu parę aparatów fotograficznych, również lustrzankę ("analogową") i pierwszy raz nie wiedziałem jak wyostrzyć obiektyw. Tak wiem do czego służą te pierścienie, ale kiedy zdjęcie jest ostre?
Rozgryzienie tych wszystkich symboli i guzików trochę trwa, ale kiedy już je opanujemy ... o radości!
Drugie wrażenie: W życiu nie miałem tak szybkiego aparatu w rękach. Włącza się szybko, wyostrza się szybko, ustawia się go szybko, zdjęcia też robi szybko. Chwila nie uwagi i ma się parędziesiąt zdjęć na karcie. Jestem zachwycony.
Trzecie wrażenie: Z obiektywem Nikkor 18-105 mm, waży 1060 gram. Noszenie go na szyi nie wchodzi w grę. Wybór torby jest zadaniem trudnym i wymaga użycia linijki, miarki bądź innego sprzętu o zbliżonych właściwościach. Skończyło się na torbie na ramię marki OptiCam. Aparat z założonym obiektywem wchodzi na styk, ale dostęp do niego jest bardzo wygodny.
Podsumowanie: Aparatem cieszymy się już od półtora tygodnia i wciąż nacieszyć się nie możemy. To niesamowite ile radości sprawia mi robienie kolejnych zdjęć. To był bardzo dobry zakup.

Przykładowe fotki, oryginały mają wymiary 4288 x 2848:




EDIT
Dodałem dwa zdjęcia.

IGK 2010

Miałem okazję wziąć udział w VII Ogólnopolskiej Konferencji Inżynierii Gier Komputerowych, czyli tzw. IGK 2010. Pojechaliśmy tam w cztery osoby jako delegacja katedry.

Muszę stwierdzić, że mocno się zawiodłem. Niestety przedstawione prezentacje były znacznie poniżej moich oczekiwań.
To czego mi zabrakło to "praktycznych prac". Fajnie jest się dowiedzieć, że istnieje jakaś technika/technologia/algorytm/..., ale znacznie fajniej jest od razu dowiedzieć się z jakimi problemami wiąże się implementacja, jakie są alternatywy i jak wypada wydajność oraz jakość wyników w konfrontacji z alternatywnymi rozwiązaniami.
Bez tej "praktycznej" części dostajemy coś w stylu tutoriala bądź reklamy.

Sama impreza została zorganizowana bardzo dobrze, był nawet transport z/do hotelu.

Oto lista prezentacji w których wziąłem udział:
1. "Środowisko Adobe AIR jako platforma do budowania gier"
2. "Przegląd gier i przemyślenia związane z technologią Adobe Flash"
3. "Modelowanie obiektów opartych na sile sprężystości"
4. "Interfejs jako podstawowy element rozgrywki"
5. "Implementacja sferycznej metody wizualizacji terenu przy użyciu algorytmu HRTMR"
6. "Wykorzystanie explicit multisample do poprawy jakości deferred shadingu"
7. "Tworzenie gier i aplikacji na platformie iPhone OS z wykorzystaniem UIKit, Core Animation i cocos2d"
8. "Elementy logiki rozmytej w grach komputerowych"
9. "Model zachowań obiektów w symulatorach pola walki i komputerowych grach wojennych"

Na prezentacji "Projektowanie Interfejsów Użytkownika na potrzeby aplikacji interaktywnych" byłem tylko częściowo.

Prezentacja "Postmortem AI w Call of Juarez" się nie odbyła. Szkoda, bardzo na nią liczyłem.

Moim zdaniem najlepszą prezentacją była "Implementacja sferycznej metody wizualizacji terenu przy użyciu algorytmu HRTMR".

Alternatywne opinie:
Xion
Adam Sawicki

Fusy i JNI

W pracy dostałem bardzo ciekawe zadanie. Otóż jest sobie pewne urządzenie nad którym mój zespół pracuje. Urządzenie to składa się z wielu elementów. Elementy mogą mieć pod elementy i parametry. Urządzenie jest podłączane do komputera PC poprzez port szeregowy RS232. Trzeba zapewnić oprogramowaniu na PC prosty dostęp do wszystkich parametrów wszystkich elementów urządzenia.

Ponieważ struktura urządzenia bardzo przypomina strukturę katalogów i plików na dysku twardym i jednocześnie trzeba zapewnić prosty i równoległy (jednego parametru może potrzebować więcej niż jedna aplikacja) dostęp, to pod linuxem wykorzystano tzw. FUSE. Moim zadaniem było opracowanie rozwiązania działającego na Windowsie. Zdecydowałem się na identyczne podejście. Co prawda nigdy w życiu nie napisałem sterownika dla Windowsa, ale ...

W ramach poszukiwań jak cały problem ugryźć trafiłem na bibliotekę Dokan na licencji LGPL i MIT, która robi dokładnie to czego potrzebowałem, tj. montuje urządzenie ze sterownikiem systemu plików, który przekierowuje wszystkie żądania do wskazanych callbacków. Jedynym zgryzem jest to, że próba debugowania kodu funkcji zwrotnych kończy się prawie zawsze BSODem. Nie można oczekiwać aby wielozadaniowy system działał stabilnie w momencie gdy ktoś zatrzymuje mu breakpointem kod jądra. A może można, tylko ja się już tak przyzwyczaiłem do fanaberii produktów Microsoftu?

Kolejnym ciekawym zadaniem, które mi się trafiło była realizacja aplikacji rysującej przebiegi parametrów w formie kontrolki na stronę internetową. Ponieważ wszystko ma działać również pod linuxem wybór padł na applet javy, który w jakiś sposób korzysta z OpenGL.
Wykorzystanie OGL z poziomu javy jest możliwe na przykład za pomocą biblioteki JOGL. Ja jednak miałem już gotowy kod w C++, który realizował całe rysowanie w OGL i nie miałem ochoty się narobić przy przenoszeniu tego do javy (zwłaszcza, że mi osobiście to jego działanie się nie podoba i chciałbym zostawić sobie możliwość poprawek). Akurat gdy zacząłem szukać alternatyw dla JOGLa pojawił się wpis na blogu Wojciecha Tomana na temat JNI. Dłużej nie musiałem szukać :) Zamknięcie renderingu w dllce okazało się prostsze niż się tego początkowo spodziewałem. Najwięcej problemów miałem z samym appletem (jak ja nie lubię javy). Jedna rzecz, która mi się nie podobała w rozwiązaniu Pana Wojciecha to użycie SWT. Na szczęście udało mi się to obejść: informacje o tym jak wydobyć uchwyt okna bez użycia swt.

2 mini recenzje

Dzisiaj chciałbym podzielić się dwoma opiniami.

Jakiś czas temu, dzięki udziałowi w konkursie organizowanym przez CDA, stałem się posiadaczem gry Burnout Paradise: Ultimate Edition.
Gra na początku robi świetne wrażenie. W menu wita nas utwór Paradise City zespołu Gun'N'Roses. Zaraz na początku natrafiamy na "wyścig" w trybie "Pirat", który można zobaczyć na podlinkowanym filmiku. Co chwila do dyspozycji jest nowy wóz.
I chciałoby się powiedzieć, że później jest tylko lepiej, ale niestety tak nie jest.
Kolejne wozy różnią się dodaniem punktu tu, czy tam do statystyk (prędkość, dopalacz i wytrzymałość) oraz przyczepnością (częścią łatwo jest driftować, a w innych bez ręcznego ani rusz). Gracz nie ma też w tej kwestii żadnego pola do popisu.
Po początkowym zachwycie, przychodzi szara rzeczywistość i część trybów rozgrywki okazuje się nie grywalna.
Paradise City po którym się ścigamy wcale nie jest taką wielką metropolią na jaką początkowo wygląda. Tak naprawdę do dyspozycji dostajemy obszar, który można pokonać w jakieś dwie minuty. Po przekątnej będzie trzy i pół minuty. Zwyczajnie brakuje tras po których się ścigamy.
Muzyka, tutaj chyba nudzimy się najwolniej. Wybór jest faktycznie spory i akurat trafia w mój gust.
Grę "ukończyłem", to jest dotarłem do punktu, w którym pogratulowano mi jej ukończenia. W praktyce mogłem jeszcze całkiem sporo zrobić, ale mi się znudziło. Wolałem w końcu skończyć Supreme Commander: Forged Alliance.

Druga "recenzja" będzie z nieco innej bajki. Otóż miałem wczoraj niezwykłą przyjemność obejrzeć w Teatrze Powszechnym w Łodzi komedii "Kolacja dla głupca". Nie jestem znawcą, więc nie odważę się ocenić przedstawienia pod kątem technicznym. Sama sztuka jest ciekawa, bardzo śmieszna i naprawdę warta obejrzenia. Spektakl trwa dwie i pół godziny w tym jedna przerwa.

Procenty

Jakiś czas temu Xion na swoim blogu zamieścił wpis Pr0centy, gdzie wyraził nadzieję: "Wszyscy oczywiście wiedzą, co to znaczy, że jedna wielkość stanowi określony procent drugiej - mam nadzieję, że w celu zdobycia tej wiedzy wciąż wystarczy skończyć jedynie podstawówkę.". Ponieważ moja żona aktualnie pracuje w gimnazjum, gdzie uczy języka niemieckiego, to mam informacje z dość wiarygodnego i aktualnego źródła. Procenty są teraz nauczane w drugim semestrze pierwszej klasy gimnazjum :(
Choć do wpisu Xiona pojawiły się komentarze ukazujące znacznie bardziej ponury obraz: "W niektórych gimnazjach to było, w większości - dopiero szkoła średnia.". Osobiście trochę trudno mi uwierzyć, żeby polska oświata, stoczyła się aż tak bardzo, ale nic nie jest wykluczone.

Odnośnie samych procentów nazwa, jak to zwykle bywa, mówi sama za siebie. Po angielsku jest percent, co jest zlepkiem łacińskich per i centum, czyli "na" "sto". Nie wiem jak łacińskie per zamieniło się u nas w pro, ale i to słowo, oznaczające "dla" pasuje całkiem dobrze. Mówiąc "99 procent", mówimy tak naprawdę "99 na/dla 100". Co chyba wyjaśnia wszystko każdemu, kto wie co to jest ułamek.

Pozory mylą

W pracy trafiło mi nieco zaskakujące zadanie. Otóż dostałem silnik elektryczny, kontroler do tego silnika, oraz polecenie:

• Pan zrobi tak, żeby z PC'ta kontrolować ten silnik


• A dokumentacja gdzie ?


• Na tej płycie, jest tam też jakiś soft.


• Ok.

4 godziny później.

• Na tej płycie nie ma dokumentacji, to jakiś katalog handlowy.


• Niemożliwe.


• Na stronie internetowej też nie ma dokumentacji.


• Niemożliwe.

Po dwóch tygodniach (plus okres świąteczny, w którym ja pracowałem) przysłali dokumentację i dedykowany program komunikacyjny.
Zdobyłem wtyczki, przylutowałem kable, wszystko spiąłem zgodnie z dokumentacją i ostatecznie udało się cały zestaw uruchomić. Kontrolując napięcie na kilku pinach mogę regulować kierunek i prędkość.
Przyszedł czas, aby podłączyć to cudo do PC. Komunikacja ma odbywać się poprzez port szeregowy RS232. I tu zaczęły się schody. Na początku stycznia nie można nigdzie dostać żeńskich wtyczek, panuje globalny brak towaru pod tytułem „Remanent”.
Ostatecznie udało mi się połączyć kontroler z komputerem, dzięki zakupowi ostatniej sztuki dostępnej w okolicach uczelni. Uruchomiłem ten dedykowany program i lipa, nie działa. Po wielu kombinacjach odkryłem przyczynę. Domyślna wartość parametru baud rate nie umożliwia komunikacji. Prawidłowa wartość to powalające 110 bodów na sekundę !?
Potem okazało się, że program się wiesza przy próbie modyfikacji parametrów pracy. Pomyślałem, więc o nowszej wersji. Znalazłem 2.03, miałem 0.06 !? Ta nowsza jest jednak tylko po japońsku i również nie działa !?
Po straceniu mnóstwa czasu, uznałem, że skoro ten soft nie potrafi nawet poprawnie rozpoznać kontrolera (wyświetla złą nazwę) to chyba to po prostu nie ma prawa zadziałać. Został wysłany e-mail do dostawcy z prośbą o pomoc. Po tygodniu odpowiedział mi przedstawiciel niemieckiego oddział, że oczywiście udzielą nam wsparcia, ale on aktualnie jest w Istambule i żebym póki co sprawdził czy wtyczki są dobrze podłączone !?
Minęły już trzy tygodnie od oryginalnego maila i wciąż nie dostałem żadnych informacji. Firma jest japońska, a oddział niemiecki, wydawało mi się, że nasza "współpraca" będzie nieco rzetelniejsza. Ehh.

Z zadań bliższych memu sercu, napisałem program do odbierania danych z portu szeregowego i przekazujący je do nazwanego pipe'a. Przy tej okazji odkryłem kilka ciekawostek:

• system Windows daje procesowi wyłączny dostęp do portu szeregowego. Ponieważ typowy desktop ma tylko jeden taki port, debugowanie aplikacji jest utrudnione. Wyjść jest kilka:
  
  
  
  • podłączyć inne urządzenie,
  
  
  • zdobyć drugi port szeregowy, na przykład taki pod usb,
  
  
  • użyć loopback, proces może jednocześnie pisać i czytać z portu.
  
  
  
  Najbardziej polecam drugi port, choć powodował na „moim” komputerze dość regularne restarty :(


• wszystkie testy jakie wykonałem pozwalają mi sądzić, że pipe'y (wykorzystywane lokalnie) są w zasadzie niezawodne i stosowanie do nich dodatkowych protokołów mija się z celem. Trzeba jedynie zapewnić, że dane będą pobierane w miarę równomiernie do ich zapisywania, aby nie dopuścić do przepełnienia bufora,


• memcpy nie działa poprawnie, gdy bufor źródłowy i docelowy się pokrywają, lepiej użyć memmove.

I to by było wszystko na dziś.

Praca, Ploter

Odnośnie pracy, zostałem oficjalnie zatrudniony na Politechnice. Umowa podpisana 8.1.2010, okres wykonania prac 9.12.2009 - 30.12.2009 ;)
Umowę mam o dzieło. Co jest o tyle fajne, że nie muszę płacić składek ZUS :]
Kolejną miłą rzeczą jest koszt uzyskania przychodu. Między innymi dla programistów wynosi on aż 50%. To sporo, bo z 19% podatku dochodowego zrobi się 9.5%.
Szkoda tylko, że tak mało mi zapłacą :(

Moduł rysujący wykresy wyszedł mi całkiem fajnie. Biblioteka jest oparta o OGL. Póki co nie działa to zbyt optymalnie, ale ... przyjdzie na to czas. Zwłaszcza, że tak od ręki to jedyne co mógłbym zrobić ze strony OGL, to użycie tablic wierzchołków. Niestety dane są przy każdym rysowaniu inne, więc użycie buforów na karcie graficznej odpada.
Doktor podpowiedział, żeby użyć jakiejś formy scrola. Pomysł jest niezły, wymagać będzie jednak sporych zmian, więc na razie leży na półce i czeka.
Także póki co, najwięcej zaoszczędziłem (w ekstremalnych sytuacjach 90% obciążenia CPU) dzięki zmianie momentu odrysowania. Zamiast w pętli, przesunąłem wywołanie do obsługi komunikatu WM_PAINT. Dzięki temu program pracuje jedynie przy poruszaniu oknami i kiedy pojawią się nowe dane.

Oprócz modułu powstała również aplikacja pod Windowsa. Programik pobiera dane z nazwanego PIPE'a, rozpakowuje i wyświetla zgodnie z plikiem konfiguracyjnym.

Z Plot

PS. Zauważyłem, że Adam Sawicki dodał mój Blog do swojej listy. Dla mnie to pewne wyróżnienie i bardzo mi z tego tytułu miło.