Techi's Weblog

Až donedávna byla práce s Bluetooth v Linuxu doslova noční můrou. Ačkoliv mi nevadí občas něco napsat do příkazové řádky, instalovat hromadu různých balíků, googlit a zkoušet různé shellové skripty, abych se mohl připojit k telefonu nebo ke sluchátkům podle jejich MAC adresy, jistě není nic uživatelsky příjemného. Navíc jedinou věc, kterou výchozí manažeři Bluetooth v Gnome/KDE umí pořádně, je spárování.

Nedávno se dostal open source Projekt Blueman do použitelné verze 1.21, ve které je schopen bezproblémově pracovat s následujícími, nejčastěji používanými Bluetooth profily:

A2DP – bezdrátová Bluetooth stereo sluchátka

HSP – headset pro telefon (mikrofon a reproduktor s nižší kvalitou přenosu)

HID – umožní připojit bezdrátovou myš/klávesnici nebo jiné polohovací zařízení

OPP/OBEX – Přenos vizitek nebo jednoduchých textových zpráv, posílání/příjímání souborů

FTP – Umožní zobrazovat a editovat obsah vzdáleného sdíleného adresáře

DUN/PAN – Sdílení internetového připojení s mobilním telefonem

Program se tradičně “uhnízdí” po startu v oznamovací oblasti (Tray). Ovládání je skutečně intuitivní, čeština je samozřejmostí. Blueman po připojení k zařízení také ukazuje sílu signálu, rychlost upload/download a oběm přenesených dat. Podporuje připojení k internetu pomocí mobilního telefonu jak pro novější PAN (Personal Area Network) (Windows Mobile 6+), tak vytáčené připojení DUN  (Dial-up Networking) podporovaná většinou telefonů. Navíc lze nastavit, aby se ukládala informace o oběmu přenesených (pro každý telefon zvlášť). Po připojení k telefonu Blueman automaticky přesměruje Network Applet (správce síťových připojení), aby použil pro připojení k internetu nově vzniklé připojení. Tzn. od připojení k internetu přes telefon vás dělí 3 kliknutí myši. PAN lze navíc využít i k zasíťování počítačů jako alternativa k Wi-Fi.

Jediné co musím vytknout je, že zatím nefunguje AVRCP profil, tedy multimediální tlačítka na sluchátkách jako je pause, předchozí/další atp. Taky mě pobavilo, že Blueman můj HTC telefon identifikoval jako Palm. Chtělo by to, aby podle MAC adresy rozeznal výrobce  jako je HTC, Sony Ericson nebo Nokia a podle toho i zobrazil patřičnou ikonu.

Na notebooku vesele používám distribuci Ubuntu 9.10 Karmic Koala, se kterou jsem opravdu spokojen. Podpora hardware, rychlost a stabilita systému je skvělá. U hardware funguje vše bez nutnosti cokoliv složitě konfigurovat nebo instalovat. Jediné, co mě mrzí je právě, že Blueman není v základní instalaci narozdíl od směšného Gnome Bluetooth manažera. Navíc v repositářích Ubuntu je často zastaralá verze a je nutno přidat repositář ručně. Viz. návod pro Ubuntu na stránkách projektu. I když zase taková práce to zase není

Co mě opravdu příjemně překvapilo je, že funguje vše na jedno kliknutí hned na poprvé, narozdíl od Windows. Vestavěná podpora Bluetooth ve Windows je dosti mizerná. Nahradit se to dá propracovaným softwarem IVT BlueSoleil. I když málokomu se chce platit extra peníze kvůli tomu, že jejich OS je nedodělaný. 

Vložil Techi

U čtenáře sepředpokládá základní znalost programování, angličtiny, jazyka C, Windows API a orientace v mobilních platformách

Po delší době jsem se vrátil k programování her, tentokrát pro platformu Pocket PC 2003 / Windows Mobile. Nejsem žádný profesionální herní vývojář, je to spíš hobby. Každopádně už jsem starý na to abych hry vymýšlel a programoval. Jednodušší je vzít existující oblíbenou hru s otevřeným zdrojovým kódem a upravit jí pro Windows Mobile.
Chvíli mi trvalo než jsem se zorientoval okolo dostupných knihoven pro vývoj her, ale pokud máte podobný záměr, tak vám snad usnadním trochu práce.

Grafika

Podívejme se nejprve na možnosti zobrazování grafiky na platformě Pocket PC

