16.08.2023 17:54
[#181]
Re: Tony - development nowej gry
@c64portal, post #180
Się udzielę :)
Co do pliku wykonywalnego BlitzBasic który tyle zajmuje, to jest wina funkcji z jakich się korzysta. Jeśli dobrze zrozumiałem zasadę na jakiej to działa, to chyba użycie jednej funkcji z danej biblioteki dołącza ją całą. Mało tego, wystarczy że, w bibliotece jest odwołanie do funkcji z innej biblioteki i znowu cała biblioteka ląduje w kodzie i takich zależności może być wiele. Tak właśnie puchnie kod programu.
Co do pliku wykonywalnego BlitzBasic który tyle zajmuje, to jest wina funkcji z jakich się korzysta. Jeśli dobrze zrozumiałem zasadę na jakiej to działa, to chyba użycie jednej funkcji z danej biblioteki dołącza ją całą. Mało tego, wystarczy że, w bibliotece jest odwołanie do funkcji z innej biblioteki i znowu cała biblioteka ląduje w kodzie i takich zależności może być wiele. Tak właśnie puchnie kod programu.
16.08.2023 18:01
[#182]
Re: Tony - development nowej gry
@RDudek, post #179
Problem jest taki, ze obecna wersja gry wymaga 1.5MB pamieci, a nie 1MB pamieci.Czyli w zasadzie wymaga 2MB pamieci, bo takie byly rozszerzenia pamieci, nie wiem czy jest jakas Amiga, ktora ma 1.5MB pamieci, az tak sie nie znam na kartach pamieci/turbo do Amigi. O ile dobrze pamietam to w latach 90-tych byly tylko 2 gry dyskietkowe na Amige 500/ 600, ktore wymagaly 2MB RAM (1MB chip plus 1MB innej), to byl Legion i Primal Rage. Ale zrobicie jak chcecie, mozecie tworzyc gre na 2MB pamieci. Tylko wtedy raczej gra bedzie miala duzo mniejszy odbior wsrod uzytkownikow Amigi.
16.08.2023 19:16
[#183]
Re: Tony - development nowej gry
@c64portal, post #180
Bardzo dużo bo sam kod jest duży. Jak pisałem wyżej, to jest 3 tys linijek, a przyznam, że sterowanie Tonym pisane przeze mnie w asemblerze jest tak zakodowane, że kilka komend jest w jednej linii, co nie powinno tak wyglądać, ale dla mnie to było bardziej czytelne pisząc w emulatorze. Oczywiście Blitz Basic wplata sobie swoje biblioteki, które są użyte w kodzie. Skoro fast ram zabiera pełny plik wykonywalny, to mamy już powód, dlaczego gra tyle zajmuje.
Co do make smallest code, to widziałem tą funkcję w kompilatorze AmiBlitz 3.9. Blitz Basic 2.1 chyba nie ma tego.
Co do make smallest code, to widziałem tą funkcję w kompilatorze AmiBlitz 3.9. Blitz Basic 2.1 chyba nie ma tego.
16.08.2023 19:31
[#184]
Re: Tony - development nowej gry
@Don_Adan, post #182
Nie wymaga 2MB :) Obecnie wymaga 0.5MB chip ram + 1MB dowolnej pamięci (może być slow ram, fast ram lub chip ram). Nie ma mowy o 2MB pamięci. Strzeliłem z głupa o A500 z 1,5MB chip ram, bo jeśli mamy golasa A500 bez slow ramu i dołożymy mu 1MB chip ram, to powinna mieć 1,5MB chip ram bez niczego innego. Na takim configu Tony będzie działać, skoro działa na 0,5 CHIP + 1MB slow/fast. No chyba że odpalimy spod Workbencha, który po drodze zje 3/4 pamięci :)
Problemu by nie było, gdybym grę stworzył jak gry w starym dobrym stylu, czyli ADF w systemie NDOS. Wtedy nikogo by nie korciło, żeby ruszać to pod systemem. Ewentualnie WHDLoad, no ale NDOS-a chyba nigdy nie tknę, bo nie mogłem znaleźć nic na jego temat. Wtedy faktycznie nie bawiłbym sie w trzymanie czegokolwiek na dłużej w fast ramie.
Problemu by nie było, gdybym grę stworzył jak gry w starym dobrym stylu, czyli ADF w systemie NDOS. Wtedy nikogo by nie korciło, żeby ruszać to pod systemem. Ewentualnie WHDLoad, no ale NDOS-a chyba nigdy nie tknę, bo nie mogłem znaleźć nic na jego temat. Wtedy faktycznie nie bawiłbym sie w trzymanie czegokolwiek na dłużej w fast ramie.
16.08.2023 19:35
[#185]
Re: Tony - development nowej gry
@RDudek, post #179
Tylko widzisz, to wymagane obecnie przez Tony'ego 1MB (teraz już chyba nawet 1,5MB) to nie całkiem jest to samo 1MB widywane w standardowych pięćsetkach 30 lat temu. Ta gra nie pójdzie na typowej A500. No ale skoro zdecydowaliście, że klientem docelowym będą posiadacze lepsiejszych amig, to spoko - to przecież Wasza gra. A my się po prostu wymądrzamy, żeby nie było zbyt sielankowo, bo Panie - to nie EAB ;) Róbcie swoje, trzymam kciuki.
16.08.2023 21:29
[#189]
Re: Tony - development nowej gry
@c64portal, post #188
Mam identycznie:
Wersja to Ultimate Blitz Basic 2.1 CD. Kiedyś przykładowo porównałem sobie użycie z niego Timer i ResetTimer. Trochę więcej zajęło po kompilacji niż to samo napisane przeze mnie w asemblerze bez ruszania biblioteki Blitza. Czysty Blitz Basic 2 nie ma obsługi Timera. Tak samo czysty Blitz nie ma wielu bibliotek, które są użyte w Tonym. Oczywiście w Tonym pominąłem bibliotekę Timera, a napisałem sobie swoją procedurkę w asemblerze od tego, chociaż to akurat kropla w morzu. Bibliotek Blitza używam sporo. W sumie to cała obsługa hardware jest to biblioteki Blitza. A naprawdę jest sporo. W menu są dwie copperlisty. Jedna jest zwykła, druga jest w DualPlayfield. Intro też jest duże, bo i jest FadePalette, są tablice palet itd itd. Na końcu kodu mam też kilka bloków danych napisanych w postaci Dc, bo tak miałem do tych danych łatwiejszy dostęp, gdy pisałem sterowanie w asemblerze.
To żadna tajemnica, więc tutaj wrzucam te dane:
I tak są bezużyteczne, dla kogoś kto nie posiada grafik, tablic i nie wie do czego służą te zmienne.
Wersja to Ultimate Blitz Basic 2.1 CD. Kiedyś przykładowo porównałem sobie użycie z niego Timer i ResetTimer. Trochę więcej zajęło po kompilacji niż to samo napisane przeze mnie w asemblerze bez ruszania biblioteki Blitza. Czysty Blitz Basic 2 nie ma obsługi Timera. Tak samo czysty Blitz nie ma wielu bibliotek, które są użyte w Tonym. Oczywiście w Tonym pominąłem bibliotekę Timera, a napisałem sobie swoją procedurkę w asemblerze od tego, chociaż to akurat kropla w morzu. Bibliotek Blitza używam sporo. W sumie to cała obsługa hardware jest to biblioteki Blitza. A naprawdę jest sporo. W menu są dwie copperlisty. Jedna jest zwykła, druga jest w DualPlayfield. Intro też jest duże, bo i jest FadePalette, są tablice palet itd itd. Na końcu kodu mam też kilka bloków danych napisanych w postaci Dc, bo tak miałem do tych danych łatwiejszy dostęp, gdy pisałem sterowanie w asemblerze.
To żadna tajemnica, więc tutaj wrzucam te dane:
I tak są bezużyteczne, dla kogoś kto nie posiada grafik, tablic i nie wie do czego służą te zmienne.
16.08.2023 23:34
[#191]
Re: Tony - development nowej gry
@mastaszek, post #158
Mamy 2023r. Rozszerzenie RAM nie kosztuje już małej fortuny z początku lat '90. Jest pełno fajnych rozszerzeń, dużo tańszych niż najtańsza Amiga.
Czas poświęcony na zmniejszenie wymagań nie jest warty poświęcenia wielu, wielu godzin, które lepiej przeznaczyć na dokończenie gry,
Starzy wyjadacze mogą robić swoje gry na 512kB CHIP, bo nie jest to dla nich takie trudne. To moje zdanie.
Czas poświęcony na zmniejszenie wymagań nie jest warty poświęcenia wielu, wielu godzin, które lepiej przeznaczyć na dokończenie gry,
Starzy wyjadacze mogą robić swoje gry na 512kB CHIP, bo nie jest to dla nich takie trudne. To moje zdanie.
17.08.2023 04:52
[#192]
Re: Tony - development nowej gry
@Don_Adan, post #190
2 pliki .exe? Co to da? Każesz mi teraz pół gry przepisać, bo zarówno menu gry jak i pętla główna samej rozgrywki korzystają z tablicy palet kolorów i zmiennych. Jak mam w programie uruchomić inny exe? Nie znam takiej opcji. Może w Amosie jest ale tutaj nie wiem. To za dużo kombinacji. Nie ma sensu robić takich schodów pod górę dla 512kB pamięci.
17.08.2023 09:54
[#194]
Re: Tony - development nowej gry
@tukinem, post #192
Ja Ci nic nie kaze. Po prostu Amiga ma cos takiego jak startup-sequence. I tam piszesz/tworzysz:
TonyIntro
TonyGame
I Amiga zrobi to za Ciebie.
Z punktu widzenia programisty kopiujesz zrodla drugi raz. Czyli masz 2 zrodla. Z jednych zrodel usuwasz wszystko co dotyczy tylko samej gry. A z drugich usuwasz wszystko co dotyczy tylko samego intra.
TonyIntro
TonyGame
I Amiga zrobi to za Ciebie.
Z punktu widzenia programisty kopiujesz zrodla drugi raz. Czyli masz 2 zrodla. Z jednych zrodel usuwasz wszystko co dotyczy tylko samej gry. A z drugich usuwasz wszystko co dotyczy tylko samego intra.
17.08.2023 10:14
[#195]
Re: Tony - development nowej gry
@Don_Adan, post #194
Takie coś w startup sequence nie pozwoli mi na przeniesienie danych zmiennych. Gdybym chciał crack intro przenieść do innego pliku exe to nie przeniosę wtedy danyxmch z tablicy odnośnie nieśmiertelności, levelu startowego itp. To samo w menu głównym. Jeśli ustawimy paletę kolorów w menu i wyjdzie z programu a wejdzie do samej gry, to nie będzie wiedział jaka ma być paleta bo dane zostaną w tamtym programie. Trzeba by zapisywać dane do plików na dysku. Za dużo kombinacji moim zdaniem.
17.08.2023 12:07
[#196]
Re: Tony - development nowej gry
@tukinem, post #195
Gdybym chciał crack intro przenieść do innego pliku exe to nie przeniosę wtedy danyxmch z tablicy odnośnie nieśmiertelności, levelu startowego itp.
Zaraz, zaraz, ale pisaniem crack intra nie zajmuje się autor gry, tylko grupa "hakerska" dodające swoją intro z nieśmiertelnością itd itp. i to oni mają się martwić jak te dane przenieść do gry.
17.08.2023 12:57
[#200]
Re: Tony - development nowej gry
@tukinem, post #195
Od tego sa crackerzy czy trainer makerzy zeby sobie z tym poradzic (po prostu sie odpowiednio ingeruje w kod gry z zewnatrz) . Nowe gry Amigowe maja po prostu dodatkowe wybory w menu gry. Ewentualnie cheat code. Same cracktra to zwykle nie mialy zadnych trainerow. Choc zdarzaly sie cracktra z trainerami. Ale w wiekszosci przypadkow inne grupy Amigowe robily trainery a inne lamaly gre. Co do zapisywanych danych na dyskietce (do pliku/plikow) to wedlug mnie paleta po jej wyborze tylko powinni/mogla byc zapisywana. Byc moze jeszcze hiscore oraz stan gry, zeby ulatwic leniwym graczom granie, i mogli kontynuowac np. od 3 levelu, zamiast od poczatku startowac.
17.08.2023 13:35
[#201]
Re: Tony - development nowej gry
@Don_Adan, post #200
A co do samej gry to mysle, ze ciekawym rozwiazaniem byloby, gdyby kazdy level mial inny kolor, czyli np.
piramida - zolty
atlantyda - niebieski
forest - zielony
itp.
Choc jak ktos by chcial grac tylko w 1 wybranym przez siebie kolorem, to tez moglby sobie tak ustawic.
piramida - zolty
atlantyda - niebieski
forest - zielony
itp.
Choc jak ktos by chcial grac tylko w 1 wybranym przez siebie kolorem, to tez moglby sobie tak ustawic.
17.08.2023 15:18
[#202]
Re: Tony - development nowej gry
@Jacques, post #199
Autor moim zdaniem to osoba która wymyśliła grę. Ja tylko wykonuję swoją robotę.
Co do kolorów, to nie było koncepcji zmiany palet. Dopiero raz Rafał wrzucił zdjęcie Tonego po przeróbce na monitor CRT ala Neptun. To mi się spodobało i ustawiłem tą paletę. Później była ankieta i ludzie wypowiadali się jakie palety kolorów by chcieli. No i tak wszystkie te palety są w grze, a jest ich dziewięć.
Co do kolorów, to nie było koncepcji zmiany palet. Dopiero raz Rafał wrzucił zdjęcie Tonego po przeróbce na monitor CRT ala Neptun. To mi się spodobało i ustawiłem tą paletę. Później była ankieta i ludzie wypowiadali się jakie palety kolorów by chcieli. No i tak wszystkie te palety są w grze, a jest ich dziewięć.
17.08.2023 15:50
[#203]
Re: Tony - development nowej gry
@tukinem, post #195
Czytam, czytam i na serio mam łezkę wzruszenia w oku. Dokładnie takie same dylematy i problemy miałem w 1996 pisząc grę "Rycerze Mroku". Gra była bardzo średnia więc niewiele ludzi ją zna ale w 1997 zdążyła jeszcze zostać wydana przez Avalon. Pod sam koniec robienia tej gry musiałem stawić czoła dokładnie temu samemu problemowi. 
Człowiek od zabezpieczeń antypirackich w Avalonie wtedy chwilowo nie był dostępny i poprosili mnie żebym zrobił w grze zabezpieczenie w postaci takiej klasycznej tabeli kodów. Ręce mi opadły, bo zupełnie tego nie zakładałem. Gra była tak upchnięta (jak na moje ówczesne mizerne AMOSowe możliwości), że na serio już czegoś takiego nie mogłem dodać. Program do wpisywania kodów musiał być osobnym execiem. No ale nie wiedziałem jak sprawić żeby gra się uruchomiła jeżeli użytkownik poda poprawny kod i nie uruchomiła jeżeli poda zły. Nie bardzo miałem się kogo poradzić i wymyśliłem coś tak prostackiego, że dzisiaj wręcz wstyd mi o tym pisać. Liczyłem po prostu na to, że nikt się nie domyśli, że można było użyć czegoś tak głupiego.
W startup-sequence były po sobie: program pytający o kod i później sam program gry. Ten pierwszy miał zaszytą dużą tabelę wygenerowanych kiedyś czteroliterowych kodów (wydrukowanych później w instrukcji), prosił kod z wylosowanego wiersza i kolumny. Jeżeli użytkownik podał poprawny to program zapisywał do RAM: malutki plik i zaraz się zamykał. Wtedy odpalał się kolejny exe ze startup-sequence, czyli gra właściwa. I exec gry sprawdzał czy w RAM: jest ten malutki plik. Jeżeli jest to go kasował i gra działała już normalnie. Jeżeli tego pliku nie było (co znaczyło brak poprawnej odpowiedzi) to gra się zamykała.
Gdyby ktoś to podpatrzył i był wystarczająco szybki to mógłby ten malutki plik będący w RAM: przez sekundę czy dwie sobie skopiować, wrzucić na dysk i w startup-sequence zrobić kopiowanie go do RAM: przed uruchomieniem exe gry. Wtedy można byłoby uruchamiać grę zupełnie bez odpalania programu do sprawdzania kodu.
Ale nikt na to chyba nie wpadł. To była przedostatnia gra na Amigę wydana przez Avalon więc nawet nie wiem czy ktokolwiek ją kiedykolwiek złamał, bo zainteresowanie już było prawie żadne.
A tak przy okazji. Istnieje kod, który zawsze jest poprawny. To pierwsze litery imion autorów MAKA (Mariusz, Andrzej, Karol, Artur). Nie trzeba sięgać do tabelki.
A wracając do oszczędzania pamięci to myślę, że dzisiaj pewnie wykombinowałoby się coś co pozwoliłoby zaoszczędzić trochę RAMu. Ale wtedy moja wiedza i świadomość były mizerne. Nie zdawałem sobie sprawy z tego, że Chip nie jest z gumy. Klatki animacji w grze miały 16 kolorów i były wielkości 1/4 ekranu, Tła miały 32 kolory i były na podad 1/4 ekranu, panel 32 kolory i był na pół ekranu. To zjadało absurdalne ilości ChipRAMu. Nawet w startup-sequence odpalałem chyba coś co zamyka ekran systemowy w tle czy zmienia go na dwukolorowy (już nie pamiętam dokładnie ale to był częsty wtedy zabieg).
Ostatnia aktualizacja: 17.08.2023 15:58:47 przez MDW
Człowiek od zabezpieczeń antypirackich w Avalonie wtedy chwilowo nie był dostępny i poprosili mnie żebym zrobił w grze zabezpieczenie w postaci takiej klasycznej tabeli kodów. Ręce mi opadły, bo zupełnie tego nie zakładałem. Gra była tak upchnięta (jak na moje ówczesne mizerne AMOSowe możliwości), że na serio już czegoś takiego nie mogłem dodać. Program do wpisywania kodów musiał być osobnym execiem. No ale nie wiedziałem jak sprawić żeby gra się uruchomiła jeżeli użytkownik poda poprawny kod i nie uruchomiła jeżeli poda zły. Nie bardzo miałem się kogo poradzić i wymyśliłem coś tak prostackiego, że dzisiaj wręcz wstyd mi o tym pisać. Liczyłem po prostu na to, że nikt się nie domyśli, że można było użyć czegoś tak głupiego.
W startup-sequence były po sobie: program pytający o kod i później sam program gry. Ten pierwszy miał zaszytą dużą tabelę wygenerowanych kiedyś czteroliterowych kodów (wydrukowanych później w instrukcji), prosił kod z wylosowanego wiersza i kolumny. Jeżeli użytkownik podał poprawny to program zapisywał do RAM: malutki plik i zaraz się zamykał. Wtedy odpalał się kolejny exe ze startup-sequence, czyli gra właściwa. I exec gry sprawdzał czy w RAM: jest ten malutki plik. Jeżeli jest to go kasował i gra działała już normalnie. Jeżeli tego pliku nie było (co znaczyło brak poprawnej odpowiedzi) to gra się zamykała.
Gdyby ktoś to podpatrzył i był wystarczająco szybki to mógłby ten malutki plik będący w RAM: przez sekundę czy dwie sobie skopiować, wrzucić na dysk i w startup-sequence zrobić kopiowanie go do RAM: przed uruchomieniem exe gry. Wtedy można byłoby uruchamiać grę zupełnie bez odpalania programu do sprawdzania kodu.
Ale nikt na to chyba nie wpadł. To była przedostatnia gra na Amigę wydana przez Avalon więc nawet nie wiem czy ktokolwiek ją kiedykolwiek złamał, bo zainteresowanie już było prawie żadne.
A tak przy okazji. Istnieje kod, który zawsze jest poprawny. To pierwsze litery imion autorów MAKA (Mariusz, Andrzej, Karol, Artur). Nie trzeba sięgać do tabelki.
A wracając do oszczędzania pamięci to myślę, że dzisiaj pewnie wykombinowałoby się coś co pozwoliłoby zaoszczędzić trochę RAMu. Ale wtedy moja wiedza i świadomość były mizerne. Nie zdawałem sobie sprawy z tego, że Chip nie jest z gumy.
Klatki animacji w grze miały 16 kolorów i były wielkości 1/4 ekranu, Tła miały 32 kolory i były na podad 1/4 ekranu, panel 32 kolory i był na pół ekranu. To zjadało absurdalne ilości ChipRAMu. Nawet w startup-sequence odpalałem chyba coś co zamyka ekran systemowy w tle czy zmienia go na dwukolorowy (już nie pamiętam dokładnie ale to był częsty wtedy zabieg).Ostatnia aktualizacja: 17.08.2023 15:58:47 przez MDW
17.08.2023 18:26
[#205]
Re: Tony - development nowej gry
@tukinem, post #202
Co do kolorów, to nie było koncepcji zmiany palet. Dopiero raz Rafał wrzucił zdjęcie Tonego po przeróbce na monitor CRT ala Neptun. To mi się spodobało i ustawiłem tą paletę. Później była ankieta i ludzie wypowiadali się jakie palety kolorów by chcieli. No i tak wszystkie te palety są w grze, a jest ich dziewięć.
Fajnie, że to wdrożyliście. Wydaje mi się, że to mój pomysł: https://www.ppa.pl/forum/scena/45498/szukam-magika-muzyka-co-przeniesie-muzyke-z-raster-music-tracker-rmt-do-amigowej-postaci/4#m785569 tym bardziej mnie cieszy:)
A ja ostatnio całkiem nieświadomy Twojego posta zaproponowałem to samo 17.08.2023 20:18
[#207]
Re: Tony - development nowej gry
@selur, post #204
Faktycznie jakoś człowiek nie miał świadomości ile chipu zjada taki kawał grafiki. Wycinał sobie wielkiego boba w jak największej liczbie kolorów i cieszył się, że może tym przesuwać płynnie. A tu jednak przydałoby się trochę ośmiobitowej pokory w programowaniu tak w końcu ograniczonej maszyny jak A500 1MB.
17.08.2023 21:22
[#210]
Re: Tony - development nowej gry
@Jacques, post #209
Nowy jest tylko pomarańczowy. Zielone już były wcześniej i są tam dalej. Niczego nie usunąłem. Zwiększyłem tylko tablicę z danymi palet i dodałem ten kolor pomarańczowy. Reszta jaka była taka jest dalej. Jest zielony, niebieski, bordowy itd.
Powyżej na moim screenie z Blitza masz dane z gry i tam są palety kolorów "DanePalet". 6 kolejnych liczb to r,g,b pierwszego koloru palety i r,g,b drugiego koloru.
To chyba 3 paleta, czyli jak masz czarnobiałe kolory to wchodzisz w ustawienia w menu i jedziesz dwa razy w prawo i powinieneś mieć zielone z czarnym.
Ostatnia aktualizacja: 17.08.2023 21:28:12 przez tukinem
Powyżej na moim screenie z Blitza masz dane z gry i tam są palety kolorów "DanePalet". 6 kolejnych liczb to r,g,b pierwszego koloru palety i r,g,b drugiego koloru.
To chyba 3 paleta, czyli jak masz czarnobiałe kolory to wchodzisz w ustawienia w menu i jedziesz dwa razy w prawo i powinieneś mieć zielone z czarnym.
Ostatnia aktualizacja: 17.08.2023 21:28:12 przez tukinem