Błędy w SDL dla Windows CE

Biblioteka SDL bardzo ułatwia programowanie urządzeń mobilnych opartych o Windows Mobile. Dzięki wielu tutorialom szybko możemy stworzyć swoją pierwszą aplikację na PPC. Niestety nie wszystko działa tak jak należy i musimy czasem pogłówkować jak coś ominąć.

Brak odczytu klawiszy sprzętowych na Pocket PC
W trakcie próby uruchomienia jakiegoś programu w SDL aby odczytał stan klawiszy sprzętowych dojdziemy do wniosku, że w zależności od pocketa odczyty klawiszy się różnią a na większości PPC jesteśmy jedynie w stanie odczytać, że któryś (ale nie wiemy który) z klawiszy został naciśnięty. Analizując kod SDL doszedłem do wniosku, że w pliku sdl_dibevents.c (dla PocketPC) prawidłowe wartości odczytanych klawiszy są błędnie zamieniane przez linię keysym->sym = VK_keymap[SDL_MapVirtualKey(scancode, vkey)]; Do tego momentu w vkey mamy prawidłową wartość… Co więc musimy zrobić? Oczywiście zmienić linie na tą keysym->sym = vkey;
I od tej pory klawisze sprzętowe odczytują się prawidłowo.
Kody otrzymywane po odczycie oznaczają:
37: joy_lewo
39: joy_prawo
38: joy_gora
40: joy_dol
193: hard_key1
194: hard_key2
195: hard_key3
196: hard_key4
112: soft_key1
113: soft_key2
W przypadku klawiatur QWERTY lub telefonicznej to tak odczyt jest jak w normalnej klawiaturze czyli „0″ odpowiada „0″ a np. literce „a” odpowiada „a” (zgodnie z tablica ascii). Oczywiście gdy SmartPhone jest wyposażony w Joya i HardKeys to działają kody podane wyżej.

Kolejny problemem są tzw. artefakty (czyli śmieci) które GAPI wyrzuca jako odczytany klawisz. Twórca SDL na PPC oczywiście to zauważył i wycina artefakty o symbolach 0×84 i 0x5B. Ja jeszcze zauważyłem pojawiające się takie śmieci jak 0×86 które także wycinam.
Do pobrania jest plik sdl_dibevents.zip w którym są zawarte wymienione poprawki.

Desynchronizacja timera
Pierwszym błędem zauważonym przeze mnie w SDL dla WinCE jest desynchronizacja czasu pobierana przez funkcję SDL_GetTicks(). Czasem po prostu wartość pobrana np. 10 milisekund później daje wynik 1000 milisekund (a powinno być 10 milisekund) lub wskazuje czas -1000 milisekund.
W grach na urządzenia mobile powinniśmy zwrócić uwagę na pobór mocy i w związku z tym należy wykorzystywać tylko tyle mocy procesora ile potrzeba. Reasumując nie ma sensu robić super płynnej grafiki w 100 FPS ale wystarczy np. w 30 FPS. Resztę czasu oddajemy systemowi (poprzez instrukcje Delay()) i dzięki temu na zasilaniu akumulatorem nasza gra może dłużej działać.
Ale tutaj ja nie o tym chciałem pisać. A wiec tam ponieważ 1 sekunda to 1000 milisekund a my chcemy uzyskać te 30 klatek na sekundę. Czyli dzielimy liczbę 1000/30 i otrzymujemy wartość 33,33 która oznacza ile mamy czasu na namalowanie pełnej klatki. Pełną klatkę malujemy powiedzmy w 10 milisekund wiec zostają nam 23 milisekundy „oddajemy” systemowi (poprzez Delay() czy SDL_Delay()).
W przypadku WinCe (chociaż nie wiem czy to wynika z SDL czy ze specyfiki WinCE) przed zrobieniem Delay musimy sprawdzić czy aby czas który Delay’emy nie jest jakiś dziwny czyli sprawdzamy czy poprzedni czas jest mniejszy od aktualnego oraz czy aktualny czas nie jest przypadkiem większy niż 33 od poprzedniego. Jeśli taka sytuacja występuje to oczywiście nie robimy SDL_Delay gdyż wartość którą byśmy ją zrobili jest można by rzec przypadkowa. W moim przypadku wszystko chodziło ok dopóki nie uruchomiłem mojej gry (Samulos) na fizycznym urządzeniu i wtedy się zdziwiłem co się dzieje. Na szczęście stosukowo szybko sobie z tym poradziłem.