23.07.2024 21:40
[#181]
Re: Ami Robbo 2
@Don_Adan, post #180
Oczywiście, że mam:
300KB na plik uruchamialny to nie jest dużo. Sołtys ma ponad 600KB, Tony to ponad 300KB, Electroman tak samo
AmiRobbo 2 ma 4 600 linii kodu. Dodatkowo ładowane są wszelkie użyte biblioteki, jak w przypadku Amosa i dodawania przez niego amos.library.
Napisałem szkielet ładowania i wyświetlania fabuły gry. Używam bitmapy z rozgrywki, więc dalej gra działa na golasach. Jedynie zostaje doczytana grafika 160x96 pikseli i dołożyłem jedną procedurę wypisującą tekst. Goła A600 (only 1MB chip) wczytuje muzykę do gry i wszystko działa pięknie. Jeszcze zostaje ponad 100KB chip ramu. A oto zdjęcie z uruchomienia na emulacji Cyberstorm PPC:
. To jest właśnie uniwersalność, że gra ruszy wszędzie bez konieczności używania WHDLoad. Ładujesz ADF i grasz
Ostatnia aktualizacja: 23.07.2024 21:41:10 przez tukinem
300KB na plik uruchamialny to nie jest dużo. Sołtys ma ponad 600KB, Tony to ponad 300KB, Electroman tak samo
AmiRobbo 2 ma 4 600 linii kodu. Dodatkowo ładowane są wszelkie użyte biblioteki, jak w przypadku Amosa i dodawania przez niego amos.library.Napisałem szkielet ładowania i wyświetlania fabuły gry. Używam bitmapy z rozgrywki, więc dalej gra działa na golasach. Jedynie zostaje doczytana grafika 160x96 pikseli i dołożyłem jedną procedurę wypisującą tekst. Goła A600 (only 1MB chip) wczytuje muzykę do gry i wszystko działa pięknie. Jeszcze zostaje ponad 100KB chip ramu. A oto zdjęcie z uruchomienia na emulacji Cyberstorm PPC:
. To jest właśnie uniwersalność, że gra ruszy wszędzie bez konieczności używania WHDLoad. Ładujesz ADF i grasz Ostatnia aktualizacja: 23.07.2024 21:41:10 przez tukinem
23.07.2024 22:41
[#182]
Re: Ami Robbo 2
@tukinem, post #181
Ok, bo w przypadku AMOS-a widzialem exeki ze skompilowanym playerem MED-ow z OctaMED-a, ktore oczywiscie byly nieuzywane przez gre, i inne dziwne odwolania. W przypadku BB2 tez dobrze byloby przejrzec wizualnie kod i zobaczyc czy cos zbednego dodaje.
Albo mozna stworzyc testowy programik, ktory by np. wyswietlal tylko logo/tytul gry i wychodzil do DOS po nacisnieciu LMB.
Wtedy byloby wiadomo czy BB2 dodaje zbedne rzeczy, jesli taki exek bylby duzy.
Albo mozna stworzyc testowy programik, ktory by np. wyswietlal tylko logo/tytul gry i wychodzil do DOS po nacisnieciu LMB.
Wtedy byloby wiadomo czy BB2 dodaje zbedne rzeczy, jesli taki exek bylby duzy.
23.07.2024 22:58
[#183]
Re: Ami Robbo 2
@Don_Adan, post #182
W opcjach kompilatora trzeba pilnować sobie ile przydziela pamięci na dane / obiekty / stringi itp. Możliwe, że wtedy mi nie działało, bo miałem zbyt duże dane tam. Trudno na oko to ustawić, a przy uruchamianiu on sam zwiększa te dane często.
Teraz gra śmiga na każdym ustawieniu gołej Amigi (oprócz Amigi 1000). Dodałem obsługę światów, ale będę musiał grafiki światów podzielić na osobne pliki. Zrobiłem obsługę wyświetlania postępu historii w grze w trakcie przechodzenia. Będzie na tej dużej bitmapie z gry wyświetlać obrazek 160x96 i będzie wypisywać tekst:
Podoba mi się to, że uruchomiłem na emulowanej Amidze 500+ gołej (tylko 1MB chip ram), gdzie wczytało muzykę, wszystko weszło w ten 1MB i jeszcze zostało się 180 KB. Moduł mam póki co taki byle jaki który sam stworzyłem co zajmuje 67KB, więc choćby wymienić go na 40KB większy to jeszcze zostaje miejsce na inne zdarzenia dźwiękowe. Moim zdaniem nie będę w tej grze łączyć dźwięków i muzyki, tylko jeśli gracz wciśnie M, to automatycznie wyczyści banki z dźwiękami i wczyta moduł, lub na odwrót.
Teraz gra śmiga na każdym ustawieniu gołej Amigi (oprócz Amigi 1000). Dodałem obsługę światów, ale będę musiał grafiki światów podzielić na osobne pliki. Zrobiłem obsługę wyświetlania postępu historii w grze w trakcie przechodzenia. Będzie na tej dużej bitmapie z gry wyświetlać obrazek 160x96 i będzie wypisywać tekst:
Podoba mi się to, że uruchomiłem na emulowanej Amidze 500+ gołej (tylko 1MB chip ram), gdzie wczytało muzykę, wszystko weszło w ten 1MB i jeszcze zostało się 180 KB. Moduł mam póki co taki byle jaki który sam stworzyłem co zajmuje 67KB, więc choćby wymienić go na 40KB większy to jeszcze zostaje miejsce na inne zdarzenia dźwiękowe. Moim zdaniem nie będę w tej grze łączyć dźwięków i muzyki, tylko jeśli gracz wciśnie M, to automatycznie wyczyści banki z dźwiękami i wczyta moduł, lub na odwrót.
23.07.2024 23:13
[#184]
Re: Ami Robbo 2
@Don_Adan, post #182
A propos Amosa to jak pamiętam to kod puchnie tylko na początku, na zasadzie byle coś i jest 50kb a potem to już nie przyrasta tak, chociaż skompilowany kod amosowy jest obrzydliwy.
Ja kiedyś zrobiłem jeden test i mi wystarczyło by nie wracać do BB2, bo przyznaję się bez bicia, że kilka programików testowych napisałem. Z ciekawości chciałem sprawdzić jak wygląda w asm funkcja/procedura/metoda czytająca stan joysticka. Jakie było moje zdziwienie gdy zobaczyłem ten sam kod powielony dwa razy z drobną zmianą na zasadzie w jednej było $dff00a a w drugiej to samo tylko $dff00c. I nie szło tego badziewia wywalić. W sumie to użyteczne jak robisz grę i pozwalasz wybrać czy joy jest w porcie 0 czy w porcie 1. Tyle że ja tego nie chciałem. Więc według mnie BB2 nie wywala martwego kodu albo wywala bardzo mało, nie wgłębiałem się w to. Być może pośrednim rozwiązaniem tego jest ostrożne używanie funkcji z bibliotek blitza i sprawdzanie co jest dokładane, co wymaga znajomości asemblera. Lepszym rozwiązaniem byłoby pisanie własnych bibliotek do blitza i ich używanie. Tylko wtedy według mnie robi się z tego programowanie jak w C.
A najlepiej jakby ktoś poprawił blitza w sprawie wywalania martwego kodu :)
Ja kiedyś zrobiłem jeden test i mi wystarczyło by nie wracać do BB2, bo przyznaję się bez bicia, że kilka programików testowych napisałem. Z ciekawości chciałem sprawdzić jak wygląda w asm funkcja/procedura/metoda czytająca stan joysticka. Jakie było moje zdziwienie gdy zobaczyłem ten sam kod powielony dwa razy z drobną zmianą na zasadzie w jednej było $dff00a a w drugiej to samo tylko $dff00c. I nie szło tego badziewia wywalić. W sumie to użyteczne jak robisz grę i pozwalasz wybrać czy joy jest w porcie 0 czy w porcie 1. Tyle że ja tego nie chciałem. Więc według mnie BB2 nie wywala martwego kodu albo wywala bardzo mało, nie wgłębiałem się w to. Być może pośrednim rozwiązaniem tego jest ostrożne używanie funkcji z bibliotek blitza i sprawdzanie co jest dokładane, co wymaga znajomości asemblera. Lepszym rozwiązaniem byłoby pisanie własnych bibliotek do blitza i ich używanie. Tylko wtedy według mnie robi się z tego programowanie jak w C.
A najlepiej jakby ktoś poprawił blitza w sprawie wywalania martwego kodu :)
24.07.2024 01:05
[#187]
Re: Ami Robbo 2
@asman, post #184
W Blitzu masz różne sposoby sprawdzania stanu joya. Ja używam Joyx(nr_portu) / Joyy(nr_portu) / joyb(nr_portu). Dla myszy również używam Joyb ale ostatnio sobie napisałem fajną procedurkę asemblerem w blitzu dla myszy, która sprawdza czy się kliknęło, czy się trzyma fire, czy się dopiero co puściło i czy nie jest kliknięta. Wykorzystałem do tego 2 bajty zwrotne, gdzie jeden bajt to lewy klawisz, a drugi to prawy. Przykładowo jeśli wciśniemy to bajt przyjmuje wartość 3. Następnie spada do dwóch i jeśli trzymamy to utrzymuje się przy dwóch. Jeśli puścimy to spada do zera. Wtedy przykładowo samo kliknięcie sprawdzamy czy zmienna ma wartość 3, a samo puszczenie, czy zmienna ma wartość 1.
Ostatnia aktualizacja: 24.07.2024 01:06:28 przez tukinem
Ostatnia aktualizacja: 24.07.2024 01:08:46 przez tukinem
Ostatnia aktualizacja: 24.07.2024 01:06:28 przez tukinem
Ostatnia aktualizacja: 24.07.2024 01:08:46 przez tukinem
06.08.2024 09:12
[#188]
Re: Ami Robbo 2
@tukinem, post #118
Masz cos dla Ciebie na przyszlosc. Wyzszy poziom Blitza.
link
Biblioteka BlitzBasic2 od Eeroka.
Co daje?
Trackloading z dyskietki.
Czyli co w realu?
2 rzeczy:
1. Wiecej miejsca na dyskietce na dane.
2. Wiecej wolnej pamieci na starcie z dyskietki.
Edycja.
link
Ostatnia aktualizacja: 06.08.2024 09:27:41 przez Don_Adan
link
Biblioteka BlitzBasic2 od Eeroka.
Co daje?
Trackloading z dyskietki.
Czyli co w realu?
2 rzeczy:
1. Wiecej miejsca na dyskietce na dane.
2. Wiecej wolnej pamieci na starcie z dyskietki.
Edycja.
link
Ostatnia aktualizacja: 06.08.2024 09:27:41 przez Don_Adan
15.08.2024 22:47
[#190]
Re: Ami Robbo 2
@tukinem, post #1
Trochę zmian było od tamtej pory, sporo też przestoju z powodu pisania TonyGO.
Grafiki Koyota nie będę wykorzystywać, gdyż nie ma raczej sensu mieszać wielu grafików naraz. Rafałowi również podziękowałem i w projekcie współpracuję jedynie z Selurem odnośnie grafiki. Po drugie tileset Koyota miał sporo bardzo podobnych kolorów i żal było ingerować w niego tak, aby dopasować go do palety Selura. Zbyt wiele kolorków by się straciło po drodze.
Zoptymalizowałem kod, zmieniłem ekran startowy jednak na grafikę HAM i teraz konkrety:
OCS 0,5MB Chip Only -> niegrywalne, ale wyświetla komunikat, że komputer nie posiada odpowiedniej ilości pamięci
OCS 0,5MB + 0,5MB -> gra + SFX
ECS Agnus 1MB Chip (np. goła A600) -> gra + SFX + muzyka w menu gry (możliwe, że będą dodatkowe SFXy)
Oto jaki obrazek będzie na starcie gry (screenshot z WinUAE):
Wrzuciłem do Aseprite i wyświetliło ładną ilość kolorów nie ma może tysiąca, ale jak na Amigę z OCS, to jest ponad 700, więc ja jestem zadowolony.
Światów w grze będzie 5, lub 6. Nie więcej.
Fabuła gry już się powoli zaczyna:
Obrazki będą kolorowe, ale tu nie chciało mi się bawić z tworzeniem kolorków, więc użyłem tylko tych z czcionki.
Pytano, czy robocik będzie mieć różne grafiki. Będzie mieć:
Dopikslowałem po swojemu dodatkowe klatki animacji aby się zgadzało z założoną animacją Selura. World 1, który nawiązuje do Robbo z Atari ma grafiki robocika podobne do oryginału, ale lekko przerobione przeze mnie.
Jak tylko będę mieć dźwięki do gry, to wrzucę ADF na profil gry.
Ostatnia aktualizacja: 15.08.2024 22:48:39 przez tukinem
Grafiki Koyota nie będę wykorzystywać, gdyż nie ma raczej sensu mieszać wielu grafików naraz. Rafałowi również podziękowałem i w projekcie współpracuję jedynie z Selurem odnośnie grafiki. Po drugie tileset Koyota miał sporo bardzo podobnych kolorów i żal było ingerować w niego tak, aby dopasować go do palety Selura. Zbyt wiele kolorków by się straciło po drodze.
Zoptymalizowałem kod, zmieniłem ekran startowy jednak na grafikę HAM i teraz konkrety:
OCS 0,5MB Chip Only -> niegrywalne, ale wyświetla komunikat, że komputer nie posiada odpowiedniej ilości pamięci
OCS 0,5MB + 0,5MB -> gra + SFX
ECS Agnus 1MB Chip (np. goła A600) -> gra + SFX + muzyka w menu gry (możliwe, że będą dodatkowe SFXy)
Oto jaki obrazek będzie na starcie gry (screenshot z WinUAE):
Wrzuciłem do Aseprite i wyświetliło ładną ilość kolorów
nie ma może tysiąca, ale jak na Amigę z OCS, to jest ponad 700, więc ja jestem zadowolony.Światów w grze będzie 5, lub 6. Nie więcej.
Fabuła gry już się powoli zaczyna:
Obrazki będą kolorowe, ale tu nie chciało mi się bawić z tworzeniem kolorków, więc użyłem tylko tych z czcionki.
Pytano, czy robocik będzie mieć różne grafiki. Będzie mieć:
Dopikslowałem po swojemu dodatkowe klatki animacji aby się zgadzało z założoną animacją Selura. World 1, który nawiązuje do Robbo z Atari ma grafiki robocika podobne do oryginału, ale lekko przerobione przeze mnie.
Jak tylko będę mieć dźwięki do gry, to wrzucę ADF na profil gry.
Ostatnia aktualizacja: 15.08.2024 22:48:39 przez tukinem
16.08.2024 00:30
[#192]
Re: Ami Robbo 2
@Jacques, post #191
Będą lepsze. Na monitorek śmiało można nanieść AmiRobbo 1 jako że gra jest sequelem.
Ten pierwszy wyświetla 1128 kolorów już. Ten drugi ma 1090. No chyba, że ktoś może mi poleci jakiś lepszy konwerter z PNG do HAM?
Ciekawe, że pliki PNG o różnej kolorystyce konwertuję do IFF 320x200 HAM 6 i zawsze docelowy plik ma taki sam rozmiar co do bajta. Myślałem, że pliki IFF są kompresowane, a kompresja jest zawsze zależna od obrazka, chyba że HAM to już nie jest ILBM.
Ostatnia aktualizacja: 16.08.2024 00:32:26 przez tukinem
Ten pierwszy wyświetla 1128 kolorów już. Ten drugi ma 1090. No chyba, że ktoś może mi poleci jakiś lepszy konwerter z PNG do HAM?
Ciekawe, że pliki PNG o różnej kolorystyce konwertuję do IFF 320x200 HAM 6 i zawsze docelowy plik ma taki sam rozmiar co do bajta. Myślałem, że pliki IFF są kompresowane, a kompresja jest zawsze zależna od obrazka, chyba że HAM to już nie jest ILBM.
Ostatnia aktualizacja: 16.08.2024 00:32:26 przez tukinem
16.08.2024 00:49
[#193]
Re: Ami Robbo 2
@tukinem, post #192
Zdaje sie, ze moga byc kompresowane, ale zadna rewelacja to to nie jest, o ile pamietam.
Byl tez program do pakowania IFF-ow, zdaje sie, ze Beta Team, uzyl go w jakims slideshow.
No chyba, ze pomylilem nazwe grupy. Ale to zdaje sie byla polska grupa.
Jak chcesz pakowac IFF-y to mozesz uzyc ARJ7 albo ZX0, powinny ladnie je popakowac.
Byl tez program do pakowania IFF-ow, zdaje sie, ze Beta Team, uzyl go w jakims slideshow.
No chyba, ze pomylilem nazwe grupy. Ale to zdaje sie byla polska grupa.
Jak chcesz pakowac IFF-y to mozesz uzyc ARJ7 albo ZX0, powinny ladnie je popakowac.
16.08.2024 02:04
[#194]
Re: Ami Robbo 2
@Don_Adan, post #193
Pliki IFF ILBM mogą być skompresowane. Kompresja nazywa się cmpByteRun1 i polega na tym, że sąsiednie bajty o tej samej wartości są redukowane.
Być może takie obrazki HAM są słabo kompresowane. Dla pewności możesz załadować obrazek do swojego ulubionego Personal Paint, zapisać z włączoną kompresja i porównać rozmiary plików.
Co do Ami Robbo 2 - trzymam kciuki za prace nad tym fantastycznym projektem i finalizację.
Z tego co słyszałem Twój ElektroMan ma premierę pod koniec sierpnia. Nie mogę się doczekać pudełkowej wersji.
Ostatnia aktualizacja: 16.08.2024 02:06:08 przez Hexmage960
Być może takie obrazki HAM są słabo kompresowane. Dla pewności możesz załadować obrazek do swojego ulubionego Personal Paint, zapisać z włączoną kompresja i porównać rozmiary plików.
Co do Ami Robbo 2 - trzymam kciuki za prace nad tym fantastycznym projektem i finalizację.
Z tego co słyszałem Twój ElektroMan ma premierę pod koniec sierpnia. Nie mogę się doczekać pudełkowej wersji.
Ostatnia aktualizacja: 16.08.2024 02:06:08 przez Hexmage960
16.08.2024 02:48
[#195]
Re: Ami Robbo 2
@Hexmage960, post #194
Sorki, zapomniałem że Personal Paint nie wczytuje plików HAM.
Możesz jednak spróbować sprawdzić kompresję wczytując przykładowo do Deluxe Paint.
Photogenics też wczytuje pliki HAM, ale nie ma zapisu do tego formatu.
Zamiast tego zarówno Deluxe Paint 5 jak i Photogenics pracują na plikach IFF-24, gdzie zawarte jest pełne kodowanie kolorów, w formie bitplanów. Przydatne, bo niweluje to zniekształcenia HAM w pliku.
Ostatnia aktualizacja: 16.08.2024 03:01:53 przez Hexmage960
Możesz jednak spróbować sprawdzić kompresję wczytując przykładowo do Deluxe Paint.
Photogenics też wczytuje pliki HAM, ale nie ma zapisu do tego formatu.
Zamiast tego zarówno Deluxe Paint 5 jak i Photogenics pracują na plikach IFF-24, gdzie zawarte jest pełne kodowanie kolorów, w formie bitplanów. Przydatne, bo niweluje to zniekształcenia HAM w pliku.
Ostatnia aktualizacja: 16.08.2024 03:01:53 przez Hexmage960
16.08.2024 09:09
[#197]
Re: Ami Robbo 2
@c64portal, post #196
Ja polecam tandem Photogenics + Deluxe Paint 5, z tą różnicą że na pliku JPG (i pewnie też Windows BMP).
Wczytujesz obrazek JPG do Photogenics i zapisujesz jako IFF-24.
W Deluxe Paint 5 wczytujesz IFF-24 i zapisujesz w formie HAM6/8.
Poniżej jest ekran tytułowy w HAM6 z jednej z moich ulubionych gier Public Domain o tytule "Mech Fight" autorstwa Floriana Marquardta, zrzucony w Photogenics do JPG:
Ja mam to szczęście, że posiadam oba te programy na mojej Amidze 1200. Photogenics jeszcze z pakietu Magic, a Deluxe Paint 5 kupiłem kilka lat temu. Jeżeli będziesz potrzebował skonwertować obrazek to daj znać.
Wczytujesz obrazek JPG do Photogenics i zapisujesz jako IFF-24.
W Deluxe Paint 5 wczytujesz IFF-24 i zapisujesz w formie HAM6/8.
Poniżej jest ekran tytułowy w HAM6 z jednej z moich ulubionych gier Public Domain o tytule "Mech Fight" autorstwa Floriana Marquardta, zrzucony w Photogenics do JPG:
Ja mam to szczęście, że posiadam oba te programy na mojej Amidze 1200. Photogenics jeszcze z pakietu Magic, a Deluxe Paint 5 kupiłem kilka lat temu. Jeżeli będziesz potrzebował skonwertować obrazek to daj znać.
16.08.2024 10:12
[#198]
Re: Ami Robbo 2
@c64portal, post #196
ja w międzyczasie znalazłem to czego używałem kiedyś do zabawy w konwertowanie do HAM6
http://mrsebe.bplaced.net/blog/wordpress/?page_id=374
niezłe rezultaty
http://mrsebe.bplaced.net/blog/wordpress/?page_id=374
niezłe rezultaty
16.08.2024 11:08
[#199]
Re: Ami Robbo 2
@c64portal, post #196
Obecnie używam tego. Ma możliwość konwersji z dowolnego formatu do HAM 6 lub HAM 8, można dodać rozstrząsanie F-S, ale go nie używam. Może również przeskalować obrazek do danego rozmiaru.
Na EAB jest wątek o tym programiku.
@Hexmag960: Ja używam Brilliance. Nigdy nie próbowałem w nim zapisywać do HAM, ale wiem wiem, że obsługuje zarówno HAM 6, jak i HAM 8. Dla przykładu tutaj plik IFF zajmuje 48836 bajtów. 48000 rozumiem, że to bitmapa 6 bitplanów rozmiaru 320x200.
Tak pytam o to kompresowanie z czystej ciekawości, bo i tak w ADFie mam miejsce na to i nawet nie muszę jeszcze pakować pliku uruchamialnego.
Na EAB jest wątek o tym programiku.
@Hexmag960: Ja używam Brilliance. Nigdy nie próbowałem w nim zapisywać do HAM, ale wiem wiem, że obsługuje zarówno HAM 6, jak i HAM 8. Dla przykładu tutaj plik IFF zajmuje 48836 bajtów. 48000 rozumiem, że to bitmapa 6 bitplanów rozmiaru 320x200.
Tak pytam o to kompresowanie z czystej ciekawości, bo i tak w ADFie mam miejsce na to i nawet nie muszę jeszcze pakować pliku uruchamialnego.
23.08.2024 23:53
[#200]
Re: Ami Robbo 2
@tukinem, post #1
Dawno nie pisałem nic, co nowego słychać w produkcji, więc mały news.
Fabuła gry powstaje bardzo ładnie. Mamy 20 poziomów, z czego pierwsze 10 to Robbo z Atari, kolejne 10 to AmiRobbo 1. Ładnie wyświetlają się obrazki i napisy z rozwoju fabuły gry.
Do niedawna jeszcze gra działała na 0.5MB fast ram, ale niestety kod gry urósł i nie mam szans tego przeskoczyć. Skoro Amiga 500 z 0.5 MB chip ram wymaga 1MB Fast Ram, to w takim razie stwierdziłem, że trzeba grę urozmaicić. Do gry będą paczki DLC, czyli archiwa bądź ADFy z dodatkowymi poziomami oraz światami. Przykładowo gra uruchomiona z ADFa bądź z HDD będzie mogła sobie wczytać dodatkowe poziomy. Takie rozwiązanie pozwala na tworzenie nowych światów w grze poza główną rozgrywką.
W samej grze będzie w sumie 5 światów, co daje 50 leveli.
Zaimplementowałem pewne cheaty, ale również będą cheaty do odpalania konkretnego poziomu. Myślałem, żeby po przejściu danego levelu wyświetlać cheat odblokowujący kolejny, ale stwierdziłem, że będą ukryte tak, jak to miało miejsce w grach, do których cheaty odkrywało się dopiero czytając gazety komputerowe. Poza tym mamy tylu koderów, że pierwszy lepszy zdeasembluje kod i odczyta wszystkie tipsy w grze.
Zmieniłem w grze alokowanie dźwięków, których jest nawet sporo. Jeśli posiadamy fast ram, to dźwięki ładują się do fast ramu. Jeśli jedynie chip ram, no to wiadomo że wszystkie lądują w Chip ramie.
Wymagania dla gry to:
A500 0.5 chip ram + 1MB fast ram - gra bez muzyki
A500 1MB chip + 0.5 slow ram - gra z muzyką
A600 fabryczna - gra z muzyką
Fabuła gry powstaje bardzo ładnie. Mamy 20 poziomów, z czego pierwsze 10 to Robbo z Atari, kolejne 10 to AmiRobbo 1. Ładnie wyświetlają się obrazki i napisy z rozwoju fabuły gry.
Do niedawna jeszcze gra działała na 0.5MB fast ram, ale niestety kod gry urósł i nie mam szans tego przeskoczyć. Skoro Amiga 500 z 0.5 MB chip ram wymaga 1MB Fast Ram, to w takim razie stwierdziłem, że trzeba grę urozmaicić. Do gry będą paczki DLC, czyli archiwa bądź ADFy z dodatkowymi poziomami oraz światami. Przykładowo gra uruchomiona z ADFa bądź z HDD będzie mogła sobie wczytać dodatkowe poziomy. Takie rozwiązanie pozwala na tworzenie nowych światów w grze poza główną rozgrywką.
W samej grze będzie w sumie 5 światów, co daje 50 leveli.
Zaimplementowałem pewne cheaty, ale również będą cheaty do odpalania konkretnego poziomu. Myślałem, żeby po przejściu danego levelu wyświetlać cheat odblokowujący kolejny, ale stwierdziłem, że będą ukryte tak, jak to miało miejsce w grach, do których cheaty odkrywało się dopiero czytając gazety komputerowe. Poza tym mamy tylu koderów, że pierwszy lepszy zdeasembluje kod i odczyta wszystkie tipsy w grze.
Zmieniłem w grze alokowanie dźwięków, których jest nawet sporo. Jeśli posiadamy fast ram, to dźwięki ładują się do fast ramu. Jeśli jedynie chip ram, no to wiadomo że wszystkie lądują w Chip ramie.
Wymagania dla gry to:
A500 0.5 chip ram + 1MB fast ram - gra bez muzyki
A500 1MB chip + 0.5 slow ram - gra z muzyką
A600 fabryczna - gra z muzyką
24.08.2024 01:02
[#201]
Re: Ami Robbo 2
@tukinem, post #200
Nie za bardzo rozumiem, dlaczego na A600 fabrycznej, czyli z 1MB chip gra dziala, A500 z 1MB chip to za malo i potrzebne jest jeszcze 0.5MB slowfast. Wedlug mnie powinna dzialac tak samo na A600 i A500 z 1MB chip. A co do 0.5MB chip i 0.5MB slow fast to sprawdzales z "avail flush" na poczatku s-s?
24.08.2024 01:51
[#202]
Re: Ami Robbo 2
@Don_Adan, post #201
Zaraz... chyba zamieszałem za bardzo.
A600 fabryczna działa.
A500 z 512kB chip potrzebuje 1MB fast ramu.
A500 z 1MB chip ram bez niczego więcej też uruchomi grę.
Chodzi o to, że do chip ramu wędruje bardzo dużo danych, jeśli posiadamy tylko 0,5MB slow ram, lub wcale. Posiadając slow/fast ram jedynie SFXy z gry lądują w nim, a podczas odtwarzania kopiują się do sound banku 0. Jeśli nie posiadamy slow/fast ramu, to wszystkie SFXy (bodajże jest ich 8) lądują do kolejnych sound banków w chip ramie. Możliwe, że gra nie startuje na 0.5 chip + 0.5 slow, ponieważ próbuje wczytać SFXy do slow ramu, który jest już zapełniony kodem gry (300KB) + tablice + listy. Nie wiem na jakiej zasadzie działa systemowy AllocMem(size,4) - czy tworzy usilnie w slow/fast ramie blok pamięci, czy w razie braku miejsca tworzy go w chip ramie. W BB funkcja AllocMem przenosi do chip ramu w razie braku miejsca w fast/slow ramie, no ale AllocMem w BB jest zupełnie inny i dodaje kilkanaście kB biblioteki do kodu gry, dlatego go nie używam.
Ekrany HAM 6 zostają. Nie będę tu próbować nawet aby gra była kompatybilna z Amigą 1000 (chipset A1000 nie uruchomi tej gry) ze względu na to, że użyłem biblioteki Display. Amiga 1000 uruchamia jedynie bibliotekę Slice, co było przykładem w AmiSnake i będzie w TonyGO. O wiele łatwiej używa się biblioteki Display, bo nie muszę za każdym razem tworzyć od nowa "slice'ów", tylko tworzę na starcie dwie copperlisty (5-bitplanowa i HAM6) i przełączam je wedle wyboru. Kto zna Blitz Basic 2, ten wie o co chodzi. Rozmiarowo biblioteki są bardzo podobne względem siebie. Slice zajmuje około 2KB mniej od Display tylko.
W grze będą również użyte ekrany Intuition, na których wyświetlać się będzie file requester do wyboru paczki DLC z dodatkowym światem oraz napisy "INSERT GAME DISK" oraz "INSERT DLC DISK", no ale to już tylko w takim wypadku, gdy uruchomimy grę z ADFa, a paczkę DLC również będziemy ładować z ADFa. Można sobie jednak wybrać taki plik z twardego dysku bądź z drugiej stacji dyskietek.
Ostatnia aktualizacja: 24.08.2024 01:55:15 przez tukinem
A600 fabryczna działa.
A500 z 512kB chip potrzebuje 1MB fast ramu.
A500 z 1MB chip ram bez niczego więcej też uruchomi grę.
Chodzi o to, że do chip ramu wędruje bardzo dużo danych, jeśli posiadamy tylko 0,5MB slow ram, lub wcale. Posiadając slow/fast ram jedynie SFXy z gry lądują w nim, a podczas odtwarzania kopiują się do sound banku 0. Jeśli nie posiadamy slow/fast ramu, to wszystkie SFXy (bodajże jest ich 8) lądują do kolejnych sound banków w chip ramie. Możliwe, że gra nie startuje na 0.5 chip + 0.5 slow, ponieważ próbuje wczytać SFXy do slow ramu, który jest już zapełniony kodem gry (300KB) + tablice + listy. Nie wiem na jakiej zasadzie działa systemowy AllocMem(size,4) - czy tworzy usilnie w slow/fast ramie blok pamięci, czy w razie braku miejsca tworzy go w chip ramie. W BB funkcja AllocMem przenosi do chip ramu w razie braku miejsca w fast/slow ramie, no ale AllocMem w BB jest zupełnie inny i dodaje kilkanaście kB biblioteki do kodu gry, dlatego go nie używam.
Ekrany HAM 6 zostają. Nie będę tu próbować nawet aby gra była kompatybilna z Amigą 1000 (chipset A1000 nie uruchomi tej gry) ze względu na to, że użyłem biblioteki Display. Amiga 1000 uruchamia jedynie bibliotekę Slice, co było przykładem w AmiSnake i będzie w TonyGO. O wiele łatwiej używa się biblioteki Display, bo nie muszę za każdym razem tworzyć od nowa "slice'ów", tylko tworzę na starcie dwie copperlisty (5-bitplanowa i HAM6) i przełączam je wedle wyboru. Kto zna Blitz Basic 2, ten wie o co chodzi. Rozmiarowo biblioteki są bardzo podobne względem siebie. Slice zajmuje około 2KB mniej od Display tylko.
W grze będą również użyte ekrany Intuition, na których wyświetlać się będzie file requester do wyboru paczki DLC z dodatkowym światem oraz napisy "INSERT GAME DISK" oraz "INSERT DLC DISK", no ale to już tylko w takim wypadku, gdy uruchomimy grę z ADFa, a paczkę DLC również będziemy ładować z ADFa. Można sobie jednak wybrać taki plik z twardego dysku bądź z drugiej stacji dyskietek.
Ostatnia aktualizacja: 24.08.2024 01:55:15 przez tukinem
24.08.2024 02:20
[#203]
Re: Ami Robbo 2
@Don_Adan, post #201
Jeszcze co do "avail flush". Gra przestała startować na 0,5 chip + 0,5 slow, gdy kod gry urósł z 250KB do 280 KB. Obecnie przekroczyłem 300KB i to dalej jest jakieś 95% kodu ostatecznego. Myślę, że dojdzie jeszcze maksymalnie 30KB. No niestety basic nie jest asemblerem i nie patrzy na ilość, jaką ładuje, a ja akurat tych rzeczy nie ogarnę asemblerem. Może funkcje ładujące pliki (BLoad) mógłbym zastąpić systemowymi, co odchudziłoby kod gry, ale zawsze staram się ograniczać ich użycie ze względu na to, że gra musi działać pod kickstartem 1.2/1.3, a nie tylko na 3.0+.
24.08.2024 09:36
[#204]
Re: Ami Robbo 2
@tukinem, post #192
No chyba, że ktoś może mi poleci jakiś lepszy konwerter z PNG do HAM?
Warto spróbować RetroPic, napisany w Javie więc win/linux:
https://github.com/marlow75/retropic
24.08.2024 09:39
[#205]
Re: Ami Robbo 2
@tukinem, post #203
Bez muzyki powinna dzialac na A500 0.5MB chip i 0.5 MB slow.
Skoro z muzyka dziala na 1MB chip.
Najpewniej jest jakis blad w alokacji pamieci.
link
Ilosc wolnej pamieci jest podobna dla 1MB chip i dla 0,5MB chip + 0,5MB slow, okolo 870kB.
Byc moze alokujesz pamiec na muzyke, nawet jak jej nie uzywasz.
Chyba, ze alokujesz 1 duzy blok pamieci na dane wtedy beda problemy jesli to nie jest 1MB chip, bo to jest pamiec ciagla.
Lepiej podziel to na 2-3 mniejsze bloki pamieci.
Masz okolo 420kB wolnego slow fastu na starcie.
420-280= 140kB
Jak teraz zaalokujesz np. 150 kB slow fastu w jednym bloku to nie bedzie pamieci.
Ale jak zaalokujesz 100kB + 50kB to bedzie, bo system zaalokuje chip jako drugi blok.
Najlepiej sobie debug wersje zrob, ktora wypluwa na ekran lub po wyjsciu, ile alokujesz pamieci a ile masz wolnej.
Skoro z muzyka dziala na 1MB chip.
Najpewniej jest jakis blad w alokacji pamieci.
link
Ilosc wolnej pamieci jest podobna dla 1MB chip i dla 0,5MB chip + 0,5MB slow, okolo 870kB.
Byc moze alokujesz pamiec na muzyke, nawet jak jej nie uzywasz.
Chyba, ze alokujesz 1 duzy blok pamieci na dane wtedy beda problemy jesli to nie jest 1MB chip, bo to jest pamiec ciagla.
Lepiej podziel to na 2-3 mniejsze bloki pamieci.
Masz okolo 420kB wolnego slow fastu na starcie.
420-280= 140kB
Jak teraz zaalokujesz np. 150 kB slow fastu w jednym bloku to nie bedzie pamieci.
Ale jak zaalokujesz 100kB + 50kB to bedzie, bo system zaalokuje chip jako drugi blok.
Najlepiej sobie debug wersje zrob, ktora wypluwa na ekran lub po wyjsciu, ile alokujesz pamieci a ile masz wolnej.
24.08.2024 10:39
[#206]
Re: Ami Robbo 2
@Don_Adan, post #205
Mając 1MB chip ciągłej pamięci wystartuje łącznie z muzyką.
Mając przerywany 1MB gdzie 0,5MB to chip ram, a 0,5MB to slow ram, już nie wystartuje.
Może ma problem z podzieleniem pewnych bloków pamięci tak, aby weszły odpowiednio. Przykładowo plik uruchamialny ładuje do slow ram, tworzy bufor ponad 300KB aby wypakować go, następnie usuwa ten spakowany plik. Ładuje plik binarny z napisami do CLI oraz ewentualnie muzykę jeśli mamy 1MB chip ram. Później przechodzi w tryb BLITZ, wyświetla ekran HAM, a po wciśnięciu FIRE czyści bitmapę HAM 6-bitplanową i na jej miejsce tworzy bitmapę 512x512 w 5 bitplanach. To jeszcze przechodzi, ale przy tworzeniu bitmapy rozmiaru 1456x32 w 5 bitplanach już zdycha. W tej bitmapie są znaki ASCII do menu głównego. No nie będę się nad tym rozczulać. Wcześniej działało na 0,5+ 0,5 póki kod gry nie urósł. A jeszcze urośnie, dlatego nie przejmuję się tamtym konfigiem, bo i tak docelowo gra nie miała być dla "RED LED'ów".
Narazie tak to wygląda na gołej A600 bez przyspieszeń:
Jak tylko to dopieszczę, to wrzucę wersję 0.4 na itch.
Ostatnia aktualizacja: 24.08.2024 10:40:35 przez tukinem
Mając przerywany 1MB gdzie 0,5MB to chip ram, a 0,5MB to slow ram, już nie wystartuje.
Może ma problem z podzieleniem pewnych bloków pamięci tak, aby weszły odpowiednio. Przykładowo plik uruchamialny ładuje do slow ram, tworzy bufor ponad 300KB aby wypakować go, następnie usuwa ten spakowany plik. Ładuje plik binarny z napisami do CLI oraz ewentualnie muzykę jeśli mamy 1MB chip ram. Później przechodzi w tryb BLITZ, wyświetla ekran HAM, a po wciśnięciu FIRE czyści bitmapę HAM 6-bitplanową i na jej miejsce tworzy bitmapę 512x512 w 5 bitplanach. To jeszcze przechodzi, ale przy tworzeniu bitmapy rozmiaru 1456x32 w 5 bitplanach już zdycha. W tej bitmapie są znaki ASCII do menu głównego. No nie będę się nad tym rozczulać. Wcześniej działało na 0,5+ 0,5 póki kod gry nie urósł. A jeszcze urośnie, dlatego nie przejmuję się tamtym konfigiem, bo i tak docelowo gra nie miała być dla "RED LED'ów".
Narazie tak to wygląda na gołej A600 bez przyspieszeń:
Jak tylko to dopieszczę, to wrzucę wersję 0.4 na itch.
Ostatnia aktualizacja: 24.08.2024 10:40:35 przez tukinem
24.08.2024 11:48
[#207]
Re: Ami Robbo 2
@tukinem, post #199
Obecnie używam tego.
Najgorsza możliwa opcja. Absolutnie nie używaj. Ten program nawet HAM8 nie potrafi dobrze wyrenderować. On generuje szarą paletę co nie daje optymalnych rezultatów. Działa podobnie jak ten z zestawu NetPBM, czyli źle. Dobrych konwerterów jest całkiem sporo np. ham_convert, abc2, większe programy typu ImageFX, ADpro. Nie polecam też png2ilbm (do HAM6, do HAM8 jest okey), sview5. Programy typu Brilliance czy DPaint nie używają ditheringu, więc ich użyteczność jest niepełna.
24.08.2024 11:52
[#208]
Re: Ami Robbo 2
@tukinem, post #206
Tylko to powinno dzialac na takim konfigu bo masz 456 kB wolnego chipu, i jezeli nigdzie nie przekraczasz tej wartosci to wszystko powinno sie zmiescic.
450 (wolny chip)+280 (kod gry)=730 kB
Jest wolnego na starcie 870kB, czyli masz 140kB wiecej.
Nie wiem, ile muzyka zajmuje, ale powiedzmy 100kB.
To dla 1MB chip masz jeszcze 40kB wolnej pamieci.
A dla 0.5MB chip i 0.5MB fast 140kB wolnej pamieci, wersja bez muzyki.
Jedynie jak nie uzywasz "avail flush" w s-s to bedziesz mial duzo mniej pamieci dla kicku 3.2.
Bo system na starcie nie zwalnia niektorych zasobow.
Ale dla kicka 1.3 to jest az 940 kB wolnej pamieci.
link
Byc moze pamiec chip sie fragmentuje.
Wtedy mozesz sprobowac zrobic tak.
Zaalokowac na starcie (tylko raz) 400-450 kB chip.
I po prostu go wykorzystywac wedlug swoich potrzeb.
Czyli kopiowac/czyscic wskazane obszary chipu.
Zreszta zrobisz jak uwazasz, ale jezeli w zadnym momencie gra (bez muzyki) nie potrzebuje na raz wiecej niz 400-450kB chipu to powinna dzialac.
450 (wolny chip)+280 (kod gry)=730 kB
Jest wolnego na starcie 870kB, czyli masz 140kB wiecej.
Nie wiem, ile muzyka zajmuje, ale powiedzmy 100kB.
To dla 1MB chip masz jeszcze 40kB wolnej pamieci.
A dla 0.5MB chip i 0.5MB fast 140kB wolnej pamieci, wersja bez muzyki.
Jedynie jak nie uzywasz "avail flush" w s-s to bedziesz mial duzo mniej pamieci dla kicku 3.2.
Bo system na starcie nie zwalnia niektorych zasobow.
Ale dla kicka 1.3 to jest az 940 kB wolnej pamieci.
link
Byc moze pamiec chip sie fragmentuje.
Wtedy mozesz sprobowac zrobic tak.
Zaalokowac na starcie (tylko raz) 400-450 kB chip.
I po prostu go wykorzystywac wedlug swoich potrzeb.
Czyli kopiowac/czyscic wskazane obszary chipu.
Zreszta zrobisz jak uwazasz, ale jezeli w zadnym momencie gra (bez muzyki) nie potrzebuje na raz wiecej niz 400-450kB chipu to powinna dzialac.
24.08.2024 12:11
[#209]
Re: Ami Robbo 2
@Don_Adan, post #208
Nie mogę na starcie zaalokować sobie pamięci w chip na wszystko. Ja piszę w basicu a nie w asemblerze i moje funkcje z basica muszą współgrać. Nie zaalokuję sobie ręcznie np. wskaźnika bitplanów do struktury bitmapy. To jest tylko basic. Używając funkcji Bitmap basic sam alokuje pamięć w chip ramie. Następnie CreateDisplay umieszcza wskaźniki bitplanów dla coppera. Funkcjami Blit/BBlit wstawiam grafiki. To wszystko jest połączone. Nic mi nie da ręcznie stworzenie bufora pamięci bo tego nie połączę z komendami BB. To tak nie będzie działać.
Tamten filmik nie był w 50 FPS więc wrzucam tu nowy, tylko mi konwerter na początku rozciągnął obraz:
Nie będę więcej drążyć tematu tych biednych konfiguracji 0,5+0,5. I tak nikt tego nie używa, chyba że dla szpanu. Już się namęczyłem przy TonyGO żeby to upchać w 256KB chip. AmiRobbo 2 ma być rozwiniętą grą a nie bidą w stylu 80's.
Przetestuję te konwertery do HAM o których tu pisano.
Tamten filmik nie był w 50 FPS więc wrzucam tu nowy, tylko mi konwerter na początku rozciągnął obraz:
Nie będę więcej drążyć tematu tych biednych konfiguracji 0,5+0,5. I tak nikt tego nie używa, chyba że dla szpanu. Już się namęczyłem przy TonyGO żeby to upchać w 256KB chip. AmiRobbo 2 ma być rozwiniętą grą a nie bidą w stylu 80's.
Przetestuję te konwertery do HAM o których tu pisano.
