24.08.2024 14:40
[#212]
Re: Ami Robbo 2
@tukinem, post #211
Dźwięki jak i muzyka początkowa są dobre, tylko że do takiej furtki dźwięk zardzewiałego zawiasu, czy dźwięk przekręcanego klucza w zamku tych drzwi prosi się o odegranie. Ale to tylko drobny szczegół, który mi nie pasował do całości. Reszta gry jest jak najbardziej wzorowa.
24.08.2024 16:58
[#219]
Re: Ami Robbo 2
@tukinem, post #209
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ć
Nieprawda. Wiele razy pisałem Ci o CludgeBitmap (i podobne funkcje z rodzaju Cludge). Ty wiele razy odpowiadałeś, że tego nie używasz. Ale to nie znaczy że się nie da.
Poza tym da się dowolnie wpływać i ustawiać adresy bitplanów w bitmapie (zobacz przykłady Earoka). Da się raz zaallokować wielki obszar w Chip RAM i samemu pilnować pod jakie adrey ram wczytywać. Da się usuwać sample i wczytywać nowe, da się wiele rzeczy bo BB2 w odróżnieniu od AMOSa jest bardzo elastyczny.
Mam wrażenie że ostatnio idziesz w ilość a nie w jakość, ale nic mi do tego. Każdy bawi się w retro tak jak lubi.
I żeby nie było tylko negatywnego wydźwięku to powiem, że zainspirowałeś mnie tym wątkiem i sam zacząłem pisać swoją wersję gry typu Robbo/Laura ale na .... Commodore +4. Zobaczymy co mi z tego wyjdzie.
24.08.2024 18:57
[#220]
Re: Ami Robbo 2
@c64portal, post #219
CludgeBitmap jest dodatkową biblioteką w Blitz Basic. Może i masz rację, ale dodając jakąkolwiek funkcję z tej biblioteki automatycznie kod gry zwiększy się znowu o tą bibliotekę. Nie jestem scenowcem i nie będę aż tak kombinować. Nie drążyłem tego jak copperliście tworzonoej przez InitCoplist ustawić bitplany ręcznie tworzone.
Wątpię czy po utworzeniu bitmapy przez AllocMem uda Ci się użyć komendy Use Bitmap, czy Blit/Bblit/Block. Chyba raczej nie. Moim zdaniem nie ma szans aby odpalić grę na 0.5+0.5. Nie w takim rozmiarze. 320KB to same bitplany, 300KB to plik exe, dźwięki to 100KB. Do tego bank shapów, bitplany dolnej belki, czy moduł to już duperele, ale suma sumarum przekroczy pamięć. A600 odpala bo tam jest ciągłość pamięci. Nie ma tak że jak braknie slow ramu, to cały blok przenosi do chip ramu. Tam właśnie wszystko ładnie kolejno tworzy bo jest jeden typ pamięci. I nie ma sensu się z tym bawić bo jeszcze kod będę rozwijać i urośnie. I nie będę ograniczać swojej gry z tego powodu że ktoś z Commodore umyślił sobie dać dwa różne rodzaje pamięci komputerowi Amiga 500.
Wątpię czy po utworzeniu bitmapy przez AllocMem uda Ci się użyć komendy Use Bitmap, czy Blit/Bblit/Block. Chyba raczej nie. Moim zdaniem nie ma szans aby odpalić grę na 0.5+0.5. Nie w takim rozmiarze. 320KB to same bitplany, 300KB to plik exe, dźwięki to 100KB. Do tego bank shapów, bitplany dolnej belki, czy moduł to już duperele, ale suma sumarum przekroczy pamięć. A600 odpala bo tam jest ciągłość pamięci. Nie ma tak że jak braknie slow ramu, to cały blok przenosi do chip ramu. Tam właśnie wszystko ładnie kolejno tworzy bo jest jeden typ pamięci. I nie ma sensu się z tym bawić bo jeszcze kod będę rozwijać i urośnie. I nie będę ograniczać swojej gry z tego powodu że ktoś z Commodore umyślił sobie dać dwa różne rodzaje pamięci komputerowi Amiga 500.
24.08.2024 20:45
[#221]
Re: Ami Robbo 2
@tukinem, post #220
Nie chce sie czepiac, ale po co to robiles?
"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."
Bo dzwieki i exek, akurat ladnie pasuja do ilosci wolnego slow fastu, jeszcze troche zostanie.
A reszte bys zmiescil w 460 kB chipu.
"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."
Bo dzwieki i exek, akurat ladnie pasuja do ilosci wolnego slow fastu, jeszcze troche zostanie.
A reszte bys zmiescil w 460 kB chipu.
24.08.2024 20:53
[#222]
Re: Ami Robbo 2
@Don_Adan, post #221
Po to, że jeśli ktoś uruchamia na 0.5 MB chip ram, to żeby nie zapchało wszystkimi samplami chip ramu. Po drugie ci co mają tylko 0.5 MB chip ram nie usłyszą muzyki, bo wtedy się nie załaduje.
Niestety, ale takie chocki-klocki też powodują, że kod rośnie i to sporo. Stworzenie zmiennej NOFAST, stworzenie zmiennej NOMUSIC, napisanie za każdym razem IF'a od ładowania to jest wzrost kilkaset bajtów kodu. WIem, że mógłbym to asemblerem ogarniać, ale już mi się naprawdę nie chce mieszać basica z asemblerem, dlatego gdy kod jest duży, to już dalej używam samego basica. Taki IF do zmiennej zajmuje w kodzie ze 20 razy więcej miejsca niż CMP. No nie obniżę już kodu gry o te 50KB bo tyle bym chyba potrzebował aby gra wystartowała na tamtej konfiguracji, a jeszcze mam do dopisania trochę. Nie ma sensu dłubanina tylko po to, aby kilku youtuberów mogło odpalić grę na swoim "RED LEDzie". Wystarczy dołożyć 1MB Fast RAM co raczej dzisiaj nie stanowi problemu.
Jeśli chcesz, to Ci wyślę plik .exe, zdeasemblujesz sobie go i zobaczysz jakie cuda tam Blitz Basic wyprawia. Nie chcę nikogo urażać, ale komu dzisiaj zależy żeby uruchomić grę na 0.5+0.5? Wydaje mi się, że kwestią czasu jest, aż powstanie nowy wątek: "Czy Amiga powyżej 0,5 chip + 0,5 slow to jeszcze jest Amiga czy AmigaNG?"
Ostatnia aktualizacja: 24.08.2024 21:00:29 przez tukinem
Niestety, ale takie chocki-klocki też powodują, że kod rośnie i to sporo. Stworzenie zmiennej NOFAST, stworzenie zmiennej NOMUSIC, napisanie za każdym razem IF'a od ładowania to jest wzrost kilkaset bajtów kodu. WIem, że mógłbym to asemblerem ogarniać, ale już mi się naprawdę nie chce mieszać basica z asemblerem, dlatego gdy kod jest duży, to już dalej używam samego basica. Taki IF do zmiennej zajmuje w kodzie ze 20 razy więcej miejsca niż CMP. No nie obniżę już kodu gry o te 50KB bo tyle bym chyba potrzebował aby gra wystartowała na tamtej konfiguracji, a jeszcze mam do dopisania trochę. Nie ma sensu dłubanina tylko po to, aby kilku youtuberów mogło odpalić grę na swoim "RED LEDzie". Wystarczy dołożyć 1MB Fast RAM co raczej dzisiaj nie stanowi problemu.
Jeśli chcesz, to Ci wyślę plik .exe, zdeasemblujesz sobie go i zobaczysz jakie cuda tam Blitz Basic wyprawia. Nie chcę nikogo urażać, ale komu dzisiaj zależy żeby uruchomić grę na 0.5+0.5? Wydaje mi się, że kwestią czasu jest, aż powstanie nowy wątek: "Czy Amiga powyżej 0,5 chip + 0,5 slow to jeszcze jest Amiga czy AmigaNG?"
Ostatnia aktualizacja: 24.08.2024 21:00:29 przez tukinem
24.08.2024 22:42
[#224]
Re: Ami Robbo 2
@Don_Adan, post #223
O ile w BB się tak da i czy będę w stanie to odzyskać? Dziwi mnie fakt, że to nie sama gra się wiesza, a menu główne zaraz przy zamknięciu ekranu HAM i dokładnie wiesza przy tworzeniu bitmapy 1456x32 ze znakami ASCII do menu gry. W tamtej konfiguracji nawet muzyka się nie ładuje do chip ramu... Może i sama rozgrywka by poszła, ale to menu główne się nie uruchamia właśnie przy alokowaniu tej szerokiej bitmapy ze grafikami odpowiadającymi znakom ASCII.
25.08.2024 00:52
[#225]
Re: Ami Robbo 2
@tukinem, post #224
To moze daj jakiegos waita. Nie wiem, jakies guru dostajesz?
A jesli chodzi o te 50kB to mozesz zrobic downsampling sampli 2 do 1.
Ja jak testowalem, bo uzywalem tego troche to nie slyszalem, zadnej roznicy.
Tutaj masz kod:
.
A jesli chodzi o te 50kB to mozesz zrobic downsampling sampli 2 do 1.
Ja jak testowalem, bo uzywalem tego troche to nie slyszalem, zadnej roznicy.
Tutaj masz kod:
*A0 - start sampla *A1 - przeznaczenie, moze byc rowne A0, czyli konwersja w miejscu *D7 - dlugosc oryginalnego sampla bclr #0,D7 ; zawsze parzysta dlugosc sampla Loop move.b (A0)+,D0 ext.w D0 move.b (A0)+,D1 ext.w D1 add.w D1,D0 asr.w D0 move.b D0, (A1)+ subq.l #2,D7 bne.b Loop
.
25.08.2024 01:18
[#226]
Re: Ami Robbo 2
@Don_Adan, post #225
Ja wczytuję sample zawsze do parzystego adresu i zawsze w parzystym rozmiarze. Tu co mi podałeś to mi nic nie daje. Jeśli sampel miałby nieparzystą długość, to automatycznie wywaliłby się nawet przy 2MB chip ram i 8MB fastu chyba.
Jeszcze jedna kwestia. Wiesza się przy tworzeniu bitmapy 1456x32x5. Dopóki nie opuszczam menu gry, to sampli kod nie tyka. A to właśnie menu gry się przestaje ładować. Nie ma guru, tylko standardowo z braku wolnej pamięci jest czarny ekran i cisza. Dyskietka staje i koniec. Nie ma guru, nie ma nic.
Pokonwertowałem pliki PNG do IFF HAM z różnymi opcjami i to są moim zdaniem najlepsze efekty:
Faktycznie Ham Converter od Choloka jest fantastyczny
no i pliki IFF pakuje bo zawsze coś tam mniej zajmują niż pełne 6 bitplanów+paleta.
Ostatnia aktualizacja: 25.08.2024 01:26:03 przez tukinem
Jeszcze jedna kwestia. Wiesza się przy tworzeniu bitmapy 1456x32x5. Dopóki nie opuszczam menu gry, to sampli kod nie tyka. A to właśnie menu gry się przestaje ładować. Nie ma guru, tylko standardowo z braku wolnej pamięci jest czarny ekran i cisza. Dyskietka staje i koniec. Nie ma guru, nie ma nic.
Pokonwertowałem pliki PNG do IFF HAM z różnymi opcjami i to są moim zdaniem najlepsze efekty:
Faktycznie Ham Converter od Choloka jest fantastyczny
no i pliki IFF pakuje bo zawsze coś tam mniej zajmują niż pełne 6 bitplanów+paleta.Ostatnia aktualizacja: 25.08.2024 01:26:03 przez tukinem
25.08.2024 10:27
[#227]
Re: Ami Robbo 2
@tukinem, post #226
Jak nic nie daje?
Konwertujesz sample do polowy ich dlugosci, w zasadzie bez utraty ich jakosci, przynajmniej ja nie slyszalem roznicy jak testowalem.
Czyli jak obecne sample zajmuja 100kB to po takiej konwersji tylko 50kB.
Skonwertuj sobie tak SFX-y (binarne) i przesluchaj, bo moj sluch moze zawodzic.
Po takiej konwersji oczywiscie trzeba zmienic 2 rzeczy:
1. dlugosc sampla do odgrywania dzielisz na 2, czyli lsr.w #1,D0
2. okres/period sampla do odgrywania mnozysz x2, czyli add.w D0,D0
Mozna tego uzyc tylko dla wersji z 0.5MB chip i 0.5MB slow. Wtedy modyfikujesz kod programu.
Albo od razu sobie konwertujesz wszystkie sample, wtedy dla wszystkich wersji gry masz 50kB wiecej wolnej pamieci.
A co do nieparzystej dlugosci sampli, to tak sa takie.
I nawet wlasnie w Blitzu w watku na EAB ktos takich uzywal, i mu sie wyburaczylo, i nie wiedzial dlaczego.
Te rozne PC-towe programy potrafia takie sample stworzyc.
Jesli masz tylko parzystej dlugosci sample to oczywiscie bclr #0,D7 nie jest potrzebne, bo ten bit jest wtedy zawsze 0.
Ale juz Ci chyba kiedys pisalem, ze jak piszesz/tworzysz to musisz przewidziec prawie wszystko co inny uzytkownik
moze zrobic z Twoim programem, a nie tylko to co Ty z nim robisz. Ludzie potrafia naprawde dziwne rzeczy robic.
Konwertujesz sample do polowy ich dlugosci, w zasadzie bez utraty ich jakosci, przynajmniej ja nie slyszalem roznicy jak testowalem.
Czyli jak obecne sample zajmuja 100kB to po takiej konwersji tylko 50kB.
Skonwertuj sobie tak SFX-y (binarne) i przesluchaj, bo moj sluch moze zawodzic.
Po takiej konwersji oczywiscie trzeba zmienic 2 rzeczy:
1. dlugosc sampla do odgrywania dzielisz na 2, czyli lsr.w #1,D0
2. okres/period sampla do odgrywania mnozysz x2, czyli add.w D0,D0
Mozna tego uzyc tylko dla wersji z 0.5MB chip i 0.5MB slow. Wtedy modyfikujesz kod programu.
Albo od razu sobie konwertujesz wszystkie sample, wtedy dla wszystkich wersji gry masz 50kB wiecej wolnej pamieci.
A co do nieparzystej dlugosci sampli, to tak sa takie.
I nawet wlasnie w Blitzu w watku na EAB ktos takich uzywal, i mu sie wyburaczylo, i nie wiedzial dlaczego.
Te rozne PC-towe programy potrafia takie sample stworzyc.
Jesli masz tylko parzystej dlugosci sample to oczywiscie bclr #0,D7 nie jest potrzebne, bo ten bit jest wtedy zawsze 0.
Ale juz Ci chyba kiedys pisalem, ze jak piszesz/tworzysz to musisz przewidziec prawie wszystko co inny uzytkownik
moze zrobic z Twoim programem, a nie tylko to co Ty z nim robisz. Ludzie potrafia naprawde dziwne rzeczy robic.
25.08.2024 10:53
[#228]
Re: Ami Robbo 2
@Don_Adan, post #227
No tu już Ci tłumaczę dlaczego nic mi nie daje.
Oto kolejność jaką wykonuje program:
- sprawdzam dostępną pamięć chip i fast i na tej podstawie ustalam zmienne do sposobu ładowania danych
- ładuję MOD do chip ram, jeśli jest 1MB chip ram minimum i go odgrywam
- tworzę wszelkie struktury, zmienne, tablice i listy używane w grze
- ładuję plik .DAT do pamięci i wypisuję w CLI napisy startowe
- tworzę 2 bufory dla bobów wstawianych BBlitem (kilkaset bajtów) i kolejkę na 2 boby wstawiany QBlitem w menu gry
- wszystkie procedury
- wszystkie funkcje przeliczające
- tworzę dwie copperlisty: jedna 5 bitplanowa, druga 6-bitplanowa w HAM
- tworzę bitmapę 320x200x6 i ładuję plik IFF HAM6 do niej oraz wyświetlam
- czyszczę tą bitmapę a na jej miejsce tworzę bitmapę 512x512x5
- czyszczę bitmapę 1,3 i 4, co na początku jest nieistotne bo to czyści po wyjściu z gry do menu. Pewnie zaraz spytasz czy to nie powoduje błędu jeśli bitmapy nie istnieją. Nie powoduje, bo tak by kompilator wywalił komunikat przy kompilacji, a nawet gdyby przeszło to na 1MB chip ram gra by się wywaliła mimo to
- czyszczę dźwięki z pamięci (ale najpierw sprawdza czy są wgrane, to dla tego momentu, gdy wychodzimy z gry do menu)
- tworzę bitmapę nr 1 1456x32x5 - I TU SIĘ WIESZA Z BRAKU PAMIĘCI
DALEJ:
- jeśli muzyka nie jest odgrywana (to w momencie gdy wychodzimy z gry do menu) to ładuje MOD do pamięci i go odgrywa
- ładuję bank shapów z pliku
- pobieram sobie dwa shape'y z tej szerokiej bitmapy jako "wybieraczki" do menu
- rysuję menu znak po znaku z tej wielkiej bitmapy
- wstawiam szybkie boby QBlitem i jednocześnie zmieniam 2 kolory gwiazdek w menu
Później już nieważne. Dźwięki są ładowane dopiero po wyborze STORY MODE lub CUSTOM WORLD.
Sprawdziłem też na konfiguracji ECS z 1MB chip ram + 0.5 MB slow RAM. Kod gry ładowany jest standardowo do slow ramu, program wykrywa, że jest pamięć slow/fast i poza wszelkimi zmiennymi, tablicami i innymi pierdołami ładuje sample do slow ramu. Działa.
Ostatnia aktualizacja: 25.08.2024 11:10:36 przez tukinem
Oto kolejność jaką wykonuje program:
- sprawdzam dostępną pamięć chip i fast i na tej podstawie ustalam zmienne do sposobu ładowania danych
- ładuję MOD do chip ram, jeśli jest 1MB chip ram minimum i go odgrywam
- tworzę wszelkie struktury, zmienne, tablice i listy używane w grze
- ładuję plik .DAT do pamięci i wypisuję w CLI napisy startowe
- tworzę 2 bufory dla bobów wstawianych BBlitem (kilkaset bajtów) i kolejkę na 2 boby wstawiany QBlitem w menu gry
- wszystkie procedury
- wszystkie funkcje przeliczające
- tworzę dwie copperlisty: jedna 5 bitplanowa, druga 6-bitplanowa w HAM
- tworzę bitmapę 320x200x6 i ładuję plik IFF HAM6 do niej oraz wyświetlam
- czyszczę tą bitmapę a na jej miejsce tworzę bitmapę 512x512x5
- czyszczę bitmapę 1,3 i 4, co na początku jest nieistotne bo to czyści po wyjściu z gry do menu. Pewnie zaraz spytasz czy to nie powoduje błędu jeśli bitmapy nie istnieją. Nie powoduje, bo tak by kompilator wywalił komunikat przy kompilacji, a nawet gdyby przeszło to na 1MB chip ram gra by się wywaliła mimo to
- czyszczę dźwięki z pamięci (ale najpierw sprawdza czy są wgrane, to dla tego momentu, gdy wychodzimy z gry do menu)
- tworzę bitmapę nr 1 1456x32x5 - I TU SIĘ WIESZA Z BRAKU PAMIĘCI
DALEJ:
- jeśli muzyka nie jest odgrywana (to w momencie gdy wychodzimy z gry do menu) to ładuje MOD do pamięci i go odgrywa
- ładuję bank shapów z pliku
- pobieram sobie dwa shape'y z tej szerokiej bitmapy jako "wybieraczki" do menu
- rysuję menu znak po znaku z tej wielkiej bitmapy
- wstawiam szybkie boby QBlitem i jednocześnie zmieniam 2 kolory gwiazdek w menu
Później już nieważne. Dźwięki są ładowane dopiero po wyborze STORY MODE lub CUSTOM WORLD.
Sprawdziłem też na konfiguracji ECS z 1MB chip ram + 0.5 MB slow RAM. Kod gry ładowany jest standardowo do slow ramu, program wykrywa, że jest pamięć slow/fast i poza wszelkimi zmiennymi, tablicami i innymi pierdołami ładuje sample do slow ramu. Działa.
Ostatnia aktualizacja: 25.08.2024 11:10:36 przez tukinem
25.08.2024 21:04
[#230]
Re: Ami Robbo 2
@koczis, post #229
Wypróbuj to:
http://aminet.net/gfx/conv/PicConvert.lha
http://aminet.net/gfx/conv/AnimConvert.lha
Nie pamiętam tylko czy HAM6 obsługuje.
Ostatnia aktualizacja: 25.08.2024 21:05:41 przez mailman
http://aminet.net/gfx/conv/PicConvert.lha
http://aminet.net/gfx/conv/AnimConvert.lha
Nie pamiętam tylko czy HAM6 obsługuje.
Ostatnia aktualizacja: 25.08.2024 21:05:41 przez mailman
26.08.2024 02:04
[#234]
Re: Ami Robbo 2
@Don_Adan, post #233
Nie zwalniam pamięci bo mnie nie brakuje chip ramu, a slow ramu. Sama copperlista dużo nie zajmuje, a dopisanie Free Coplist i InitCoplist za każdym razem zwiększy o wiele kod gry. Takich przeskoków jest dosłownie 6. Dodatkowo będą mignięcia ekranu.
Sama copperlista to jakieś 322 bajty jak dobrze liczyłem.
Ostatnia aktualizacja: 26.08.2024 02:07:51 przez tukinem
Ostatnia aktualizacja: 26.08.2024 02:08:18 przez tukinem
Sama copperlista to jakieś 322 bajty jak dobrze liczyłem.
NEWTYPE .coplist size.l ;0 = not initialised coppos.l ;location in chipmem colors.l sprites.l bpcons.l bplanes.l dot.l customs.l dob.l numbp.w:colpokes.w ;limits fetchwid.w:xand:xshift ;for show calculations (3 words) ypos.w:height:res numsprites.w:numcols:numcustoms aga.w ;24bit=$8000 fetch = $00,$10,$20,$30 resshift.w ;lo,hi,shi = 2 1 0 setup.w ;lines taken for setup cblow.w ;if custom goes below 256 sfetch.w:spres:spif:spwid:sspwid ;sprite mode for display End NEWTYPE
Ostatnia aktualizacja: 26.08.2024 02:07:51 przez tukinem
Ostatnia aktualizacja: 26.08.2024 02:08:18 przez tukinem
26.08.2024 04:02
[#235]
Re: Ami Robbo 2
@tukinem, post #234
A skad wiesz, ze brakuje Ci slow, a nie chip?
Nie masz wersji debug wyswietlajacej ilosc wolnej i ilosc ciaglej pamieci.
A to ze cos duzo nie zajmuje nie oznacza, ze nie blokuje Ci duzo wiekszego obszaru pamieci.
Przykladowo, masz 460 kB chip (ciaglego)
Alokujesz cos ma 300kB
Potem cos co ma 5kB (powiedzmy copperlista)
Zwalniasz te 300kB, ale nie zwalniasz tych 5kB.
Czyli w teorii masz 455 kB, tylko ze w 2 obszarach 300kB i 155kB.
Teraz wczytujesz/alokujesz cos co ma 200kB.
W teorii masz 255kB, ale w dwoch obszarach 100kB i 155kB.
Probujesz teraz wczytac/alokowac cos co ma powiedzmy 170kB.
Nie da sie. Nie w ten sposob, choc ogolna ilosc wolnej pamieci jest Ok, brak jest wolnego obszaru ciaglego.
O ile, nie zarzadzasz sam calym obszarem pamieci to najlepiej jest wszystkie male alokacje pamiieci zrobic jako pierwsze na poczatku. A jezeli robisz duza alokacje pamieci to juz jej nie zwalniac potem.
No i zawsze na poczatku mozna zaalokowac wiekszy obszar niz potrzebuje dany plik.
Np. pierwszy plik potrzebuje 200kB chip, a drugi 250 kB.
Alokujesz od razu 250kB.
Wczytujesz w to samo miejsce najpierw pierwszy plik, a potem drugi.
Nie masz wersji debug wyswietlajacej ilosc wolnej i ilosc ciaglej pamieci.
A to ze cos duzo nie zajmuje nie oznacza, ze nie blokuje Ci duzo wiekszego obszaru pamieci.
Przykladowo, masz 460 kB chip (ciaglego)
Alokujesz cos ma 300kB
Potem cos co ma 5kB (powiedzmy copperlista)
Zwalniasz te 300kB, ale nie zwalniasz tych 5kB.
Czyli w teorii masz 455 kB, tylko ze w 2 obszarach 300kB i 155kB.
Teraz wczytujesz/alokujesz cos co ma 200kB.
W teorii masz 255kB, ale w dwoch obszarach 100kB i 155kB.
Probujesz teraz wczytac/alokowac cos co ma powiedzmy 170kB.
Nie da sie. Nie w ten sposob, choc ogolna ilosc wolnej pamieci jest Ok, brak jest wolnego obszaru ciaglego.
O ile, nie zarzadzasz sam calym obszarem pamieci to najlepiej jest wszystkie male alokacje pamiieci zrobic jako pierwsze na poczatku. A jezeli robisz duza alokacje pamieci to juz jej nie zwalniac potem.
No i zawsze na poczatku mozna zaalokowac wiekszy obszar niz potrzebuje dany plik.
Np. pierwszy plik potrzebuje 200kB chip, a drugi 250 kB.
Alokujesz od razu 250kB.
Wczytujesz w to samo miejsce najpierw pierwszy plik, a potem drugi.
26.08.2024 05:19
[#236]
Re: Ami Robbo 2
@Don_Adan, post #235
Nie wiem dokładnie, co przekracza pamięć.
Jak pisałem wcześniej, tworzenie bitmapy w chip ramie wiesza dalsze działanie programu. Z drugiej strony, dopóki plik wykonywalny nie przekraczał 256KB, wszystko działało na tej konfiguracji. Jeśli masz pomysł, jak sprawdzić, którą pamięć przekracza, to Ci podeślę ADF z grą i sobie sprawdzisz. Obecnie plik uruchamialny to już ponad 300KB. Wszystko za sprawą zaprogramowania obsługi DLC do gry i uwzględnienia różnych sytuacji, np. gdy gra zostanie zabootowana z dyskietki, a dodatkowe poziomy chcemy wczytać z innej dyskietki, musiałem stworzyć wyświetlanie komunikatów o włożenie dyskietki, z której będzie ładowany następny plik, aby gra się nie zawiesiła. I tak zrobiłem "ukłon" dla Amig 500 z kickstartem 1.3 i użyłem File Requestera zgodnego z kickiem 1.3, chociaż wolałem użyć ASLPathRequester do samego katalogu DLC, lecz ASL jest dopiero zgodne z kickiem 2.0.
Wiem, że masz sporą wiedzę i pomysły. Może wystarczy, że uruchomisz grę ze SnoopDosem, czy w jakiś inny sposób? Wy "scenowcy-magicy" macie swoje triki
Jak pisałem wcześniej, tworzenie bitmapy w chip ramie wiesza dalsze działanie programu. Z drugiej strony, dopóki plik wykonywalny nie przekraczał 256KB, wszystko działało na tej konfiguracji. Jeśli masz pomysł, jak sprawdzić, którą pamięć przekracza, to Ci podeślę ADF z grą i sobie sprawdzisz. Obecnie plik uruchamialny to już ponad 300KB. Wszystko za sprawą zaprogramowania obsługi DLC do gry i uwzględnienia różnych sytuacji, np. gdy gra zostanie zabootowana z dyskietki, a dodatkowe poziomy chcemy wczytać z innej dyskietki, musiałem stworzyć wyświetlanie komunikatów o włożenie dyskietki, z której będzie ładowany następny plik, aby gra się nie zawiesiła. I tak zrobiłem "ukłon" dla Amig 500 z kickstartem 1.3 i użyłem File Requestera zgodnego z kickiem 1.3, chociaż wolałem użyć ASLPathRequester do samego katalogu DLC, lecz ASL jest dopiero zgodne z kickiem 2.0.
Wiem, że masz sporą wiedzę i pomysły. Może wystarczy, że uruchomisz grę ze SnoopDosem, czy w jakiś inny sposób? Wy "scenowcy-magicy" macie swoje triki
26.08.2024 11:19
[#237]
Re: Ami Robbo 2
@tukinem, post #236
Nie mam dostepu do Amigi.
Snoopdos nie pokazuje zuzycia pamieci.
Jedyny prosty pomysl jaki mam to zebys zrobil wyjscie (break) z programu pod np. F10, bez zwalniania pamieci na wyjsciu i uzyl Avail.
Wtedy mozna by wiedziec ile jest wolnej pamieci ogolem, a ile jest pamieci ciaglej wolnej.
Bo to wyglada, ze gra potrzebuje pamieci ciaglej pomiedzy 100-200 kB.
Mozesz tez sprobowac stworzyc bitmape1456x32x5 od razu na poczatku, przed bitmapa 320x200x6.
Snoopdos nie pokazuje zuzycia pamieci.
Jedyny prosty pomysl jaki mam to zebys zrobil wyjscie (break) z programu pod np. F10, bez zwalniania pamieci na wyjsciu i uzyl Avail.
Wtedy mozna by wiedziec ile jest wolnej pamieci ogolem, a ile jest pamieci ciaglej wolnej.
Bo to wyglada, ze gra potrzebuje pamieci ciaglej pomiedzy 100-200 kB.
Mozesz tez sprobowac stworzyc bitmape1456x32x5 od razu na poczatku, przed bitmapa 320x200x6.
26.08.2024 18:44
[#238]
Re: Ami Robbo 2
@Don_Adan, post #237
Właśnie o to mi chodziło, że program potrzebuje ciągłej pamięci 1MB tak jak to się dzieje w przypadku gołej Amigi 600. Tam nawet muzyka się ładuje i wszystko jest ok.
C64portal mi wytłumaczył o co chodzi z CludgeBitmap i faktycznie mógłbym narzucić na starcie największy możliwy rozmiar dla bitmap, tylko że znowu samo menu główne nie zżera aż tak dużo chip ramu. Tam jest tylko bitmapa 320x200x5 i ta 1456x32x5. Wszystko pojedynczo, bo nie ma tam podwójnego buforowania. Dodatkowo są pobrane dwie grafiki do banku shapów, ale to później już po utworzeniu tej szerokiej bitmapy, co nie zdąży się utworzyć, bo się wiesza na A500 ze slow ramem.
Dźwięki gry mają też różne rozmiary i musiałbym to uwzględnić, a paczki DLC mogą zawierać różne dźwięki, więc wtedy ich rozmiary by się pozmieniały. No i musiałbym pilnować offsetów dla pamięci :) to chyba za dużo na moją prymitywną głowę :D
C64portal mi wytłumaczył o co chodzi z CludgeBitmap i faktycznie mógłbym narzucić na starcie największy możliwy rozmiar dla bitmap, tylko że znowu samo menu główne nie zżera aż tak dużo chip ramu. Tam jest tylko bitmapa 320x200x5 i ta 1456x32x5. Wszystko pojedynczo, bo nie ma tam podwójnego buforowania. Dodatkowo są pobrane dwie grafiki do banku shapów, ale to później już po utworzeniu tej szerokiej bitmapy, co nie zdąży się utworzyć, bo się wiesza na A500 ze slow ramem.
Dźwięki gry mają też różne rozmiary i musiałbym to uwzględnić, a paczki DLC mogą zawierać różne dźwięki, więc wtedy ich rozmiary by się pozmieniały. No i musiałbym pilnować offsetów dla pamięci :) to chyba za dużo na moją prymitywną głowę :D
28.08.2024 15:25
[#240]
Re: Ami Robbo 2
@asman, post #239
Znając możliwości c64portal, to obstawiam asembler albo C jeśli istnieje na C Plus4.
Nauczyłem się nareszcie prawidłowo konwertować filmiki z WinUAE tak, aby youtube je wykrywał w 50 fpsach. I tak nagrałem filmik, jak działa woda w grze (tu akurat woda jest kwasem, bo jest zielona):
PS. Do tych, co nagrywają wideo bezporednio emulatorem. Też tak macie, że wam się emulator zacina co chwilę podczas tworzenia tych 2GB-owych plików?
Ostatnia aktualizacja: 28.08.2024 15:26:33 przez tukinem
Nauczyłem się nareszcie prawidłowo konwertować filmiki z WinUAE tak, aby youtube je wykrywał w 50 fpsach. I tak nagrałem filmik, jak działa woda w grze (tu akurat woda jest kwasem, bo jest zielona):
PS. Do tych, co nagrywają wideo bezporednio emulatorem. Też tak macie, że wam się emulator zacina co chwilę podczas tworzenia tych 2GB-owych plików?
Ostatnia aktualizacja: 28.08.2024 15:26:33 przez tukinem