(Wpis przeniesiony z Jabby, napisany dnia: 2007-02-23 15:56:54)

W lutym mija pół roku od momentu, gdy w moje ręce wpadła wreszcie konsolka GP2X i mogę chyba sobie pozwolić na małe podsumowanie wrażeń z jej użytkowania w tym czasie, zainspirowane komentarzem do sierpniowego wpisu… Ogólnie: nie żałuję.

Dobre…

Konsolka spełniła moje najważniejsze oczekiwania: jest świetnym gadżetem, dzięki któremu można pobawić się ciekawym sprzętem z w pełni otwartym środowiskiem software’owym. Sprzęt, zbudowany na bazie zwykłych komponentów (producent praktycznie złożył ją z gotowych części), sprawuje się bardzo przyzwoicie pod względem wydajności – bez problemu działają takie gry jak Duke Nukem 3D, Quake (pierwsza część), Egoboo (dzięki implementacji OpenGL ES w oparciu o rdzeń ARM940T), czy komercyjnie dostępne na tę platformę Vektar oraz Payback. Interesujące mnie emulatory (NES, SNES) również nie sprawiają problemów.

Oprócz grania używam mojej GP2X również do rozrywki “multimedialnej” – głównie słuchania muzyki i oglądania filmów w pociągu/łóżku. Pod tym względem nie mam większych zastrzeżeń – płynnie odtwarzają się filmy w dużych rozdzielczościach (wyjście TV robi pocieszne wrażenie), choć w trosce o żywotność baterii oraz miejsce na karcie SD warto je sobie przekompresować. Odtwarzacz do muzyki… dobrze odtwarza muzykę i chyba o to chodzi. Z rzadka zdarza mi się też poczytać jakiegoś ebooka (w czystym tekście) oraz przeglądać zdjęcia – dostępne oprogramowanie nadaje się do tego idealnie. Co więcej, bardzo dobra jakość ekranu znacząco podnosi przyjemność czerpaną z rozrywki.

Oprócz tego miałem okazję zdobyć swoje pierwsze doświadczenia z programowaniem na “platformę wbudowaną” (choć to określenie trochę na wyrost w przypadku mini-komputera z Linuksem na pokładzie), przygotowaniem narzędzi do kompilacji skrośnej, ich wykorzystaniem i drobnymi problemami wynikającymi w trakcie tych prób. Ostatnio wróciłem też do grzebania przy “Wesnoth4GP2X”; o szczegółach napiszę przy okazji na sciniksie. Na zdjęciu powyżej widać konsolkę okablowaną semi-developersko: słuchawki, zasilanie i USB (sieć!); niestety ekran wyszedł na nim kiepsko.

… i złe strony

Jest też kilka detali, na których się zawiodłem. Jednym z nich jest zupełne odcięcie się producenta od społeczności używającej jego sprzętu – GPH w żaden sposób nie uczestniczy w życiu użytkowników i nie zapewnia żadnego (?) wsparcia programistom tworzącym oprogramowanie na ich sprzęt. Chyba tylko dzięki wyjątkowo utalentowanym hobbystom można w pełni cieszyć się możliwościami tej konsolki – łatwo można skompletować pełen toolchain oraz uzyskać względnie wygodny dostęp do wszelkich możliwości systemu. Sam producent skazuje potencjalnych developerów na czytanie referencyjnej dokumentacji chipsetu (jak to często bywa w takich przypadkach, nie wolnej od błędów) i bolesnego rzeźbienia w assemblerze.

W niezmierne zdziwienie wprawił mnie też fakt, że dioda sygnalizująca zużycie baterii nie jest obsługiwana przez system operacyjny, a jej zaświecenie w przypadku wyczerpującego się zasilania leży w gestii aplikacji użytkownika. Nie muszę chyba dodawać, że nie wszyscy programiści troszczą się o odczytywanie tajemniczych wskazań odstarczanych przez jądro. Sama żywotność baterii, ok. 4 godzin przy umiarkowanym użytkowaniu dwóch 2500mAh paluszków, nie imponuje.

Cyfrowy manipulator jest trochę zwodniczy – po płynnie wychylającym się kontrolerze człowiek spodziewa się intuicyjnie płynnego sterowania. Tymczasem trzeba wychylić go dość daleko, co w przypadku intensywnej gry często się nie udaje, a chwilowa utrata kontroli potrafi być frustrująca.

USB, oprócz problemów wspomnianych na sciniksie, jest powolne. Wygodę korzystania z FTP do manipulowania plikami skutecznie zabija prędkość połączenia (ok. 50-60kB/s).

W sumie jednak dobrze

