[#121] Re: Tony - development nowej gry

@Don_Adan, post #120

...no albo sciezka dostepu jest zwalona i szuka pliku tam gdzie go nie ma.
[#122] Re: Tony - development nowej gry

@Don_Adan, post #120

Pod systemem mam 2MB chip ram. To nie to, bo zaraz po wymianie ADF lekko zamieli i koniec. A wiem że najpierw wczytuje pliki do fast ramu po to, żeby je rozpakować. No i właśnie też dlatego gra ma takie wymagania co do fast ramu. Może wytłumaczę, jak to tutaj działa.
1. Alokuję pamięć w fast ramie o rozmiarze 8 bajtów
2. Wczytuję pierwsze 2 długie słowa pliku
3. Odczytuję drugie długie słowo, bo tam jest zapisany rozmiar pliku po rozpakowaniu
4. Kasuję zaalokowaną pamięć i alokuję nową o rozmiarze odczytanej wcześniej wartości
5. Wczytuję spakowany plik do pamięci i go rozpakowuję

Moim zdaniem nie wygląda to źle, bo gra ma dużo danych, a i samo menu główne jest spore. Kilka grafik, które trzymam w fast ramie, przewijany napis to bitmapa ok. 320x1000 pix w 3 bitplanach, bo tam wyświetlam to w DualPlayfieldzie. Sporo rzeczy trzymam ciągle w fast ramie, aby nie trzeba było za każdym razem doczytywać z dyskietki i dzięki temu unikam "wachlowania" ADFami. Jedynie gdy będzie ładowany level powyżej drugiego, bądź z takiego levelu będziemy wracać do menu głównego. 0,5MB fast ram to nie jest wcale tak wiele, jeśli każdy plik na początku wczytuję do fast ramu i go wypakowuję, a tablice w pamięci też trochę zajmują. No i trochę ich jest.




Może się zdarzyć, że gra będzie wymagać 1,5MB fastu, ale to się okaże gdy będzie gotowa piramida, bo tam tablica mapy to jest narazie 240x200 kafli 8x8, ale wiem że to mało i będzie większa.

@Selur
Ścieżka dostępu raczej dobra, skoro bootując z ADFa działa dobrze. Może ja tu wrzucę ten kod odczytu, bo on jest prosty (amosowaty :D):
dir$="LVL3/"
music$=dir$+"music.pack"
While exists(music$) = false
   VWait
Wend


Pod pętlą While...Wend program czeka na drugiego ADFa, jeśli nie znajduje pliku. Tak jak pisałem, uruchamiając spod systemu po włożeniu ADFa z plikiem chwilkę zamieli ADF i się wyłącza. Bootując taki kod, wszystko działa jak należy :)

Ostatnia aktualizacja: 15.08.2023 08:03:26 przez tukinem
[#123] Re: Tony - development nowej gry

@tukinem, post #113

A udostępnisz wersję z bursztynowym schematem?
[#124] Re: Tony - development nowej gry

@tukinem, post #122

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"

powinno byc tak glowny$+dir$ gdzie glowny$, to komenda ktora odczyta do zmiennej bierzacy katalog. W amosie to jest wlasnie komenda Dir$.
[#125] Re: Tony - development nowej gry

@tukinem, post #122

tablica mapy to jest narazie 240x200 kafli 8x8

to mimo wszystko nie duża mapa. raptem 48000 bajtów (no może x2 jeśli word'ów) i to wg mnie powinno się całkiem ładnie pakować. tak jak jednobitplanowa grafika.
pytanie czym pakujesz?
no i rozważył bym jednak doładowywanie z dyskietki ale możliwość grania przez posiadaczy 512+512 ramu.
[#126] Re: Tony - development nowej gry

@selur, post #124

Tutaj dir$ to zmienna tekstowa. W Blitzu nie ma funkcji Dir$ z Amosa. Tzn jej odpowiednikiem jest ChDir.

Tutaj nie ma znaczenia że nie ścieżki bezpośredniej. Ma odczytać plik z podkatalogu LVL3 o nazwie music.pack. nie ma pliku, to czeka a po zmianie dyskietki znajduje katalog LVL3/ i dany plik w nim. Nie pamiętam jak w Amosie było ale też można moło chyba użyć ścieżki pośredniej z podkatalogami typu Load "katalog/plik.dat",0
[#127] Re: Tony - development nowej gry

@c64portal, post #125

No ale co ma do tego pakowanie? Żeby rozpakować to muszę zaalokować w fast ramie tyle pamięci ile po rozpakowaniu. Zgadza się 48000 bajtów zajmuje narazie a będzie więcrj. Całość gry to nie jest tylko tablica mapy. Jak pisałem jest wiele danych do ładowania, a też zostają załadowane ekrany z menu głównego. Do tego domyślam się że ładowane są też do fastu różne biblioteki których używa Blitz w tym kodzie. To nie jest 89 rok więc niech rzuci kamień ten co ma Amigę bez 1MB fastu
[#128] Re: Tony - development nowej gry

@c64portal, post #125

to wg mnie powinno się całkiem ładnie pakować. tak jak jednobitplanowa grafika


Z tego co pamiętam, to chyba 2 bitplanowa została użyta, mimo że tylko 2 kolory są w grze.
[#129] Re: Tony - development nowej gry

@karolb, post #128

Tak. 2 bitplany, bo przy 1 bitplanie nie ma koloru czarnego, tylko transparentny.

@Jacques
W sumie to dodam tą paletę do wersji demo, skompiluję i wyślę na Aminet w wolnej chwili.
1
[#130] Re: Tony - development nowej gry

@tukinem, post #126

no to uzyj tego ChDir
komputer to nie wrozbita Maciej z TVN'u. Jak mu nie podasz konkretnej sciezki do pliku, to go nie znajdzie chociaz bys mial 1000 kopii tego pliku na dysku w roznych miejscach
[#131] Re: Tony - development nowej gry

@tukinem, post #129

no to dajcie potworki i przeszkadzajki w innym kolorze, bedzie latwiej dla graczy.
[#132] Re: Tony - development nowej gry

@selur, post #130

Czyli bootując z ADFa komputer jest wróżbitą Maciejem to nie takie proste żeby zmienić ścieżkę. Ktoś uruchamiając z HDD będzie mieć początek DHx: więc nie mogę zmieniać sobie ścieżki głównej.

A teraz najważniejsze. Czysty Blitz Basic nie ma ChDir. Ultimate Blitz Basic ma ją niby ale ta biblioteka nie działa jak należy. Nie jest dobrze przepisana. Konkretnie nazywa się Elmore's Dos Library. Próbowałem użyć jej do napisania filemanagera typu Norton Commander. Nie wyświetlało nazw katalogów i plików. Co ciekawe identyczny kod w AmiBlitz działał prawidłowo. Niestety Tonego tak łatwo nie przerzucę z BB do AmiBlitz bo tam od nowa musiałbym znowu pisać odtwarzanie modułów i dźwięków

Będę próbować jeszcze ominąć ten problem.

Co do koloru dla potworków to nie. Trzeci kolor jest użyty w grze. Oczy czaszki na dolnej belce migają właśnie bo są zrobione tym kolorem szeroki uśmiech to taki mój trik.

Sprawdzałem jeszcze coś takiego, że odmontowałem ADFa nawet gdy nic nie jest wczytywane. Zamontowałem go znowu, stacja niby zamieliła i koniec. Tak jakby system przejął kontrolę i przesunął po swojemu laser przez co Blitz stracił kontrolę. Nie byłoby problemu gdyby ADFy były w NDosie. Wtedy nie dałoby rady odpalić gry spod systemu z ADFa. No ale tego nie potrafię zrobić więc zawsze kogoś będzie kusić żeby odpalić tak zamiast skopiować sobie na HDD bądź zabootować z ADFa.

Ostatnia aktualizacja: 15.08.2023 13:35:41 przez tukinem

Ostatnia aktualizacja: 15.08.2023 13:41:47 przez tukinem
[#133] Re: Tony - development nowej gry

@tukinem, post #132

Ktoś uruchamiając z HDD będzie mieć początek DHx: więc nie mogę zmieniać sobie ścieżki głównej

można by zrobić assigna np Tony: i od takiej ścieżki bezwzględnej ładować dane.

co do 1 MB to zgoda. Sporo ludzi już faktycznie ma 1 mb. I żeby być dobrze zrozumianym... to Twoja/Wasza gra ;).
I powracam do pytania. Czym pakujesz?
[#134] Re: Tony - development nowej gry

@c64portal, post #133

Assign moim zdaniem odpada bo jeśli ktoś sobie zgra na HDD to by musiał ręcznie Assigna dopisać. Dla wielu to dużo roboty.

Co do pakera to udało mi się użyć Implodera. Blitz Basic ma swoje wbudowane funkcje od pakowania rozpakowywania, ale rozkminiałem je chyba z 3 miesiące to nie PPSave i PPLoad z Amosa hehe bardziej skomplikowane to jest. Dobrze że użyty jest Imploder, bo nim można pakować MODy dzięki algorytmowi delta oraz nie jest wymagana biblioteka w LIBSach.
[#135] Re: Tony - development nowej gry

@tukinem, post #122

Ogolnie to alokowanie 8 bajtow i pozniejsze dealokowanie jest calkowicie bezsensowna koncepcja, bo defragmentujesz sobie tylko pamiec. Powinienes po prostu w programie przydzielic na stale 8 bajtow na te 2 dlugie slowa i tam je wczytywac. Koder to pewnie by wczytywal te 8 bajtow prosto na stos A7. A co do ilosci pamieci fast to musialbys powiedziec, ile potrzebujesz pamieci na rozpakowane dane i tabele na 1 level. Np. tabele 64KB, dane 300KB itp, wtedy mozna by policzyc czy sie da to zrobic.
A co do tego trzeciego levelu to sprobuj odpalic go jako pierwszy i zobaczyc czy sie wczyta.
[#136] Re: Tony - development nowej gry

@tukinem, post #129

Super, dzięki!
[#137] Re: Tony - development nowej gry

@tukinem, post #127

Czym innym jest Amiga 500 z 1MB pamieci, a czym innym Amiga 500 z 1MB pamieci slowfast lub fast. Tych drugich jest malo, nie wiem czy z 10% uzbierasz. Wiec bardzo ograniczasz ilosc przyszlych graczy dla tej gry w przypadku A500 i A600.
[#138] Re: Tony - development nowej gry

@tukinem, post #134

ja z blitzem używałem STC (Stone Cracker) niezły. nie potrzebowałem biblioteki bo dorwałem kod w asm'ie do depackera i go sobie po prostu użyłwam w BB. niedawno natrafiłem na RNC (był używany komercyjnie np w Wormsach) i można go używać teraz do projektów własnych. RNC ma niezłe osiągi i dwa rodzaje pakowania - na szybkie rozpakowanie albo na minimalny rozmiar pliku. polecam.
tyle że w obu przypadkach (STC i RNC) kod w ASM trzeba sobie zaadaptować w BB ale z tego co widziałem w innych Twoich wątkach dajasze rade z asm'em.
[#139] Re: Tony - development nowej gry

@Don_Adan, post #135

I właśnie to jest najciekawsze. Uruchamiając z trainera level 3 na starcie uruchamiało się na 0.5 MB natomiast przy przejściu 2 levelu i podczas ładowania levelu 3 już się nie uruchamiało. Czarny ekran zostawał. Ale to było wcześniej. Od tamtej wersji doszło nowe menu główne, więcej danych w fast ramie i teraz nie widzę już szans na to. Łatwo wyliczyć sobie dane, chociaż nie wszystkie dla levelu 3:
- tablica mapy: 23,4kB
- pliki IFF z bitmapami roboczymi: 32kB
- dane obiektów: 4,26kB

Próbowałem teraz uruchomić aktualną wersję i niestety na 1MB fast ram nie wystartuje. Dane z menu głównego trzymają pamięć najbardziej pewnie. Co ciekawe kick 1.3 nie zabootował gry:


Pytano mnie o paletę kolorów a'la Neptun. Proszę:


@C64Portal
StoneCrackerem pakuję plik uruchamialny. Ten paker chyba nie da rady spakować modułów. Wiem, że to jeden z lepszych pakerów. Nawet bije CrunchyDAT.

Ostatnia aktualizacja: 15.08.2023 14:17:13 przez tukinem
1
[#140] Re: Tony - development nowej gry

@tukinem, post #139

Czyli wyglada, ze masz pofragmentowana pamiec, albo zapominasz zwalniac zaalokowana pamiec przez dane z poprzedniego levelu gry. Nie wiem czy jest jakas funkcja z blitzu, ktora umozliwia wyswietlanie dostepnej ilosci pamieci, ale w celach testowych moglbys to sobie wyswietlac. Przy takiej ilosci danych jakie podales, wymog 1MB fastu to jest overkill, przynajmniej dla mnie.

Edycja. Raczej wyglada na to, ze masz jakis blad w programie, byc moze zasmiecasz dostepna pamiec, albo zle depakujesz dane.

Ostatnia aktualizacja: 15.08.2023 14:41:22 przez Don_Adan
[#141] Re: Tony - development nowej gry

@tukinem, post #134

Assign moim zdaniem odpada bo jeśli ktoś sobie zgra na HDD to by musiał ręcznie Assigna dopisać. Dla wielu to dużo roboty.


Zrobisz skrypt i ikonkę pod WB, w skrypcie najpierw Assign a potem plik wykonywalny Tony.
[#142] Re: Tony - development nowej gry

@karolb, post #141

Ale podczas bootowania z ADF nie będzie uruchamiany skrypt, a plik wykonywalny "Tony". Nie wiem, jeszcze będę kombinować z tym. Nigdy nie używałem czekania na przełączanie ADFów w Blitzu, dlatego to dla mnie nowość.

Co do depakowania pliku, to na pewno nie ma błędu. Zarówno kod z dema i pełnej wersji jest identyczny, a jedynie to jest okrojona pełna wersja (poza wyświetlaniem kilku bitmap w demku). Nawet sterowanie asemblerem jest zerżnięte z pełnej wersji. To nie będzie to. Może w pełnej wersji mam coś dodane, co powoduje błąd. A może źle mam ADFa zrobionego.

Teraz na nowo skompilowałem plik wykonywalny pełnej wersji i go spakowałem STC no i teraz odpala na kick 1.3 :P nie wiem o co chodziło ale jedno z głowy.

Ostatnia aktualizacja: 15.08.2023 15:07:27 przez tukinem
[#143] Re: Tony - development nowej gry

@tukinem, post #142

Mi chodzi o depakowanie danych przez gre. Taka ilosc potrzebnej pamieci fast moze po prostu maskowac problem, ze depakowanie zasmieca jakies dane, czego nie widac. No i jakiego depakera uzywasz, w jakiej wersji? Sa depakery z jednego miejsca w drugie miejsce, sa tez depakery z tego samego miejsca w to samo miejsce to sie bowiem nazywa "in place". W zaleznosci od pakera depakuja od przodu do tylu, ale wtedy zwykle wymagaja jakiegos przesuniecia na poczatku, albo wczytania pliku na odpowiedni adres, np. plik spakowany ma 20KB a zdepakowany ma 60KB to taki plik laduje sie na adres docelowy +40KB. Inne depakuja od tylu do przodu, to wtedy laduje sie taki spakowany plik na koniec bufora.
[#144] Re: Tony - development nowej gry

@tukinem, post #139

Ale Neptun nie świeci żółtym
.
[#145] Re: Tony - development nowej gry

@tukinem, post #132

musisz przekonwertowac kod z Amosa

glowny$=Dir$ : rem odczyt aktualnego katalogu ze sciezka w ktorej zostal uruchomiony program

katal$="TONYHALIK/"

sciezka$=glowny$+katal$+plik$ : rem pelen dostep do plikow


i teraz wazna rzecz, wszystkie pliki i katalogi gry musza znajdowac sie w katalogu TONYHALIK a wiec cos w stylu.

TONYHALIK/grafika/...
TONYHALIK/muzyka/...
TONYHALIK/dane/...

na dyskietce musi byc to glowny jeden katalog DF0:TONYHALIK w ktorym trzymasz reszte a na dysku bedzie to jakas tam sciezka startowa z katalogiwem TONYHALIK np. DH0/Amigowe/Gry/TONYHALIK/...

suma sumarum musisz miec oodpowiednik instrukcji Dir$ z Amosa w BB

Ostatnia aktualizacja: 15.08.2023 15:44:23 przez selur
[#146] Re: Tony - development nowej gry

@selur, post #145

To nie przejdzie pod Blitzem. Jedynie co by ratowało, to przepisanie wszystkiego do AmiBlitz 3.9. Ale tam może być jeszcze więcej problemów niż tu. Dziwię się, że używając pośrednich ścieżek wszystko jest ok dopóki nie odmontuje się ADFa. Przypomnę, że level 1 i level 2 uruchamiają się zawsze, bo ADF nie zostaje odmontowany. Level3 i level 5 już nie ładuje się jak uruchomimy spod systemu plik z ADF. Bootowanie z ADF odpala każdy level. Uruchomienie zgranych ADFów w jeden katalog na HDD (czyli połączenie dwóch ADFów) też odpala każdy level. Tak jakby odpalając system nie chciał zainicjować drugiego ADFa. A powinien bo uruchamiając grę z niego automatycznie początek ścieżki pliku, czy to pośrednio czy bezpośrednio z pełną nazwą, to zawsze jest DFx:
[#147] Re: Tony - development nowej gry

@Jacques, post #144

To taki jest jeszcze najbliższy Twoim oczekiwaniom, chociaż ten zielony jest zbyt ciepły w porównaniu do tego z Twojego zdjęcia, no i tło jest lekko zielonkawe


Od razu tutaj jest zaprezentowana woda, która jest płynnie animowana jak widać spory kawałek animacji, a nie wpływa znacząco na szybkość gry.
1
[#148] Re: Tony - development nowej gry

@tukinem, post #147

Fajny OK
Kojarzy mi się z trybem zielonym na Philipsie CM-8833-II.

Ostatnia aktualizacja: 15.08.2023 16:29:52 przez Jacques
[#149] Re: Tony - development nowej gry

@tukinem, post #146

Nie powinno byc zadnego odwolania do dfx: tylko do nazwy dyskietki typu, "Tony1" i "Tony2". Bo taka gre mozna na przyklad uruchomic z RAD: x 2, albo z RAD: i dfx:. A co do braku startu levelu 3 z dyskietki spod systemem to nie jest takie dziwne. Prawdopodobnie Blitz robi swoj wlasny assign nazwy dyskietki, gdy gra startuje. A poniewaz masz dwie takie same nazwy pod systemem to gra/system glupieje bo masz ta sama nazwe przypisana do 2 roznych miejsc, a tak sie nie da. Albo dane z dyskietki albo z HD. To tak jakbys startowal z HD jakas gre, ktora robi assigny nazw dyskietki w momencie startu w skrypcie startowym i mial rownoczesnie dyskietke z taka nazwa w stacji dyskow, tez system zglupieje, albo da jakis komunikat o bledzie, juz nie pamietam.
[#150] Re: Tony - development nowej gry

@Don_Adan, post #149

Nie mam odwołania ani do DFx ani do TonyX. Pisałem jak wygląda mój kod, czyli wyświetlenie bitmapy z prośbą o włożenie konkretnej dyskietki i od razu sprawdzanie czy istnieje plik, ale ze ścieżką pośrednią, czyli sam podkatalog. Chyba że zrobić jeszcze taki manewr, żeby ADF 1 i ADF 2 miały tą samą etykietę, to wtedy jeśli on sobie przypisuje etykiety dyskietek jako nazwa dysku, czyli nie DF0: a TONY1: no to może wystarczy stworzyć oba ADFy z tą samą etykietą

Jednak to zły trop.

Prawdopodobnie trzeba bardziej skrupulatnie, czyli:
If Exist(plik$) = false
  ;wyswietlenie bitmapy z prosba o dyskietke
   While Exist('ETYKIETA:'+plik$) = false
      Vwait
   Wend
EndIf



Ostatnia aktualizacja: 15.08.2023 16:47:54 przez tukinem
Na stronie www.PPA.pl, podobnie jak na wielu innych stronach internetowych, wykorzystywane są tzw. cookies (ciasteczka). Służą ona m.in. do tego, aby zalogować się na swoje konto, czy brać udział w ankietach. Ze względu na nowe regulacje prawne jesteśmy zobowiązani do poinformowania Cię o tym w wyraźniejszy niż dotychczas sposób. Dalsze korzystanie z naszej strony bez zmiany ustawień przeglądarki internetowej będzie oznaczać, że zgadzasz się na ich wykorzystywanie.
OK, rozumiem