(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.

(Wpis przeniesiony z Jabby, napisany dnia: 2006-08-03 17:07:54)

Zabrałem się za aktualizację kodu Battle for Wesnoth odpowiedzialnego za wyświetlanie gry na ekranach o małych (320×240) rozdzielczościach. Od dłuższego czasu nikt się nim nie zajmował, więc większość interfejsu wygląda kiepsko albo w ogóle nie nadaje się do użycia, ale widać już pierwsze efekty. Udało mi się doprowadzić do względnego porządku ekran tytułowy:

oraz intra kampanii:

Nie najgorzej wyglądają też już preferencje:

Pozostało natomiast mnóstwo pracy przy ekranie gry, który być może trzeba będzie nieco przerobić pod kątem koncepcji, bo czytelność górnego paska i jednostek pozostawiają jeszcze bardzo dużo do życzenia:

Zanim uda mi się jednak pobawić Wesnoth na małym ekranie, będę musiał jeszcze zająć się zużyciem pamięci, usuwając część niepotrzebnej funkcjonalności. Długa droga przede mną, ale efekty pracy już są (a to lubię), a jedna osoba na kanale #gp2xdev już wyraziła zainteresowanie dostępnością Wesnoth na tej konsolce. Na razie morale mam więc wysokie.

(Wpis przeniesiony z Jabby, napisany dnia: 2006-08-03 01:01:48)

Właśnie dotarło do mnie z pełną siłą, że jeśli cały pomysł z GP2X wypali, to nie obejdzie się bez próby uruchomienia Battle for Wesnoth na tej konsolce, ale łatwo nie będzie. Co prawda niegdyś Wesnoth wspierał urządzenia z małymi ekranami (320×240 pikseli) dzięki opcji skryptu configure “–enable-tinygui” i odpowiednim kawałkom kodu ujętym w dyrektywy #ifdef, ale wszystko wskazuje na to, że od dawna nikt się tym nie zajmował, a zatem z pewnością nie działa. Co więcej, wraz z kolejnymi wersjami wzrasta zapotrzebowanie gry na pamięć operacyjną – a to za sprawą kolorowania jednostek, animacji, nowych dźwięków, a GP2X ma jej tylko 64MB…

Przerobienie gry tak, by zachowując wspólną bazę kodu zmusić ją do działania na tak nietypowym sprzęcie zdaje się być zadaniem trudnym, ale jednocześnie dość fascynującym. Czas pokaże, co z tego wyjdzie.

(Wpis przeniesiony z Jabby, napisany dnia: 2006-08-02 16:57:43)

Konsole zawsze były dla mnie czymś mało przydatnym. Z jednej strony zapewniają świetne możliwości rozrywkowe, ale z drugiej sporo kosztują (o grach nie wspominając), a ja aż tak dużo czasu grając nie spędzam. Ostateczny bilans zawsze był taki, że żadna konsola nie była warta moich pieniędzy.

Przeszło miesiąc temu się to zmieniło i kilka dni temu zamówiłem moją pierwszą konsolkę typu handheld, ale nie jest to ani Playstation Portable, ani GameBoy. Mój wybór padł na niszowy sprzęt o mało marketingowej nazwie GP2X, produkowany przez koreańską firmę Gamepark Holdings. Paczka jest w drodze, więc nie jestem jeszcze w stanie ocenić, czy na pewno był to dobry wybór, ale spędziwszy trochę czasu czytając poświęcone jej fora jestem tego prawie pewien. Dlaczego – o tym niżej. Jeśli zakup okaże się udany, to możecie spodziewać się kolejnych wpisów poświęconych moim przygodom z GP2X (jakkolwiek to brzmi).

Podstawowe informacje o produkcie możemy poznać na oficjalnej stronie GP2X. Oprócz standardowego marketingowego bełkotu mamy m.in. dostęp do specyfikacji konsolki oraz galerii. Jak widać jest to dość eleganckie urządzenie, ale jego prawdziwa miodność kryje się wewnątrz: dwa procesory ARM i 64MB pamięci operacyjnej, czytnik kart SD, standardowe porty USB i dobry wyświetlacz oraz… Linux.

Tak właśnie, Linux. Oprócz otwartego systemu operacyjnego (z dostępnymi źródłami kernela i części aplikacji użytkowych, w tym mplayera) użytkownik z zacięciem programistycznym dostaje także pełne SDK dla Windows, Linuksa i MAC OSXa, dzięki któremu bez problemu można tworzyć własne aplikacje uruchamiane na tym cudeńku! W czasach, gdy kolejne wersje fimware’u do PSP coraz bardziej ograniczają użytkowników i domowych programistów, Gamepark Holdings raczą nas sprzętem, z którym zapaleńcy mogą praktycznie dowolnie eksperymentować! Przyznam, że głównie to przekonało mnie do zakupu.

Jednak GP2X to nie konsolka dla mas, jak produkty Sony czy Nintendo. Powstała na nią jak na razie jedna komercyjna gra, a druga jest jakoby w przygotowaniu. Pole, na którym ten komputerek lśni, to oprogramowanie tworzone przez użytkowników oraz emulacja. Więcej napiszę o nich, gdy będę miał za sobą kilka(naście) godzin zabawy, ale na razie polecam zapoznanie się z recenzją konsolki oraz ściągnięcia dołączonego do niej filmiku. Warte odwiedzenia jest też oficjalne forum.

Przyznam, że nie mogę doczekać się kuriera i momentu, gdy uda mi się uruchomić na GP2X pierwszą grę mojego autorstwa, z czym nie będzie raczej wielu problemów, bo dostępny jest port biblioteki SDL, w tym ze sprzętowo akcelerowanymi funkcjami…