GAPI
Kdysi v počítačovém středověku (cca rok 2001) Microsoft uvolnil "herní" knihovnu nazvanou GAPI neboli Game API. V ROM jí najdete jako knihovnu gx.dll.  Nejvtipnější ovšem je, že tuto knihovnu Microsoft za těžké peníze odkoupil od firmy
Revolutionary Software Front, která tuto knihovnu původně vytvořila, když portovala legendární hru Doom pro Pocket PC. Jedná se přitom o velice low-level knihovnu, která vám dá jenom přístup k ukazateli na displej. Je to samozřejmě velice rychlé, ale knihovna samotná neumí vykreslit čáru ani obrázek. Vše ostatní si (ne)musí programátor napsat sám, ale k tomu se dostanu později. Knihovna je napsána v čistém C, ale existuje i wrapper pro .NET CF (C# a Visual Basic). Když jsme u programovacích jazyků, tak za ideální programovací jazyk pro psaní her považuji C++, resp. C pro malé hry. Jazyky C# a Visual Basic jsou závislé na .NET, který je přece jenom těžkopádný. Aplikace reaguje pomaleji a zabere více paměti, také není (snadno) přenositelná na jiné systémy, ačkoliv uznávám, že vývoj programu postaveném na .NET je pohodlnější a rychlejší.

DirectDraw
S příchodem Windows Mobile 5 Microsoft zabudoval do systému podporu pro DirectX. Konkrétně DirectDraw a Direct3D (tedy herní knihovna původně pro stolní Windows), aby tak usnadnil port stávajících her ze stolních Windows. Zároveň označil GAPI jako deprecated, aby donutil vývojáře her přejít na DirectX. Microsoft se tak oprávněně setkal s vlnou kritiky.

RAWFRAMEBUFFER
Další alternativou je technika RAWFRAMEBUFFER, která obdobně pracuje s displejem jako GAPI. Tj. s ukazatelem na displej. Tato technika ale není moc rozšířená. Používá se třeba, když zařízení pracuje s webkamerou.

GDI
Je grafická knihovna dostupná ve všech verzích Windows. Dovoluje kreslit základní obrazce jako elipsy, polygony, zobrazovat bitmapy. Nevýhodou je blikání obrázovky při překreslování a velmi nízká rychlost renderování oproti ostatním technikám. Proto se GDI na vytváření her nehodí.

OpenGL ES
OpenGL není ve Windows CE podporováno. Existuje však pokus o port 3. strany nazvaný OpenGL ES. Nicméně u zařízení je vyžadována HW akcelerace, bez které se mi žádný program nepovedl spustit. Proto tedy nepřipadá v úvahu. Stránky knihovny zde: http://www.khronos.org/opengles/

GAPI vs. DirectDraw

1. GAPI je mnohem rychlejší než DirectDraw resp. Direct3D (alespoň pokud se používá SW rendering) Navíc co se týče grafických čipů tak je to bída na druhou. Modelů s grafickým čipem (DELL Axim) spočítáte na jedné ruce.  Místo abych jich postupně přibývalo tak jich spíš ubývá. Distributoři používají levnější grafické čipy v nových zařízeních než se používaly předtím. Navíc grafický čip (i přes velké snažení výrobců) je stále velmi energeticky náročný. Chcete aby vám telefon vydržel na hraní her jenom pár hodin?
2. DirectDraw není podporováno v Pocket PC 2003 a starších!
3. Na GAPI je postavena skoro každá "fullscreen" hra. (několik tisíc! her)
4. Na GAPI jsou postaveny i herní frameworky a enginy
5. Aplikace běžící ve fullscreen v DirectDraw nedokáže přepnout na aktivní okno. Např detekovat příchozí hovor a minimalizovat se. Prostě musíte nejdřív ukončit aplikaci a potom zvednout hovor.
6. DirectDraw má také problémy s překreslováním. Např. právě při příchozím hovoru nebo když vyjede start menu. Na displeji zůstanou "mrtvé body"
7. Dokumentace k DirectDraw na Windows Mobile je stručně řečeno ubohá.

A to nemluvím o tom, že tutorial aplikaci k DirectDraw nešla spustit na žádných z 3 systémů s Windows Mobile 5/6/6.1 ani na emulátoru. Aplikace skončila chybou typu nelze inicializovat bla bla bla. Musí se pracně měnit nějaké nastavení v registrech. Navíc dal Microsoft také jasně najevo, že o OpenGL ve Windows Mobile nemá zájem.  Abych to shrnul. Microsoft se může jít s DirectDraw vycpat. <flame>Zkrátka nemá dost inteligentních vývojářů a musí software jenom kupovat od jiných. Takto de facto vzniknul už MS-DOS, ale to je jiný příběh.</flame>
Podle mě GAPI ještě dlouhou dobu zůstane jedinou funkční a podporovanou knihovnou pro grafiku. Ať už to bude oficiálně podporován nebo ne. Vždy se dá do zařízení přidat knihovna gx.dll optimalizovaná pro konkrétní hardware, díky které bude GAPI šlapat jak má i na nestandardních rozlišeních. Nevýhodou GAPI zůstává, že nedokáže využít grafickou akceleraci.

Nicméně na každém zařízení se rychlost DirectDraw, GAPI a RAWFRAMEBUFFER projevuje jinak. Zpravidla jde však o rozdíly v desítkách procent.

Zvuk

Tak podpora zvuku je u Windows CE snad ještě horší než podpora grafiky Jediné na co se Microsoft zmohl implementovat do svého operačního systému je přehrávání WAVE a to pouze bezkanálový zvuk. (Klasická funkce z Windows API - PlaySound() ) Žádné další nastavení. Prostě nic. Abych nelhal, CE samozřejmě vícekanálový zvuk podporují, ale API je velmi těžkopádné. Teprve až ve Windows Mobile 6 (rok 2007!) implementoval jednoduché API pro přehrání běžně podporovaných formátů pro které jsou dostupné kodeky (MP3, WMA a MID) a multikanálový zvuk. Kdyby si to odpustil asi by udělal líp, z důvodu zpětné kompatibility
. Vtipné také je, že Windows CE do verze 4.2 podporovali DirectSound (pouze pro přehrávání WAVE). Ve verzi 5.0 byl DirectSound ze systému odstraněn a ve verzi 6.0 přepsáno celé API pro práci se zvukem. Tomu říkám programátorská ZOO. Pro zvuk samozřejmě existují knihovny 3. stran. Samozřejmě komerční. Nejlepší z nich je pravděpodobně

FMOD 3 (100 USD)

Velmi precizní multiplatformní knihovna pro přehrávání zvuků a hudby navíc s podporou MP3, OGG/VORBIS, S3M, MOD a hromadu dalších blbostí jako nahrávání, streaming nebo ripping. Umí snadno přizpůsobit kvalitu zvuku, mono/stereo a další věci potřebné pro práci s mobilním zařízením. Pro nekomerční využití poskytována dokonce zdarma. Pro komerční využití od 100 USD což je v porovnání s ostatními knihovnami velmi slušná cena. FMOD 3 byla naprostá špička co se dá na nejen-kapesních Windows použít dokud se právě neobjevil Windows Mobile 6 s přepsaným API - ve kterém má FMOD problémy s některými formáty.  Oficiálně má FMOD podporovat pro přehrávání hudby

• MOD
• S3M
• XM
• IT
• MID
• RMI
• SGT
• FSB

• WAV
• MP2
• MP3
• OGG
• RAW

MIDI

Zde je návod přímo z MSDN jak převést MIDI do WAVE a přehrát standardními funkcemi.

Pokud se tedy nespokojíte s trapným WAVE musíte napsat podporu pro zvuk zvlášť pro Pocket PC 2003 + Windows Mobile 5 a zvlášť pro Windows Mobile 6/6.1 - Na žádný wrapper, all1one řešení nebo jinou použitelnou knihovnu jsem zatím nenarazil. Pokud o něčem víte, tak se prosím podělte.

Ještě bych zmínil, že MP3 není vhodný formát z licenčních důvodů. Nevím jak u non-commercial produktů, ale pokud má hra nad 5000 kopií (což nevím jak se u online prodeje dá zjistit) musíte si zakoupit licenci za 2500 USD Osobně tak preferuji Ogg/vorbis. <flame>Je to ironie, že z formátu původně vytvořeným pro kradení hudby se stane licencovaný produkt. Někdy je mi z těch licencí opravdu na blití.</flame>

Herní Knihovny

Aby si programátor zjednodušil práci často sáhne po hotových odladěných knihovnách. Multiplatformní knihovny Vám dovolí s minimálním úsilím vytvořenou hru distribuovat na řadě různých mobilních platforem.

EDGELIB (950 USD)

Je asi nejkomplexnější knihovnou s podporou WM, Symbianu, GP2X a Gizmondo s podporou 3D, zvuku, sítí, utilit, zkrátka všeho co je potřeba. Pro nekomerční použití je zdarma (ale s logem na obrazovce)

GAPIDRAW (995 USD) (source code licence 3495 USD)

Toto je 2D grafická knihovna pro Pocket PC / Windows Mobile. Ovšem zato velmi vyspělá s vysokou mírou optimalizace podporující všechny možné grafické operace. Podpora jak pro GAPI tak i DirectDraw. Pro nekomerční použití je sice také zdarma, ovšem na displeji bude napsáno, že se jedná o evalution verzi.

SDL (LGPLv2)

SDL
je můj osobní favorit. Jedná se o multiplatformní herní knihovnu (soubor knihoven), původně určenou pro Linux ovšem podporuje celou škálu mobilních zařízení  jako Symbian, GameBoy Advanced i právě Windows CE, neoficiálně PalmOS a dokonce iPhone. (Kromě řady UNIXových odrůd jsou podporovány i exotické systémy jako AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS a OS/2) Asi nemusím říkat, že práce s grafikou pro Windows CE je právě řešena přes GAPI. (V budoucnu je možné nahradit video wrapper třeba DirectDraw nebo si třebanapsat vlastní) SDL je standartně napsaná v C, ale je dostupná snad v každém trochu známém programovacím jazyce. (Dokonce i PHP!) SDL byla napsána zkušenými herními programátory pro herní programátory. Autorem této knihovny je Sam Lantinga - Vedoucí softwarový inženýr v Blizzard Entertainment.  Je to sada více knihoven pro práci s 2D/3D grafikou/vstup/výstup/sítěmi/ulitami/hudbou. Existují další knihovny, které samotné SDL rozšířují, nejpoužívanější je SDL_image pro načítání různých formátů obrázků, SDL_ttf pro práci TrueType písmy,  SDL_net pro práci se sítí a SDL_Mixer pro přehrávání hudby a zvuků - bohužel bez podpory Windows CE.(Většina lidí sáhne po FMOD, ačkoliv si můžete napsat wrapper pro SDL_Mixer a udělat tak aplikaci úplně nezávislou na platformě) Nicméně je SDL knihovna prověřena několika lety usilovného vývoje. Existuje celá řada tutoriálů a open source her a knihoven (herních enginů) rozšiřující možnosti SDL. Současná verze SDL 1.2 je pod GPL licencí. Můžete jí použít pro komerční účely pokud přilinkujete knihovnu jako DLL. Nová SDL 1.3 beta je možno volně distribuovat pro komerční účely. Všechny potřebné DLL knihovny pro SDL zaberou v paměti něco mezi 500kB až 1MB. Pokud je aplikace dobře napsaná není problém jí portovat pro libovolnou platformu. Jediná věc, která vás v portování omezuje jsou různá rozlišení a hlavně konfigurace vašeho vývojového prosředí Všem zájemcům vřele doporučuji 
Seriál o programování v SDL na serveru root.cz

Proč Windows CE

Windows CE je i přes pár nedostatků velmi dobrou platformou co se týče vývoje aplikací. Narozdíl například od PalmOS nebo Symbianu. PalmOS je velmi časově náročný na psaní a ladění aplikací a Symbian má velký handicap při portování aplikace na různé verze systému mezi sebou jako EPOC, S60, S60v1, S60v2, S60v3, S70, S80, UIQ, různé feature packy z toho by se člověk zbláznil. Na rozebírání nevýhod J2ME a Linuxu tu už není místo, zkrátka Windows CE vítězí U Windows máte verzi pro Pocket PC (dotykový displej), Handheld PC = Pocket PC s větším displejem a pro Smartphone (bezdotykový). Windows CE má velmi dobrou zpětnou kompatibilitu. V podstatě není velký problém přenést aplikaci ze stařičkých Windows 3.11 pro Windows CE Dříve byl problém s architekturou procesorů (SH3, SH4, MIPS, ARM, XSCALE). Dnes se používá (od Windows CE 3.0) výhradně architektura StrongARM. (XSCALE je kompatiblní s ARM), takže už se architektura procesoru řešit naštěstí nemusí.

Windows CE a kompatibilita s ANSI/ISO C

Drtivá většina her s otevřeným zdrojovým kódem je napsaná v C. Proto je C ideální jazyk pro port těchto her. Nicméně Windows CE trpí menším nedostatkem, protože nepodporují všechny standardní funkce jazyka C. Například úplně chybí <signal.h> a <errno.h> a chybí implementace funkcí z <time.h>. Dále chybí náhodně různé funkce (rewind, asprintf, vasprintf, strcoll, tmpfile, getenv, setbuf) a pro Windows např. GetVersion()
Naštěstí chybějící podporu pro <time.h> lze vyřešit díky knihovně
OpenTimeCE a případně dopsat makra. Nicméně SDL nabízí vlastní funkce pro práci s časovačem nezávislé na platformě
K dispozici je jednoduchý návod na některé chybějící funkce jazyka C ve Windows CE - jiné funkce je možno ignorovat
Dále se určitě hodí implementace zlib pro Windows CE pro práci s archivem 

Poměrně závažným rozdílem Windows CE je absence relativních adresářů. Tzn. například kód fopen("score.txt", "r") vrátí NULL i pokud bude soubor ve stejném adresáři jako program. Ve Windows CE se vždy musíte odkazovat absolutní cestou. Já to řeším tak, že si z funkce GetModuleFileName() vyparsuji aktuální cestu a tu všude přidám před každý otvíraný soubor.

Co se týče síťové komunikace podporováno je samozřejmě i standardní API pro práci se sockety <winsock.h>. Pozor jenom na funkce close() v Linuxu a closesocket() ve Windows. Dobrou alternativou je opět SDL_net zapouzdřující práci se síti (netestováno)

Windows CE samozřejmě nepodporují příkazovou řádku, ale pokud program vypisuje na standardní výstup STDOUT např. funkcí printf(), tak se výstup automaticky uloží do souboru stdout.txt ve stejném adresáři. Alespoň u programů zkompilovaných ve Visual Studiu. Bohužel výstup na stderr se mi nepodařilo zachytit

Vývojová prostředí pro Windows CE a Windows Mobile

Za nejlepší vývojové prostředí považuji Microsoft Visual Studio 2005. Umožňuje programování v C++/C# a Visual Basicu. To je samozřejmě komerční a občas se trochu vyblbnete když musíte nastavovat různé záludnosti jako linker a compiler, buffer overflow chyby atp. Microsoft však zdarma uvolnil straší Embeded Visual C++ 4.0 pro vývoj Windows CE. Musíte si však stáhnout a nakonfigurovat několik balíků.
Pro Linux existuje projekt ce-xcompile, které umožní kompilovat programy v C/C++ v běžném gcc kompilátoru pro architekturu StrongARM. Vývojové prostředí si každý Linuxák určitě zvolí sám.

Článek může být průběžně aktualizován a rozšiřován

Veškeré vaše postřehy a komentáře uvítám tady v diskuzi nebo na adrese techi zavináč techi tečka name

Vložil Techi

Používám už nějaký týden kapesní počítač, tzv. palm, konkrétně model Tungsten T3.

Zkusím shrnout svoje zkušenosti, co jsem se svým PDA nasbíral.

Měl bych podotknout, že tvzení, nazývat kapesní počítač, který používá systém PalmOS, je palm, je chybné, nicméně zažité. Modelů existuje celá řada, model Palm byl ten nejstarší

Často slýchávám o nedostatcích o nedostatcích této platformy (PalmOS) oproti konkurenčnímu Windows CE, resp. Windows Mobile. Hlavním rozdílem je, že PalmOS je singletasking - tj. běží pouze jedna aplikace v jeden moment. Ovšem u PDA, které většnou využíváte naplno, využíváte stejně jenom jednu aplikaci v jeden moment. Pokud přepnete do jiné aplikace, ta uloží svůj stav a když se do ní vrátíte, nepoznáte, že se spouští znovu. Díky singetaskingu běží aplikace velmi rychle (žádné čekání) a šetří procesor, tj. spotřebu baterií (Černobílí dědečci vydrží až měsíc!). Pro šťouraly bych podotknul, že hudbu lze přehrávat na pozadí. (Takový malý div. Možné s procesorem od 200MHz) ICQ lze také provozovat za běhu.

Pokračovat ve čtení "PALM - Dojmy a zkušenosti"

Vložil techi