forum speccy.pl
ZX Spectrum => PROGRAMOWANIE => Wątek zaczęty przez: tooloud w 2018.12.04, 14:36:33
-
Tygrys mnie zachęcił, żeby opisać - więc publikuję kolejne kroki jakie dzieją się z portem/modem gry Oregon Trail, którą przenoszę na ZXa, z ogromną pomocą programistyczną Tygrysa.
Podstawowe założenia: grafika czb z wersji z Macintosha, mechanizmy podobnie - dużo bardziej rozbudowane niż wersja pierwotna w BASICu.
Dev narzędzia - z80dk, co daje też szansę na sportowanie tego na CPC i ZX81 (z ZXPandem rzecz jasna). Robiłem też przymiarkę do cc65, ale to daleeeeeeki etap :)
Pozostałe: Photoshop, ZX Painbrush na Wine (robię wszystko na MacOS) i pewnie parę innych rzeczy - postaram się wspominać co, może się komuś przyda.
Żeby była jasność NIGDY nic nie napisałem w stricte C. Moje ostatnie programowanie to skrypty w Apple Script, aczkolwiek jak się zastanowić to w użyciu też był AppleScriptObjC - ale to doświadczenie totalnego amatora i nooba - jak to mówią.
Dlaczego ta gra? Bardzo ją lubię (ale w wersji na Macintosha, sterowanie w trakcie "polowania" na Apple II mnie odrzuca). Mam ją w iluś wersjach, łącznie z kolekcjonerkami i małą "konsolką" jaka wyszła rok temu. Jeżeli ktoś obserwuje mój profil/stronę na fejsie, to pewnie już pewne "zwiastuny" notatkowe widział.
Dlaczego w ogóle gra? To coś z mojej tzw. kupki wstydu. Miałem ileś takich projektów rozgrzebanych w latach 80tych jako dzieciak. Niby skończone, ale guzik z tego było na 100% zapięte. Zwykle gry i programy w BASICu. Teraz chcę to trochę nadrobić, tylko pozostał dylemat platformowy - gra na ZXa to mój hołd dla komputera którego nie miałem mając 12lat a który chciałem mieć. Całość projektu mam tak przemyślaną, że wydaje mi się, że będzie możliwe zrobienie portów na inne platformy - dla sportu i poznania tej opcji. Zawsze lubiłem przygodówki - co prawda myślałem, że zacznę od gry przygodowo-tekstowej, ale z kolei ten wariant sobie trochę skomplikowałem na studiach pracując przy "algorytmach słownikowych" (analiza słowotwórcza etc.) - więc nie mogłem po prostu wziąść PAW i napisać prostej gry tekstowej. Do tego wrócę w osobnym wątku :)
Czyli OREGON TRAIL - gra decyzyjna, coś tam kupujemy, zużywają się nam zasoby (jedzenie, amunicja etc.), losowo (ale i zgodnie z logiką) napadają nas bandyci, indianie, jak nie jemy to chorujemy, można złamać nogę, zgubić się, trzeba zdobywać pożywienie i... można umrzeć. Dodatkowym motywatorem jest czas, podróż nie może trwać zbyt długo - na razie nie odkryję Wam wszystkiego, tym bardziej, że dodaję pewne zmienne czynniki.
Dla mnie ta gra jest mockupem pisania w C, używania z88dk. Jak skończę tą grę to siadam z Tygrysem do drugiego projektu, ale to osobny temat.
Czemu ma posłużyć ten wątek - to finalnie będzie albo jakiś przykład, że można pisać sobie gry na ZX Spectrum, albo jak nie należy tego robić :D
Jak wygląda projekt - z brutalną uczciwością:
1. Zrobiłem analizę już istniejących wersji gry. Generalnie... zagrałem we wszystkie dostępne porty. Od crapów na Atari w BASICu, po wersję BASICową na ZX81, port na DSa i Wii etc.
2. zrobiłem skrukturę i algorytm na cyfrowym papierze - pętle zależności etc. Taki mindmapping - zresztą de facto użyłem do tego apki mindmappingowej.
3. Postanowiłem co chcę zmienić i co jest dla mnie istotne w tej grze. Np. cały motyw zręcznościowy - polowania oraz motyw spływu tratwą na koniec - dla mnie na ten element jest pomijalny. To będzie wynikać z umiejętności/predyspozycji postaci oraz podjętych decyzji. Na Macintoshu celowanie myszką ma sens. To samo na Apple II joystickiem jest tragiczne. Po prostu - traper będzie polował lepiej niż bankier i lekarz, o nauczycielu nie wspominam :)
4. Tygrys zlitował się i napisał mi procki do wczytywania fragmentów ekranu - grafika zajmuje 2/3 ekranu, ale żeby zoptymalizować część rzeczy konieczne będzie operowanie fragmentami ekranu. Generalnie - bez motywacji Tygrysa na tym etapie pewnie bym się poddał.
5. Przygotowałem grafiki, sprawdziłem ich wczytywanie. Testowo sprawdziłem ekran tytułowy i wczytywanie części ekranu procką Tygrysa - duża oszczędność pamięci. Alternatywą była tablica ze współrzędnymi do czegoś w rodzaju plot/draw, niestety w konwencji takiej grafiki i jej szczegółowości się to nie sprawdza - zrobiłem test na jednym obrazku i wyszło prawie tyle co cały ekran ZXa z atrybutami czyli masakra, pewnie można zoptymalizować takie generowanie wektorowe - ale potem jest jeden feler - rysowanie tego trwa. Procka Tygrysa i zmiana grafiki jest w zasadzie niezauważalna czasowo.
6. Grafiki zajmują za dużo, być może trzeba będzie kompresować albo zrzucić je na doczytywanie. To drugie oznacza, że będzie to chodzić na czymś pozwalającym na więcej niż RAM 128k. Dandanator? DivMMC? dyskietka? Czyli pierwszy problem sprzętowy pt. pamięć.
7. mockup zmiennych w trakcie testowania. Czyli cała gra bez grafiki za to z wyświetlaniem wszystkich używanych zmiennych. Jak zwykle coś nie działa i muszę to ogarnąć - zachciało się zrobić wersję rozszerzoną - tylko jak znam życie jak bym zrobił konwersję tej pierwotnej z BASICa to tak by zostało, a chciałem coś od siebie dodać i zrobić "ciekawszą" wersję, pod względem decyzyjnym.
8. zauważyłem, że zamiast wyliczać krzywą prawdopodobieństwa czegoś mogę zrobić tablicę z wartościami, zajmuje... chyba z 10 razy mniej miejsca, aczkolwiek to jest powiedzmy 200-300 bajtów vs 12 bajtów tablicy. O prędkości nie wspominam, bo pomijalna - sprity tu nie latają.
To jest moment w którym jestem. Testuję mockup logiki. Czyli mam nadzieję nastąpi kontynuacja, a jak ktoś ma pytania to można śmiało pytać.
-
Trzymam kciuki za dalsze prace. Obrazki robią wrażenie.
Próbowałeś używać PikoPixel pod macOS zamiast ZX Paintbrusha?
-
ZX Paintbrush potrzebny mi jest do specyficznego zadanego zakodowania bitmapy w pliku .bin, którą potem konwertuję bin2c na postać wczytywalną do z88dk.
-
6. Grafiki zajmują za dużo, być może trzeba będzie kompresować albo zrzucić je na doczytywanie.
Można jedno i drugie.
Jest sporo mocnych pakerów dla ZX (zx7, MegaLZ, pucrunch, hrust itp, itd), można przebierać :)
To drugie oznacza, że będzie to chodzić na czymś pozwalającym na więcej niż RAM 128k. Dandanator? DivMMC? dyskietka? Czyli pierwszy problem sprzętowy pt. pamięć.
Niekoniecznie. ZX + FDD to nadal jedynie 48K (tak samo zdaje się w przypadku większości zewnętrznych napędów)
Gdyby się okazało że jednak trzeba dogrywać to proponuję operacje i/o wydzielić do osobnego bloku kodu, tak żeby można było łatwo napisać wersję/drivery dla różnych stacji/systemów.
(mogę pomóc w przypadku FDD3000)
-
Piękny coming out :) Trzymam kciuki, aby starczyło wytrwałości.
A przy okazji właśnie mnie zmotywowałeś, aby wrócić do swoich "projektów" :)
Stawiałbym na doczytywanie obrazków. Chyba, że będą dobrze się kompresować, to może po prostu wydanie tylko na 128k?
Doczytywanie z FDD3000 w ASM jest proste i dużo bajtów nie zabiera. Pamiętam jak będąc dzieckiem, wystarczyły mi trzy listingi w Bajtku, aby ogarnąć temat. Teraz oczywiście nic nie pamiętam :(
-
Można jedno i drugie.
Jest sporo mocnych pakerów dla ZX (zx7, MegaLZ, pucrunch, hrust itp, itd), można przebierać :)
już ten temat badałem, Tygrys też mnie trochę nakierował:
obrazek ma 2/3 ekranu czyli 256x128 pikseli, to jest bitmapa bez atrybutów czyli ma 6 144 4096 bajtów na surowo.
Exonomizer = 3 477 bajtów
ZX7 = 3 622 bajtów
może trochę panikuję :)
Niekoniecznie. ZX + FDD to nadal jedynie 48K (tak samo zdaje się w przypadku większości zewnętrznych napędów)
Gdyby się okazało że jednak trzeba dogrywać to proponuję operacje i/o wydzielić do osobnego bloku kodu, tak żeby można było łatwo napisać wersję/drivery dla różnych stacji/systemów.
(mogę pomóc w przypadku FDD3000)
Dzięki, będę pamiętać, tym bardziej że FDD3 już nie mam.
-
2/3 ekranu to 4096bajtów ;)
-
Sporo ditheringu mają te obrazki, jakby zmienić próg i mniej pikseli.... to by się lepiej kompresowały, ale to już wtedy remake a nie port :)
-
2/3 ekranu to 4096bajtów ;)
sorki - test dotyczył pełnego obrazka czyli całego ekranu, a ja się zagalopowałem :)
oryginał 2/3 ekranu 4096 bajtów
Exonomizer 3475 bajtów
ZX7 3588 bajtów
przewiduję do 20 obrazków czyli oszczędzam w tym momencie 10k minus dekompressor.
-
Sporo ditheringu mają te obrazki, jakby zmienić próg i mniej pikseli.... to by się lepiej kompresowały, ale to już wtedy remake a nie port :)
to już jest nieco uproszczone, aczkolwiek... pewnie można dalej. Zobaczę końcowo o ile się nie mieszczę.
-
A taki? Powinien się lepiej kompresować.... tyle że to już dalsza ingerencja.
-
20 obrazków w 48k? ciężko będzie. W 128k będzie dobrze. :)
Można się pokusić, aby pokazywać co drugą linię, czyli obrazek de facto wtedy ma 256x64 i jest lepiej kompresowalny. Dekompresor trzeba by wtedy zmodyfikować.
-
Pamiętam jak będąc dzieckiem, wystarczyły mi trzy listingi w Bajtku, aby ogarnąć temat. Teraz oczywiście nic nie pamiętam :(
Jest szansa, że moje :)
Ale też nic nie pamiętam :D
-
A taki? Powinien się lepiej kompresować.... tyle że to już dalsza ingerencja.
no tak, tylko to jest już gruba redukcja detali... Za to to, co zrobiłeś to ładnie się skompresuje do wektora plot/draw.
-
20 obrazków w 48k? ciężko będzie. W 128k będzie dobrze. :)
Można się pokusić, aby pokazywać co drugą linię, czyli obrazek de facto wtedy ma 256x64 i jest lepiej kompresowalny. Dekompresor trzeba by wtedy zmodyfikować.
będę walczył, cała nadzieja... w Tygrysie :D
-
Jest szansa, że moje :)
Ale też nic nie pamiętam :D
Oczywiście. :) Krótka rozprawka z taśmą. Początek 90tych.
-
A taki? Powinien się lepiej kompresować.... tyle że to już dalsza ingerencja.
no tak, tylko to jest już gruba redukcja detali... Za to to, co zrobiłeś to ładnie się skompresuje do wektora plot/draw.
No bardziej, chodziło mi o ideę. Tu cały obrazek pokryty został maską
01
10
czy 50% dither, nigdy nie wiem jak to fachowo się mówi. :)
-
oryginał 2/3 ekranu 4096 bajtów
Exonomizer 3475 bajtów
ZX7 3588 bajtów
przewiduję do 20 obrazków czyli oszczędzam w tym momencie 10k minus dekompressor.
Nie możesz tak liczyć.
Wielkość po kompresji zależy od treści obrazka.
Musisz skompresować wszystkie i zsumować :)
-
oryginał 2/3 ekranu 4096 bajtów
Exonomizer 3475 bajtów
ZX7 3588 bajtów
Shrinkler ścisnął go do 3312 :)
-
no to musielibyśmy ten sam obrazek przemielić jeszcze :)
mam gdzieś tabelkę kompresji poszczególnych plików - zrobię zrzut z tego i wstawię tutaj. W sensie oszczędności na Exomizerze było 400-600 bajtów, średnia wychodziła okolice 500. Sprawdzałem na 12 obrazkach.
-
Był raczej ten sam (zapisałem, przyciąłem, wyciąłem, wynik zx7 był identyczny)
Natomiast sam shrinkler to raczej ciekawostka, bo potrzebuje 3k bufora i rozpakowuje coś ze 150 razy wolniej niż zx7.
Ale wiedzieć że jest coś takiego IMO warto :)
-
Dobra, jest nieźle - w międzyczasie od ostatniego testu optymalizowałem trochę grafiki - i wygląda to tak:
plik source ZX7 EXOMIZER
01independence.bin 4096 3320 3188
02crossingriver.bin 4096 3588 3473
03fort_kearney.bin 4096 3292 3185
brak 04 ------------------------------
05southpass.bin 4096 3649 3553
06fortbridger.bin 4096 2782 2556
07sodasprings.bin 4096 3632 3501
08forthall.bin 4096 2972 2804
09fortboise.bin 4096 3419 3297
10fortwallawalla.bin 4096 2426 2343
11granderonde.bin 4096 3464 3382
12thedalles.bin 4096 3585 3470
sumarycznie pliki 45056 36129 34752
rozbijam teraz część obrazków na "fragmenty" bo np. z tytułowym wyszło mi, że są dwa elementy 1k i 300bajtów plus ramka i tekst.
-
o! super że mi przypomnieliście żeby przetestować Shrinkler'a na kodzie z80 ;) na m680xx bije na głowę wszystko!
-
Sprawdziłem Shrinklera, jest trochę lepiej - dzięki Panowie. Akurat tutaj czas dekompresji nie jest tak istotny, no chyba, że będzie to zbyt widoczne.
-
Pomysł bardzo mi się podoba :) Czy możesz wkleić na forum wszystkie obrazki jakie będziesz kompresował? Może na coś wpadniemy wspólnie.
Temat jest mi bliski, bo w TCS35 też miałem problem z wielkością grafiki. Ja używałem MegaLZ z lenistwa, bo najłatwiej integrował się z Borielem.
-
Nie chciałem z premedytacją BASIC'owej wersji klepać, bo chcę się trochę nauczyć C, zresztą mam trochę problemu z BORIELEM pod OSX, muszę spróbować go zainstalować na Win7.
Z obrazkami jest na razie temat ogarnięty, nie ma co bardziej rozkminiać - raczej pójdzie to w Exomizerze - kończę konwertować pozostałe, które będą w użyciu i poprawiam "krzywe" wydarzeń losowych.
-
Co masz na myśli mówiąc o "krzywych" wydarzeń losowych? Chodzi Ci o losowanie z pewnym określonym prawdopodobieństwem? Np. jeśli chcesz żeby wypadała reszka 3 razy a orzeł 1 raz na 4 rzuty?
-
Już wyjaśniam - w zależności od:
- lokalizacji (czyli gdzie zabrneliśmy)
- ile czasu już podróżujemy
jest różne prawdopodobieństwo np.:
- zachorowania (to może być też skutek niedożywienia, ale dodajemy do tego śnieg w górach i mamy komplet)
- spotkania bandytów (pierwsze 1000 mil to górka krzywej, potem w górach ich nie ma)
- łatwości znalezienia pożywienia
- wystąpienia ochłodzenia etc.
Dodajemy do tego "skille" poszczególnych profesji (lekarz łatwo uleczy chorobę, farmer czy traper łatwo znajdą pożywienie, traper dobrze strzela, a nauczyciel ma przewalone bo nic nie potrafi dodatkowo).
-
OK, czyli dokładnie to o czym myślę. Najprościej faktycznie zrobić to na tablicach, im więcej elementów, tym większa "rozdzielczość" zdarzeń.
-
Dzięki tooloud za ujawnienie projektu!
Kompresja danych, przerwania z muzyką jeszcze przed nami, ale damy rade ;)
-
Hej, jakiś update Oregona?
-
Doszedłem do tematu problemu, którejś wersji Z88DK i biblioteki muzycznej - wywala mi błędy, Tygrys zbada temat.
Ponieważ jednocześnie klepię ten sam kod pod cc65 to wychodzą mi kwiatki z innej platformy - ale generalnie powoli idzie do przodu. Chciałbym zamknąć temat Oregona na ZX'a do najbliższego party, ponieważ mam już "na tapecie" temat logiki silnika przygodówkowego, ale to kompletnie inny temat.
PS. dzięki za przypomnienie, wcisnąłem to właśnie "na tapetę" :)
-
Jakiś tydzień temu mnie tknęło i skontaktowałem się z aktualnym właścicielem praw (w moim przekonianiu) zadając pytanie czy taka konwersja jak "robię" mieści się w granicach akceptowalnych i... chyba zamykam projekt, bo odpisał mi ludzik HMH, że ponieważ nadal jest eksploatowana licencja/trademark to jedynie dopuszczają użycie w produktach licencjonowanych.
Chyba chodzi o tą konsolkę (mam zresztą) którą wydali z Oregon Trail. No nic, trochę ciekawych rzeczy człowiek popróbował, trzeba robić kolejne :) Być może przerobię to co powstało na kompletnie inny scenariusz gry / zmienię grafikę i coś z tego będzie, ale - generalnie nie zamierzam się pakować w przerzucanie się korespondencją z jakimś działem prawnym zza wielkiej wody. Szkoda czasu.
-
Bardzo szkoda. Ale tak, jak piszesz. Zmień tytuł i grafikę (tia, łatwo powiedzieć) i działaj dalej, bo szkoda poniesionego wysiłku.
-
Dokładnie. Szkoda roboty - zmiana tytułu i po sprawie.
Mało to klonów gier wychodzi/wychodziło i to w oficjalnej dystrybucji?
-
ale serio - kopać się z dużą firmą nie zamierzam. Zmienię scenariusz, grafikę, tytuł, mechanika może zostać, albo ją rozbuduję - co też może być in plus.
-
zupełnie inaczej podchodzi na przykład taki autor Saboteur, który sobie tylko życzy małego procenu od sprzedaży kopii
-
procentu od sprzedaży konwersji na newgena.