22.07.2024 13:00
[#121]
Re: Ami Robbo 2
@Cezarykl, post #120
Pomyślałem że zrezygnuję z HAM i wstawię z powrotem tamten ekran w 5 bitplanach. Okazuje się że on też się wykrzacza na OCS. Gra startuje na 1MB Chip. Przy OCS się wykrzacza, jakby źle ładował bank grafik. Przy ECS jest prawidłowo. Czy OCS naprawdę jest tak ograniczony?
22.07.2024 13:12
[#123]
Re: Ami Robbo 2
@cholok, post #110
Testowałem na winuae amirobbo2 0.3 i to nie chodzi na 0,5 MB chip + 0,5 slow => zwis. Na 1 MB chip OCS =?>sieczka na ekranie. Na 1 MB chip ECS działa. Nie wiem jak działa winuae, ale normalnie OCS nie obsługuje 1 MB chip i więcej. Tak samo OCS Agnus i ECS Denise nie występują naturalnie w przyrodzie. Także proponuję ustawianie konfiguracji w sekcji quick configuration a nie wymyślanie swoich.
Co do allocmem to widzę, że nie sprawdzasz czy alokacja się dokonała. Jeśli kompilujesz z debugerem to raczej ok, ale jęśli bez to wiesz co się dzieje jak zabraknie pamięci.
Teraz dopiero odczytałem to, co napisałeś i to mnie cieszy. Skoro OCS nie może mieć 1MB CHIP, to w takim razie gra po prostu będzie wymagać ECS Agnus, czyli minimum Amiga 500+ / Amiga 600 / Amiga 2000.
Ale WIKIPEDIA mówi, że w OCS występował FAT Agnus (1MB) i Super Agnus (2MB).
Ostatnia aktualizacja: 22.07.2024 13:13:01 przez tukinem
22.07.2024 13:36
[#125]
Re: Ami Robbo 2
@tukinem, post #121
To jest tak napisał cholok w poście #110.
A powód wykrzaczania jest według mnie taki, będzię technicznie.
OCS Agnus (8370) używa 19 bitów (w zasadzie 18 bitów bo bit 0 jest pomijany i stąd musi być wszystko podzielne przez 2) , 2 ^ 19 = 512 kilobajtów. Jeśli coś ładujesz powyżej tego obszaru bądź przekracza w jakiś sposób adres $7ffff to blitter zwyczajnie w tym przypadku ignoruje wyższe bity na przykład w bltXpt (x = a,b,c,d) (popatrz na opis na przykład BPL1PTH i BPL1PTL link masz napisane low 15 bits i high 3 bits) i robi się zwyczajnie kaszanka (łącznie ze zwisem jak wejdziesz na adresy gdzie są wektory przerwań), bo jest wtedy inny adres.
Zauważ że może to powodować bardzo nieciekawe błędy, które mogą się pojawić tylko czasami, w zależności od tego, kiedy chcesz wykonać operacje bliterem powyżej $7ffff. Masz i tak dużo szczęścia, bo efekty tego błędu widzisz na ekranie a co by było gdybyś kopiował sobie nieduże bloki pamięci i by to działo się w innych obszarach niż ekran ?
Zatem jeśli celujesz w OCS to przede wszystkim musisz być pewny że dane które leżą w CHIP nie przekraczają adresu $7ffff, chodzi o to że jak coś ładujesz pod $78000 to żeby nie przekroczyło $7ffff. Bo co z tego że masz pamięć skonfigurowaną jako CHIP powyżej $80000 skoro układ Agnus 8370 nie ogarnie tego.
Stąd też propozycja Don Adana by przejąć całkowicie zarządzanie nad pamięcią. Co pewnie nie do końca jest możliwe w przypadku Blitz, ale mogę się mylić bo jestem waflem z Blitza.
A powód wykrzaczania jest według mnie taki, będzię technicznie.
OCS Agnus (8370) używa 19 bitów (w zasadzie 18 bitów bo bit 0 jest pomijany i stąd musi być wszystko podzielne przez 2) , 2 ^ 19 = 512 kilobajtów. Jeśli coś ładujesz powyżej tego obszaru bądź przekracza w jakiś sposób adres $7ffff to blitter zwyczajnie w tym przypadku ignoruje wyższe bity na przykład w bltXpt (x = a,b,c,d) (popatrz na opis na przykład BPL1PTH i BPL1PTL link masz napisane low 15 bits i high 3 bits) i robi się zwyczajnie kaszanka (łącznie ze zwisem jak wejdziesz na adresy gdzie są wektory przerwań), bo jest wtedy inny adres.
Zauważ że może to powodować bardzo nieciekawe błędy, które mogą się pojawić tylko czasami, w zależności od tego, kiedy chcesz wykonać operacje bliterem powyżej $7ffff. Masz i tak dużo szczęścia, bo efekty tego błędu widzisz na ekranie a co by było gdybyś kopiował sobie nieduże bloki pamięci i by to działo się w innych obszarach niż ekran ?
Zatem jeśli celujesz w OCS to przede wszystkim musisz być pewny że dane które leżą w CHIP nie przekraczają adresu $7ffff, chodzi o to że jak coś ładujesz pod $78000 to żeby nie przekroczyło $7ffff. Bo co z tego że masz pamięć skonfigurowaną jako CHIP powyżej $80000 skoro układ Agnus 8370 nie ogarnie tego.
Stąd też propozycja Don Adana by przejąć całkowicie zarządzanie nad pamięcią. Co pewnie nie do końca jest możliwe w przypadku Blitz, ale mogę się mylić bo jestem waflem z Blitza.
22.07.2024 13:55
[#126]
Re: Ami Robbo 2
@asman, post #125
W Blitzu można wszystko, ale gdybym ładował dane (grafika+muzyka+tworzenie ręczne copperlisty), to musiałbym zrezygnować z bibliotek rysujących. Wtedy nie byłoby sensu pisać w Blitzu.
Masz rację, że przekraczam adresowanie pamięci, bo gra na 0,5MB chip ram nie ruszy, choćby Amiga miała 8MB Fastu. Jak pisałem na początku muszę dla gry stworzyć dwie bitmapy 5-bitplanowe o rozmiarze 512x512 pikseli, więc to już pożera 300KB. Nie ogarnę w inny sposób scrolla, jak użycie dużych bitplanów raz narysowanych i przesuwanych na copperliście. Przy menu gry dochodzi bitmapa 1456x32 5-bitplanowa, z której wklejane są znaki ASCII w menu gry. Muzyka + narazie 1 dźwięk też coś tam dokłada, bank shapów z grafikami to samo i już jest przekroczenie tego magicznego 0,5 MB.
To jak to jest z tymi Agnusami? Według Wikipedii OCS posiadał zarówno Agnusa, jak i FAT Agnusa (1 MB) oraz Super Agnusa (2 MB).
Według WinUAE Amigi 500 miały takie konfiguracje:
Dostałem właśnie grafikę startową i nie potrzeba ekranu HAM:
Nawet bez przełączania trybu graficznego wywalało się, bo faktycznie przekraczałem pamięć.
Ostatnia aktualizacja: 22.07.2024 14:11:02 przez tukinem
Masz rację, że przekraczam adresowanie pamięci, bo gra na 0,5MB chip ram nie ruszy, choćby Amiga miała 8MB Fastu. Jak pisałem na początku muszę dla gry stworzyć dwie bitmapy 5-bitplanowe o rozmiarze 512x512 pikseli, więc to już pożera 300KB. Nie ogarnę w inny sposób scrolla, jak użycie dużych bitplanów raz narysowanych i przesuwanych na copperliście. Przy menu gry dochodzi bitmapa 1456x32 5-bitplanowa, z której wklejane są znaki ASCII w menu gry. Muzyka + narazie 1 dźwięk też coś tam dokłada, bank shapów z grafikami to samo i już jest przekroczenie tego magicznego 0,5 MB.
To jak to jest z tymi Agnusami? Według Wikipedii OCS posiadał zarówno Agnusa, jak i FAT Agnusa (1 MB) oraz Super Agnusa (2 MB).
Według WinUAE Amigi 500 miały takie konfiguracje:
Dostałem właśnie grafikę startową i nie potrzeba ekranu HAM:
Nawet bez przełączania trybu graficznego wywalało się, bo faktycznie przekraczałem pamięć.
Ostatnia aktualizacja: 22.07.2024 14:11:02 przez tukinem
22.07.2024 14:23
[#127]
Re: Ami Robbo 2
@tukinem, post #126
W Blitzu można wszystko, ale gdybym ładował dane (grafika+muzyka+tworzenie ręczne copperlisty), to musiałbym zrezygnować z bibliotek rysujących. Wtedy nie byłoby sensu pisać w Blitzu.
To już zależy od Ciebie. A możesz policzyć z ilu rzeczy korzystasz w Blitzu i powolutku tworzć bazę własnych funkcji. Wtedy będziesz miał większą kontrolę i zbliżysz się bardziej do tworzenia w asm/c. :)
Masz rację, że przekraczam adresowanie pamięci, bo gra na 0,5MB chip ram nie ruszy, choćby Amiga miała 8MB Fastu.
Mnie uczono tak, że mimo że w instrukcji jest napisane że gra wymaga 1MB chip to program/gra powinna wywalić komunikat że gra nie ruszy na maszynie z 0.5MB chip. Bo ja na przykład czytam instrukcję dopiero jak gra się wywali.
Według Wikipedii OCS posiadał zarówno Agnusa, jak i FAT Agnusa (1 MB) oraz Super Agnusa (2 MB).
Ja to nawet kompilatorowi nie ufam a gdzie tu Wikipedia :).
Edit: Grafika mi się podoba.
Ostatnia aktualizacja: 22.07.2024 14:25:01 przez asman
22.07.2024 15:07
[#129]
Re: Ami Robbo 2
@asman, post #127
Czyli rozumiem, że blokada sprawdzająca ilość pamięci chip ram. Dodatkowo bym dodał sprawdzanie czy użytkownik posiada ECS Agnus. To tylko chyba sprawdzenie konkretnych bitów starszego bajtu pod rejestrem $DFF004, więc bez problemu można tym sposobem wyeliminować tych co spróbują uruchomić na emulatorze tak jak ja próbowałem i poległem.
22.07.2024 15:31
[#133]
Re: Ami Robbo 2
@Don_Adan, post #130
Napisałem, że tu nie ma szans na uruchomienie na 0.5+0.5. Chip ramu potrzeba ponad 512 KB, więc Amiga z ECS Agnus posiadająca minimum 1MB chip ram. Nie zrobię scrolla z dorysowywaniem kafli, dlatefo stworzyłem bitmapy 512x512 pikseli które zajmują ponad 300KB. Kolejność alokowania pamięci nie ma znaczenia, chociaż mam to alokowane tak, jak piszesz. Same bitplany gry to 327KB. Muzyka ze 100 KB, dźwięki, bank ponad 100 shapów (grafik), bank sprajtów i mamy przekroczony chip ram.
Dlatego pytam jak najlepiej napisać sprawdzanie czy program da radę się uruchomić na starcie. Czy sprawdzać tylko wolną pamięć chip ram licząc że nikt nie użyje OCS z 1MB na winuae, czy też sprawdzać bajt spod adresu $DFF004 jaki chipset ma dana konfiguracja.
@AD99: i to jest OCS czy już ECS?
Ostatnia aktualizacja: 22.07.2024 15:32:40 przez tukinem
Dlatego pytam jak najlepiej napisać sprawdzanie czy program da radę się uruchomić na starcie. Czy sprawdzać tylko wolną pamięć chip ram licząc że nikt nie użyje OCS z 1MB na winuae, czy też sprawdzać bajt spod adresu $DFF004 jaki chipset ma dana konfiguracja.
@AD99: i to jest OCS czy już ECS?
Ostatnia aktualizacja: 22.07.2024 15:32:40 przez tukinem
22.07.2024 16:00
[#136]
Re: Ami Robbo 2
@Don_Adan, post #131
Ograniczenie do 19 bitów (18 jeśli nie liczymy bitu 0) dotyczy też niestety pauli, widać to w tym linku, gdzie masz na przykład
Ale ogólnie uważam podobnie albo i nawet tak samo :). Dane do blittera i grafiki (o ile chcesz wszystko przewalać blitterem, czasem się nie opłaca) najpierw. Pozwala to na uruchomienie gry bez sfx/mus jeśli jest za mało pamięci CHIP i elegancko rozwiązuje problem malkotentów, czemu ta gra nie działa na 0.5 MB CHIP. Wtedy jest odpowiedź: działa ale nie miejsca na sfx/mus.
Ostatnia aktualizacja: 22.07.2024 16:03:10 przez asman
AUD0LCH + 0A0 W A( E ) Audio channel 0 location (high 3 bits, 5 if ECS) AUD0LCL + 0A2 W A Audio channel 0 location (low 15 bits)
Ale ogólnie uważam podobnie albo i nawet tak samo :). Dane do blittera i grafiki (o ile chcesz wszystko przewalać blitterem, czasem się nie opłaca) najpierw. Pozwala to na uruchomienie gry bez sfx/mus jeśli jest za mało pamięci CHIP i elegancko rozwiązuje problem malkotentów, czemu ta gra nie działa na 0.5 MB CHIP. Wtedy jest odpowiedź: działa ale nie miejsca na sfx/mus.
Ostatnia aktualizacja: 22.07.2024 16:03:10 przez asman
22.07.2024 16:29
[#138]
Re: Ami Robbo 2
@asman, post #136
Ja moduly muzyczne testowalem na 1MB chip ECS i dzialaly, nie mialem nigdy Amigi z OCS.
Ale faktycznie wersja bez muzyki jest najlepsza w takim razie dla AmiRobbo 2.
Swoja droga to dodatkowo wyjasnia dlaczego gry Amigowe, zabijaly system i przejmowaly kontrole nad wczytywaniem danych.
Po prostu dane typu grafika i muzyka musialy byc w obszarze do $80000.
Ale faktycznie wersja bez muzyki jest najlepsza w takim razie dla AmiRobbo 2.
Swoja droga to dodatkowo wyjasnia dlaczego gry Amigowe, zabijaly system i przejmowaly kontrole nad wczytywaniem danych.
Po prostu dane typu grafika i muzyka musialy byc w obszarze do $80000.
22.07.2024 16:30
[#140]
Re: Ami Robbo 2
@tukinem, post #137
Wiesz, w WinUAE, mozesz ustawic rozne dziwne konfigi, niektore dzialaja a niektore juz nie.
Edycja.
Przejmowac to sie powinienes tylko REALNYMI AMIGAMI i ich konfigiem.
A nie WinUAE.
W WinUAE konfig mozesz sobie latwo zmienic.
W realu to juz takie proste nie jest.
Ostatnia aktualizacja: 22.07.2024 16:38:33 przez Don_Adan
Edycja.
Przejmowac to sie powinienes tylko REALNYMI AMIGAMI i ich konfigiem.
A nie WinUAE.
W WinUAE konfig mozesz sobie latwo zmienic.
W realu to juz takie proste nie jest.
Ostatnia aktualizacja: 22.07.2024 16:38:33 przez Don_Adan
22.07.2024 17:35
[#144]
Re: Ami Robbo 2
@tukinem, post #133
hej
piszesz że ekran 512x512 to 327 kilo bo rozumiem że liczysz podwojne buforowanie?
ja bym olał podwójne buforowanie bo tu wg mnie nie będzie potrzebne. tzn ja w BB bym zaczął to robić bez podwójnego bufora i zobaczyl czy bedzie potrzebny dopiero potem jak bedziesz animowal obiekty na ekranie. a bez drugiego byfora to masz jakieś 167 kilo (z grubsza licząc). zrobił bym też tak jak piszą inni zaalokował sobie na początku obszar na największy możliwy obszar pamięci powiedzmy te ~167 kilo i używał go do wyswietlania wszystkich grafik używając w BB komendy CludgeBitmap.
muze jak poprosisz zdolnego muzyka to ci zmieści w 70 +/- 10 kb.
resztę jak intro , game over, itp możesz doczytywać
piszesz że ekran 512x512 to 327 kilo bo rozumiem że liczysz podwojne buforowanie?
ja bym olał podwójne buforowanie bo tu wg mnie nie będzie potrzebne. tzn ja w BB bym zaczął to robić bez podwójnego bufora i zobaczyl czy bedzie potrzebny dopiero potem jak bedziesz animowal obiekty na ekranie. a bez drugiego byfora to masz jakieś 167 kilo (z grubsza licząc). zrobił bym też tak jak piszą inni zaalokował sobie na początku obszar na największy możliwy obszar pamięci powiedzmy te ~167 kilo i używał go do wyswietlania wszystkich grafik używając w BB komendy CludgeBitmap.
muze jak poprosisz zdolnego muzyka to ci zmieści w 70 +/- 10 kb.
resztę jak intro , game over, itp możesz doczytywać
22.07.2024 17:45
[#145]
Re: Ami Robbo 2
@c64portal, post #144
Właśnie teraz pozmieniałem na doczytywanie danych. Dodałem sprawdzanie dostępnej pamięci i w razie braku chip ram nie wczytuje muzyki, bo po wczytaniu się wieszał na niskim chip ramie.
Ogólnie teraz gra działa nawet na OCS z 0.5 MB Chip RAM + 1 MB Fast. Niestety, ale pozmieniało się sporo i 1MB fast jest zawsze wymagany, nawet jeśli mamy 1MB Chip.
CludgeBitmap nigdy nie używałem.
Ogólnie teraz gra działa nawet na OCS z 0.5 MB Chip RAM + 1 MB Fast. Niestety, ale pozmieniało się sporo i 1MB fast jest zawsze wymagany, nawet jeśli mamy 1MB Chip.
CludgeBitmap nigdy nie używałem.
22.07.2024 19:05
[#147]
Re: Ami Robbo 2
@tukinem, post #145
Nie wiem po co Ci ten 1 MB fast.
0,5 MB fast jest wystarczajace wedlug mnie
Zrob sobie test wersje, ktora bedzie na dole (ponizej ekranu gry) wyswietlala ilosc dostepnej pamieci chip i fast.
Wywoluj taka procedure raz na sekunde lub rzadziej np. po alokacji/zwolnieniu pamieci tylko.
Niektorzy koderzy tak sobie robia, zeby wiedziec na czym stoja jak tworza gre.
0,5 MB fast jest wystarczajace wedlug mnie
Zrob sobie test wersje, ktora bedzie na dole (ponizej ekranu gry) wyswietlala ilosc dostepnej pamieci chip i fast.
Wywoluj taka procedure raz na sekunde lub rzadziej np. po alokacji/zwolnieniu pamieci tylko.
Niektorzy koderzy tak sobie robia, zeby wiedziec na czym stoja jak tworza gre.
22.07.2024 19:42
[#150]
Re: Ami Robbo 2
@Don_Adan, post #147
Tworzenie drugiej bitmapy 512x512 przekracza fast ram. Podejrzewam że chodzi o samą strukturę. Sprawdziłem linijka po linijce i po zwolnieniu pamięci bitmap wykorzystywanych przez menu gry jeszcze było ok, dopóki nie stworzyłem drugiej bitmapy dla podwójnego buforowania. Nie ma sensu kombinować, bo w kodzie znajdują się listy dynamiczne i jeśli one będą rosnąć, to również będzie bardzo łatwo przekroczyć pamięć. Skoro samo alokowanie pamięci już przekracza te 0.5MB to nie ma sensu tego ograniczać a jak wiadomo Blitz jest basiciem i swoje dane z bitmap również dołącza do fast ramu.
Gra teraz śmiga na 0.5 MB Chip + 1 MB Fast i tak niech zostanie. Na upartego red ledowcy uruchomią jeśli sobie dodadzą fast ram. Kod sprawdza na starcie czy mam powyżej 600KB Fastu. Jeśli nie, to gra wywali komunikat i się wylączy. Sprawdza również chip ram. Jeżeli jest powyżej 500 000, to załaduje muzykę. Jeśli nie, to nie ma nawet możliwości podczas gry wciśnięcia klawisza M. OCS / ECS działa tak samo. Uporządkowałem kolejność, bo przy aktywowaniu nowej copperlisty było mruganie ekranu. Teraz ładnie się przełącza z copperlisty wysokiej na 200 pikseli do copperlisty na 176 pikseli.
Gra teraz śmiga na 0.5 MB Chip + 1 MB Fast i tak niech zostanie. Na upartego red ledowcy uruchomią jeśli sobie dodadzą fast ram. Kod sprawdza na starcie czy mam powyżej 600KB Fastu. Jeśli nie, to gra wywali komunikat i się wylączy. Sprawdza również chip ram. Jeżeli jest powyżej 500 000, to załaduje muzykę. Jeśli nie, to nie ma nawet możliwości podczas gry wciśnięcia klawisza M. OCS / ECS działa tak samo. Uporządkowałem kolejność, bo przy aktywowaniu nowej copperlisty było mruganie ekranu. Teraz ładnie się przełącza z copperlisty wysokiej na 200 pikseli do copperlisty na 176 pikseli.