Tak, jestem zadowolony. Mimo, że dostrzegam wady tej zabawki, to sporo się dzięki niej nauczyłem (i uczę). Nadal niezmiernie cieszy mnie otwartość – nikt nie próbuje ograniczyć moich możliwości uruchamiania dowolnych, wybranych przeze mnie programów (jak na, tfu tfu, Sony PSP). Dzięki temu mogę z GP2X robić wszystko to, co sobie wymarzyłem przed jej kupnem, a drobne problemy mimo wszystko nie psują radości. Zatem jeśli ktoś nie brzydzi się tym, że zabawa wiąże się też z pewną ilością grzebania i ceni sobie wolność – nadal polecam.

(Wpis przeniesiony z Jabby, napisany dnia: 2006-08-18 01:54:47)

Jednym z bardziej rażących błędów graficznych, który miałem jak do tej pory okazję wyeliminować przy pracach nad trybem “tiny gui” w Battle for Wesnoth, były błędnie rysowane paski HP i XP pokazujące się obok jednostek. Jeszcze do niedawna ekran gry wyglądał np. tak:

Pomijam tu popsuty theme, bo przystosowana do pracy w rozdzielczości 320×240 wersja jest już od dość dawna, a chodzi mi raczej o paski stanu, które są bardzo, bardzo brzydkie. Problem udało mi się jednak usunąć nie zmieniając ani jednej linijki kodu w C++. Efekt jest zdecydowanie lepszy:

Otóż w czym rzecz: budowanie Wesnoth z włączoną opcją --enable-tinygui skryptu configure powoduje, że podczas kopiowania plików gry do katalogu docelowego pliki graficzne są automatycznie pomniejszane, by gra nie musiała “w locie” skalować grafik do mniejszej rozdzielczości. Rozwiązanie proste i skuteczne… z jednym wyjątkiem. Grzebiąc w kodzie odpowiedzialnym za wyświetlanie jednostek i pasków stanu trafiłem na taki komentarz:


// calculate_energy_bar returns incorrect results if the surface colors
// have changed (for example, due to bilinear interpolaion)


Funkcja calculate_energy_bar odpowiedzialna jest za obliczenie pozycji i rozmiarów pasków stanu. Robi to na podstawie pliku graficznego z kolorową kulką, która pojawia się nad jednostką, tak by narysowane zostały one dokładnie pod nią. Przesunięcie określa na podstawie piksela o predefiniowanym kolorze, szukając go punkt po punkcie na załadowanym obrazku. Co się jednak stanie, gdy takiego punktu nie znajdzie? To widać było na pierwszym zrzucie ekranu. W kodzie co prawda znajduje się odpowiednie zabezpieczenie, dzięki któremu zawsze brana jest pod uwagę grafika w oryginalnym rozmiarze (na wypadek gdyby w trakcie gry została zmieniona skala), ale nie działa ono, gdy skalowanie przeprowadzone zostało poza programem, a tak właśnie dzieje się podczas instalacji z opcją --enable-tinygui – zmiana rozmiaru grafiki powoduje, że potrzebny do prawidłowego działania punkt zostaje usunięty. I tak oto poprawienie błędu, który pozornie znajdował się w kodzie, sprowadziło się do zmiany jednej linijki w pliku Makefile.am:


- (cd $(top_srcdir) && find data/campaigns data/tutorial images images/terrain ( $(findfilterflags) -o -name '*.png' -print ) ) | while read p; do
+ (cd $(top_srcdir) && find data/campaigns data/tutorial images images/terrain ( $(findfilterflags) -o -name '*.png' -and -not -name 'bar-energy-unmoved.png' -print ) ) | while read p; do


(Wpis przeniesiony z Jabby, napisany dnia: 2006-08-04 22:34:20)

Prace nad przystosowaniem interfejsu Battle for Wesnoth do działania w rozdzielczości 320×240 idą mi względnie sprawnie. Nieźle wygląda dialog wyboru kampanii:

oraz lobby do gry wieloosobowej:

Ekran zakładania gry był okropnie pracochłonny, ale daje się go już używać:

Jak widać z obu powyższych usunąłem możliwość wprowadzania tekstu: nie jest ona zbyt prosta do wykorzystania na urządzeniach przenośnych, a muszę walczyć praktycznie o każdy piksel wolnej przestrzeni. Nie wygląda to jeszcze zbyt estetycznie, ale zaczyna być funkcjonalne, a o to przede wszystkim mi chodzi. Na pewno przyda się dopieścić rozmiary fontów, choć nie wiem, czy uda się uzyskać odpowiedni kompromis między czytelnością, a używanym miejscem.