20.07.2010 16:23
[#1]
Gra pod OS - pytania, wątpliwości, rozwiązania
Witam
Pierwsze pytanie jakie mnie nachodzi od pewnego czasu to:
1. Jak powinna wyglądać główna pętla w grze ( gra jest OS firendly ) ?
Powinna czekać tylko na zdarzenia od klawiatury/myszy/joysticka i timerrequesta i przez pozostały czas spać w Wait ?
Pozdrawiam
Pierwsze pytanie jakie mnie nachodzi od pewnego czasu to:
1. Jak powinna wyglądać główna pętla w grze ( gra jest OS firendly ) ?
Powinna czekać tylko na zdarzenia od klawiatury/myszy/joysticka i timerrequesta i przez pozostały czas spać w Wait ?
Pozdrawiam
20.07.2010 17:22
[#2]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@asman, post #1
Dokładnie tak, a co miałaby robić? Bezcelowo obciążać procesor? Oczywiście to przy założeniu, że timer wyznacza odświeżanie sytuacji w grze. Można też przyjąć SDL-ową strategię odświeżania tak często, jak procesor pozwoli. To jednak daje taki efekt, że na czym bym takiej gry nie odpalił, zawsze wżera 100% mocy procesora. Taka gra dla mnie nie do końca pasuje do miana "system friendly".
Ostatnia modyfikacja: 20.07.2010 17:28:21
Ostatnia modyfikacja: 20.07.2010 17:28:21
21.07.2010 11:24
[#3]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@G. Kraszewski, post #2
Tak dokładnie robię. Czyli moja głowna pętla gry wygląda tak:
Następne pytanie to czym najlepiej sprawdzić ile czasu procka zżera moja gra. ( na os 3.0+ )
while( !end )
{
ULONG signals = Wait( win_signal | timer_signal )
if( signals & win_signal )
{
// zbieram klawisze i close window
}
if( signals & timer_signal )
{
//odbieram mesgi z timer porta
//wywołuje funkcję za pomocą wskaźnika (*g_loop_function)();
//ustawiam timer i SendIO
}
}Następne pytanie to czym najlepiej sprawdzić ile czasu procka zżera moja gra. ( na os 3.0+ )
21.07.2010 11:43
[#4]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@asman, post #3
Jeżeli to są szachy i czekają na ruch gracza to oczywiście powinna czekać. No ale jeżeli to jest dynamiczna gra w której pomimo tego, że gracz nie dotyka klawiatury/myszy, wszystko na ekranie się zmienia (pada deszcz, ruszają się drzewa, jeżdżą jakieś pojazdy, coś się dymi, gdzieś tam w tle jakieś stworzenia podejmują jakieś decyzje, szukają drogi, zmienia się temperatura, całe otoczenie odbija się w falującej wodzie) no to takie czekanie zatrzyma całą akcję. Wszystkie dynamiczne gry zjadają max procesora i najczęściej nawet tego jest za mało. :) W takich grach jedyne co można byłoby to tyle, żeby to czekanie (zwolnienie procesora) zrobić gdy okno/ekran są nieaktywne. Wtedy zawartość okna niekoniecznie musi być odświeżana albo niech będzie odświeżana tylko na jakieś zdarzenia typu klik myszą, aktywacja okna.
Programów do badania zajętości procka jest cała masa. Ja ich za bardzo nigdy nie szukałem, bo lata temu jak jeszcze używałem OS3 to miałem taki procent po prostu na belce WB/Opus za sprawą jednej z opcji MCP. Jak nie chcesz mieć tej informacji cały czas przed oczami to rzuć okiem do Scouta - tam widać ile procent procka zjada każdy z odpalonych tasków.
Ostatnia modyfikacja: 21.07.2010 11:45:04
Programów do badania zajętości procka jest cała masa. Ja ich za bardzo nigdy nie szukałem, bo lata temu jak jeszcze używałem OS3 to miałem taki procent po prostu na belce WB/Opus za sprawą jednej z opcji MCP. Jak nie chcesz mieć tej informacji cały czas przed oczami to rzuć okiem do Scouta - tam widać ile procent procka zjada każdy z odpalonych tasków.
Ostatnia modyfikacja: 21.07.2010 11:45:04
21.07.2010 12:19
[#5]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@MDW, post #4
no to takie czekanie zatrzyma całą akcję.
Nie zatrzyma. Po to oprócz sygnałów z myszy/klawiatury masz sygnały z timera. Jeżeli user nic nie robi, to gra i tak odświeża okno w tempie wynikającym z sygnałów timera.
Teraz zakładasz sobie tempo odświeżania. Niech to będzie przykładowo 20 fps. Wtedy ustawiasz timer co 50 milisekund. Po każdym sygnale timera wykonujesz krok akcji gry. Jak poruszysz wszystkimi samochodami, dymami, żołnierzami i resztą, wracasz do Wait(). Dięki temu gra odpalona np. na Efice zassie dajmy na to 80% CPU, odpalona na Mini zassie 15%. Gry SDL-owe tak nie robią, po prostu puszczają pętlę gry najszybciej jak się da na danym sprzęcie. To jest dobre w przypadku gier, które w pełni angażują gracza i gra się w nie zwykle na pełnym ekranie. Jednak w przypadku gierki, w którą sobie pykam w oknie na WB w oczekiwaniu na skompilowanie się czegoś, wolę jeżeli nie usiłuje ona notorycznie zagrabić sobie całej mocy procesora tylko po to, żeby z spalonych czołgów dymiło się w 120 fps...
Nie zatrzyma. Po to oprócz sygnałów z myszy/klawiatury masz sygnały z timera. Jeżeli user nic nie robi, to gra i tak odświeża okno w tempie wynikającym z sygnałów timera.
Teraz zakładasz sobie tempo odświeżania. Niech to będzie przykładowo 20 fps. Wtedy ustawiasz timer co 50 milisekund. Po każdym sygnale timera wykonujesz krok akcji gry. Jak poruszysz wszystkimi samochodami, dymami, żołnierzami i resztą, wracasz do Wait(). Dięki temu gra odpalona np. na Efice zassie dajmy na to 80% CPU, odpalona na Mini zassie 15%. Gry SDL-owe tak nie robią, po prostu puszczają pętlę gry najszybciej jak się da na danym sprzęcie. To jest dobre w przypadku gier, które w pełni angażują gracza i gra się w nie zwykle na pełnym ekranie. Jednak w przypadku gierki, w którą sobie pykam w oknie na WB w oczekiwaniu na skompilowanie się czegoś, wolę jeżeli nie usiłuje ona notorycznie zagrabić sobie całej mocy procesora tylko po to, żeby z spalonych czołgów dymiło się w 120 fps...
21.07.2010 13:34
[#7]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@G. Kraszewski, post #5
Oczywiście można i tak zrobić. W przypadku gdy w jednym przebiegu (np. 1/50 sekundy) zostało wszystko zrobione i jeszcze trochę zostało czasu to rzeczywiście lepiej wtedy oddać czas procesora. :) Chociaż w praktyce to i tak najczęściej większość gier zje 100% procka. No ale to prawda, że tak jak mówisz jest bardziej elegancko i gra będzie przygotowana na naprawdę dużo szybsze maszyny, które w przyszłości na pewno się pojawią. Czyli oczywiście masz 100% racji, a ja chciałem tylko zwrócić uwagę na to, że w grach często coś tam w tle się dzieje i tak zupełnie aplikacja czekać tylko na reakcję gracza nie może. Jakiś tam wątek jednak musi co pewien czas coś zrobić nawet jak gracz poszedł do WC. :)
Ostatnia modyfikacja: 21.07.2010 13:47:50
Ostatnia modyfikacja: 21.07.2010 13:47:50
21.07.2010 17:15
[#8]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@asman, post #3
Petla, jak petla. W teorii powinna byc ok.
Jezeli chodzi o goly klasyk to raczej ciezko, tam jest prosty scheduler.
Najlepszym wyjsciem jest zainstalowanie executive. Na 99% bedzie mozliwosc podgladu zuzycia cpu. Mozesz takze poprobowac monitory systemowe typu xopa, moze beda mialy jakies pacze;)
Jezeli chodzi o goly klasyk to raczej ciezko, tam jest prosty scheduler.
Najlepszym wyjsciem jest zainstalowanie executive. Na 99% bedzie mozliwosc podgladu zuzycia cpu. Mozesz takze poprobowac monitory systemowe typu xopa, moze beda mialy jakies pacze;)
21.07.2010 17:55
[#11]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@MDW, post #7
W przypadku gdy w jednym przebiegu (np. 1/50 sekundy) zostało wszystko zrobione i jeszcze trochę zostało czasu to rzeczywiście lepiej wtedy oddać czas procesora.
Jeżeli czasu procesora nie starczy no to oczywiście cudów nie ma, obciążamy procesor do końca. Można co najwyżej frameskipa zrobić, jeżeli da się to zaimplementować w engine gry. Coś podobnego zrobiłem w DigiBoosterze 3. Jeżeli GUI nie nadąża z przewijaniem patternu, zaczyna się przewijać co dwie, trzy pozycje i scroll jest szarpany. Ale muzyka nadal gra płynnie, oczywiście jeżeli mocy CPU wystarcza na samą przynajmniej muzykę.
Jeżeli czasu procesora nie starczy no to oczywiście cudów nie ma, obciążamy procesor do końca. Można co najwyżej frameskipa zrobić, jeżeli da się to zaimplementować w engine gry. Coś podobnego zrobiłem w DigiBoosterze 3. Jeżeli GUI nie nadąża z przewijaniem patternu, zaczyna się przewijać co dwie, trzy pozycje i scroll jest szarpany. Ale muzyka nadal gra płynnie, oczywiście jeżeli mocy CPU wystarcza na samą przynajmniej muzykę.
22.07.2010 09:38
[#12]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@G. Kraszewski, post #11
Jeżeli czasu procesora nie starczy no to oczywiście cudów nie ma, obciążamy procesor do końca. Można co najwyżej frameskipa zrobić, jeżeli da się to zaimplementować w engine gry.
Jak i kiedy ( którym momencie ) można się dowiedzieć, że czasu procesora nie starczy ?
Jak i kiedy ( którym momencie ) można się dowiedzieć, że czasu procesora nie starczy ?
22.07.2010 10:56
[#13]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@asman, post #12
Ja bym to zrobił tak, że puszczam do timera np. 10 requestów od razu, oczywiście rozstawionych np. co te 50 ms. I teraz jak dostanę sygnał z portu odbierającego requesty, sprawdzam ile przyszło. Jeżeli więcej niż 1, to wiem, że poprzednia zmiana stanu gry trwała za długo i procesor nie zdążył. Wtedy na przykład robię tak, że dla wszystkich zwróconych requestów oprócz ostatniego puszczam pętlę gry bez renderingu (czyli tylko np. wyliczanie nowych pozycji obiektów, sprawdzenie kolizji, ale nic nie rysuję). W ten sposób osiągam frameskip dynamicznie dostosowujący się do dostępnej mocy procesora. Oczywiście każdy odebrany request wysyłam ponownie do timera po dodaniu odpowiedniego czasu (np. 10 requestów chodzi w pętli co 50 ms, po odebraniu requesta dodaję do niego 500 ms i wysyłam powtórnie).
Ten sposób nie zadziała tylko w dwóch przypadkach:
1. Procesor jest za wolny nawet do przeliczania stanu gry bez rysowania. To jednak oznacza po prostu, że maszyna jest zwyczajnie za słaba dla danej gry.
2. Rysowanie gry zajmuje znacznie mniej czasu procesora niż przeliczanie "logiki". Badzo rzadki przypadek, ale np. przy wspomnianych przez MDW szachach może się zdarzyć. Może też wystąpić w grach z bardzo rozbudowanymi algorytymami AI graczy sterowanych przez komputer. Jednak takie gry z reguły nie są grami czasu rzeczywistego i nie stosujemy wtedy technik z timerowaniem, tylko przerzucamy AI na osobny proces, żeby GUI nie umierało, w czasie gdy komputer oblicza ruch.
Ostatnia modyfikacja: 22.07.2010 11:00:54
Ten sposób nie zadziała tylko w dwóch przypadkach:
1. Procesor jest za wolny nawet do przeliczania stanu gry bez rysowania. To jednak oznacza po prostu, że maszyna jest zwyczajnie za słaba dla danej gry.
2. Rysowanie gry zajmuje znacznie mniej czasu procesora niż przeliczanie "logiki". Badzo rzadki przypadek, ale np. przy wspomnianych przez MDW szachach może się zdarzyć. Może też wystąpić w grach z bardzo rozbudowanymi algorytymami AI graczy sterowanych przez komputer. Jednak takie gry z reguły nie są grami czasu rzeczywistego i nie stosujemy wtedy technik z timerowaniem, tylko przerzucamy AI na osobny proces, żeby GUI nie umierało, w czasie gdy komputer oblicza ruch.
Ostatnia modyfikacja: 22.07.2010 11:00:54
22.07.2010 11:26
[#14]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@asman, post #12
Zazwyczaj robi się to tak (tak ja to zawsze robiłem), że każdy element zależny od prędkości sprzętu uzależniam od czasu. Czyli jak w takiej typowej grze nacisnę np. klawisz "idź" to nie przesuwam ludka o np. 10 pixeli, tylko o jakąś wartość będącą prędkością i mnożę ją przez czas jaki minął od ostatniego przesuwania (różnica czasu między aktualnym czasem, a czasem ostatniego przesuwania). W ten sposób ludek w ciągu np. 5 sekund przesunie się o dokładnie taką samą odległość zarówno na strasznie wolnym jak i na niesamowicie szybkim sprzęcie.
22.07.2010 11:43
[#15]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@MDW, post #14
Gdy masz pętlę sterowaną timerem, wyjdzie Ci to samo, mimo że w algorytmie gry będziesz miał zawsze 5 pikseli. Na sprzęcie przeciętnym będzie się odrysowywał np. 20 razy na sekundę co 5 pikseli. Na sprzęcie wolnym na skutek frameskipa odrysuje się np. 5 razy na sekundę co 20 pikseli. Na sprzęcie szybkim odrysuje się (w zależności od skoku timera) np. 50 razy na sekundę co 2 piksele. A na sprzęcie rakietowym dzięki górnemu limitowi szybkości pętli, wynikającemu z odstępu czasowego między requestami, też będzie 50 fps (zamiast 120 nie wiadomo po co), ale gra będzie zużywała tylko 30% CPU...
22.07.2010 15:04
[#18]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@asman, post #17
Trochę się rozpędziłem z pisaniem... Oczywiście jeżeli w procedurze obliczającej nowe położenia obiektów przyjmiemy skok równy 5 pikselom, to obiekt będzie się przesuwał co 5 pikseli, jeżeli przeskakiwanie ramek nie nastąpi, lub co całkowitą wielokrotność 5 pikseli, jeżeli ramki zostaną przeskoczone. Przykładowo załóżmy że chcemy odświeżać grę 20 razy na sekundę, ale na danej maszynie przeliczenie i odrysowanie gry trwa 72 ms, z czego 12 ms to przeliczenie a 60 ms - rysowanie. Wtedy odbywać się to będzie następująco:
0,000 s, położenie obiektu w grze 0, na ekranie 0, zaczynamy przeliczać i rysować.
0,050 s, timer zwraca nam pierwszy request, ale program jeszcze rysuje
0,072 s, skończyliśmy rysować. Odbieramy request i ruszamy od razu z następną klatką (przeliczanie + rysowanie). Obiekt w grze i na ekranie ma położenie 5.
0,100 s, kolejny request, program wciąż rysuje.
0,144 s, program narysował drugą klatkę. Odbieramy drugi request i natychmiast bierzemy się za trzecią (pozycja obiektu w grze i na ekranie = 10).
0,150 s, przychodzi trzeci request, program rysuje.
0,200 s, przychodzi czwarty request, program wciąż rysuje.
0,216 s, trzecia klatka narysowana, w porcie mamy dwa requesty. Dlatego klatkę 4 tylko przeliczamy (pocyzja obiektu w grze = 15, na ekranie 10).
0,228 s, przeliczona 4 klatka, od razu przechodzimy do klatki 5, ponieważ jest tylko jeden request, lecimy z przeliczaniem i rysowaniem. W grze obiekt przesuwa się o kolejne 5 pikseli, ale na ekranie skacze o 10 (klatka 4 padła ofiarą frameskipa).
0,250 s, kolejny request.
0,288 s, klatka 5 narysowana. Odbieramy jedyny request z portu i lecimy przeliczać i rysować klatkę 6. Tym razem bez opuszczenia ramki, więc obiekt zarówno w grze jak i na ekranie przesunie się o 5 pikseli.
0,300 s, request.
0,350 s, request.
0,360 s, klatka 6 narysowana. Mamy 2 requesty, więc klatkę 7 tylko przeliczamy, padnie ona znów ofiarą frameskipa.
0,372 s, klatka 7 przeliczona, jeden request w kolejce, natychmiast klatka 8 do przeliczenia i narysowania.
0,400 s, request.
I tak dalej. Algorytm zapewnia równomierne rozłożenie opuszczonych klatek w czasie. Jeżeli dostępna moc procesora będzie się zmniejszać, traconych klatek będzie coraz więcej (ale wciąż równomiernie, więc ruch będzie możliwie najmniej szarpany), aż do przypadku granicznego, gdy samo przeliczanie zajęłoby 50 ms, wtedy wszystkie klatki będą tylko przeliczane a na ekranie gra "stanie w miejscu". Jeżeli pójdziemy w drugą stronę z mocą procesora, zużycie będzie wynosiło 100% ze zmniejszającym się frameskipem aż do momentu, gdy czas przeliczania + rysowania spadnie poniżej 50 ms. Od tego momentu przy nadal zwiększającej się wydajności systemu gra będzie szła ze stałą prędkością 20 fps, a obciążenie CPU będzie malało (oczywiście 20 fps jest przykładowe, można dać więcej, zmieniając odstęp czasowy między requestami).
0,000 s, położenie obiektu w grze 0, na ekranie 0, zaczynamy przeliczać i rysować.
0,050 s, timer zwraca nam pierwszy request, ale program jeszcze rysuje
0,072 s, skończyliśmy rysować. Odbieramy request i ruszamy od razu z następną klatką (przeliczanie + rysowanie). Obiekt w grze i na ekranie ma położenie 5.
0,100 s, kolejny request, program wciąż rysuje.
0,144 s, program narysował drugą klatkę. Odbieramy drugi request i natychmiast bierzemy się za trzecią (pozycja obiektu w grze i na ekranie = 10).
0,150 s, przychodzi trzeci request, program rysuje.
0,200 s, przychodzi czwarty request, program wciąż rysuje.
0,216 s, trzecia klatka narysowana, w porcie mamy dwa requesty. Dlatego klatkę 4 tylko przeliczamy (pocyzja obiektu w grze = 15, na ekranie 10).
0,228 s, przeliczona 4 klatka, od razu przechodzimy do klatki 5, ponieważ jest tylko jeden request, lecimy z przeliczaniem i rysowaniem. W grze obiekt przesuwa się o kolejne 5 pikseli, ale na ekranie skacze o 10 (klatka 4 padła ofiarą frameskipa).
0,250 s, kolejny request.
0,288 s, klatka 5 narysowana. Odbieramy jedyny request z portu i lecimy przeliczać i rysować klatkę 6. Tym razem bez opuszczenia ramki, więc obiekt zarówno w grze jak i na ekranie przesunie się o 5 pikseli.
0,300 s, request.
0,350 s, request.
0,360 s, klatka 6 narysowana. Mamy 2 requesty, więc klatkę 7 tylko przeliczamy, padnie ona znów ofiarą frameskipa.
0,372 s, klatka 7 przeliczona, jeden request w kolejce, natychmiast klatka 8 do przeliczenia i narysowania.
0,400 s, request.
I tak dalej. Algorytm zapewnia równomierne rozłożenie opuszczonych klatek w czasie. Jeżeli dostępna moc procesora będzie się zmniejszać, traconych klatek będzie coraz więcej (ale wciąż równomiernie, więc ruch będzie możliwie najmniej szarpany), aż do przypadku granicznego, gdy samo przeliczanie zajęłoby 50 ms, wtedy wszystkie klatki będą tylko przeliczane a na ekranie gra "stanie w miejscu". Jeżeli pójdziemy w drugą stronę z mocą procesora, zużycie będzie wynosiło 100% ze zmniejszającym się frameskipem aż do momentu, gdy czas przeliczania + rysowania spadnie poniżej 50 ms. Od tego momentu przy nadal zwiększającej się wydajności systemu gra będzie szła ze stałą prędkością 20 fps, a obciążenie CPU będzie malało (oczywiście 20 fps jest przykładowe, można dać więcej, zmieniając odstęp czasowy między requestami).
02.04.2011 21:42
[#19]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@asman, post #1
Witam,
Kolejne pytanie ( bądź pytania ). Gra w okienku WB. Czyli normalnie sobie otwieram okno i do niego kopiuje z oddzielnej bitmapy grafikę. I tak się zastanawiam czy jeśli grafikę mam 2-kolorową to czy powinienem tą oddzielną bitmapę zaalokować z depth = 2 ? Tylko problem polega na tym, że ja chcę by ta grafika 2-kolorowa miała określone kolory ( bądź zbliżone ). I jak narazię to widzę to tak, że muszę pobrać depth z WB i zaalokować takiej głębokości bitmapy, cobym miał szanse na dobre kolory.
Druga sprawa też jest związana z tą grafiką. Dane do grafiki trzymam jako chunky aby skopiować ją za pomocą WritePixelArray8. W tym przypadku ( 2 kolorów) są to zera bądź jedynki.
Jeśli już udało mi się uzyskać pędzle za pomocą ObtainBestPenA, to zwyczajnie robię najpierw proste remapowania grafiki ( tablicy która zawiera dane chunky ) i grafika ma kolorki jak trzeba. I tu widzę problemik, bo czy może się zdarzyć że ObtainBestPenA zwróci mi pędzęl poza 255 ? wtedy będę miał problem z remapowaniem, gdyż WritePixelArray8 oczekuje tablicy UBYTE.
Pozdrawiam
Kolejne pytanie ( bądź pytania ). Gra w okienku WB. Czyli normalnie sobie otwieram okno i do niego kopiuje z oddzielnej bitmapy grafikę. I tak się zastanawiam czy jeśli grafikę mam 2-kolorową to czy powinienem tą oddzielną bitmapę zaalokować z depth = 2 ? Tylko problem polega na tym, że ja chcę by ta grafika 2-kolorowa miała określone kolory ( bądź zbliżone ). I jak narazię to widzę to tak, że muszę pobrać depth z WB i zaalokować takiej głębokości bitmapy, cobym miał szanse na dobre kolory.
Druga sprawa też jest związana z tą grafiką. Dane do grafiki trzymam jako chunky aby skopiować ją za pomocą WritePixelArray8. W tym przypadku ( 2 kolorów) są to zera bądź jedynki.
Jeśli już udało mi się uzyskać pędzle za pomocą ObtainBestPenA, to zwyczajnie robię najpierw proste remapowania grafiki ( tablicy która zawiera dane chunky ) i grafika ma kolorki jak trzeba. I tu widzę problemik, bo czy może się zdarzyć że ObtainBestPenA zwróci mi pędzęl poza 255 ? wtedy będę miał problem z remapowaniem, gdyż WritePixelArray8 oczekuje tablicy UBYTE.
Pozdrawiam
02.04.2011 23:38
[#22]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@kiero, post #21
Znaczy to, że moje podejście z kolorami za pomocą penów ma ograniczenie, bo mogę nie uzyskać koloru takiego jak chcę. W takim razie może trzeba w jakiś inny specjalny sposób wgrać grafikę - tylko jeszcze nie wiem jak. Do głowy tak na szybko przychodzi mi iffparse.library bądź datatypy.
03.04.2011 13:49
[#23]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@asman, post #22
na ekranach z paleta kolorow zawsze jest szansa, ze nie uzyskasz koloru jaki bys chcial. jezeli sa jakies wolne kolory (na ekranach do 32 kolorow mozna praktycznie o tym zapomniec) to wystarczy przydzielic sobie taki i wtedy mozna go dowolnie zmienic.
w innym przypadku system wyszuka najblizszy dostepny kolor.
w innym przypadku system wyszuka najblizszy dostepny kolor.
03.04.2011 20:22
[#26]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@asman, post #22
Znaczy to, że moje podejście z kolorami za pomocą penów ma ograniczenie, bo mogę nie uzyskać koloru takiego jak chcę. W takim razie może trzeba w jakiś inny specjalny sposób wgrać grafikę - tylko jeszcze nie wiem jak. Do głowy tak na szybko przychodzi mi iffparse.library bądź datatypy.
Datatypy pod Amiga Os 3.x nie obsługują więcej niż 8 bit na pixel.
Jak chcesz więcej to musisz sam załatwić sprawę wczytywania danych graficznych.
Tu polecam .bmp, format jest prymitywny, wczytywanie bardzo łatwe, prawie wszystko ma zapis/odczyt niepakowanego .bmp.
Do zabawy z grafiką zdecydowanie polecam - kupić amigową kartę graficzną lub mediatora plus Radeon.
Zaznaczyć że soft działa tylko na trybach co najmniej 24 bit, wtedy można całkiem fajnie bawić się w rysowanie po pamięci i tylko przerzucanie za pomocą funkcji CGX,P96 danych na ekran (WritePixelArrayA/p96WritePixelArray).
Niebo a ziemia w porównaniu z męczeniem się z AGA.
03.04.2011 20:44
[#27]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@Panter, post #26
"Datatypy pod Amiga Os 3.x nie obsługują więcej niż 8 bit na pixel."
oczywiscie, ze obsluguja. wystarczy miec odpowiednio nowsza wersje picture.datatype
"Zaznaczyć że soft działa tylko na trybach co najmniej 24 bit, wtedy można całkiem fajnie bawić się w rysowanie po pamięci i tylko przerzucanie za pomocą funkcji CGX,P96 danych na ekran (WritePixelArrayA/p96WritePixelArray).
Niebo a ziemia w porównaniu z męczeniem się z AGA."
ta, niebo i ziemia o ile czlowiek godzi sie na srednia wydajnosc. rysowanie wszystkiego procesorem i potem jeszcze przewalanie tego do pamieci karty (do tego w 16/24/32bit) to sredni pomysl na 68k.
oczywiscie, ze obsluguja. wystarczy miec odpowiednio nowsza wersje picture.datatype
"Zaznaczyć że soft działa tylko na trybach co najmniej 24 bit, wtedy można całkiem fajnie bawić się w rysowanie po pamięci i tylko przerzucanie za pomocą funkcji CGX,P96 danych na ekran (WritePixelArrayA/p96WritePixelArray).
Niebo a ziemia w porównaniu z męczeniem się z AGA."
ta, niebo i ziemia o ile czlowiek godzi sie na srednia wydajnosc. rysowanie wszystkiego procesorem i potem jeszcze przewalanie tego do pamieci karty (do tego w 16/24/32bit) to sredni pomysl na 68k.
03.04.2011 21:04
[#28]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@kiero, post #27
oczywiscie, ze obsluguja. wystarczy miec odpowiednio nowsza wersje picture.datatype
Rzeczywiście.
Trzeba mieć picture.datatype z Amiga OS 3.9 od Amiga Inc i wtedy faktycznie jest obsługa 24 bit.
To już nie będzie ten "rasowo czysty" Amiga OS z Commodore, ale faktycznie da się.
ta, niebo i ziemia o ile czlowiek godzi sie na srednia wydajnosc. rysowanie wszystkiego procesorem i potem jeszcze przewalanie tego do pamieci karty (do tego w 16/24/32bit) to sredni pomysl na 68k.
No to pech.
Jednak trzeba dokupić jeszcze to ppc.
04.04.2011 01:22
[#29]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@asman, post #25
chodzilo mi o ten moment
przeliczanie klatki i nie rysowanie, to jednak jakies marnotrastwo. uzycie zegara "nic nie kosztuje" - tzn. zegar jest sprzetowy.., a kazdy ruch odbywa sie w czasie, wystarczy wiec sprawdzic czy rysowanie zakonczono (oczywiscie nie w "glupiej" petli katujac cpu milionami tych samych instrukcji.., tylko co jakis ustalony czas, nazwany powiedzmy, czasem reakcji.., po czym zaczac kolejne operacje tj. zdarzenia,przeliczanie.. i uruchomic kolejne rysowanie, jezeli konieczne.., a korzystajac z zegara odmierzyc roznice czasu jaka minela od ostatniego przeliczania... a tzw. frameskip powstanie sam, w zaleznosci od wydajnosci cpu.. Gorny limit odswiezania jest tez wskazany np: 60fps, nie ma sensu katowac 300fps, bo tego nikt nie dojrzy, czlowiek widzi ok. 25-30 fps, tylko w szczegolnych sytuacjach mozg potrafi wskoczyc na wyzsze obroty np: strach, nagle zagrozenie zyciu itp., ale wtedy nie widzimy np: w kolorach..., ciekawe, prawda :).
---
Co do kolorow, to proponuje uwzglednic mozliwosc otwarcia takze osobnego ekranu. Zrobilbym tak. Wyswietlil najpierw okienko z mozliwoscia wyboru, ekran czy okienko, sprawdzajac w obu przypadkach taka mozliwosc, jak nie ma, wyswietlil wskazowke, blad etc. Idac dalej, w przypadku okienka wb to chyba najlepiej sprawdzic ile tych kolorow jest, jak wystarczajaco, dalej, sprawdzic ile mozna uzyc (chodzi oczywiscie o tryby bitplanes i ew. chunky 15/16bit (prekalulowany dithering, jak sie "oplaca"), bo w chunky 24/32bit to zawsze starczy), jak wystarczajaco, dalej. I co dalej w przypadku bitplanes. To chyba juz zalezy jaka grafike gra preferuje. Mozna pokusic sie o dodatkowe prekalkulowanie uzywajac "prostych" i szybkich alg. redukcji kolorow (dithering), gdyby mialo to sens, ale to zalezy od tejze grafiki itd.., choc zawsze pozostaja tryby monochromatyczne, wtedy min. to powiedzmy 16 kolorow, a dok. odcieni, niekoniecznie szarosci... :). Ogolnie temat dosc rozlegly i wart przemyslenia zanim sie cokolwiek zacznie robic...
Ostatnia modyfikacja: 04.04.2011 01:28:02
0,216 s, trzecia klatka narysowana, w porcie mamy dwa requesty. Dlatego klatkę 4 tylko przeliczamy (pocyzja obiektu w grze = 15, na ekranie 10).
0,228 s, przeliczona 4 klatka, od razu przechodzimy do klatki 5, ponieważ jest tylko jeden request, lecimy z przeliczaniem i rysowaniem. W grze obiekt przesuwa się o kolejne 5 pikseli, ale na ekranie skacze o 10 (klatka 4 padła ofiarą frameskipa).
przeliczanie klatki i nie rysowanie, to jednak jakies marnotrastwo. uzycie zegara "nic nie kosztuje" - tzn. zegar jest sprzetowy.., a kazdy ruch odbywa sie w czasie, wystarczy wiec sprawdzic czy rysowanie zakonczono (oczywiscie nie w "glupiej" petli katujac cpu milionami tych samych instrukcji.., tylko co jakis ustalony czas, nazwany powiedzmy, czasem reakcji.., po czym zaczac kolejne operacje tj. zdarzenia,przeliczanie.. i uruchomic kolejne rysowanie, jezeli konieczne.., a korzystajac z zegara odmierzyc roznice czasu jaka minela od ostatniego przeliczania... a tzw. frameskip powstanie sam, w zaleznosci od wydajnosci cpu.. Gorny limit odswiezania jest tez wskazany np: 60fps, nie ma sensu katowac 300fps, bo tego nikt nie dojrzy, czlowiek widzi ok. 25-30 fps, tylko w szczegolnych sytuacjach mozg potrafi wskoczyc na wyzsze obroty np: strach, nagle zagrozenie zyciu itp., ale wtedy nie widzimy np: w kolorach..., ciekawe, prawda :).
---
Co do kolorow, to proponuje uwzglednic mozliwosc otwarcia takze osobnego ekranu. Zrobilbym tak. Wyswietlil najpierw okienko z mozliwoscia wyboru, ekran czy okienko, sprawdzajac w obu przypadkach taka mozliwosc, jak nie ma, wyswietlil wskazowke, blad etc. Idac dalej, w przypadku okienka wb to chyba najlepiej sprawdzic ile tych kolorow jest, jak wystarczajaco, dalej, sprawdzic ile mozna uzyc (chodzi oczywiscie o tryby bitplanes i ew. chunky 15/16bit (prekalulowany dithering, jak sie "oplaca"), bo w chunky 24/32bit to zawsze starczy), jak wystarczajaco, dalej. I co dalej w przypadku bitplanes. To chyba juz zalezy jaka grafike gra preferuje. Mozna pokusic sie o dodatkowe prekalkulowanie uzywajac "prostych" i szybkich alg. redukcji kolorow (dithering), gdyby mialo to sens, ale to zalezy od tejze grafiki itd.., choc zawsze pozostaja tryby monochromatyczne, wtedy min. to powiedzmy 16 kolorow, a dok. odcieni, niekoniecznie szarosci... :). Ogolnie temat dosc rozlegly i wart przemyslenia zanim sie cokolwiek zacznie robic...
Ostatnia modyfikacja: 04.04.2011 01:28:02
04.04.2011 07:51
[#30]
Re: Gra pod OS - pytania, wątpliwości, rozwiązania
@1989, post #29
przeliczanie klatki i nie rysowanie, to jednak jakies marnotrastwo. uzycie zegara "nic nie kosztuje" - tzn. zegar jest sprzetowy.., a kazdy ruch odbywa sie w czasie, wystarczy wiec sprawdzic czy rysowanie zakonczono (oczywiscie nie w "glupiej" petli katujac cpu milionami tych samych instrukcji.., tylko co jakis ustalony czas, nazwany powiedzmy, czasem reakcji.., po czym zaczac kolejne operacje tj. zdarzenia,przeliczanie.. i uruchomic kolejne rysowanie, jezeli konieczne.., a korzystajac z zegara odmierzyc roznice czasu jaka minela od ostatniego przeliczania...
Napisałeś tak grę kiedyś?
Napisałeś tak grę kiedyś?