03.07.2024 13:48
[#31]
Re: Ami Robbo 2
@tukinem, post #29
No tak, założeniem GnuRobbo było chyba tylko odtworzenie oryginału i danie możliwości podmiany grafik i tworzenia leveli na dzisiejszych komputerach. A tutaj nie będziesz musiał się trzymać narzuconych zasad (gdy już wszystko będzie działało) i będzie można puścić wodze fantazji. To jest "dwójka" więc można szaleć. 
03.07.2024 15:51
[#32]
Re: Ami Robbo 2
@MDW, post #31
Myślę, że samo dodanie widoku "top down" już jest jakąś nowością i urozmaiceniem.
Rozlewająca się woda po mapie może być bardzo uciążliwa bo trzeba się będzie spieszyć, żeby nas nie "zalała" lub nam nie zablokowała drogi przejścia.
Czasu zostało 5 miesięcy więc trzeba się trochę pospieszyć nad wymyślaniem nowych obiektów, bo później trzeba stworzyć fabułę, grafiki, poziomy i to wszystko połączyć.
Rozlewająca się woda po mapie może być bardzo uciążliwa bo trzeba się będzie spieszyć, żeby nas nie "zalała" lub nam nie zablokowała drogi przejścia.
Czasu zostało 5 miesięcy więc trzeba się trochę pospieszyć nad wymyślaniem nowych obiektów, bo później trzeba stworzyć fabułę, grafiki, poziomy i to wszystko połączyć.
03.07.2024 16:01
[#33]
Re: Ami Robbo 2
@tukinem, post #29
Ja służę pomocą w razie czego - co do algorytmów Robbo jak i grafiki. Kiedyś opracowałem klon Robbo z zaledwie kilkoma elementami. Ale odwzorowałem te elementy dosyć wiernie.
Przygotowałem sporo grafiki do Robbo, ale to było przed 2016 rokiem i się nie zapamiętały.
Przyznam, że od pewnego czasu nosiłem się z zamiarem przygotowania trójki gier z automatem komórkowym.
W kwietniu br. przygotowałem troszkę grafiki do klonu Boulder Dasha. link
Jeśli nie masz nic naprzeciwko chciałem kontynuować prace nad swoim Robbo w zestawie gier komórkowych. Zawsze chciałem zaimplementować więcej oryginalnych elementów niż w mojej starszej wersji (choć grafiki do tych elementów jeszcze nie mam).
Co do Magnesu, to chodziło mi o to, że powinien być on zawsze widoczny dla gracza. Jeżeli dodasz scroll poziomy, nie zawsze musi tak być.
Co do fabuły, to ona w Robbo dla Atari jest wyświetlana w formie tekstu po załadowaniu gry. (Widzę, że kolega Jacques już o tym wspomniał).
Oczywiście trzymam kciuki za Twój projekt. Ciekaw jestem elementów i chętnie zagram.
P.S. Poniżej zamieściłem pierwotną grafikę do mojego Robbo, a jeszcze niżej moje bieżące rezultaty w malowaniu:
Ogólnie chciałem zrobić płynnie poruszające się elementy i nawet częściowo to zakodowałem - ale wciąż zastanawiam się czy to dobry pomysł i czy nie jest to za duże utrudnienie dla programisty. W grze w sumie jest kilka wydarzeń na komórce, które mogą powodować inny efekt animacyjny:
- Pojawia się zupełnie nowy obiekt (np. pocisk),
- Obiekt jest animowany (np. eksplozja),
- Obiekt przechodzi z pola na pole (np. bohater, skrzynia, pocisk),
- Obiekt jest zastępowany innym (np. pocisk w mały wybuch),
- Obiekt "rozciąga się" lub klonuje (laser).
Ponadto w płynnym ruchu zauważyłem, że lepiej jest jak obiekt przechodzący z pola na pole na czas ruchu okupuje oba te pola blokując inne obiekty.
Sprawdziłem teraz i Wayback Machine zapamiętał kod źródłowy mojego klonu Robbo w pliku RobboSrc.lha z mojej starej strony na ONecie.
Ostatnia aktualizacja: 03.07.2024 16:12:31 przez Hexmage960
Przygotowałem sporo grafiki do Robbo, ale to było przed 2016 rokiem i się nie zapamiętały.
Przyznam, że od pewnego czasu nosiłem się z zamiarem przygotowania trójki gier z automatem komórkowym.
W kwietniu br. przygotowałem troszkę grafiki do klonu Boulder Dasha. link
Jeśli nie masz nic naprzeciwko chciałem kontynuować prace nad swoim Robbo w zestawie gier komórkowych. Zawsze chciałem zaimplementować więcej oryginalnych elementów niż w mojej starszej wersji (choć grafiki do tych elementów jeszcze nie mam).
Co do Magnesu, to chodziło mi o to, że powinien być on zawsze widoczny dla gracza. Jeżeli dodasz scroll poziomy, nie zawsze musi tak być.
Co do fabuły, to ona w Robbo dla Atari jest wyświetlana w formie tekstu po załadowaniu gry. (Widzę, że kolega Jacques już o tym wspomniał).
Oczywiście trzymam kciuki za Twój projekt. Ciekaw jestem elementów i chętnie zagram.
P.S. Poniżej zamieściłem pierwotną grafikę do mojego Robbo, a jeszcze niżej moje bieżące rezultaty w malowaniu:
Ogólnie chciałem zrobić płynnie poruszające się elementy i nawet częściowo to zakodowałem - ale wciąż zastanawiam się czy to dobry pomysł i czy nie jest to za duże utrudnienie dla programisty. W grze w sumie jest kilka wydarzeń na komórce, które mogą powodować inny efekt animacyjny:
- Pojawia się zupełnie nowy obiekt (np. pocisk),
- Obiekt jest animowany (np. eksplozja),
- Obiekt przechodzi z pola na pole (np. bohater, skrzynia, pocisk),
- Obiekt jest zastępowany innym (np. pocisk w mały wybuch),
- Obiekt "rozciąga się" lub klonuje (laser).
Ponadto w płynnym ruchu zauważyłem, że lepiej jest jak obiekt przechodzący z pola na pole na czas ruchu okupuje oba te pola blokując inne obiekty.
Sprawdziłem teraz i Wayback Machine zapamiętał kod źródłowy mojego klonu Robbo w pliku RobboSrc.lha z mojej starej strony na ONecie.
Ostatnia aktualizacja: 03.07.2024 16:12:31 przez Hexmage960
03.07.2024 19:27
[#35]
Re: Ami Robbo 2
@Hexmage960, post #33
Próbowałem użyć poruszania się co 2 piksele taki obiektów (stworki, nietoperze) i powiem szczerze, że to jest tylko Amiga i nie ma szans z wyświetleniem płynnym takiej ilości obiektów jak Atari XL. Bobami można strasznie zamulić grę, blitter i graficzny układ planarny temu nie sprzyja kompletnie. Moim zdaniem jedyna szansa to multiplexing sprajtów, ale ja próbowałem i nie umiem tego używać. Tu w tej wersji wszystko jest wklejane zwykłym Blitem a do BBlitów (bobów) mam ogólną niechęć i wolę ręcznie wykonać 3xBlit niż 1x BBlit (bob).
Można by znowu rozmawiać o użyciu Dual Playfieldu, ale jednak poćwiartowanie 32-kolorowej palety na dwie 8-kolorowe to nie jest dobre rozwiązanie, jeśli chcemy aby gra była graficznie dopieszczona. Przykładem był AmiHERO w wersji 1.0 na dual playfieldzie i AmiHERO 1.1 w wersji 5-bitplanowej.
Można by znowu rozmawiać o użyciu Dual Playfieldu, ale jednak poćwiartowanie 32-kolorowej palety na dwie 8-kolorowe to nie jest dobre rozwiązanie, jeśli chcemy aby gra była graficznie dopieszczona. Przykładem był AmiHERO w wersji 1.0 na dual playfieldzie i AmiHERO 1.1 w wersji 5-bitplanowej.
03.07.2024 20:01
[#38]
Re: Ami Robbo 2
@tukinem, post #35
Skoro odnosisz się do płynnej animacji, to z moich wnikliwych eksperymentów wynika że da się to zrobić.
Nie namawiam Cię zupełnie na to. Wspomniałem o płynnej animacji tylko i wyłącznie jako dalszemu wyzwaniu, który ja chciałem podjąć w przypadku automatu komórkowego do Boulder Dasha i Robbo.
Co więcej zaznaczyłem, że może to utrudniać realizację gry, dlatego sam skłaniam się też ku ruchowi co komórkę w tym moim zestawie gier komórkowych. Na pewno powinienem czerpać dobre wzorce z Twojej pracy, jeśli chcę dokończyć projekt.
Jeszcze napiszę jak to realizuję: otóż faktycznie dużo obiektów o rozmiarze 16x16 pikseli może być trudne do zaprogramowania. Ale można spojrzeć na to w ten sposób:
- Zauważ, że animacja na ekranie Amigi w rozdzielczości wysokiej 640x256 w 4 kolorach działa szybko nawet z użyciem funkcji systemowych, które są lekko mówiąc mało-optymalne. (A te funkcje można dodatkowo znacznie poprawić w prosty sposób).
Skoro 640x256 w 4 kolorach działa dobrze to będzie dobrze działać też:
- 320x256 w 16 kolorach,
- 320x128 w 256 kolorach.
Bo to ta sama liczba danych. I chodzi o animację całego tego obszaru. Na pewno na AGA będzie to łatwiej uzyskać.
Warto też rysować obiekty np. 32x32 po jednym bitplanie. Kontrolując liczbę bitplanów, możemy też rysowanie przyśpieszyć, więc ta architektura wprowadza tego typu możliwości.
Testowałem w praktyce podobne rzeczy parę miesięcy temu.
Płynny ruch wprowadza przede wszystkim trudności w silniku logiki, które jednak da się przezwyciężyć.
Przykład: jak klocek porusza się z pola na pole w poziomie, to blokuje wszystkie klocki poruszające się w pionie i na odwrót.
Poza tym w grze Magazyn było dosyć dużo obiektów animowanych.
Ale tak jak pisałem, skłaniam się ku realizacji normalnego ruchu co pole, ale z tymi elementami gry Robbo, których nie zaimplementowałem wcześniej.
Ostatnia aktualizacja: 03.07.2024 20:09:39 przez Hexmage960
Nie namawiam Cię zupełnie na to. Wspomniałem o płynnej animacji tylko i wyłącznie jako dalszemu wyzwaniu, który ja chciałem podjąć w przypadku automatu komórkowego do Boulder Dasha i Robbo.
Co więcej zaznaczyłem, że może to utrudniać realizację gry, dlatego sam skłaniam się też ku ruchowi co komórkę w tym moim zestawie gier komórkowych. Na pewno powinienem czerpać dobre wzorce z Twojej pracy, jeśli chcę dokończyć projekt.
Jeszcze napiszę jak to realizuję: otóż faktycznie dużo obiektów o rozmiarze 16x16 pikseli może być trudne do zaprogramowania. Ale można spojrzeć na to w ten sposób:
- Zauważ, że animacja na ekranie Amigi w rozdzielczości wysokiej 640x256 w 4 kolorach działa szybko nawet z użyciem funkcji systemowych, które są lekko mówiąc mało-optymalne. (A te funkcje można dodatkowo znacznie poprawić w prosty sposób).
Skoro 640x256 w 4 kolorach działa dobrze to będzie dobrze działać też:
- 320x256 w 16 kolorach,
- 320x128 w 256 kolorach.
Bo to ta sama liczba danych. I chodzi o animację całego tego obszaru. Na pewno na AGA będzie to łatwiej uzyskać.
Warto też rysować obiekty np. 32x32 po jednym bitplanie. Kontrolując liczbę bitplanów, możemy też rysowanie przyśpieszyć, więc ta architektura wprowadza tego typu możliwości.
Testowałem w praktyce podobne rzeczy parę miesięcy temu.
Płynny ruch wprowadza przede wszystkim trudności w silniku logiki, które jednak da się przezwyciężyć.
Przykład: jak klocek porusza się z pola na pole w poziomie, to blokuje wszystkie klocki poruszające się w pionie i na odwrót.
Poza tym w grze Magazyn było dosyć dużo obiektów animowanych.
Ale tak jak pisałem, skłaniam się ku realizacji normalnego ruchu co pole, ale z tymi elementami gry Robbo, których nie zaimplementowałem wcześniej.
Ostatnia aktualizacja: 03.07.2024 20:09:39 przez Hexmage960
03.07.2024 20:27
[#39]
Re: Ami Robbo 2
@ppill, post #36
Nie "odrysowuję bobami". Pisałem, że wolę wkleić grafikę tła zamazując obiekt, po tym wkleić górny kafelek, żeby odzyskać jego dolną część jak tu w przypadku widoku top-down, a następnie wkleić dolny kafelek jeśli czasem ruszaliśmy skrzynkę, która nachodzi na dolny kafelek. To jest jednorazowy zabieg 2 ramki pod rząd (podwójne buforowanie) i nie spowalnia tak, jakbym miał zamiast tego wszystkiego wklejać boba co ramkę.
Wystarczy, że umieściłbym 4 biegające stworki jako boby i już blitter zwolni. Teraz stworki są wklejane i następnie zamazywane, dzięki czemu mogę ich umieścić 10 nawet nie licząc innych obiektów. Przykładem niech będzie Electroman, gdzie zamiast wklejać ruchomego pionowo boba 16x16 pikseli wolałem blitować same grafiki rozmiaru 16x80 pikseli jedna po drugiej, bo wtedy unikałem kopiowania do bufora ikopiowania z powrotem z bufora tła co ramkę.
@Hexmage960: nigdy nie próbowałem używać systemowych funkcji rysujących. Łatwiej by mi już było ręcznie napisać sobie procedurę rysowania blitterem w asemblerze, chociaż jeszcze nie potrafię napisać blitowania co do piksela w poziomie. Dużym udogodnieniem w Blitz Basic są gotowe funkcje rysujące, pomimo że są napisanie "uniwersalnie" przez co mogą nie być aż tak optymalne jak ręcznie napisana funkcja w asemblerze dla danej gry.
Wystarczy, że umieściłbym 4 biegające stworki jako boby i już blitter zwolni. Teraz stworki są wklejane i następnie zamazywane, dzięki czemu mogę ich umieścić 10 nawet nie licząc innych obiektów. Przykładem niech będzie Electroman, gdzie zamiast wklejać ruchomego pionowo boba 16x16 pikseli wolałem blitować same grafiki rozmiaru 16x80 pikseli jedna po drugiej, bo wtedy unikałem kopiowania do bufora ikopiowania z powrotem z bufora tła co ramkę.
@Hexmage960: nigdy nie próbowałem używać systemowych funkcji rysujących. Łatwiej by mi już było ręcznie napisać sobie procedurę rysowania blitterem w asemblerze, chociaż jeszcze nie potrafię napisać blitowania co do piksela w poziomie. Dużym udogodnieniem w Blitz Basic są gotowe funkcje rysujące, pomimo że są napisanie "uniwersalnie" przez co mogą nie być aż tak optymalne jak ręcznie napisana funkcja w asemblerze dla danej gry.
04.07.2024 06:31
[#40]
Re: Ami Robbo 2
@tukinem, post #35
Próbowałem użyć poruszania się co 2 piksele taki obiektów (stworki, nietoperze) i powiem szczerze, że to jest tylko Amiga i nie ma szans z wyświetleniem płynnym takiej ilości obiektów jak Atari XL.
Niebywałe: Atari XL/XE - Amiga killer
A tak poważnie: to wynika z Twoich algorytmów, użycia Blitz Basica czy jeszcze czegoś innego? Bo jest na Amigę wiele gier, które wydają się temu przeczyć
04.07.2024 09:37
[#41]
Re: Ami Robbo 2
@tukinem, post #39
Wystarczy, że umieściłbym 4 biegające stworki jako boby i już blitter zwolni
pytanie czy wszystkie 4 stworki muszą być co ramkę odświeżane? nie znam za bardzo Robbo, ale jeśli ruszasz je co kafelek (16x16) to znaczy że nie musisz ich wszystkich ruszać co ramkę. to jest miejsce gdzie można by pożonglować kolejnością wyświetlania i zoptymalizować szybkość działania.
poza tym:
- ile tych bobów na raz na ekranie musisz poruszać?
- czy coś może być na sprajtach? np główny bohater albo jakieś kluczyki itp?
04.07.2024 09:59
[#42]
Re: Ami Robbo 2
@tukinem, post #35
W Robbo na Atari, ruch postaci i innych stworów był skokowy (tak samo jak np. promieni lasera), bo gra była w trybie tekstowym. Animacja postaci (robocika czy tam ptaka/nietoperza/oczu) odbywała się dopiero wtedy, gdy ta przesunęła się na miejsce docelowe, czyli o jedną pozycję obok.
Tylko przesuwanie ekranu było płynne (i to co jedno pole, czy tam kafelek), co dawało jakby efekt płynności wszystkiego.
Czyli uproszczenia na maksa.
----edit
Widać to dobrze na filmiku z yt: https://youtu.be/btRek7UytUQ
Można sobie poklatkować żeby zobaczyć, np pocisk z działa skacze co kafelek, ale ma dwie klatki animacji na kafelek, więc wydaje się bardziej płynny.
Ostatnia aktualizacja: 04.07.2024 10:09:31 przez karolb
Tylko przesuwanie ekranu było płynne (i to co jedno pole, czy tam kafelek), co dawało jakby efekt płynności wszystkiego.
Czyli uproszczenia na maksa.
----edit
Widać to dobrze na filmiku z yt: https://youtu.be/btRek7UytUQ
Można sobie poklatkować żeby zobaczyć, np pocisk z działa skacze co kafelek, ale ma dwie klatki animacji na kafelek, więc wydaje się bardziej płynny.
Ostatnia aktualizacja: 04.07.2024 10:09:31 przez karolb
04.07.2024 12:57
[#44]
Re: Ami Robbo 2
@c64portal, post #41
Nasz Robbo porusza się co 2 piksele na ramkę. Przeciwnicy powinni się poruszać mniej więcej tak samo szybko, więc w jaki sposób rzadziej odświeżać? Co 4 piksele na 2 ramki? Co 8 pikseli na 4 ramki? To nic nie da bo taki obiekt trzeba rysować i tak co ramkę jako bob żeby odrysować później tło spod niego. No chyba że czarne tło ma zostać, jak w Atari. Stworki biegają nieustannie. Nietoperze tak samo. W wersji Atari takich obiektów było nieraz bardzo dużo na ekranie.
To nie wina algorytmów, ani basica. Nie wiem na czym polegał tryb tekstowy w 8 bitowcach i nie interesuje mnie to ale pewnie dlatego dało radę wyświetlić tyle ruchomych obiektów naraz. Tak jak pisałem, u mnie takie obiekty nie mogą być bobami. Nie jestem scenowcem ani magikiem więc używam tylko blittera do rysowania który łatwo jest zajechać.
To nie wina algorytmów, ani basica. Nie wiem na czym polegał tryb tekstowy w 8 bitowcach i nie interesuje mnie to ale pewnie dlatego dało radę wyświetlić tyle ruchomych obiektów naraz. Tak jak pisałem, u mnie takie obiekty nie mogą być bobami. Nie jestem scenowcem ani magikiem więc używam tylko blittera do rysowania który łatwo jest zajechać.
04.07.2024 13:40
[#46]
Re: Ami Robbo 2
@tukinem, post #44
link
Tu masz opisane parę sztuczek. Najłatwiesza to zmiana palety tak by kolory elementów przesunąć do początkowych bitplane'ów. Jeżeli zmieszczą się w pierwszych ośmiu to już masz dwa mniej. Robisz oddzielny tileset w tej ilości i kolejności kolorów i z niego wycinasz elementy przeciwników.
Tu masz opisane parę sztuczek. Najłatwiesza to zmiana palety tak by kolory elementów przesunąć do początkowych bitplane'ów. Jeżeli zmieszczą się w pierwszych ośmiu to już masz dwa mniej. Robisz oddzielny tileset w tej ilości i kolejności kolorów i z niego wycinasz elementy przeciwników.
04.07.2024 14:28
[#47]
Re: Ami Robbo 2
@Jacques, post #45
Nie wiem jak to tam działa. Jak wiesz to napisz. Na pewno one nie są typowymi bobami.
@Ppill: zmianą kolorów nie przemieszczę obiektu o 2 piksele, a jedynie zmienię grafikę. Poza tym jeśli inne obiekty będą używać którychś z tych kolorów no to też będzie łapać je.
Ruchomych obiektów jest sporo, bo oprócz głównego robota są lasery (pionowe, poziome), nietoperze latające poziomo i pionowo, stworki prawoskrętne, lewoskrętne oraz oczy, które gonią robota. Z samego wyliczenia obiektów już wychodzi ponad 5. Ani jeden z nich nie może być bobem (a tymbardziej lasery). Nie chce mi się bawić w rozkminianie, czy stosując jakieś chwilowe skopiowanie tła odzyskam kilka FPSów. Piszę taki silnik, aby można było jak najwięcej obiektów ruchomych umieścić w danym poziomie, a poziomy będą większe o wiele od tych oryginalnych, bo bitmapy są rozmiaru 512x512. Zresztą już 4 tys linii kodu skrobnąłem więc nie zamierzam tam nic zmieniać jeśli chodzi o sam sposób wyświetlania obiektów.
@Ppill: zmianą kolorów nie przemieszczę obiektu o 2 piksele, a jedynie zmienię grafikę. Poza tym jeśli inne obiekty będą używać którychś z tych kolorów no to też będzie łapać je.
Ruchomych obiektów jest sporo, bo oprócz głównego robota są lasery (pionowe, poziome), nietoperze latające poziomo i pionowo, stworki prawoskrętne, lewoskrętne oraz oczy, które gonią robota. Z samego wyliczenia obiektów już wychodzi ponad 5. Ani jeden z nich nie może być bobem (a tymbardziej lasery). Nie chce mi się bawić w rozkminianie, czy stosując jakieś chwilowe skopiowanie tła odzyskam kilka FPSów. Piszę taki silnik, aby można było jak najwięcej obiektów ruchomych umieścić w danym poziomie, a poziomy będą większe o wiele od tych oryginalnych, bo bitmapy są rozmiaru 512x512. Zresztą już 4 tys linii kodu skrobnąłem więc nie zamierzam tam nic zmieniać jeśli chodzi o sam sposób wyświetlania obiektów.
04.07.2024 14:56
[#48]
Re: Ami Robbo 2
@tukinem, post #47
Jak mieliśmy problemy z prędkością przy Escape Velocity to przeniesienie przeciwników do pierwszych 3 bitplane'ów sporo pomogło. Byłem ciekaw czy w Blitzu można operować na mniejszej ilości niż te zdefiniowane przy otwarciu ekranu i trafiłem na to. Teoretycznie wszystkie operacje typu Blit, QBlit i Block będą używały tylko pierwszych trzech jeżeli użyjesz GetaShape z tak zmienionego tilesetu.
04.07.2024 15:14
[#49]
Re: Ami Robbo 2
@tukinem, post #1
Jako że ja mam gdzieś u siebie na dysku, prawie 99% zgodny z Atari 8 bit port robbo (napisany w C). To może się wypowiem, chociaż mam wrażenie że dawno temu o tym pisałem na forum.
Port jest 99% zgodny, bo ja świadomie wywaliłem sprawdzanie czy na przykład z lewej strony dotykamy granicy planszy. Co ma swoje minusy, gdyż w robbo można zbudować na przykład planszę bez lewego ograniczającego murku a w moim porcie nie można, więc odpadają niektóre plansze zbudowane w ten sposób. Oczywiście można to rozwiązać umieszczająć planszę w piaskownicy (sandboxie), czyli planszy szerszej i wyższej o dwa klocki.
Ze względu na to że wszystko przemieszcza się o 16 pikseli (czyli o klocek), to byłoby za szybko dla gracza ogarnąć grę. Dlatego ruch odbywa się co 4 ramki. Co ramkę odbywa się scroll pionowy, w tym przypadku co 4 piksele. To oznacza że mamy 4 ramki by narzucić widoczny ekran. Taka ilość czasu pozwala na wiele. Ja uparłem się na wersję zgodną z OS w okienku i tu okazało się że najwięcej zajmuje przekopiowanie ekranu widocznego do okna, oczywiście to zależy w jakiej rozdzielczości mamy WB otwarty i ile mamy bitplanów. Tu sztuczki z planami nie pomogą, choćbym nie wiem jak się napinał.
Pewnie kilka osób, bądź więcej, pamięta że nawet napisałem mejla do właścicieli praw autorskim ale nie dostałem pozwolenia.
@MDW
Zapomniałeś dodać że GNURobbo w wersji dla 68k wymaga FPU i SDL. Odpaliłem z ciekawości na moim 030 i fpu. O zgrozo pomieliło, asety wczytało i ukazał się komunikat że jednak potrzeba SDL. A ja myślałem że najpierw sprawdzamy czy są wszystkie potrzebne rzeczy a potem wczytujemy asety. Poza tym plik wykonywalny zajmuje ponad 500 kilobajtów, co dla mnie już jest sporym zaskoczeniem. Z ciekawości też zajrzałem do źródeł i nie polecam tam patrzeć, i to jest delikatnie powiedziane. Podsumowując GNURobbo może jest ok dla AOS4 i Morphos.
@Jacques
W Swiv nie ma 50 ramek na sekunde, w niektórych momentach spada i to grubo, ale taki był zamysł autora.
W Batle Squadron sprajty 50 ramek na sekundę, boby co drugą ramkę.
Deluxe Galaga też zwalnia w niektórch momentach, tyle że tu jest to ogarnięte tak że odpada zapamiętywanie tła jak dobrze pamiętam.
Ostatnia aktualizacja: 04.07.2024 15:15:50 przez asman
Port jest 99% zgodny, bo ja świadomie wywaliłem sprawdzanie czy na przykład z lewej strony dotykamy granicy planszy. Co ma swoje minusy, gdyż w robbo można zbudować na przykład planszę bez lewego ograniczającego murku a w moim porcie nie można, więc odpadają niektóre plansze zbudowane w ten sposób. Oczywiście można to rozwiązać umieszczająć planszę w piaskownicy (sandboxie), czyli planszy szerszej i wyższej o dwa klocki.
Ze względu na to że wszystko przemieszcza się o 16 pikseli (czyli o klocek), to byłoby za szybko dla gracza ogarnąć grę. Dlatego ruch odbywa się co 4 ramki. Co ramkę odbywa się scroll pionowy, w tym przypadku co 4 piksele. To oznacza że mamy 4 ramki by narzucić widoczny ekran. Taka ilość czasu pozwala na wiele. Ja uparłem się na wersję zgodną z OS w okienku i tu okazało się że najwięcej zajmuje przekopiowanie ekranu widocznego do okna, oczywiście to zależy w jakiej rozdzielczości mamy WB otwarty i ile mamy bitplanów. Tu sztuczki z planami nie pomogą, choćbym nie wiem jak się napinał.
Pewnie kilka osób, bądź więcej, pamięta że nawet napisałem mejla do właścicieli praw autorskim ale nie dostałem pozwolenia.
@MDW
Od kilkunastu lat dla AmigaOS (Aminet) i MorphOS (MorphOS Storage) jest dostępne GNURobbo 0.66 (https://gnurobbo.sourceforge.net). Jest to kompletna wersja Robbo w której można zrobić i zmienić wszystko. Bez dotykania kodu można sobie podstawiać własną grafikę. Jest kilka zestawów grafik (niestety dosyć siermiężnych), a ten oryginalny z Atari wcale nie jest idealnie oryginaly. :) Jest w tym chyba nawet Robbo Konstruktor pozwalający robić własne poziomy. Zresztą jest tam tych zestawów poziomów tyle, że życia nie wystarczyłoby żeby to wszystko przejść. Nawet kiedyś myślałem żeby powycinać graficzki z atarowskiego Robbo i zrobić taki zestaw z NAPRAWDĘ tą pierwszą grafiką z Atari z 1989. Ale trochę szkoda mi czasu na przeróbki cudzych projektów gdy własne błagają o jeszcze więcej czasu. szeroki uśmiech
Zapomniałeś dodać że GNURobbo w wersji dla 68k wymaga FPU i SDL. Odpaliłem z ciekawości na moim 030 i fpu. O zgrozo pomieliło, asety wczytało i ukazał się komunikat że jednak potrzeba SDL. A ja myślałem że najpierw sprawdzamy czy są wszystkie potrzebne rzeczy a potem wczytujemy asety. Poza tym plik wykonywalny zajmuje ponad 500 kilobajtów, co dla mnie już jest sporym zaskoczeniem. Z ciekawości też zajrzałem do źródeł i nie polecam tam patrzeć, i to jest delikatnie powiedziane. Podsumowując GNURobbo może jest ok dla AOS4 i Morphos.
@Jacques
No a jak to się odbywa na Amidze w Swiv, Battle Squadron, Deluxe Galaga, itp.?
W Swiv nie ma 50 ramek na sekunde, w niektórych momentach spada i to grubo, ale taki był zamysł autora.
W Batle Squadron sprajty 50 ramek na sekundę, boby co drugą ramkę.
Deluxe Galaga też zwalnia w niektórch momentach, tyle że tu jest to ogarnięte tak że odpada zapamiętywanie tła jak dobrze pamiętam.
Ostatnia aktualizacja: 04.07.2024 15:15:50 przez asman
04.07.2024 15:49
[#51]
Re: Ami Robbo 2
@ppill, post #48
Block czyści wszystkie 5 bitplanów.
Blit faktycznie użyje tylu bitplanów ile posiada shape w pamięci, chyba że użyjemy dodatkowego parametru EXCESSONOFF
QBlit nadaje się do dual playfieldu, gdyż nie odrysowuje tła po bobie
Zapomniałeś o BBlit, czyli typowym bobie właśnie.
Wszystkie Block i Blit nie nadają się do większego przemieszczania obiektów, ponieważ po nich trzeba odrysować kolejne kafle, jak tu w przypadku widoku top-down gdzie odrysowując tło obiektu pod murkiem należy później odysować zarówno jego tło jak i wykończenie murku nad nim.
Dodam jeszcze, że tu w kodzie nie użyłem typowego Blit, a ClipBlit (troszkę wolniejsza metoda sprawdzająca czy pole blitu nie wychodzi poza bitmapę), ze względu na fakt, że niektóe kafle są rozmiaru 16x20 pikseli i wykroczyłyby poza bitmapę. To i tak niewielka różnica w porównaniu z wolnym działaniem komendy BBlit, której unikam jak ognia, jak już pisałem.
Pytano, czy główny robot jest sprajtem. Nie. Jest bobem właśnie i to jeden z dwóch takich obiektów w grze. Drugim obiektem BOB jest animacja wybuchu bomby (48x48 pikseli). Na sprajta 16-kolorowego już nie mam szans, bo mam sprajta 3-kolorowego jako strzał robota, sprajtem 3-kolorowym jest liczba żyć na ekranie na górze oraz po przejściu poziomu sprajtem 16-kolorowym jest animowany statek odlatujący tak jak to działało w AmiRobbo 1. W tej wersji na itch.io nie ma jeszcze animacji odlotu statku, ale u siebie już to mam wklepane w kod. Musiałem trochę to napisać od siebie, bo oryginał był napisany w AMALu.
Blit faktycznie użyje tylu bitplanów ile posiada shape w pamięci, chyba że użyjemy dodatkowego parametru EXCESSONOFF
QBlit nadaje się do dual playfieldu, gdyż nie odrysowuje tła po bobie
Zapomniałeś o BBlit, czyli typowym bobie właśnie.
Wszystkie Block i Blit nie nadają się do większego przemieszczania obiektów, ponieważ po nich trzeba odrysować kolejne kafle, jak tu w przypadku widoku top-down gdzie odrysowując tło obiektu pod murkiem należy później odysować zarówno jego tło jak i wykończenie murku nad nim.
Dodam jeszcze, że tu w kodzie nie użyłem typowego Blit, a ClipBlit (troszkę wolniejsza metoda sprawdzająca czy pole blitu nie wychodzi poza bitmapę), ze względu na fakt, że niektóe kafle są rozmiaru 16x20 pikseli i wykroczyłyby poza bitmapę. To i tak niewielka różnica w porównaniu z wolnym działaniem komendy BBlit, której unikam jak ognia, jak już pisałem.
Pytano, czy główny robot jest sprajtem. Nie. Jest bobem właśnie i to jeden z dwóch takich obiektów w grze. Drugim obiektem BOB jest animacja wybuchu bomby (48x48 pikseli). Na sprajta 16-kolorowego już nie mam szans, bo mam sprajta 3-kolorowego jako strzał robota, sprajtem 3-kolorowym jest liczba żyć na ekranie na górze oraz po przejściu poziomu sprajtem 16-kolorowym jest animowany statek odlatujący tak jak to działało w AmiRobbo 1. W tej wersji na itch.io nie ma jeszcze animacji odlotu statku, ale u siebie już to mam wklepane w kod. Musiałem trochę to napisać od siebie, bo oryginał był napisany w AMALu.
04.07.2024 17:27
[#53]
Re: Ami Robbo 2
@asman, post #49
Zapomniałeś dodać że GNURobbo w wersji dla 68k wymaga FPU i SDL.
Faktycznie nie przyszło mi to do głowy. To znaczy uznałem, że skoro gra jest multiplatformowa i po prostu tak sobie przeportowana to na pewno wymaga SDL. Linuxowcy uwielbiają tę bibliotekę.
O zgrozo pomieliło, asety wczytało i ukazał się komunikat że jednak potrzeba SDL. A ja myślałem że najpierw sprawdzamy czy są wszystkie potrzebne rzeczy a potem wczytujemy asety.
Faktycznie średnio ładnie... Niestety tak wygląda cały dzisiejszy świat. Myślę, że prawie 100% gier AAA robionych za setki milionów dolarów na dzisiejsze platformy ma w nosie tę i tysiąc innych podstawowych zasad poprawnego programowania. No ale jednak po domowym projekcie (jakim jest GNURobbo) można byłoby spodziewać się porządniejszej architektury.
Z punktu widzenia Amig w niższych konfiguracjach to rzeczywiście GNURobbo jest nieakceptowalne. Zresztą też mógłbym się tam przyczepić do kilku elementów, bo kojarzę, że coś tam było zrobione dosyć niedbale.
07.07.2024 15:43
[#57]
Re: Ami Robbo 2
@Hexmage960, post #56
Ruch naszego robocika jest płynny co 2 piksele, ale to stworzyło mnóstwo kodu. Rozwklekłem to ogromnie, ale dzięki temu to tak ładnie działa i dobrze się steruje.
Ruch przeciwników jest skokowy co 16 pikseli.
Zacząłem ostatnio pisać sobie menu gry, tworzyć grafiki dla napisów itd, ale to taka dłubaninka. Zastanawiam się, czy nie stworzyć w menu dual playfieldu z jakimiś przemieszczającymi się gwiazdami w tle. Ładny efekt by był z tego.
Ruch przeciwników jest skokowy co 16 pikseli.
Zacząłem ostatnio pisać sobie menu gry, tworzyć grafiki dla napisów itd, ale to taka dłubaninka. Zastanawiam się, czy nie stworzyć w menu dual playfieldu z jakimiś przemieszczającymi się gwiazdami w tle. Ładny efekt by był z tego.