15.08.2023 17:28
[#151]
Re: Tony - development nowej gry
@tukinem, post #150
Nie znam sie na Blitzu, ale jak podajesz sciezke do pliku w formacie:
Tony2: Grafika/Bobas
To pod systemem powinien sie wyswietlic komunikat typu "Please Insert Volume Tony2 in any drive." To wedlug mnie powinno wystarczyc, przynajmniej do testow, chyba ze chcesz jakas grafike dyskietki wyswietlic jeszcze.
W przypadku gier dwudyskowych, bardzo czesto wyswietlany jest komunikat "Exchange disk".
Tony2: Grafika/Bobas
To pod systemem powinien sie wyswietlic komunikat typu "Please Insert Volume Tony2 in any drive." To wedlug mnie powinno wystarczyc, przynajmniej do testow, chyba ze chcesz jakas grafike dyskietki wyswietlic jeszcze.
W przypadku gier dwudyskowych, bardzo czesto wyswietlany jest komunikat "Exchange disk".
15.08.2023 19:50
[#152]
Re: Tony - development nowej gry
@Don_Adan, post #151
Pisałem jak wygląda kod od sprawdzania czy dany plik się znajduje pod podaną ścieżką. To tak wygląda jakby obecny katalog inaczej wyglądał podczas bootowania ADFu, a inaczej podczas uruchomienia z ADFa spod systemu. Tym bardxziej, że kod jest dobry bo bootując z ADFa działa przemienianie obrazów dyskietek, a podczas uruchomienia z HDD o nic nie prosi tylko ładuje. Tutaj system coś musi mieszać.
Zostaje jeszcze jedna opcja. Bezpośrednie ścieżki do plików, a dla tych co chcą na HDD, to wersja WHDLoad, tylko jak taką stworzyć...
Zostaje jeszcze jedna opcja. Bezpośrednie ścieżki do plików, a dla tych co chcą na HDD, to wersja WHDLoad, tylko jak taką stworzyć...
15.08.2023 21:06
[#153]
Re: Tony - development nowej gry
@tukinem, post #152
Ale nie musisz sprawdzac, czy plik jest na dyskietce, tylko go ladujesz, jak to jest dyskietka z tym plikiem to sie zaladuje od razu, a jak nie, to system poprosi o wlozenie dyskietki z odpowiednim numerem i plik zostanie wczytany. Jedynie przy starcie z HD dodajesz/uruchamiasz skrypt startowy (i ikone typu Project):
assign Tony1: ""
assign Tony2: ""
Tony
Tak sie uruchamia bardzo duzo gier DOS-owych na Amidze.
assign Tony1: ""
assign Tony2: ""
Tony
Tak sie uruchamia bardzo duzo gier DOS-owych na Amidze.
15.08.2023 21:14
[#154]
Re: Tony - development nowej gry
@selur, post #124
dla mnie to nie jest dobrze, bo masz na sztywno ustawiony dostep do dyskietki w stylu "LVL3/music.pack"
no a w HDD z reguly masz jeszcze przed katalogiem z gra cala plejade katalogow np. w stylu
"HD0:amiga_gry/LVL3/music.pack"
Moim zdaniem program to rozumie i nie trzeba "precyzować" tego co jest wcześniej. Szuka katalogu LVL3 (i dalej w nim pliku) w katalogu, z którego uruchomiony został program.
15.08.2023 21:19
[#155]
Re: Tony - development nowej gry
@tukinem, post #152
A może Blitz ma tak, że skoro wszedł do LVL1 i stamtąd pobrał plik, to gdy teraz coś chcesz z LVL3, to on szuka folderu tam, gdzie obecnie się znajduje, czyli w LVL1, a tutaj LVL3 nie ma.
A te dwa ADF-y jaką mają etykietę? Różną czy taką samą?
Ostatnia aktualizacja: 15.08.2023 21:20:44 przez mailman
A te dwa ADF-y jaką mają etykietę? Różną czy taką samą?
Ostatnia aktualizacja: 15.08.2023 21:20:44 przez mailman
15.08.2023 22:36
[#156]
Re: Tony - development nowej gry
@mailman, post #155
Już to ogarnąłem. Jak pisałem bootując z ADF wszystko działa więc po co piszecie że czytając z podkatalogu LVL3 przechodzi do niego na stałe? Nie.
Ocyganiłem to. Mianowicie wprowadziłem zmienną disk.b i ADF.b. Jeśli któryś plik nie istnieje to ADF=1. Wtedy po numerze levelu zmienna disk przyjmuje wartość 1 lub 2. Następnie dir$ to już nie będzie pośrednia ścieżka LVL3/ tylko coś takiego strzeliłem:
If Exists(music$)=false
dir$="DISK"+Str$(disk)+":LVL"+Str$(level)+/
music$=dir$+"music.pack"
While exists(music$)=false
VWait
Wend
EndIf
Bload music$,MAdredress,FileSize(music$)
Icała reszta plików też przez BLoad z nowym dir$ z bezpośrednią ścieżką.
Próby tych samych etykiet od ADFów były błędem. Użyłem etykiet DISK1 i DISK2. Myślę że teraz nawet na dwóch stacjach dyskietek naraz można używać dwóch ADFów bez żonglerki.
Ocyganiłem to. Mianowicie wprowadziłem zmienną disk.b i ADF.b. Jeśli któryś plik nie istnieje to ADF=1. Wtedy po numerze levelu zmienna disk przyjmuje wartość 1 lub 2. Następnie dir$ to już nie będzie pośrednia ścieżka LVL3/ tylko coś takiego strzeliłem:
If Exists(music$)=false
dir$="DISK"+Str$(disk)+":LVL"+Str$(level)+/
music$=dir$+"music.pack"
While exists(music$)=false
VWait
Wend
EndIf
Bload music$,MAdredress,FileSize(music$)
Icała reszta plików też przez BLoad z nowym dir$ z bezpośrednią ścieżką.
Próby tych samych etykiet od ADFów były błędem. Użyłem etykiet DISK1 i DISK2. Myślę że teraz nawet na dwóch stacjach dyskietek naraz można używać dwóch ADFów bez żonglerki.
16.08.2023 03:54
[#158]
Re: Tony - development nowej gry
@tukinem, post #139
Gra mi się bardzo podoba, ale będę brutalnie szczery - 1,5MB fastu na tego typu produkcję to jest kosmos. Gierki typu PP Hammer, albo Rick Dangerous chodzą na standardowej pięćsetce z 0,5MB chip + 0,5MB slow, więc to na pewno jest wykonalne. Ba, nawet na 8-bitowcach z wielokrotnie mniejszym ramem takie gry powstały. Za daleko już jesteś z kodowaniem, żeby teraz wszystko zmieniać, ale myślę że na przyszłość warto nad tym pomyśleć, bo tu z samą koncepcją silnika ewidentnie jest coś nie tak.
16.08.2023 04:39
[#159]
Re: Tony - development nowej gry
@mastaszek, post #158
Oj wiem że się da. Wystarczy 64kB pamięci ram jak w przypadku 8-bitowców 
wychodzi różnica między Blitzem a asemblerem. Ale szczerze mówiąc to Amos by jeszcze więcej zjadł. Taka tablica piramidy to 240x240 kafli, czyli 56,25kB. W Amosie zajęłaby 4krotność, bo tam nie ma typów zmiennych.
Faktycznie męczące są zmiany w grze ale przywykłem do tego. Co chwilę zmieniają się jakieś koncepcje w grze.
wychodzi różnica między Blitzem a asemblerem. Ale szczerze mówiąc to Amos by jeszcze więcej zjadł. Taka tablica piramidy to 240x240 kafli, czyli 56,25kB. W Amosie zajęłaby 4krotność, bo tam nie ma typów zmiennych.Faktycznie męczące są zmiany w grze ale przywykłem do tego. Co chwilę zmieniają się jakieś koncepcje w grze.
16.08.2023 08:14
[#160]
Re: Tony - development nowej gry
@tukinem, post #159
to nie do końca kwestia assemblera vs blitz basica. tylko organizacji danych. dawne gry nie bez powodu doczytywały dane aby pomieścić się w pamięci 512+512.
w przypadku Waszej gry zastanawia mnie następujące kwestie:
- po co 2 bitplanowa grafika planszy?
- po co 2 bitplanowa grafika panelu na dole? jeśli tylko po to aby oczy mrugały to jest to rozrzutność IMO - można tam po prostu dać sprajta i tyle.
- mapę gry możesz trzymać w kawałkach spakowaną i rozpakowywać te elementy które są potrzebne - nawet partiami po kilka ekranów.
- ciekawi mnie jak trzymasz mapę w pamięci? jeśli jako Dim to to moze też zjadać więcej pamięci niż treba. ja używam Incbin, albo Dc.b albo Dc.w jak w assemblerze a do danych dobieram się po prostu jako peek z operatorem "?". i to też jest najszybsze rozwiązanie.
- jeśli gra będzie działała z dysku twardego to doładowanie ekranu startowego po game over to też będzie szybka sprawa i wg mnie nie trzeba tego trzymać w pamięci
- aby nie allokować i zwalniać pamięci zrobił bym jeden buffor na stałe gdzie będę rozpakowywał rzeczy (o rozmiarze największego bloku danych jaki rozpakujesz)
co do 8 bit to tam grafika jest inaczej zorganizowana (na znakach) a i tam duże gry (np na c64) doczytywały się z dyskietki. w dyskusji o Tonym na C64 też wychodzi, że mało pamięci będzie na mapę. link
podczas pisania gier często to ta cała "inżynieria" jest trudniejsza do zrobienia niż sam silnik gry. a ta dyskusja skłania mnie aby wrócić do mojego silnika gry i pociągnąć go może dalej. zresztą też w BB go robiłem.
jakieś przymiarki i odświeżenie pamięci (mojej) zacząłem robić w tym kierunku ;)
tak czy tak trzymam kciuki Tukinem za ten projekt!
w przypadku Waszej gry zastanawia mnie następujące kwestie:
- po co 2 bitplanowa grafika planszy?
- po co 2 bitplanowa grafika panelu na dole? jeśli tylko po to aby oczy mrugały to jest to rozrzutność IMO - można tam po prostu dać sprajta i tyle.
- mapę gry możesz trzymać w kawałkach spakowaną i rozpakowywać te elementy które są potrzebne - nawet partiami po kilka ekranów.
- ciekawi mnie jak trzymasz mapę w pamięci? jeśli jako Dim to to moze też zjadać więcej pamięci niż treba. ja używam Incbin, albo Dc.b albo Dc.w jak w assemblerze a do danych dobieram się po prostu jako peek z operatorem "?". i to też jest najszybsze rozwiązanie.
- jeśli gra będzie działała z dysku twardego to doładowanie ekranu startowego po game over to też będzie szybka sprawa i wg mnie nie trzeba tego trzymać w pamięci
- aby nie allokować i zwalniać pamięci zrobił bym jeden buffor na stałe gdzie będę rozpakowywał rzeczy (o rozmiarze największego bloku danych jaki rozpakujesz)
co do 8 bit to tam grafika jest inaczej zorganizowana (na znakach) a i tam duże gry (np na c64) doczytywały się z dyskietki. w dyskusji o Tonym na C64 też wychodzi, że mało pamięci będzie na mapę. link
podczas pisania gier często to ta cała "inżynieria" jest trudniejsza do zrobienia niż sam silnik gry. a ta dyskusja skłania mnie aby wrócić do mojego silnika gry i pociągnąć go może dalej. zresztą też w BB go robiłem.
jakieś przymiarki i odświeżenie pamięci (mojej) zacząłem robić w tym kierunku ;)
tak czy tak trzymam kciuki Tukinem za ten projekt!
16.08.2023 08:43
[#161]
Re: Tony - development nowej gry
@tukinem, post #159
Ale szczerze mówiąc to Amos by jeszcze więcej zjadł.
Nie pisz głupot. To, że nie wiesz, jak czegoś zrobić w Amosie nie znaczy, że się tego nie da zrobić. Trochę skromności.
Cały problem polega na tym, co napisał @c64portal:
to nie do końca kwestia assemblera vs blitz basica. tylko organizacji danych.
Śledząc wątek gry, która jest bardzo fajnym projektem, nie ulega wątpliwości, że źle zorganizowałeś dane w pamięci, ale idziesz w zaparte, że nie da się inaczej, albo że to wina BB. Tego typu gier tak się nie pisze, a przykłady podał np. @masteszek.
Dalej za @c64portal:
podczas pisania gier często to ta cała "inżynieria" jest trudniejsza do zrobienia niż sam silnik gry.
Tutaj leży sedno gier, które mają chodzić z dyskietek. Nie można ich rozrzutnie projektować, bo później nie pozostaje inne wyjście, jak zwiększać wymogi pamięci, więc nie dziw się krytyce, że tak prosta gra wymaga 1 MB Chip i 1,5 MB Fast. Wciąż możesz zejść do tylko 1 MB Chip bez dodatkowej pamięci, ale całość wymaga reorganizacji przechowywania, wczytywania i używania danych.
16.08.2023 10:24
[#163]
Re: Tony - development nowej gry
@selur, post #162
Chłopak robi niezłe postępy, ale niepotrzebnie blokuje go jego upartość. Gdyby nie uważał, że wie najlepiej, to rady, jakich mu tu już chłopaki nie raz udzielali wyniosłyby go na kolejny level.
@tukinem, masz ogromny potencjał. Nie hamuj go sztucznie brakiem pokory. Zamiast bezsensownie „ocyganiać” kod, posłuchaj rozsądnych rad (to aluzja m.in. do tej dziwacznej rzeźby z szukaniem ścieżki. Ręce więdną. @Don_Adan podał Ci banalnie proste i fundamentalne rozwiązanie dla amigowego systemu. Nie musisz udowadniać, że zrobisz to lepiej, bo wychodzi odwrotnie).
A tymczasem powodzenia
@tukinem, masz ogromny potencjał. Nie hamuj go sztucznie brakiem pokory. Zamiast bezsensownie „ocyganiać” kod, posłuchaj rozsądnych rad (to aluzja m.in. do tej dziwacznej rzeźby z szukaniem ścieżki. Ręce więdną. @Don_Adan podał Ci banalnie proste i fundamentalne rozwiązanie dla amigowego systemu. Nie musisz udowadniać, że zrobisz to lepiej, bo wychodzi odwrotnie).
A tymczasem powodzenia
16.08.2023 10:28
[#164]
Re: Tony - development nowej gry
@Umpal, post #161
Chcesz to pisz sobie w Amosie swoje dzieła. W Amosie nie stworzysz tablicy w typie bajta lub worda. Nie masz struktur chyba. Sam nie wiem bo Amos mnie znudził.
Może faktycznie zbyt dużo danych mam narqz załadowane ale to głównie też przez to żeby zaoszczędzić czekania na załadowanie wszystkiego z ADFa. Pobierz sobie demko Tonego, ustaw floppy na 100% i licz czas jak długo będzie się czytać level. Menu główne zostaje w fast ramie bo z powrotem doczytywanie znowu zjada dużo czasu.
Przyznam że może faktycznie coś pominałem i zostaje w pamięci bo było dużo dużo zmian. Inne menu główne, inne grafiki, inna koncepcja w grze, zmiana sterowania na uniwersalne joy/klawiatura. Nie jest mało danych w tej grze wbrew pozorom. Policzcie sobie ile jest obiektów w levelu. Każdy ma swój komplet danych. Tablica levelu to kafle 8x8. Mam przy każdym przechodzeniu między komnatami doczytywać z ADFa tablicę? Oj nie. To już było i nie przeszło. Zbyt długo trzeba czekać na załadowanie. Nie graliście od początku chyba w pierwsze wersje. Gdybyś co komnatę miał czekać kilka sekund na ADF az wczyta to zmieniłbyś zdanie.
Może faktycznie zbyt dużo danych mam narqz załadowane ale to głównie też przez to żeby zaoszczędzić czekania na załadowanie wszystkiego z ADFa. Pobierz sobie demko Tonego, ustaw floppy na 100% i licz czas jak długo będzie się czytać level. Menu główne zostaje w fast ramie bo z powrotem doczytywanie znowu zjada dużo czasu.
Przyznam że może faktycznie coś pominałem i zostaje w pamięci bo było dużo dużo zmian. Inne menu główne, inne grafiki, inna koncepcja w grze, zmiana sterowania na uniwersalne joy/klawiatura. Nie jest mało danych w tej grze wbrew pozorom. Policzcie sobie ile jest obiektów w levelu. Każdy ma swój komplet danych. Tablica levelu to kafle 8x8. Mam przy każdym przechodzeniu między komnatami doczytywać z ADFa tablicę? Oj nie. To już było i nie przeszło. Zbyt długo trzeba czekać na załadowanie. Nie graliście od początku chyba w pierwsze wersje. Gdybyś co komnatę miał czekać kilka sekund na ADF az wczyta to zmieniłbyś zdanie.
16.08.2023 11:44
[#165]
Re: Tony - development nowej gry
@tukinem, post #164
pobrałem z ciekawości wersję demo i mam parę uwag, ale najpierw myślę że trzeba nieco ostudzić emocje bo robi się jakoś nerwowo wg mnie. nikt tutaj nie piętnuje twojej pracy, wręcz przeciwnie wszyscy podziwiamy Twoje postępy od kilku miesięcy. Ja podziwiam.
Kilka uwag do wersji demo jakie mam jednak na szybko to
- po co są pliki .lbm (np 01.lbm, itp)? zgaduję że to kolizje i wg mnie można to zrobić inaczej i zaoszczędzić pamięć.
- plik z mapą ma 10kb spakowany co nie jest dużo.rozpakowany zakładam 48000 bajtów jak liczyłem wcześniej więc możesz takich plików spakowanych mieć w pamięci zdecydowanie więcej i rozpakowywać tylko te elementy mapy które są teraz potrzebne. szybciej na pewno niż załadować pliki z dyskietki.
- masz masę plików i to słychać podczas ładowania. to też bardzo spowalnia wczytanie
- dodatkowo dla wielu plików BB musi allokować pamięć więc tu mogą pojawić się problemy z poszatkowaną pamięcią.
- pliki .dat połączył bym w jeden plik. zakładam że to są boby albo sprajty ruchomych elementów. ponownie to wczyta się szybciej niż kilkanaście plików oddzielnie i może zająć mniej miejsca w pamięci.
- wszystkie grafiki tytułowe mają 4 kolor (2 bitplany) co wg mnie jest zupełnie zbędne.
- kafelki 8x8 to wg mnie także nienajlepsze rozwiązanie. po pierwsza mapa jest większa i chyba dłużej buduję się plansza. sam Blit albo Block 16 pikselowego kafelka jest chyba szybszy, ale rozumiem że grafika jest już gotowa.
to tak na szybko. każdy z tych punktów wg mnie to miejsce do optymalizacji.
pisałem wcześniej o tej inżynierii ale jest jeszcze jeden aspekt optymalizacji w grach :)
negocjacje z grafikiem i muzykiem aby obcinać ich pomysły ;) ja rozumiem układ na jakim powstaje ta gra (na wszystkie platformy) ale kompromisy to także element retro-developmentu.
Trzymam nadal kciuki!
Ostatnia aktualizacja: 16.08.2023 11:45:53 przez c64portal
Kilka uwag do wersji demo jakie mam jednak na szybko to
- po co są pliki .lbm (np 01.lbm, itp)? zgaduję że to kolizje i wg mnie można to zrobić inaczej i zaoszczędzić pamięć.
- plik z mapą ma 10kb spakowany co nie jest dużo.rozpakowany zakładam 48000 bajtów jak liczyłem wcześniej więc możesz takich plików spakowanych mieć w pamięci zdecydowanie więcej i rozpakowywać tylko te elementy mapy które są teraz potrzebne. szybciej na pewno niż załadować pliki z dyskietki.
- masz masę plików i to słychać podczas ładowania. to też bardzo spowalnia wczytanie
- dodatkowo dla wielu plików BB musi allokować pamięć więc tu mogą pojawić się problemy z poszatkowaną pamięcią.
- pliki .dat połączył bym w jeden plik. zakładam że to są boby albo sprajty ruchomych elementów. ponownie to wczyta się szybciej niż kilkanaście plików oddzielnie i może zająć mniej miejsca w pamięci.
- wszystkie grafiki tytułowe mają 4 kolor (2 bitplany) co wg mnie jest zupełnie zbędne.
- kafelki 8x8 to wg mnie także nienajlepsze rozwiązanie. po pierwsza mapa jest większa i chyba dłużej buduję się plansza. sam Blit albo Block 16 pikselowego kafelka jest chyba szybszy, ale rozumiem że grafika jest już gotowa.
to tak na szybko. każdy z tych punktów wg mnie to miejsce do optymalizacji.
pisałem wcześniej o tej inżynierii ale jest jeszcze jeden aspekt optymalizacji w grach :)
negocjacje z grafikiem i muzykiem aby obcinać ich pomysły ;) ja rozumiem układ na jakim powstaje ta gra (na wszystkie platformy) ale kompromisy to także element retro-developmentu.
Trzymam nadal kciuki!
Ostatnia aktualizacja: 16.08.2023 11:45:53 przez c64portal
16.08.2023 13:49
[#166]
Re: Tony - development nowej gry
@tukinem, post #164
Jestem od niedawna szczęśliwym posiadaczem A500 z 512 Kb Chip i zepsutą stacją dysków. Zamierzam dokupić PiStorma, by mieć więcej pamięci i twardy dysk. Moje pytanie brzmi: Czy ta gra będzie chodziła na PiStormie?
Co do dyskusji odnośnie optymalizacji to świetny temat, ale w dzisiejszych czasach najważniejszy jest czas. Dlatego cała gra powinna być w pamięci fast łącznie z dyskietkami. Gra ma chodzić jak zegarek, bez czekania na jakieś dogrywanie. Gra ma w dwie sekundy załadować się do pamięci i zanim mrugnę ma chodzić. Jak ktoś chce zgrzytania dyskietki to mogę taki program napisać i gdy pójdzie się spać to przez całą noc będzie się słyszeć ten terkot.
Wgraj sampla zgrzyt= zgrzyt..zgrzyt...zgrzt.tt..t..ttt.....
From x=0 to 1
Odegraj sampla zgrzyt
X=0
Next
Co do dyskusji odnośnie optymalizacji to świetny temat, ale w dzisiejszych czasach najważniejszy jest czas. Dlatego cała gra powinna być w pamięci fast łącznie z dyskietkami. Gra ma chodzić jak zegarek, bez czekania na jakieś dogrywanie. Gra ma w dwie sekundy załadować się do pamięci i zanim mrugnę ma chodzić. Jak ktoś chce zgrzytania dyskietki to mogę taki program napisać i gdy pójdzie się spać to przez całą noc będzie się słyszeć ten terkot.
Wgraj sampla zgrzyt= zgrzyt..zgrzyt...zgrzt.tt..t..ttt.....
From x=0 to 1
Odegraj sampla zgrzyt
X=0
Next
16.08.2023 14:02
[#167]
Re: Tony - development nowej gry
@tukinem, post #164
W Amosie nie stworzysz tablicy w typie bajta lub worda. Nie masz struktur chyba.
to nie tak...
mozesz stworzyc sobie sam strukture tablicy o danym rozmiarze (banki pamieci) ale to zmienna na ktorej operujesz jest 4-bajtowa.
W Amosie kluczowe jest zoptymalizowanie programu a to wymaga setek programow testowych, dlatego w latach 90-tych nie powstala zadna swietna gra, bo nikt nie wiedzial jak sie optymalizuje amosowy program a w manualu nie ma o tym slowa.
w kazdy razie... sporo jeszcze musisz sie 'naumiec' w Blitzie zanim stworzysz cos 'szybkiego'.
Nie ma sensu wynajdywanie kola samemu, najlepiej podpatrzyc jak zrobili to inni w grach stworzonych w BB. A wiec szukaj kodow zrodlowych i je analizuj i zakoduj sobie, ze Amiga a komputery 8-bit to inne maszynki i tutaj duzo rzeczy wyglada zupelnie inaczej.
16.08.2023 14:15
[#170]
Re: Tony - development nowej gry
@tukinem, post #164
Wiesz, dobrze napisane gry Amigowe potrafily wykorzystywac extra pamiec ale dzialac tez na 1MB czy 0.5 MB RAM (np. Turrican 2). I tu jest podstawowa roznica. Taka gra jak ta powinna dzialac na 0.5MB RAM, maximum na 1 MB RAM. Za to moze ona wykorzystywac wieksza ilosc pamieci na buforowanie danych, ale odgorne zalozenie trzymania wszystkich (albo wiekszosci) danych w pamieci to nie jest Amigowe podejscie. Tylko wymysl Linuxa i Windowsa, bo tak jest latwiej. Ale z czysto praktycznego podejscia, po prostu ograniczasz sam sobie liczbe osob, ktore zakupia ta gre, bo nie beda mialy wystarczajacej ilosci pamieci, juz teraz odpada jakies 90% Amig 500/500+/600. Byc moze gola A1200 z 2MB chip to tez juz jest za malo, a tego to raczej nawet Selur nie przezyje.
16.08.2023 14:47
[#171]
Re: Tony - development nowej gry
@Don_Adan, post #170
A z jakiej racji na A1200 ma nie działać? Właśnie że działa bo A1200 ma 2MB chp ramu więc jeszcze więcrj niż wymagania minimalne. Wszyscy nie możecie znieść tego że wymagania są podniesione do 1MB fast ram. Mamy 21 wiek i naprawdę jeśli ktoś gra na Amidze 500 czy 600 to nie posiada tego 1MB fast ram? Może zaraz ktoś powie że gra się nie nadaje na Amigę bo nie ruszy na gołej Amidze 1000 z 256kB chip ram i kick 1.2. Czy tu na forum musi być tylu malkontentów? I tak 90% z Was używa emulacji więc o co te pretensje? Mam dopisać masę kodu sprawdzania pamięci i dwojako zrobić ładowanie danych z gry? Wątpię że to się uda. Według was jest mało danych bo gra jest 2-kolorowa. Spoko niech tak będzie. Gra ma dwa kolory więc powinna chodzić na Amidze z 2x0.5 MB ram. Jakoś jak Farmigę pisałem w Amosie to wyszło jeszcze więcej wymagań do gry i nikomu to nie przeszkadzało. Tutaj ewidentnie gra musi działać na golasie bo ma 2 kolory. To jest kluczowe dla was. Nie ważne że są dźwięki i muzyka jednocześnie co w wielu grach było rqczej do wyboru. Po wciśnięciu klawisza P wyświetla się grafika z pauzą. W starych grach tylko gra się zatrzymywała. Nie widzicie ile wodotrysków ma ta gra.sam plik wykonywalny po rozpakowaniu zajmuje też dużo. Tego nikt nie widzi. Wystarczy sobie Stonecrackerem rozpakować i zobaczyć co zapycha ram a nie narzucać tutaj swoje "bo tak być musi".
16.08.2023 14:48
[#172]
Re: Tony - development nowej gry
@koczis, post #166
Dlatego cała gra powinna być w pamięci fast łącznie z dyskietkami. Gra ma chodzić jak zegarek, bez czekania na jakieś dogrywanie. Gra ma w dwie sekundy załadować się do pamięci i zanim mrugnę ma chodzić. Jak ktoś chce zgrzytania dyskietki to mogę taki program napisać i gdy pójdzie się spać to przez całą noc będzie się słyszeć ten terkot.
Od tego co napisałeś w pierwszym zdaniu masz WHDLoad z opcją PRELOAD. Jak dla mnie celem każdego autora powinien być jak największy zasięg tworzonej gry i najszersza baza użytkowników, także A500 z 1MB RAM. Tym bardziej, że to wersja konceptu z 8-bit
Tak uważam pomimo tego, że będę odpalać najpewniej tylko na 060
Ostatnia aktualizacja: 16.08.2023 14:49:53 przez Jacques
16.08.2023 15:40
[#173]
Re: Tony - development nowej gry
@tukinem, post #171
Dodam jeszcze, że mam w sobie sporo pokory, ale pieklę się, bo niestety ale mam świadomość że się uczę ciągle i praktycznie zawsze się będę uczyć programowania/kodowania na Amidze, bo mi się to podoba. AmigaC i AmigaE to nie moja bajka, stwierdzam pokornie że do tych języków się nie nadaję, bo jestem zbyt głupi. Dziwnie to zabrzmi, ale bardziej mi asembler leży, bo coś potrafię w nim napisać (choćby same obliczenia i warunki). Przyznaję też, że tutaj jest sporo koderów, którzy lepiej by napisali Tonego, ale Rafał wybrał mnie, może za to ile czasu poświęcam na to, a może za to że coś jednak tworzę usilnie, a nie narzekam ciągle. Naprawdę nieraz było tak, że wprowadziłem grafikę do gry, ustawiłem copperlistę, paletę, wszystko pięknie ładnie, ledwo zdążyłem skompilować, a tu dostałem wiadomość, że zmiana planów, że inna grafika, inny rozmiar, inny styl.
Co do mojej pokory, przyznam że nie znam się na hardware Amigi na tyle dobrze, więc niech ktoś jeszcze mnie oświeci i mi powie dwie rzeczy, bo może to zjada sporo fast ramu:
1 - Uruchamiając grę plik wykonywalny siedzi w fast ramie czy w chip ramie?
2 - Jeśli plik wykonywalny jest spakowany Stonecrackerem, to w pamięci ram ten plik jest już wypakowany?
Bo jeśli to wędruje do fast ramu i siedzi tam rozpakowane, to nie dziwi mnie że tyle zjada pamięci. Proszę, oto pokaz ile zajmuje plik wykonywalny przed spakowaniem go:
Co do mojej pokory, przyznam że nie znam się na hardware Amigi na tyle dobrze, więc niech ktoś jeszcze mnie oświeci i mi powie dwie rzeczy, bo może to zjada sporo fast ramu:
1 - Uruchamiając grę plik wykonywalny siedzi w fast ramie czy w chip ramie?
2 - Jeśli plik wykonywalny jest spakowany Stonecrackerem, to w pamięci ram ten plik jest już wypakowany?
Bo jeśli to wędruje do fast ramu i siedzi tam rozpakowane, to nie dziwi mnie że tyle zjada pamięci. Proszę, oto pokaz ile zajmuje plik wykonywalny przed spakowaniem go:
16.08.2023 15:44
[#174]
Re: Tony - development nowej gry
@tukinem, post #171
Czym innym jest wymaganie fastu, a czym innym wymaganie chipu. Ogolnie jesli nie ma to znaczenia to sie zwykle podaje plus 1MB RAM innej pamieci. No i to ze sie gra uruchomi na 2MB chipu to wcale nie oznacza, ze bedzie cala dzialala, np. 4 level moze sie juz nie wczytac bo pamiec bedzie pofragmentowana przez wczytywanie poprzednich leveli. Szczegolnie jesli czesto uzywasz alokacji i dealokacji pamieci. Najlepiej jest zawsze pisac gre w ten sposob jak podal Mastaszek, przydzielasz sobie 2 bloki pamieci, np. 320KB chip i 400 KB fast (innej) pamieci, i sam nimi zarzadzasz (czyli ladujesz/depakujesz) dane gdzie sam chcesz.
Co do ilosci pamieci w A600, to standardowo ma tylko 1MB chipu, rozszerzenia do 2MB chipu byly bardzo drogie kiedys i podejrzewam, ze malo osob je ma. Oczywiscie sa jeszcze karty turbo z fastem do A600. Ale tez raczej tez malo osob je ma.
Podobnie jest z A500, rozszerzenia pamieci o wiecej niz 0.5MB slowfast byly bardzo drogie i rzadko spotykane. Wiec tez raczej karta turbo do A500 z fastem bedzie potrzebna.
Ty raczej tworzysz gre, ktora bedzie wymagala HD, a nie stacji dyskietek, wtedy i wymagania dotyczace pamieci sa zwykle inne/wieksze.
Nie wiem ile ma exek z tej gry (bo nie mam dostepu do Amigi) , ale czesto jak sie dobrze nie zna opcji kompilatora to dolacza on do exeka rzeczy zbedne. Ale powinienes pamietac, ze w Blitz Basicu 2, byly stworzone takie gry jak SkidMarks czy Worms, wiec da sie.
Co do ilosci kolorow to mi sie podobaja 2 kolory i 2 bitplany. Ale powinienes wiedziec, ze beda komentarze w stylu "tylko 2 kolory i az 2MB pamieci".
Co do ilosci pamieci w A600, to standardowo ma tylko 1MB chipu, rozszerzenia do 2MB chipu byly bardzo drogie kiedys i podejrzewam, ze malo osob je ma. Oczywiscie sa jeszcze karty turbo z fastem do A600. Ale tez raczej tez malo osob je ma.
Podobnie jest z A500, rozszerzenia pamieci o wiecej niz 0.5MB slowfast byly bardzo drogie i rzadko spotykane. Wiec tez raczej karta turbo do A500 z fastem bedzie potrzebna.
Ty raczej tworzysz gre, ktora bedzie wymagala HD, a nie stacji dyskietek, wtedy i wymagania dotyczace pamieci sa zwykle inne/wieksze.
Nie wiem ile ma exek z tej gry (bo nie mam dostepu do Amigi) , ale czesto jak sie dobrze nie zna opcji kompilatora to dolacza on do exeka rzeczy zbedne. Ale powinienes pamietac, ze w Blitz Basicu 2, byly stworzone takie gry jak SkidMarks czy Worms, wiec da sie.
Co do ilosci kolorow to mi sie podobaja 2 kolory i 2 bitplany. Ale powinienes wiedziec, ze beda komentarze w stylu "tylko 2 kolory i az 2MB pamieci".
16.08.2023 15:59
[#175]
Re: Tony - development nowej gry
@tukinem, post #173
Exek siedzi tam gdzie mu chunki nakazuja, a jak sa dowolne to najpierw stara sie zaladowac do fastu, a jak nie ma wolnego fastu to do chipu. W pamieci jest on juz wypakowany. Exek z gry troche duzy choc zalezy co oprocz kodu w nim jest jeszcze, moze po prostu puste buffory lub rzeczy zbedne. Zalezy do ilu bajtow sie pakuje.
16.08.2023 16:04
[#176]
Re: Tony - development nowej gry
@Don_Adan, post #174
Alokując blok pamięci w fast ram, jeśli nie jest dostępna, to automatycznie alokuje w chip ramie. Dlatego na A500 z dodatkowym 1MB pamięci chip też gra zadziała. A Amiga 500 z 1,5MB chip ram to chyba nie problem? Rafał wychodzi z założenia, że gra ma mieć bajery, czyli w menu głównym mam Dual Playfield z wielką bitmapą przesuwającą tekst. Przechodzenie z komnaty do komnaty ma działać szybko, więc bitmapy kolizyjne i cała tablica levelu jest wczytana do fast ramu. W Prince of Persia pomiędzy komnatami był po prostu przeskok graficzny. Tutaj ładnie jest przyciemnianie i rozjaśnianie ekranu za każdym razem, bo koder z ZX Spectrum wyszedł z inicjatywą i zrobił taki numer, że widać przenikanie jednego ekranu na drugi. Nie mogłem pozwolić żeby tutaj było biednie po prostu przerysowanie bitmapy. To też są kolejne linijki kodu. Póki co kod Tonego ma prawie 3000 linii kodu (plus dwa pliki gdzie jeden jest od menu głównego gry, a drugi od samych struktur i deklaracji zmiennych/tablic itd). Zaczynając pisać Tonego wiele jeszcze nie wiedziałem o blokach pamięci. Deklarowanie tablic też musiałbym zrobić na blokach pamięci, a mam jedynie deklarację poprzez Dim. Gdybym używał bloków pamięci wszędzie, to ciężko byłoby mi ogarnąć struktury Tonego i obiektów.
Skoro piszesz, że zależy ile zajmuje po spakowaniu to w fast ramie siedzi jako spakowany? Spakowany zajmuje 76kB.
Ostatnia aktualizacja: 16.08.2023 16:06:54 przez tukinem
Skoro piszesz, że zależy ile zajmuje po spakowaniu to w fast ramie siedzi jako spakowany? Spakowany zajmuje 76kB.
Ostatnia aktualizacja: 16.08.2023 16:06:54 przez tukinem
16.08.2023 17:10
[#178]
Re: Tony - development nowej gry
@tukinem, post #176
Sa eksperci od sprzetu na PPA. Ale wedlug mnie A500 z 1.5MB chip (a pewnie w zasadzie 2MB chip) to bardzo rzadko spotykana Amiga, ale moze sie myle. Amiga normalnie (upraszczajac) moze alokowac 3 typy pamieci. Jesli alokujesz fast to jak go nie ma wolnego w ilosci potrzebnej to zwroci Ci blad. To samo dotyczy pamieci chip. Ale jak alokujesz pamiec inna/dowolna, to jest tak jak piszesz, zwykle najpierw to bedzie fast a potem chip, zalezy od priorytetow pamieci.
W pamieci fast/innej mozna trzymac tylko najczesciej uzywane dane. Np. wchodzisz do komnaty to sa tam wtedy wczytane dane dla 4, sasiednich komnat z gory, dolu, lewa i prawa. Wchodzisz do nastepnej komnaty to tez znowu tylko dla 4 sasiednich komnat dane. czyli doczytywalo by sie dane dla 3 sasiednich komnat tylko, w momencie kiedy sie wchodzi na nowa komnate. Ewentualnie trzymac dane komnat w formie spakowanej w pamieci, i rozpakowywac je jak gracz wchodzi do nowej komnaty. To wedlug mnie powinno wystarczyc, zeby bylo plynnie i mniejsza ilosc pamieci byla potrzebna.
A co do exeka z gry to po prostu chodzilo mi o to czy on ma puste miejsca. I tak wyglada, ze troche ich ma, bo sie calkiem niezle pakuje.
W pamieci fast/innej mozna trzymac tylko najczesciej uzywane dane. Np. wchodzisz do komnaty to sa tam wtedy wczytane dane dla 4, sasiednich komnat z gory, dolu, lewa i prawa. Wchodzisz do nastepnej komnaty to tez znowu tylko dla 4 sasiednich komnat dane. czyli doczytywalo by sie dane dla 3 sasiednich komnat tylko, w momencie kiedy sie wchodzi na nowa komnate. Ewentualnie trzymac dane komnat w formie spakowanej w pamieci, i rozpakowywac je jak gracz wchodzi do nowej komnaty. To wedlug mnie powinno wystarczyc, zeby bylo plynnie i mniejsza ilosc pamieci byla potrzebna.
A co do exeka z gry to po prostu chodzilo mi o to czy on ma puste miejsca. I tak wyglada, ze troche ich ma, bo sie calkiem niezle pakuje.
16.08.2023 17:27
[#179]
Re: Tony - development nowej gry
@Don_Adan, post #178
czesc
to ja jestem sprawca tego zamieszania... chcialem by TONY byl na Amidze bo jako stary Amigowiec mam sentyment, szukalem kodera a wiecie jakie to zadanie dla czlowieka ktory nie ma znajomych i plecow na scenie... na dziesiatki z moich listow email odpisal jeden... Pawel.
Zaznaczyl ze gre napisze w Blitzbasic, ale skoro gra pierwotnie jest robiona na 8bit Atari, C64 i ZX Spectrum to uznalem ze spokojnie Amisia da rade nawet w basicu. Amiga to kolory Pawel chcial kolorow, tu zaprzeczylem, tego nie zmienie bo grafika ma byc taka sama na Amidze i 8bit.. tzn na Amidze jest wiecej grafik i sie okazuje ze poziomy beda wieksze tu limit 8bit jest bezwzgledny. Wiec moja koncepcja gry na Amidze nie jest cieta na 8bit czasem musiala byc troszke pozmieniana.
Dodatkowo Pawel wiele mi uswiadomil bo jako grafik DTP malo sie znam na grach i do tego rastrowych w niskiej rozdzielczosci mono .. :D
Przez ten czas co pracowalem z Pawlem, ja i on sie rozwinal, i powiem tyle mam wielki szacunek za czas i jego ciezka prace bo malo kto tak pracowity jest.
Jak gra bedzie miala wymagania 1MB to co z tego, dla mnie to nie problem na opakowaniu gry bedzie adnotacja jaki konfig minimalny. Ciesze sie ze gra jest na Amidze a nie ze na Amidze bedzie gra pod emulatorem Atari czy C64.
Pozdrawiam serdecznie wszystkich czytajacych
to ja jestem sprawca tego zamieszania... chcialem by TONY byl na Amidze bo jako stary Amigowiec mam sentyment, szukalem kodera a wiecie jakie to zadanie dla czlowieka ktory nie ma znajomych i plecow na scenie... na dziesiatki z moich listow email odpisal jeden... Pawel.
Zaznaczyl ze gre napisze w Blitzbasic, ale skoro gra pierwotnie jest robiona na 8bit Atari, C64 i ZX Spectrum to uznalem ze spokojnie Amisia da rade nawet w basicu. Amiga to kolory Pawel chcial kolorow, tu zaprzeczylem, tego nie zmienie bo grafika ma byc taka sama na Amidze i 8bit.. tzn na Amidze jest wiecej grafik i sie okazuje ze poziomy beda wieksze tu limit 8bit jest bezwzgledny. Wiec moja koncepcja gry na Amidze nie jest cieta na 8bit czasem musiala byc troszke pozmieniana.
Dodatkowo Pawel wiele mi uswiadomil bo jako grafik DTP malo sie znam na grach i do tego rastrowych w niskiej rozdzielczosci mono .. :D
Przez ten czas co pracowalem z Pawlem, ja i on sie rozwinal, i powiem tyle mam wielki szacunek za czas i jego ciezka prace bo malo kto tak pracowity jest.
Jak gra bedzie miala wymagania 1MB to co z tego, dla mnie to nie problem na opakowaniu gry bedzie adnotacja jaki konfig minimalny. Ciesze sie ze gra jest na Amidze a nie ze na Amidze bedzie gra pod emulatorem Atari czy C64.
Pozdrawiam serdecznie wszystkich czytajacych
16.08.2023 17:36
[#180]
Re: Tony - development nowej gry
@RDudek, post #179
@rdudek
jeśli takie przyjąłeś założenia to mi (nam) w sumie nic do tego. ja komentuję bo zakładam że nie tylko tukinem ale wszyscy przy okazji czegoś się uczymy.
@tukinem
gra po wczytaniu w pamięci fast zajmie tyle ile ma rozpakowana. przecież spakowany kod nie będzie się wykonywał ;). nie wiem jak działa loader STC ale zakładam że rozpakowuje go stopniowo podczas ładowania (tak robi np Titanics).
swoją drogą to 266 kb po rozpakowaniu to bardzo dużo. czy do kompilacji końcowej wyłaczasz opcje debugera
"Runtime Debugger" i "Make smallest code" ?
jeśli takie przyjąłeś założenia to mi (nam) w sumie nic do tego. ja komentuję bo zakładam że nie tylko tukinem ale wszyscy przy okazji czegoś się uczymy.
@tukinem
gra po wczytaniu w pamięci fast zajmie tyle ile ma rozpakowana. przecież spakowany kod nie będzie się wykonywał ;). nie wiem jak działa loader STC ale zakładam że rozpakowuje go stopniowo podczas ładowania (tak robi np Titanics).
swoją drogą to 266 kb po rozpakowaniu to bardzo dużo. czy do kompilacji końcowej wyłaczasz opcje debugera
"Runtime Debugger" i "Make smallest code" ?