29.10.2010 18:26
[#1]
Programowanie w asemblerze "deprecated" w OS4 ?
Dlaczego tak jest, że programowanie w asemblerze jest już zarzucone (nie powinno się już tego robić) w OS4? Brakuje low-level includes. Ktoś wie dlaczego tak jest? Czyżby planowana zmiana procesora w przyszłości? Czy może nowe procki już nie są kompatybilne z tymi starymi PowerPC? Ja uważam, że to nie jest dobra sytuacja, ponieważ brakuje niskopoziomowych implementacji wielu procedur, które znacząco poprawiły by "performance" systemu i oprogramowania. Dlatego np. napisałem "diamond playera", bo wysokopoziomowe AHI na AmigaOS4.0 zachowuje się tragicznie.
29.10.2010 19:09
[#2]
Re: Programowanie w asemblerze
@Minniat, post #1
Nie ma sensu klepac w asm ppc. Duzo instrukcji, niektore mozesz uzywac nieefektywnie , architektura load/store co troszke zwieksza liczbe klepanych instrukcji itp. Lepiej jak o to zadba np gcc czy inny kompilator.
W mosie jest mozliwosc pisania pod asm ppc poprzez gcc i vbcc ale szkoda czasu :)
Ostatnia modyfikacja: 29.10.2010 19:10:51
W mosie jest mozliwosc pisania pod asm ppc poprzez gcc i vbcc ale szkoda czasu :)
Ostatnia modyfikacja: 29.10.2010 19:10:51
29.10.2010 19:46
[#3]
Re: Programowanie w asemblerze "deprecated" w OS4 ?
@Minniat, post #1
Ktoś wie dlaczego tak jest?
Bo nie warto wszystkiego pisac w assemblerze. Po co?
ponieważ brakuje niskopoziomowych implementacji wielu procedur,
skad to wiesz? Jakie procedury chcialbys pisac w assemblerze? Potrafisz napisac kod pod PPC, ktory jest wydajniejszy od tego co generuje kompilator (pomijam kwestie Altivec, ktorego obsluga w gcc jest taka sobie)?
które znacząco poprawiły by "performance" systemu i oprogramowania
Skad wiesz ze takie procedury by pomogly? W wiekszosci przypadkow zmiana algorytmu moze dac duzo wiekszy skok wydajnosci niz mozolne przepisywanie wsyzstkiego na assembler.
PS. "performance"? Polskiego slowa zabraklo?
29.10.2010 20:13
[#4]
Re: Programowanie w asemblerze "deprecated" w OS4 ?
@szuler, post #3
Dziękuję za odpowiedzi. Chodzi mi tylko o to, że obecnie oprogramowanie, które jest tworzone dla OS4 korzysta aż nadto z warstw abstrakcji (np. gry pisze się w SDL'u zamiast korzystać z procedur systemowych). Oczywiście jestem pewien, że da się napisać taką implementację SDL dla Amigi, żeby chodziła szybko nawet na słabszym procesorze. No bo niby dlaczego miało by się nie dać? I dlaczego wydajność programów napisanych w SDL jest taka słaba na Amidze? Gdzie tkwi przyczyna takiego stanu rzeczy? Przecież SDL jest zbiorem procedur odpowiedzialnych m. in. za rysowanie, odtwarzanie muzyki i dźwięków oraz odczyt stanu klawiatury i myszy. Czy nie dałoby się tych procedur zoptymalizować pod słabszy PPC? Pytanie też na czasie przy okazji nadchodzącego AmigaOS4.1 dla Amig klasycznych.
Według mnie do korzystania z klawiatury i myszy jest input.device tudzież IDCMP okienka, po co dodatkowo obciążać system/procesor?? Do rysowania jest graphics.library i Picasso96API.library. Do dźwięku ahi.device. Podejrzewam, że SDL w jakiś sposób odnosi się do tych zasobów, ale dlaczego w taki "niebezpośredni" sposób ;) - piszę niezbezpośredni, bo szybkość działania programów korzystających z SDL na amigowym sprzęcie pozostawia wiele do życzenia. Czy można zachować portowalność SDL, a jednocześnie uczynić go wydajniejszym na Amidze?
Według mnie do korzystania z klawiatury i myszy jest input.device tudzież IDCMP okienka, po co dodatkowo obciążać system/procesor?? Do rysowania jest graphics.library i Picasso96API.library. Do dźwięku ahi.device. Podejrzewam, że SDL w jakiś sposób odnosi się do tych zasobów, ale dlaczego w taki "niebezpośredni" sposób ;) - piszę niezbezpośredni, bo szybkość działania programów korzystających z SDL na amigowym sprzęcie pozostawia wiele do życzenia. Czy można zachować portowalność SDL, a jednocześnie uczynić go wydajniejszym na Amidze?
29.10.2010 20:31
[#5]
Re: Programowanie w asemblerze "deprecated" w OS4 ?
@Minniat, post #4
np. gry pisze się w SDL'u zamiast korzystać z procedur systemowych
A to juz wina programistow. Assembler w tym nie pomoze.
Według mnie do korzystania z klawiatury i myszy jest input.device tudzież IDCMP okienka, po co dodatkowo obciążać system/procesor?? Do rysowania jest graphics.library i Picasso96API.library. Do dźwięku ahi.device. Podejrzewam, że SDL w jakiś sposób odnosi się do tych zasobów, ale dlaczego w taki "niebezpośredni" sposób - piszę niezbezpośredni, bo szybkość działania programów korzystających z SDL na amigowym sprzęcie pozostawia wiele do życzenia.
Na temat nadmiaru warstw abstrakcji dyskusja toczyla sie i tu, i na exec.pl niejednokrotnie. W wiekszosci wypadkow konczyla sie rzucaniem blota na wszystkie strony i obrazaniem dyskutantow. Prawda jest, ze SDL to czesto jedna z wielu warstw abstrakcji, z ktorej mozna by zrezygnowac. Prawda jest, ze masa programow i gier pod SDL jest napisana gorzej niz fatalnie - jedna wielka petla permanentnie sprawdza stan klawiatury i myszki, oraz odrysowuje ekran gry tak czesto jak tylko mozliwe. Ale na to nic nie poradzisz. Gry dla OS4, MOS-a i AROS-a to czesto porty gierek w SDL pisanych pod linuksa, gdzie marny styl pisania i zasobozernosc gierek tlumione sa dosc sprawnie dzialajacym shedulerem. Tutaj nie pomoze assembler, bo to nie o przyspieszenie procedor w OS4 czy MOS-ie chodzi.
A co do warstw abstrakcji. Tobie przeszkadza SDL, innym ixemul, jeszcze innym Cygnix. Z kazdej z tych warstw mozna zrezygnowac, ale oznaczalo by to pisanie osobnego GUI albo calego silnika gry pod AmigaOS/MorphOS. Czesto z braku czasu albo umiejetnosci jest to po prostu niemozliwe.
29.10.2010 21:13
[#6]
Re: Programowanie w asemblerze "deprecated" w OS4 ?
@Minniat, post #4
SDL to przenoszalna biblioteka i dlatego jest dodatkowa warstwa miedzy systemem. Odpowiednio napisana jest np. w MOS-ie i jest naprawde bardzo szybka. Zapewne blitowanie jest wykonywane porownywalnie z tym ktore bys zrobil za pomoca gfx.lib.
Domyslam sie, ze raczej mowisz bardziej o SDL na os4 i np. klasyku. Tam nie ma co sie dziwic, jest tylke waskich gardel ze pomimo napisania ultra szybkiej implementacji tegoz az tak bardzo nie zyskasz na szybkosci. Po prostu policz sobie ile np gra z 25fps w rozdzielczosci 640x480 musi przerzucic danych a grafika to oczywiscie nie wszystko.
Jezeli ci chodzi o dostep bezposredni to jak sobie to wyobrazasz, kazda aplikacja bedaca jakas warstwa ma banglac sprzetowo?:)
To juz bylo i przez to jest z softem klasycznym jak jest.
Domyslam sie, ze raczej mowisz bardziej o SDL na os4 i np. klasyku. Tam nie ma co sie dziwic, jest tylke waskich gardel ze pomimo napisania ultra szybkiej implementacji tegoz az tak bardzo nie zyskasz na szybkosci. Po prostu policz sobie ile np gra z 25fps w rozdzielczosci 640x480 musi przerzucic danych a grafika to oczywiscie nie wszystko.
Jezeli ci chodzi o dostep bezposredni to jak sobie to wyobrazasz, kazda aplikacja bedaca jakas warstwa ma banglac sprzetowo?:)
To juz bylo i przez to jest z softem klasycznym jak jest.
30.10.2010 13:05
[#7]
Re: Programowanie w asemblerze
@szuler, post #5
@Szuler
@AmiChris
Dziękuję za wyczerpujące wyjaśnienie problemu. Teraz rozumiem, że przyczyna tkwi w samym SDLu i stylu pisania gier pod tą bibliotekę, a nie w amigowej implementacji tej biblioteki. Filozofia SDLu zatem moim zdaniem troszkę nie wpasowuje się w filozofię programowania na AmigaOS, gdzie liczy się wydajność.
Z ciekawości wdrożyłem się troszkę w SDL i przestudiowałem dokumentację na libsdl.org. Widzę, że ta biblioteka jest jednak dość wysokopoziomowa, niektóre procedury są niemalże tym czym komendy w AMOSie (muszę z prerażeniem stwierdzić, że jest to biblioteka jeszcze wyższego poziomu). Ja inaczej sobie wyobrażam taką bibliotekę dla AmigaOS. Ja rozumiem, że to musi być portowalne, ale nie można aż tak ułatwiać programiście zadania, by ten kompletnie zapomniał o implementacji własnych algorytmów i wręcz zabrać mu możliwość ingerencji w wiele mechanizmów swojego programu.
Portowanie gier pod SDL zapewne sprowadza się tylko do kompilacji programów korzystających tylko i wyłącznie z tej biblioteki pod AmigaOS (sławetne Configure & Make). Czy nie warto jednak przysiąść nad jednym projektem, który się portuje i go przyspieszyć niż zabierać się za portowanie kolejnego programu (no bo obecnie tak wygląda portowanie gier dla AmigaOS).
Dla mnie ta biblioteka w obecnej postaci jest po prostu dla kogoś kto lubi już gotowe rozwiązania (ja rozumiem że trzeba korzystać z gotowych rozwiązań, ale ma to swoje granice). Czyli dla kogoś kto jednak preferuje Basic od C/C++. Ja wiem, że programy korzystające z tej biblioteki pisze się w C++ (choć teraz nawet w Pythonie), ale trudno nie zauważyć analogii. Taka jest moja opinia na ten temat. Według mnie za dużo się portuje, a za mało poświęca czas na samo portowanie.
Konkluzja jest taka - powinna powstać biblioteka powiedzmy, że nazywałaby się Amiga MultiMedia Layer, która korzystałaby ze specyfiki AmigaOS. Wiele razy udowodniono, że korzystanie przy projektowaniu programów ze specyfiki danego systemu, procesora, danych, daje dużo dobrych rozwiązań. Np. MPEG Layer III to kodowanie dźwięku, inne dane tą metodą są źle kompresowane, metod sortowań jest całe mnóstwo, ale każde nadaje się do specyficznego rodzaju danych itd. Mam nadzieję, że mój apel spotka się z jakąś pozytywną reakcją środowiska developerów AmigaOS. Przygotujcie się proszę na pisanie dla AmigaOS4.1 tak by już nikt nie narzekał, że wszystko jest tam ślamazarne (zważywszy, że AmigaOS4.1 ma się pojawić również dla klasyka).
Pozdrawiam i zapraszam chętnych do dysusji nt. pisania wydajnie dla AmigaOS. Sam jestem bardzo wdzięczny za informacje które tutaj mi przekazano i jestem gotów podzielić się też własnym doświadczeniem. Czy ktoś z Was też wyobraża sobie taką amigową bibliotekę?
Ostatnia modyfikacja: 30.10.2010 13:53:12
@AmiChris
Dziękuję za wyczerpujące wyjaśnienie problemu. Teraz rozumiem, że przyczyna tkwi w samym SDLu i stylu pisania gier pod tą bibliotekę, a nie w amigowej implementacji tej biblioteki. Filozofia SDLu zatem moim zdaniem troszkę nie wpasowuje się w filozofię programowania na AmigaOS, gdzie liczy się wydajność.
Z ciekawości wdrożyłem się troszkę w SDL i przestudiowałem dokumentację na libsdl.org. Widzę, że ta biblioteka jest jednak dość wysokopoziomowa, niektóre procedury są niemalże tym czym komendy w AMOSie (muszę z prerażeniem stwierdzić, że jest to biblioteka jeszcze wyższego poziomu). Ja inaczej sobie wyobrażam taką bibliotekę dla AmigaOS. Ja rozumiem, że to musi być portowalne, ale nie można aż tak ułatwiać programiście zadania, by ten kompletnie zapomniał o implementacji własnych algorytmów i wręcz zabrać mu możliwość ingerencji w wiele mechanizmów swojego programu.
Portowanie gier pod SDL zapewne sprowadza się tylko do kompilacji programów korzystających tylko i wyłącznie z tej biblioteki pod AmigaOS (sławetne Configure & Make). Czy nie warto jednak przysiąść nad jednym projektem, który się portuje i go przyspieszyć niż zabierać się za portowanie kolejnego programu (no bo obecnie tak wygląda portowanie gier dla AmigaOS).
Dla mnie ta biblioteka w obecnej postaci jest po prostu dla kogoś kto lubi już gotowe rozwiązania (ja rozumiem że trzeba korzystać z gotowych rozwiązań, ale ma to swoje granice). Czyli dla kogoś kto jednak preferuje Basic od C/C++. Ja wiem, że programy korzystające z tej biblioteki pisze się w C++ (choć teraz nawet w Pythonie), ale trudno nie zauważyć analogii. Taka jest moja opinia na ten temat. Według mnie za dużo się portuje, a za mało poświęca czas na samo portowanie.
Konkluzja jest taka - powinna powstać biblioteka powiedzmy, że nazywałaby się Amiga MultiMedia Layer, która korzystałaby ze specyfiki AmigaOS. Wiele razy udowodniono, że korzystanie przy projektowaniu programów ze specyfiki danego systemu, procesora, danych, daje dużo dobrych rozwiązań. Np. MPEG Layer III to kodowanie dźwięku, inne dane tą metodą są źle kompresowane, metod sortowań jest całe mnóstwo, ale każde nadaje się do specyficznego rodzaju danych itd. Mam nadzieję, że mój apel spotka się z jakąś pozytywną reakcją środowiska developerów AmigaOS. Przygotujcie się proszę na pisanie dla AmigaOS4.1 tak by już nikt nie narzekał, że wszystko jest tam ślamazarne (zważywszy, że AmigaOS4.1 ma się pojawić również dla klasyka).
Pozdrawiam i zapraszam chętnych do dysusji nt. pisania wydajnie dla AmigaOS. Sam jestem bardzo wdzięczny za informacje które tutaj mi przekazano i jestem gotów podzielić się też własnym doświadczeniem. Czy ktoś z Was też wyobraża sobie taką amigową bibliotekę?
Ostatnia modyfikacja: 30.10.2010 13:53:12
30.10.2010 13:54
[#8]
Re: Programowanie w asemblerze "deprecated" w OS4 ?
@Minniat, post #7
Mamy rok 2010.
Sprzęt do MOSa łatwo dostać i jest tani.
Zastępowanie sprzętu ludzką pracą nie ma sensu.
Tym bardziej że w przypadku gier 2d które zwykle i tak działają na całym ekranie nie będzie na szybkim sprzęcie widać różnicy.
Jest tyle rzeczy których brakuje i byłoby lepiej żeby ktoś się tym zajął.
Sprzęt do MOSa łatwo dostać i jest tani.
Zastępowanie sprzętu ludzką pracą nie ma sensu.
Tym bardziej że w przypadku gier 2d które zwykle i tak działają na całym ekranie nie będzie na szybkim sprzęcie widać różnicy.
Jest tyle rzeczy których brakuje i byłoby lepiej żeby ktoś się tym zajął.
30.10.2010 14:58
[#9]
Re: Programowanie w asemblerze "deprecated" w OS4 ?
@qwerty40001, post #8
Tym bardziej że w przypadku gier 2d które zwykle i tak działają na całym ekranie nie będzie na szybkim sprzęcie widać różnicy.
Moim zdaniem na dłuższą metę to jest troszkę niewłaściwe podejście, ale cóż to tylko moje zdanie...
Jest tyle rzeczy których brakuje i byłoby lepiej żeby ktoś się tym zajął
No i obecnie lekarstwem na to jest portowanie bibliotek, które mają na celu umożliwienie przeportowania kolejnych programów w krótkim czasie. Ja rozumiem, że przyczyną takiej sytuacji jest to, że brakuje rąk ludzkich (czyt. developerów amigowych) którzy podjęliby się zadania uzupełnienia luk w amigowym oprogramowaniu. Na szczęście są wypadki, że osoby łączą swoje wysiłki żeby coś zrobić (np. Open Office 4 Kids), choć to kropla w morzu potrzeb.
Ja na przykład jestem odpowiedzialny za powstawanie edytora ikon 32-bit dla AmigaOS. Jak ja się sprawuję w roli developera AmigaOS4 będziecie mogli się wkrótce przekonać (jak czas pozwoli to będzie to w miarę szybko) :D
30.10.2010 15:19
[#10]
Re: Programowanie w asemblerze
@Minniat, post #9
Ha! Znalazłem dowód swojej teorii :D Właśnie na OS4Depot umieszczono bardzo szybki silnik 3D.
http://os4depot.net/?function=showfile&file=demo/scene/universe/pxs-engine.lha
W komentarzach chwalą autora za 59/58 FPS na Sam440ep w rozdzielczości 1600x900 !! Autor korzysta z Warp3D czyli niskopoziomowej biblioteki 3D.
Ostatnia modyfikacja: 30.10.2010 15:21:24
http://os4depot.net/?function=showfile&file=demo/scene/universe/pxs-engine.lha
W komentarzach chwalą autora za 59/58 FPS na Sam440ep w rozdzielczości 1600x900 !! Autor korzysta z Warp3D czyli niskopoziomowej biblioteki 3D.
Ostatnia modyfikacja: 30.10.2010 15:21:24
30.10.2010 17:20
[#11]
Re: Programowanie w asemblerze
@Minniat, post #7
Odpisze ci hurtowo na wszystkie posty. Spojrz na to tak, jest sobie bibliotek rtgmaster, ktora jest wlasnie tym czego szukasz, mozesz jak i inni pisac na niej gry nie martwiac sie o kompatybilnosc bo to jest typoowo amigowa bilbioteka. Widzisz wysyp softu wykorzystujacego to?
Chyba napalm z tego korzystal, kilka demek, moze jeszcze kilka gier i amen. Dobra biblioteka a i tak nie wniosla wysypu nowych gier.
SDL jako taka jest swietna abstrakcja dla gier. Wybacz ale o jakich algorytmach piszesz? Przeciez tam sa procki do blitowania, odtwarzania,oblsugi zdarzen itp. Kto ci zakazuje uzywania np ahi do odgrywania muzyki pod sdl-em? Chodzi o przenoszalnosc wiec kazdy wybiera to co jest wbudowane. Z blitowaniem jest inna sprawa bo (na szczescie) nie mozesz odwolywac sie do typowych struktur systemowych odpowiadajacych za obraz.Oczywiscie jest to mozliwe ale po co kombinowac.
Na klasyku bedzie slamazarnie, raczej przywyknij, tak to juz jest. Szczegolnie gdy piszesz o AGA :)
OS4 i klasyk to jest ostatnia grupa docelowa kazdego z nowych amigaos-ow. To ze bedzie sie ciac nikogo nie bedzie obchodzic bo mozna kupic pega,sam,maki za smieszne pieniadze i miec szybko.
Chyba napalm z tego korzystal, kilka demek, moze jeszcze kilka gier i amen. Dobra biblioteka a i tak nie wniosla wysypu nowych gier.
SDL jako taka jest swietna abstrakcja dla gier. Wybacz ale o jakich algorytmach piszesz? Przeciez tam sa procki do blitowania, odtwarzania,oblsugi zdarzen itp. Kto ci zakazuje uzywania np ahi do odgrywania muzyki pod sdl-em? Chodzi o przenoszalnosc wiec kazdy wybiera to co jest wbudowane. Z blitowaniem jest inna sprawa bo (na szczescie) nie mozesz odwolywac sie do typowych struktur systemowych odpowiadajacych za obraz.Oczywiscie jest to mozliwe ale po co kombinowac.
Na klasyku bedzie slamazarnie, raczej przywyknij, tak to juz jest. Szczegolnie gdy piszesz o AGA :)
OS4 i klasyk to jest ostatnia grupa docelowa kazdego z nowych amigaos-ow. To ze bedzie sie ciac nikogo nie bedzie obchodzic bo mozna kupic pega,sam,maki za smieszne pieniadze i miec szybko.
30.10.2010 18:19
[#12]
Re: Programowanie w asemblerze
@Minniat, post #10
Sądze, że z Warp3D można osiągnąć też taki wynik na klasyku z PPC (tylko w niższej rozdziałce). Z resztą, od niedawna mam CSPPC i CVPPC, więc może sam ogarnę też temat ;).
Aha, jeszcze chciałem wyrazić swoje poprarcie dla autora wątku. Za to że mu się chce w ogóle. Nie uważam aby poznawanie asm'a PPC było bezcelowe. Nawet jeśli go nie będzie sam na codzień używał to może dzięki temu ogólna jakość jego kodu i świadomość programistyczna wzrośnie.
Ostatnia modyfikacja: 30.10.2010 18:27:59
Aha, jeszcze chciałem wyrazić swoje poprarcie dla autora wątku. Za to że mu się chce w ogóle. Nie uważam aby poznawanie asm'a PPC było bezcelowe. Nawet jeśli go nie będzie sam na codzień używał to może dzięki temu ogólna jakość jego kodu i świadomość programistyczna wzrośnie.
Ostatnia modyfikacja: 30.10.2010 18:27:59
28.12.2010 13:00
[#13]
Re: Programowanie w asemblerze
@Minniat, post #10
chwalą autora za 59/58 FPS na Sam440ep w rozdzielczości 1600x900 !! Autor korzysta z Warp3D czyli niskopoziomowej biblioteki 3D
Przecież przy korzystaniu z 3D taki rezultat to żadne osiągnięcie. Wszystko zależy co się tam dzieje na ekranie. :) No przecież jest chyba różnica czy kręci się sześcian czy 200 tysięcy multiteksturowanych dużymi teksturami trójkątów. Rozdzielczość tak bardzo nie wpływa na prędkość jak przy softwareowym rendererze. Ocena ilości FPS bez analizy tego co się tam dzieje zupełnie nie ma sensu. Niezależnie od rozdzielczości ekranu.
Przecież przy korzystaniu z 3D taki rezultat to żadne osiągnięcie. Wszystko zależy co się tam dzieje na ekranie. :) No przecież jest chyba różnica czy kręci się sześcian czy 200 tysięcy multiteksturowanych dużymi teksturami trójkątów. Rozdzielczość tak bardzo nie wpływa na prędkość jak przy softwareowym rendererze. Ocena ilości FPS bez analizy tego co się tam dzieje zupełnie nie ma sensu. Niezależnie od rozdzielczości ekranu.
29.12.2010 11:45
[#14]
Re: Programowanie w asemblerze
@MDW, post #13
Już piszę co widać na ekranie: jest to w sumie statyczna scena, jedyne co rusza się to kamera, która okrąża całą scenerię z każdej strony: widzimy przepiękne złociste niebo z chmurami i Słońcem i zawieszone w chmurach samoloty (jeden lub wiele samolotów w zależności od wersji dema). Samoloty mają bardzo ładny profil i są dopracowane w każdym calu. Całość sprawia niesamowite wrażenie i jest bardzo realistyczne (szczególnie w wysokiej rozdzielczości). Szybkość renderowania jest super przyzwoita, u mnie 40 FPS na Sam440ep-flex w rozdzielczości 1280x1024x32.
Polecam do obejrzenia każdemu fanowi renderów i właścicielowi komputera z AmigaOS4.x.
Ostatnia modyfikacja: 29.12.2010 11:48:30
Polecam do obejrzenia każdemu fanowi renderów i właścicielowi komputera z AmigaOS4.x.
Ostatnia modyfikacja: 29.12.2010 11:48:30
29.12.2010 13:21
[#15]
Re: Programowanie w asemblerze
@Minniat, post #14
No tak... ale wygląd sceny to sprawa grafika. Coś może wyglądać koszmarnie i być zbudowane z 200 tysięcy trójkątów, niepotrzebnie ogromnych teksturach bez mipmappingu. No a coś może być przepiękne i być zbudowane z 5000 trójkątów, odpowiednio zoptymalizowanych tekstur, itd... Jeżeli coś chodzi dobrze w 640x480 to w 1280x960 dużo gorzej chodziło nie będzie. Dla akceleratora rozdzielczość ekranu nie robi aż tak zabójczej różnicy jak dla czysto programowych rozwiązań (chociaż na pewno FPS będzie mniejszy).