PDAclub.pl - Forum użytkowników technologii mobilnych
Windows Mobile (Classic, Professional, Standard), Windows Phone 6.x oraz 7/8.x/10 => Oprogramowanie PPC => Dla programistów => Wątek zaczęty przez: Komame w Maj 21, 2006, 15:46:24
-
Wstęp do pytania ;)
Od jakiegoś czasu Microsoft radzi nie używać biblioteki GAPI, jako już przestarzałego sposobu na szybką grafikę. Pozostaje jednak jeszcze funkcja ExtEscape(), która to ma zastąpić GAPI w wersjach systemu od 2003SE w górę. Co prawda teraz dla wersji okienek 2005 jest już DirectX, ale nie ma darmowych narzędzi, które pozwoliłyby to wykorzystać, tak więc moje pytanie okręca się wokół programowania w eVC++.
W przypadku GAPI, gdy np. jakaś gra przygotowana była na wyświetlacz 240x320 w momencie odpalenia na sprzęcie z ekraneem VGA (480X640), piksele są dublowane. Dzięki temu gra pozostaje nadal w trybie pełnoekranowym.
Moje pytanie brzmi: jak jest to rozwiązane przy użyciu ExtEscape? - czy piksele też są dublowane?
-
No cóż, odpowiem sobie sam...
Otóż przy użyciu ExtEscape() z parametrem GETRAWFRAMEBUFFER niestety nie są dublowane... Mój program sypie się przez to na ekranach VGA i trzeba wrócić do starego poczciwego GAPI, które to potrafi zdublować piksele jeśli trzeba.
Trochę to dziwne, bo GAPI już nie jest wspierane przez MS, ale jest bardziej uniwersalne. Natomiast system RAW jest raczej trudny do obsłużenia w taki sposób, aby program go wykorzystujący działał tak samo na ekranach QVGA jak i VGA. Jednak nie zaleca się już używać GAPI... więc co tu zrobić? Jak teraz się "regulaminowo" rozwiązuje tego typu problemy pisząc aplikacje?
A może jest jakiś sposób (którego nie znam) na automatyczne włączenie dublowania w trybie RAW, gdy zostanie wykryty ekran hires?
-
Wracam do temamu, który niegdyś (łohoo to już grubo ponad pół roku) sam rozpocząłem, ponieważ stałem się szczęsliwym posiadaczem sprzętu z ekranem VGA. No cóż, bardzo się zdziwiłem, gdy moje gry napisane wczesniej w GAPI i działające super szybko (wykorzystywałem wstawki w assemblerze) na ekranach QVGA - tu (na VGA) po prostu umierały z mułowacenia się - wyswietlały co 3-cią klatkę.
Problem tkwi w tym, że GAPI wykrywając ekran VGA włącza warstwę emulacji gdzie dubluje piksele - co jest dobre, bo softy napisane pod QVGA działają również na VGA.
Niestety emulacja ta jest tragicznie powolna. Dla przykładu powiem, że narysowanie jednej klatki w mojej gierce zajmowało na procku niecałe 200 MHz (Wizard, QTEK 9100) ok. 4-5ms, a na procku ponad 500 MHz i ekranie VGA (Universal, QTEK 9000) w warstwie emulacji GAPI to samo rysuje się... 35ms (!!!). Taaa, różnica jest straszna.
Jak się okazało, problemem nie jest ekran VGA tylko rozwiązanie, które dubluje piksele w warstwie emulacji GAPI. Tak więc problem tkwi w samej bibliotece GAPI.
Nie wiem jakie doładnie procesy zachodzą podczas tworzenia obrazu w trybie emulacji, jednak zrobiłem mały test i zamiast wykorzystywać GAPI zastosowałem funkcję ExtEscape i wykorzystałem tryb RAW, "ręcznie" dublując piksele. Tzn. zamiast rysować jeden piksel przez GAPI, które go samo zmieniało w 4 piksele tego samego koloru, po prostu sam je narysowałem (wszystkie 4 piksele) bez wykorzystywania GAPI - tylko w trybie RAW.
Efekt był taki, że ten sam obraz, który w warstwie emulacji był rysowany w prawie 40ms teraz rysuje się w 6ms. I jest OK, bo czas jest bardzo zbliżony do tego który był w GAPI na QVGA :)
To mi dało dużo do myslenia, ponieważ wydaje mi się, iż pewnie dałoby się stworzyć na nowo biblioteki GAPI - nieco zmodyfikowane, tak aby dużo szybciej dublowały piksele. Wtedy na ekranach VGA stare programy fullscreen'owe i gry chodziły by pewnie dużo lepiej - wystarczyłoby podmienic bibliotekę gx.dll.
Wiem, że z dniem dzisiejszym nie zaleca się już korzytać z GAPI, bo po prostu nie jest wspierany, tym bardziej, że tryb RAW działa już nawet na maszynkach QVGA z WM 5.0, a jest tak samo szybki jak GAPI i dodatkowo daje możliwość pracy na VGA. Jednak jest całkiem sporo starych gierek i progsów na GAPI, które nadal chciałbym używać mając ekran VGA, ale na razie nie za bardzo się da widząc co drugą albo nawet co trzecią klatkę.
Nie żądam żadnych odpowiedzi - po prostu ponad pół roku temu taki post jak ten bardzo ułatwiłby mi życie, gdy szukałem mądrego rozwiązania na szybką grafikę, ale wtedy jeszcze nie miałem takiej wiedzy.
Tak więc wszyscy młodzi stażem programiści GAPI - dodajcie dodatkowo obługe trybu RAW do Waszych programów jeśli pracujecie na QVGA, bo inaczej na VGA Wasze programy będą działać bardzo powoli...
Oczywiście nie mówię tutaj o programach pisanych z wykorzystaniem GDI, bo tu akurat większych problemów nie zauważyłem. Działają dobrze zarówno na QVGA jak i VGA (może są jakieś wyjątki ale na razie mam zbyt krótko VGA żeby się na coś nadziać).
Mam nadzieję, że kiedyś komuś się to przyda, bo niestety na tym forum jest bardzo mało na temat grafiki HIRES.
-
Hmm a co z biblioteką gapi napisaną specjalnie pod X50v? Nie wiem jak ona działa od strony technicznej - wiem tylko ze podmienia oryginalny sterownik ekranu na swój, i w nieznany mi bliżej sposób przyśpiesza wyświetlanie grafiki w trybie GAPI. Jedyne co zauważam od mojej strony przy wykorzystywaniu tej biblioteki to to iż ekran w momencie włączenia aplikacji GAPI nagle staje się ekranem 320x240... [nie potrafię tego opisać inaczej, to trzeba zobaczyć]
-
EnD, przecież dokładnie to samo dzieję się przy standardowej bibliotece GAPI - ekran staje się nagle 240x320. Gdybyś na Twoim X50v teraz odpalił aplikacje GAPI, wziął do ręki dobrą lupę i się dokładnie przyjrzał to zauważyłbyś, że każdy piksel składa się z czterech pikseli ułożonych w kwadrat (musisz patrzeć gdzieś na napisach, albo gdzies gdzie leży samotny piksel, tzn. że dookoła niego leżą piksele o innym kolorze, wtedy najlepiej widać).
Przykład działania GAPI:
A, B, C to trzy różne kolory
na QVGA GAPI rysuje np. taki obraz w ten sposób (każda literka oznacza jeden piksel):
ABBA
BACA
CCAB
natomiast w trybie emulacji na VGA GAPI rysuje to samo w ten sposób:
AABBBBAA
AABBBBAA
BBAACCAA
BBAACCAA
CCCCAABB
CCCCAABB
Dzięki temu, że każdy piksel został powiększony dwukrotnie, a że ekran VGA ma na krawędziach dwa razy więcej pikseli niż QVGA to rysowanie w ten sposób sprawia, ze aplikacja nadal zajmuje cały ekran i wydaje się, że piksele są dwa razy większe (czyli ekran 240x320).
Ale to złudzenie występuje tylko wtedy, gdy patrzymy na ekran z odległości (no chyba, że ktoś ma super dobry wzrok i widzi dobrze bez lupy).
Tak naprawdę ekran jest cały czas w rozdzielczości 480x640 tylko ten sposób rysowania powiększonych pikseli daje takie wrażenie i dzięki temu aplikacja w ten sposób powiększona nadal (tak jak na QVGA) zajmuje cały ekran a nie tylko jego ćwierć.
Nie wiem czy biblioteka GAPI pisana specjalnie dla X50v jest szybsza niż standardowa, ale jeśli np. odpalisz gierkę Z-Raid (demo można znaleźć w sieci) i obraz przesuwa się idealnie płynnie to znaczy że jest szybsza niż standardowa, bo u mnie na VGA przy emulacji GAPI na tej grze to trudno mówić o płynności.