04.04.2011 09:49
[#31]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@G. Kraszewski, post #30
Napisałeś tak grę kiedyś?
takiej gry to nie, w ogole nie pisze gier :). nie opisuje dok. bo to za duzo pisania.
chcialem tylko zauwazyc, ze przeliczanie i nie rysowanie, to jest pewne marnotrastwo, przed przeliczaniem w/w pozycji.., lepiej sprawdzic czy skonczylo sie poprzednie rysowanie, nie wiele to kosztuje, a wiele sie zyskuje, wszystko i tak odbywa sie w przedzialach czasu, ktore nie musza byc stale, a sa zmienne - rysowanie nigdy nie trwa dok. tyle samo... od tego jest zegar zeby sprawdzic jaki minal czas, po czym przeliczyc w/w pozycje i narysowac.
nie mowie o takich sprawach jak rozne zdarzenia, zmiany poszczegolnych stanow etc.. - logika gry, to musi odbywac dok. w tych ustalonych przedzialach czasu i jednak w nich zmiescic... w grach czasu rzeczywistego.
oczywiscie traktowac to tylko jako propozycje, kazdy zrobi jak umie i bedzie chcial:)
Ostatnia modyfikacja: 04.04.2011 09:58:30
04.04.2011 09:58
[#32]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@1989, post #31
Instruktor KO
Tylko. Właśnie nie wiem bo ja prawdę mówiąc... Nie słyszałem piosenki, więc chciałem powiedzieć parę słów na jej temat, bo wydaje mi się, że panowie tutaj chyba dość, przepraszam, mylnie interpretują treść tego co panowie słyszeli, bo jeżeli... Jeżeli ktoś u nas w tej chwili, na bieżąco, w konkretnych bardzo okolicznościach, jak teraz żyjemy prawda wszyscy w końcu tutaj gdzieś, i ktoś nagle śpiewa, że jest mu nie dobrze, że nie ma konkretnego celu, w czasach kiedy dookoła od celów jest aż... aż... aż gęsto aż... aż się mnożą te cele w ogóle aż jeden za drugim następuje, gdzie kolektyw obok kolektywu, gdzie ludzie są naprawdę wszędzie razem, gdzie ciągle... gdzie ciągle czują się jakoś związani ze sobą i nagle ktoś śpiewa, że jest samotny i, że nie ma się gdzie przystosować i, że nie ma nikogo, że... że... że w ogóle nie wie co ze sobą zrobić, że tęskni za czymś bliżej nieokreślonym, skoro wiadomo, że mamy bardzo konkretne cele i konkretne dążenia i wiemy za czym mamy... jeżeli mamy tęsknoty to wiemy jakie to są tęsknoty i bardzo są konkretne, jeżeli ten ktoś w ten sposób śpiewa, panowie, no to przecież panowie... to przecież... to on nie śpiewa tego serio po prostu. Na tym polega problem
POETA
Ale skąd się łzy biorą ?
W jego oczach. W takim śpiewaniu.
04.04.2011 10:17
[#33]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@Tomski, post #32
to ma byc scenariusz gry :)
wiem co chcesz mi powiedziec, nie tworzysz gier, nie odzywaj sie, na pewno jestes w bledzie, nie masz racji, malo wiesz :), okey. programuje/programowalem co innego. czasu rzeczywistego w tym nie potrzeba. Tworzenie gier mnie nie interesuje, bo nie mam pomyslu na gre w ktora chcialbym sam grac - klasyki z lat 90 sa dla mnie zbyt doskonale i wiele zostalo do pogrania :), za to robie male cos na party w Lodzi, w ramach relaksu i z mysla o czyms kolejnym, moze programie uzytecznym.
Ostatnia modyfikacja: 04.04.2011 10:19:48
wiem co chcesz mi powiedziec, nie tworzysz gier, nie odzywaj sie, na pewno jestes w bledzie, nie masz racji, malo wiesz :), okey. programuje/programowalem co innego. czasu rzeczywistego w tym nie potrzeba. Tworzenie gier mnie nie interesuje, bo nie mam pomyslu na gre w ktora chcialbym sam grac - klasyki z lat 90 sa dla mnie zbyt doskonale i wiele zostalo do pogrania :), za to robie male cos na party w Lodzi, w ramach relaksu i z mysla o czyms kolejnym, moze programie uzytecznym.
Ostatnia modyfikacja: 04.04.2011 10:19:48
04.04.2011 10:19
[#34]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@1989, post #31
1. Przeliczenie pozycji obiektów zazwyczaj zajmuje o wiele mniej czasu niż odrysowanie klatki.
2. Taki sposób organizacji pętli (z pomiarem czasu) komplikuje przeliczenie pozycji. Przykładowo, jeżeli obiekt porusza się ruchem jednostajnym, jeżeli przeliczamy pozycję każdej klatki wystarczy jedno dodawanie. Jeżeli zrobi się to metodą pomiaru czasu, mamy dodawanie i mnożenie. A spróbuj sobie wyobrazić jak skomplikują się obliczenia, jeżeli w zmierzonym czasie np. obiekt odbija się od przeszkody...
2. Taki sposób organizacji pętli (z pomiarem czasu) komplikuje przeliczenie pozycji. Przykładowo, jeżeli obiekt porusza się ruchem jednostajnym, jeżeli przeliczamy pozycję każdej klatki wystarczy jedno dodawanie. Jeżeli zrobi się to metodą pomiaru czasu, mamy dodawanie i mnożenie. A spróbuj sobie wyobrazić jak skomplikują się obliczenia, jeżeli w zmierzonym czasie np. obiekt odbija się od przeszkody...
04.04.2011 10:32
[#35]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@1989, post #33
wiem co chcesz mi powiedziec, nie tworzysz gier, nie odzywaj sie, na pewno jestes w bledzie, nie masz racji, malo wiesz usmiech, okey.
programuje/programowalem co innego. .... za to robie male cos na party w Lodzi, w ramach relaksu i z mysla o czyms kolejnym, moze programie uzytecznym.
Chwała Ci za to.
04.04.2011 10:41
[#36]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@G. Kraszewski, post #34
1. Przeliczenie pozycji obiektów zazwyczaj zajmuje o wiele mniej czasu niż odrysowanie klatki.
ale zajmuje znacznie wiecej niz sprawdzenie czy juz zakonczono rysowanie i zmiana stanu zegara (sprzetowy).
2. Taki sposób organizacji pętli (z pomiarem czasu) komplikuje przeliczenie pozycji. Przykładowo, jeżeli obiekt porusza się ruchem jednostajnym, jeżeli przeliczamy pozycję każdej klatki wystarczy jedno dodawanie
w takim prostym przypadku to moze tak, ale przeliczanie w nawet prostej grze jest bardziej zlozone. przelicza sie wiele pozycji, nie tylko proste przesuniecie (dodatkowe mnozenie nie jest raczej wielkim narzutem), a jezeli nie bedzie "pustych" przeliczen to rekompensuje z nawiazka, w przypadku wlasnie slabszych konfiguracji. tak sadze.
Ostatnia modyfikacja: 04.04.2011 10:44:18
04.04.2011 10:53
[#37]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@1989, post #36
No cóż, widzę, że wiesz lepiej. Trudno, ja swoje programy będę pisał mimo wszystko metodą przeliczania wszystkich klatek. Zauważ, że Twoja metoda daje realne zyski tylko wtedy, kiedy sprzęt i tak okazuje się za wolny. A komplikacja przeliczania Twoim sposobem jest proporcjonalna do złożoności sceny. Jeżeli przesuwasz 50 obiektów, to będziesz miał 50 mnożeń ekstra. Jeżeli masz obiekty poruszające się ruchem jednostajnie przyspieszonym, zamiast 3 dodawań masz 2 dodawania i 2 mnożenia... I tak dalej.
Rozpisz sobie oboma sposobami równania ruchu np. kulki odbijającej się idealnie sprężyście od dolnej i bocznych krawędzi ekranu, poruszającej się jednostajnie w poziomie i grawitacyjnie (ruch jednostajnie przyspieszony/opóźniony) w pionie... Zobaczysz jaka jest różnica.
Ostatnia modyfikacja: 04.04.2011 10:57:55
Rozpisz sobie oboma sposobami równania ruchu np. kulki odbijającej się idealnie sprężyście od dolnej i bocznych krawędzi ekranu, poruszającej się jednostajnie w poziomie i grawitacyjnie (ruch jednostajnie przyspieszony/opóźniony) w pionie... Zobaczysz jaka jest różnica.
Ostatnia modyfikacja: 04.04.2011 10:57:55
04.04.2011 11:20
[#39]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@G. Kraszewski, post #37
No cóż, widzę, że wiesz lepiej.
tego nie napisalem, zaproponowalem inne rozwiazanie, nie uwazam zeby Twoja metoda byla zla, w pewnych szczegolnych przypadkach jest idealna... kiedy np: trafien w "puste" przeliczenia jest bardzo malo.
Zauważ, że Twoja metoda daje realne zyski tylko wtedy, kiedy sprzęt i tak okazuje się za wolny.
nie tylko, piszemy o grze pod OS, a tu czasami zachodzi cos w tle, wiec przeliczanie kazdej klatki byloby bardziej obciazajace dla calego OS, takze na szybkich konfiguracjach.
A komplikacja przeliczania Twoim sposobem jest proporcjonalna do złożoności sceny.
i tak, i nie :). jeden argument w/w (rekompensuje w przypadku b.zloznej gry, a slabszej konfiguracji, co daje mysle wiecej czasu innym operacjom, wlasnie o ten zysk na przeliczeniach, takze ogolnie powinno byc wiecej fps), drugi to taki, ze w przypadku szybkich cpu, operacja mnozenia dziala lepiej, wiec ten dodatkowy narzut jest znacznie mniejszy, niz wynikaloby to z tego samego przeliczenia dla slabszego cpu.
04.04.2011 12:34
[#40]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@1989, post #39
nie tylko, piszemy o grze pod OS, a tu czasami zachodzi cos w tle, wiec przeliczanie kazdej klatki byloby bardziej obciazajace dla calego OS, takze na szybkich konfiguracjach.
Otóż nie. Jeżeli przez "szybką" konfigurację rozumiemy taką, na której gra wyrabia założony limit FPS, to wtedy i tak trzeba obliczyć każdą ramkę, a wtedy moja metoda jest mniej obciążająca (bo przeliczenie ramki jest prostsze).
Prosty przykład obliczeniowy dla kilku różnych konfiguracji. Zakładam, że nominalne tempo gry to 20 FPS (50 ms na ramkę) i optymistycznie bardzo, że Twoja metoda ma złożoność obliczeniową tylko 200% mojej (dlaczego optymistycznie – na większości procesorów dodawanie i mnożenie trwa dłużej niż dwa dodawania, na procesorze, na którym czasy byłyby te same, byłoby 200%. Jak wcześniej pokazałem dla jednostajnego ruchu obiektów moja metoda wymaga jednego dodawania, Twoja - dodawania i mnożenia):
1. Szybki sprzęt. Rysowanie 20 ms, liczenie 2/4 ms (moja/Twoja metoda). Moja metoda w ciągu sekundy potrzebuje 440 ms, Twoja 480 ms, obciążenie procesora 44% do 48% na moją korzyść.
2. Wolniejszy sprzęt. Rysowanie 40 ms, liczenie 4/8 ms. Na sekundę 880/960 ms, czyli 88% do 96% na moją korzyść.
3. Sprzęt zaczyna się nie wyrabiać. Rysowanie 60 ms, liczenie 6/12 ms. W mojej metodzie policzone jest zawsze 20 ramek na sekundę, więc liczenie zje 120 ms, zostanie 880 ms na rysowanie, co wystarczy na 14 2/3 ramki. W Twojej metodzie liczysz tylko te ramki, które się zdążą narysować, zatem 1000 ms dzielimy przez 72 ms, co daje 13 8/9 FPS, czyli mniej.
4. Sprzęt ewidentnie wolny. Rysowanie 100 ms, liczenie 10/20 ms. Tu moja metoda 200 ms zeżre na policzenie 20 ramek, narysowane zostanie tylko 8. Twoja metoda daje 1000/120 = 8 1/3 FPS, czyli dopiero na "dwa razy za wolnym" sprzęcie widać zysk na szybkości, całe 4%.
Żeby Twoja metoda dała znaczącą przewagę, muszą być spełnione dwa warunki:
- Czas poświęcony przeliczaniu klatki musi być porównywalny z czasem rysowania. To może zachodzić w przypadku złożonych gier 3D i szybkiej grafiki, ale my tu mówimy o klasyku.
- Gra musi być uruchomiona na kompie, który jest za wolny, żeby wyrobić założone w projekcie gry FPS-y.
Przykładowo przy ekstremalnym założeniu że na jakiejś maszynie rysowanie trwa 40 ms a liczenie 40 ms moją metodą i 70 ms Twoją (założyłem tu, że ruchy są bardziej skomplikowane niż jednostajnie przyspieszone, i/lub warunki kolizji są bardzo złożone, przez co przewaga mojej metody jest mniejsza), moja metoda daje 5 FPS a Twoja 9,1 FPS, oczywiście obie obciążają procesor w 100%. Niemniej jeżeli sięgniemy po maszynę np. dwa razy szybszą (rysowanie 20 ms, liczenie 20/35 ms) to moja metoda robi pełne 20 FPS i obciąża procesor w 80%, a Twoja robi framedropy (18,2 FPS) przy obciążeniu proca 100%...
Otóż nie. Jeżeli przez "szybką" konfigurację rozumiemy taką, na której gra wyrabia założony limit FPS, to wtedy i tak trzeba obliczyć każdą ramkę, a wtedy moja metoda jest mniej obciążająca (bo przeliczenie ramki jest prostsze).
Prosty przykład obliczeniowy dla kilku różnych konfiguracji. Zakładam, że nominalne tempo gry to 20 FPS (50 ms na ramkę) i optymistycznie bardzo, że Twoja metoda ma złożoność obliczeniową tylko 200% mojej (dlaczego optymistycznie – na większości procesorów dodawanie i mnożenie trwa dłużej niż dwa dodawania, na procesorze, na którym czasy byłyby te same, byłoby 200%. Jak wcześniej pokazałem dla jednostajnego ruchu obiektów moja metoda wymaga jednego dodawania, Twoja - dodawania i mnożenia):
1. Szybki sprzęt. Rysowanie 20 ms, liczenie 2/4 ms (moja/Twoja metoda). Moja metoda w ciągu sekundy potrzebuje 440 ms, Twoja 480 ms, obciążenie procesora 44% do 48% na moją korzyść.
2. Wolniejszy sprzęt. Rysowanie 40 ms, liczenie 4/8 ms. Na sekundę 880/960 ms, czyli 88% do 96% na moją korzyść.
3. Sprzęt zaczyna się nie wyrabiać. Rysowanie 60 ms, liczenie 6/12 ms. W mojej metodzie policzone jest zawsze 20 ramek na sekundę, więc liczenie zje 120 ms, zostanie 880 ms na rysowanie, co wystarczy na 14 2/3 ramki. W Twojej metodzie liczysz tylko te ramki, które się zdążą narysować, zatem 1000 ms dzielimy przez 72 ms, co daje 13 8/9 FPS, czyli mniej.
4. Sprzęt ewidentnie wolny. Rysowanie 100 ms, liczenie 10/20 ms. Tu moja metoda 200 ms zeżre na policzenie 20 ramek, narysowane zostanie tylko 8. Twoja metoda daje 1000/120 = 8 1/3 FPS, czyli dopiero na "dwa razy za wolnym" sprzęcie widać zysk na szybkości, całe 4%.
Żeby Twoja metoda dała znaczącą przewagę, muszą być spełnione dwa warunki:
- Czas poświęcony przeliczaniu klatki musi być porównywalny z czasem rysowania. To może zachodzić w przypadku złożonych gier 3D i szybkiej grafiki, ale my tu mówimy o klasyku.
- Gra musi być uruchomiona na kompie, który jest za wolny, żeby wyrobić założone w projekcie gry FPS-y.
Przykładowo przy ekstremalnym założeniu że na jakiejś maszynie rysowanie trwa 40 ms a liczenie 40 ms moją metodą i 70 ms Twoją (założyłem tu, że ruchy są bardziej skomplikowane niż jednostajnie przyspieszone, i/lub warunki kolizji są bardzo złożone, przez co przewaga mojej metody jest mniejsza), moja metoda daje 5 FPS a Twoja 9,1 FPS, oczywiście obie obciążają procesor w 100%. Niemniej jeżeli sięgniemy po maszynę np. dwa razy szybszą (rysowanie 20 ms, liczenie 20/35 ms) to moja metoda robi pełne 20 FPS i obciąża procesor w 80%, a Twoja robi framedropy (18,2 FPS) przy obciążeniu proca 100%...
04.04.2011 17:18
[#41]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@kiero, post #23
Witam,
Dzięki wielkie.
I kolejne pytanie ( trochę dziwne ). Jeśli funkcja początkowe ( wczytanie grafiki i umieszczenie w bitmapie ) zajmują więcej niż sobie przyjałem ( 0.02 ), to czy powinienem się tym przejmować i zrobić tak ( przez dzielenie funkcji na mniejsze - wszędzie gdzie to ma sens ) by się ewentualnie wyrabiały i było możliwe w tym czasie odebranie klawiszy, czy dać sobie siana z takim czymś. Nie wiem czy to ma większe znaczenie, gdyż ekran powitalny pojawia się po 2 sekundach na testowym środowisku.
Pozdrawiam.
Dzięki wielkie.
I kolejne pytanie ( trochę dziwne ). Jeśli funkcja początkowe ( wczytanie grafiki i umieszczenie w bitmapie ) zajmują więcej niż sobie przyjałem ( 0.02 ), to czy powinienem się tym przejmować i zrobić tak ( przez dzielenie funkcji na mniejsze - wszędzie gdzie to ma sens ) by się ewentualnie wyrabiały i było możliwe w tym czasie odebranie klawiszy, czy dać sobie siana z takim czymś. Nie wiem czy to ma większe znaczenie, gdyż ekran powitalny pojawia się po 2 sekundach na testowym środowisku.
Pozdrawiam.
04.04.2011 20:27
[#42]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@G. Kraszewski, post #40
eżeli przez "szybką" konfigurację rozumiemy taką, na której gra wyrabia założony limit FPS, to wtedy i tak trzeba obliczyć każdą ramkę
to jest jeden z idealnych przypadków, o których w/w. Jednak wychodzę z założenia, ze tylko zły żeglarz zakłada pomyślność wszystkich wiatrów. Metoda którą proponujesz, jest moim zdaniem metodą na tzw. ramkę, czyli zawsze jest jakaś minimalna konfiguracja kiedy wszystko będzie działać idealnie w idealnej sytuacji tj. założone 60fps lub 30fps :)
Obliczenia przedstawiasz optymistycznie dla proponowanej przez siebie metody, ale nawet dla prostych gier rysowanie wykonywane jest przez dodatkowy koprocesor graficzny, także rysowanie nie obciążenia w takim stopniu procesora głównego, nawet jeżeli zajmuje nieco czasu, to procesor w tym czasie przecież nie musi czekać bezczynnie. Czy w przypadku gier na klasyka należy korzystać z dodatkowych koprocesorów i czy ma to sens, to już inna sprawa.
Za każdym razem założyłeś, że obliczenia w metodzie zaproponowanej przeze mnie będą wykonywać się dwa razy dłużej, co oczywiście nie jest prawdą, gdyż taka/bardziej.złożona procedura nie składa się tylko z instrukcji dodawania i mnożenia. Znów w innym miejscu przyjmujesz liniowy przelicznik dla rysowania i obliczeń, kiedy np: dla poszczególnych instrukcji procesora nie zmienia się liniowo, nawet dla dwóch takich samych procesorów taktowanych inną częstotliwością.
04.04.2011 20:58
[#43]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@1989, post #42
Obliczenia przedstawiasz optymistycznie dla proponowanej przez siebie metody, ale nawet dla prostych gier rysowanie wykonywane jest przez dodatkowy koprocesor graficzny
Ale ten procesor graficzny sam się automagicznie nie zaprogramuje. Dla każdego detalu CPU musi wpisać cel, źródło, rozmiary blitowanego obszaru i inne parametry. A przed następnym detalem zaczekać na koniec poprzedniego... Pomijam fakt, że już na procesorze 68030 szybciej jest małe detale wrzucać na ekran procesorem.
Za każdym razem założyłeś, że obliczenia w metodzie zaproponowanej przeze mnie będą wykonywać się dwa razy dłużej, co oczywiście nie jest prawdą
Dlaczego "oczywiście"?
Jakbym się nudził, to bym zrobił Ci trójwymiarowe wykresy wydajności obu metod dla różnych stosunków czasu rysowania do czasu obliczeń i różnych stosunków czasu liczenia Twoją i moją metodą. Zobaczyłbyś, że Twoja metoda wygrywa tylko jeżeli jednocześnie spełnione są dwa warunki: liczenie trwa długo w stosunku do rysowania (co jest dla klasyka nieprawdą) i komputer jest przeciążony, czyli realne FPS jest znacznie poniżej założonego.
A w międzyczasie – zrób chociaż prostego scrolla w okienku, albo zaprogramuj na klasyku "Ponga", a potem pogadamy
Ale ten procesor graficzny sam się automagicznie nie zaprogramuje. Dla każdego detalu CPU musi wpisać cel, źródło, rozmiary blitowanego obszaru i inne parametry. A przed następnym detalem zaczekać na koniec poprzedniego... Pomijam fakt, że już na procesorze 68030 szybciej jest małe detale wrzucać na ekran procesorem.
Za każdym razem założyłeś, że obliczenia w metodzie zaproponowanej przeze mnie będą wykonywać się dwa razy dłużej, co oczywiście nie jest prawdą
Dlaczego "oczywiście"?
Jakbym się nudził, to bym zrobił Ci trójwymiarowe wykresy wydajności obu metod dla różnych stosunków czasu rysowania do czasu obliczeń i różnych stosunków czasu liczenia Twoją i moją metodą. Zobaczyłbyś, że Twoja metoda wygrywa tylko jeżeli jednocześnie spełnione są dwa warunki: liczenie trwa długo w stosunku do rysowania (co jest dla klasyka nieprawdą) i komputer jest przeciążony, czyli realne FPS jest znacznie poniżej założonego.
A w międzyczasie – zrób chociaż prostego scrolla w okienku, albo zaprogramuj na klasyku "Ponga", a potem pogadamy
04.04.2011 21:18
[#44]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@G. Kraszewski, post #43
"Ale ten procesor graficzny sam się automagicznie nie zaprogramuje. Dla każdego detalu CPU musi wpisać cel, źródło, rozmiary blitowanego obszaru i inne parametry. A przed następnym detalem zaczekać na koniec poprzedniego... "
z tym czekaniem to nie do konca prawda. nie wiem czy dziala to na kartach graficznych (pewnie nie, ale tutaj tez nie trzeba czekac na koniec poprzedniego blitu) ale na aga/ecs mozna tworzyc kolejki dla blittera (funkja QBlit()). jak to dziala z blitowaniem do okien nie wiem, nigdy tej funkcji nie uzywalem.
aha, to wszystko ma sens jedynie wtedy kiedy sam blit trwa w miare dlugo
Ostatnia modyfikacja: 04.04.2011 21:20:56
z tym czekaniem to nie do konca prawda. nie wiem czy dziala to na kartach graficznych (pewnie nie, ale tutaj tez nie trzeba czekac na koniec poprzedniego blitu) ale na aga/ecs mozna tworzyc kolejki dla blittera (funkja QBlit()). jak to dziala z blitowaniem do okien nie wiem, nigdy tej funkcji nie uzywalem.
aha, to wszystko ma sens jedynie wtedy kiedy sam blit trwa w miare dlugo
Ostatnia modyfikacja: 04.04.2011 21:20:56
04.04.2011 23:05
[#45]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@G. Kraszewski, post #43
Jakbym się nudził, to bym zrobił Ci trójwymiarowe wykresy wydajności obu metod dla różnych stosunków czasu rysowania do czasu obliczeń i różnych stosunków czasu liczenia Twoją i moją metodą.
Tak, ale Ty wszystko liczysz dla "idealnego" procesora, "idealnego" systemu itd... "idealnie" upraszczajac pod kazdym wzgledem. To nie jest wystarczajaco miarodajne.
Wezmy ten ostatni przyklad. "Przykładowo przy ekstremalnym założeniu że na jakiejś maszynie rysowanie trwa 40 ms a liczenie 40 ms moją metodą i 70 ms Twoją (założyłem tu, że ruchy są bardziej skomplikowane niż jednostajnie przyspieszone, i/lub warunki kolizji są bardzo złożone, przez co przewaga mojej metody jest mniejsza), moja metoda daje 5 FPS a Twoja 9,1 FPS, oczywiście obie obciążają procesor w 100%. Niemniej jeżeli sięgniemy po maszynę np. dwa razy szybszą (rysowanie 20 ms, liczenie 20/35 ms) to moja metoda robi pełne 20 FPS i obciąża procesor w 80%, a Twoja robi framedropy (18,2 FPS) przy obciążeniu proca 100%..."
40ms i 40/70ms, a potem sprzet x2 niby, 20ms i 20/35ms, to jest naciagane, uzylbym nawet mocniejszego slowa, nieprawdziwe. Dla mnie to juz propaganda :)
Pomijam fakt, że już na procesorze 68030 szybciej jest małe detale wrzucać na ekran procesorem.
a ja pomijam fakt, ze na procesorze 68000/7Mhz, nie szybciej. I co z tego wynika ?
Ostatnia modyfikacja: 04.04.2011 23:11:49
05.04.2011 01:36
[#46]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@kiero, post #44
z tym czekaniem to nie do konca prawda.
zgadza sie. nie trzeba czekac na koniec rysowania (DMA). dopiero przed kolejnym uzyciem blittera nalezy sprawdzic czy nie wykonuje jeszcze poprzedniej operacji.
tworzenie listy operacji dla blittera ma sens w przypadku krotszych i dluzszych blitow.
ps. tak samo jest w kartach graficznych.
G. Kraszewski
Przypadki...
przypadek pierwszy Kraszewskiego tj. "liczenie trwa długo w stosunku do rysowania (co jest dla klasyka nieprawdą)". Dla procesora nawet proste liczenie bedzie trwalo dluzej niz rysowanie za pomoca koprocesora graficznego tzn. praktycznie zawsze dluzej niz zapisanie jego rejestrow... i jest to prawda rowniez dla klasyka.
przypadek drugi Kraszewskiego tj. "komputer jest przeciążony, czyli realne FPS jest znacznie poniżej założonego". Procesor bedzie/moze byc momentami przeciazony, spadnie fps, ale nie tak dramatycznie... dla metody jaka proponuje.
przypadek nieznany Kraszewskiego, tj. "Dlaczego "oczywiście"?". Dlaczego obliczenia nie wykonuja sie dwa razy dluzej, bo nie maja jak, jezeli na powiedzmy np: 130.op, jest 60.op do/z pamieci, 50.op arytmetycznych (w tym 30.op dodawania, 15.op mnozenia, 5.op logicz.), i 20.op sterujacych. Jezeli do tego dodamy 15.op mnozenia, co da sumarycznie 145.op, to nawet w przypadku wolnej jednostki arytm., nie bedzie to 2x wiecej, a co dopiero w przypadku szybkiej jednostki arytm. gdzie operacje mnozenia moga wykonywac sie tyle samo cykli co dodawania, a jak bedzie 260.op (+30.op mnozenia),390.op(+45.op mnozenia).itd...
No coz, moim skromnym zdaniem nie ma najlepszej metody, trzeba wybrac taka ktora najlepiej pasuje do oczekiwan :)
Ostatnia modyfikacja: 05.04.2011 02:07:53
05.04.2011 21:26
[#47]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@G. Kraszewski, post #40
Zakładam, że nominalne tempo gry to 20 FPS (50 ms na ramkę)
zwroce jeszcze uwage zainteresowanym na zaproponowana przez Ciebie metode, ze jak zwiekszyc nominalne tempo np: 5x, do 100 fps, to juz w przykladzie pierwszym traci sie na "pustych" przeliczeniach calkiem sporo. wyjdzie odpowiednio Ad.1 40 fps do 41.6 fps, na korzysc metody zaproponowanej przeze mnie :) Ad.2 15 fps do 20.8 fps, Ad.3 6.6 fps do 13.8fps..
Oczywiscie to przy zalozeniu, ze ta procedura liczenia jest rzeczywiscie 2x wolniejsza, jezeli nie np: szybsza maszyna (tylko CPU) to Ad.1 40 fps do 45 fps Ad.2 15 fps do 22.7 fps Ad.3 6.6 fps do 15.1 fps....
W takim przypadku dla przypadku Ad.2 i Ad.3 metoda zaproponowana przez Ciebie jest ponizej 20fps, a Ad.2 nawet ponizej 10 fps - dramatyczny spadek fps. Spadek fps wynosi odpowiednio 6x w metodzie zaproponowanej przez Ciebie i 3x w metodzie zaproponowanej przeze mnie. Spadek fps jest istotny w przypadku pisania pod OS.
Takze liczyc to mozna wszystko jak sie chce, drogi Panie :)
PS> Ad.4 lepiej nie uzwgledniac, ponizej 1fps, spadek fps ponad 41x - ekstremalnie dramatyczny, dla porownania 8.3fps(wolny CPU)/9fps(szybki CPU)/spadek 5x... Do wykrecania FPS metoda zaproponowana przez Ciebie nie jest ;)
Ostatnia modyfikacja: 05.04.2011 22:19:30
05.04.2011 22:09
[#48]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@kiero, post #44
QBlit() jest fajny i szybki, tylko to nie jest rozwiązanie systemowe, bo korzysta z przerwań i wymaga od użytkownika napisania procedury korzystającej bezpośrednio z Blittera. Warto wspomnieć, że ta funkcja ma specjalną wersję przeznaczoną do synchronizacji z promieniem wizji QBSBlit().
15.03.2012 21:36
[#49]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@asman, post #1
Witam,
Kolejne pytanie:
1) Jak zrobić gładki scroll w oknie. Obecnie robię to w ten sposób, że kopiuje kawałek bitmapy z planszy do bitmapy okna ( zwyczajo BltBitMapRastPort ). Jest jakaś możliwość ?
Edit: zauważyłem, że WaitTOF() przed kopiowaniem tejże bitmapy ( z planszy do okna ) chyba polepsza scroll ale czy to jest prawda i jak można to sprawdzić ?
Pozdrawiam
Ostatnia aktualizacja: 15.03.2012 21:46:24 przez asman
Kolejne pytanie:
1) Jak zrobić gładki scroll w oknie. Obecnie robię to w ten sposób, że kopiuje kawałek bitmapy z planszy do bitmapy okna ( zwyczajo BltBitMapRastPort ). Jest jakaś możliwość ?
Edit: zauważyłem, że WaitTOF() przed kopiowaniem tejże bitmapy ( z planszy do okna ) chyba polepsza scroll ale czy to jest prawda i jak można to sprawdzić ?
Pozdrawiam
Ostatnia aktualizacja: 15.03.2012 21:46:24 przez asman
15.03.2012 22:47
[#50]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@asman, post #49
@scrolling
w oknie nie zrobisz nic sprytniej. moglbys skrolowac raster ale wtedy musialbys martwic sie o odrysowanie uszkodzonych fragmentow (ewentualnie okno typu smartrefresh ale wtedy pewnie bedzie jeszcze wolniej). no i watpie zeby bylo to szybsze. tyle samo odczytow i zapisow do pamieci (nie wazne czy przez blitter czy cpu).
@waittof
polepsza w taki sposob, ze mniej 'rwie'. po prostu blit nie zaczyna sie jak 'promien' jest w polowie ramki a jak jest na gorze co daje bliterowi czanse na skonczenie blitu zanim wygaszanie dojdzie do twojego okna. ogolnie WaitTOF to 'lewa' funkcja (nie ma kontekstu) i lepiej uzywac (o ile juz uzywasz) WaitBOVP. dodatkowo masz wtedy jeszcze wieksze szanse na to, ze nie bedzie widac rwania (oba overscany + pamiec chip jest szybsza jak nie jest aktualnie wyswietlana).
w oknie nie zrobisz nic sprytniej. moglbys skrolowac raster ale wtedy musialbys martwic sie o odrysowanie uszkodzonych fragmentow (ewentualnie okno typu smartrefresh ale wtedy pewnie bedzie jeszcze wolniej). no i watpie zeby bylo to szybsze. tyle samo odczytow i zapisow do pamieci (nie wazne czy przez blitter czy cpu).
@waittof
polepsza w taki sposob, ze mniej 'rwie'. po prostu blit nie zaczyna sie jak 'promien' jest w polowie ramki a jak jest na gorze co daje bliterowi czanse na skonczenie blitu zanim wygaszanie dojdzie do twojego okna. ogolnie WaitTOF to 'lewa' funkcja (nie ma kontekstu) i lepiej uzywac (o ile juz uzywasz) WaitBOVP. dodatkowo masz wtedy jeszcze wieksze szanse na to, ze nie bedzie widac rwania (oba overscany + pamiec chip jest szybsza jak nie jest aktualnie wyswietlana).
17.03.2012 10:16
[#53]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@Hextreme, post #52
Witam,
Zbyt ogólnie napisałem o scrollu w oknie. Mam na myśli nie scrollowanie całej zawartości ekranu a jedynie mniejszą powierzchnię. Za przykład niech posłuży gra Bobbo nad którą siedzę. Okno ma rozmiar w stylu 296 pikseli szerokości na 208 pikseli wysokości. Okno gry ( czyli obszar widzianej planszy ) to 256 x 160 + panel punktów na dole, ale to osobna bajka ( ujest aktualizowany gdy zajdzie potrzeba). I tutaj zwyczajnie kopiuje bitmapę planszy do bitmapy okna. Czyli co ustalony czas zawsze kopiuje tą bitmapę i tego nie ominę choćbym nie wiem jak się napinał ( i to zawsze zjada około 0,01 czasu na słabej maszynie a timer device odlicza co 0,02). WaitBOVP rozwiązuje problem, przynajmniej wygląda to znacznie lepiej niż wcześniej.
Pozdrawiam
Zbyt ogólnie napisałem o scrollu w oknie. Mam na myśli nie scrollowanie całej zawartości ekranu a jedynie mniejszą powierzchnię. Za przykład niech posłuży gra Bobbo nad którą siedzę. Okno ma rozmiar w stylu 296 pikseli szerokości na 208 pikseli wysokości. Okno gry ( czyli obszar widzianej planszy ) to 256 x 160 + panel punktów na dole, ale to osobna bajka ( ujest aktualizowany gdy zajdzie potrzeba). I tutaj zwyczajnie kopiuje bitmapę planszy do bitmapy okna. Czyli co ustalony czas zawsze kopiuje tą bitmapę i tego nie ominę choćbym nie wiem jak się napinał ( i to zawsze zjada około 0,01 czasu na słabej maszynie a timer device odlicza co 0,02). WaitBOVP rozwiązuje problem, przynajmniej wygląda to znacznie lepiej niż wcześniej.
Pozdrawiam
17.03.2012 23:46
[#55]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@asman, post #54
Co do Twojego poprzedniego posta:
Mnie nie chodziło o ekran z SuperBitMap, ale okno z SuperBitMap. Wtedy można naturalnie skrolować zawartość okna za pomocą funkcji ScrollLayer() !!! Kilka razy Ci o tym opowiadałem, jeśli nie wiesz jak to robić podeślę Ci działający przykład. Co do QBSBlit to radzę w tej chwili nie używać go, bo wtedy gra traci kompatybilność z kartami graficznymi na przykład.
Spróbuj metody z ScrollLayer() najpierw według mnie.
Mnie nie chodziło o ekran z SuperBitMap, ale okno z SuperBitMap. Wtedy można naturalnie skrolować zawartość okna za pomocą funkcji ScrollLayer() !!! Kilka razy Ci o tym opowiadałem, jeśli nie wiesz jak to robić podeślę Ci działający przykład. Co do QBSBlit to radzę w tej chwili nie używać go, bo wtedy gra traci kompatybilność z kartami graficznymi na przykład.
Spróbuj metody z ScrollLayer() najpierw według mnie.