Autor Wątek: [tooloud] jakby Oregon Trail  (Przeczytany 20368 razy)

tooloud

  • *****
  • Wiadomości: 3185
  • Miejsce pobytu:
    Warszawa
  • mydłem go!
[tooloud] jakby Oregon Trail
« dnia: 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ć.
dużo sprzętu mało czasu.

KWF

  • *****
  • Wiadomości: 6823
  • Miejsce pobytu:
    trzecia planeta od Słońca
  • "I co ja robię tu, u-u, co Ty tutaj robisz ..."
    • Insta do lasownia
Odp: [tooloud] jakby Oregon Trail
« Odpowiedź #1 dnia: 2018.12.04, 14:42:25 »
Trzymam kciuki za dalsze prace. Obrazki robią wrażenie.

Próbowałeś używać PikoPixel pod macOS zamiast ZX Paintbrusha?
KWF
-----
R Tape loading error 0:1
Moje zabawki: https://github.com/McKlaud76

tooloud

  • *****
  • Wiadomości: 3185
  • Miejsce pobytu:
    Warszawa
  • mydłem go!
Odp: [tooloud] jakby Oregon Trail
« Odpowiedź #2 dnia: 2018.12.04, 15:09:53 »
ZX Paintbrush potrzebny mi jest do specyficznego zadanego zakodowania bitmapy w pliku .bin, którą potem konwertuję bin2c na postać wczytywalną do z88dk.
dużo sprzętu mało czasu.

steev

  • *****
  • Wiadomości: 1362
  • Miejsce pobytu:
    inode 42
Odp: [tooloud] jakby Oregon Trail
« Odpowiedź #3 dnia: 2018.12.04, 15:21:56 »
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)
Machines should work. People should think.

ZX Freeq

  • *****
  • Wiadomości: 1833
  • Miejsce pobytu:
    Warszawa
Odp: [tooloud] jakby Oregon Trail
« Odpowiedź #4 dnia: 2018.12.04, 15:28:57 »
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 :(
ZX80|ZX81+16kB+PandAY|ZX 48k/+/128k+/+2/+2A/+3/Vega/Next|QL+QIDE|JS128|Timex 2048+2040|UK2086|FDD3000+3.5''|AY|ZX HD|Divide2k11/2k14|DivMMC/PicoDivSD|BetaDisk 128|Opus|Masakrator FM|If 1/2/Microdrv|Multiface 1|+2A\B SDI-1|SJS 1/2|ZX Printer|TZXDuino|+3 HxC USB|ZXUno|Omni
Z88|A500/600|PC200|Ent128

tooloud

  • *****
  • Wiadomości: 3185
  • Miejsce pobytu:
    Warszawa
  • mydłem go!
Odp: [tooloud] jakby Oregon Trail
« Odpowiedź #5 dnia: 2018.12.04, 15:49:49 »
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.
« Ostatnia zmiana: 2018.12.04, 16:09:54 wysłana przez tooloud »
dużo sprzętu mało czasu.

ZX Freeq

  • *****
  • Wiadomości: 1833
  • Miejsce pobytu:
    Warszawa
Odp: [tooloud] jakby Oregon Trail
« Odpowiedź #6 dnia: 2018.12.04, 16:01:09 »
2/3 ekranu to 4096bajtów ;)
ZX80|ZX81+16kB+PandAY|ZX 48k/+/128k+/+2/+2A/+3/Vega/Next|QL+QIDE|JS128|Timex 2048+2040|UK2086|FDD3000+3.5''|AY|ZX HD|Divide2k11/2k14|DivMMC/PicoDivSD|BetaDisk 128|Opus|Masakrator FM|If 1/2/Microdrv|Multiface 1|+2A\B SDI-1|SJS 1/2|ZX Printer|TZXDuino|+3 HxC USB|ZXUno|Omni
Z88|A500/600|PC200|Ent128

ZX Freeq

  • *****
  • Wiadomości: 1833
  • Miejsce pobytu:
    Warszawa
Odp: [tooloud] jakby Oregon Trail
« Odpowiedź #7 dnia: 2018.12.04, 16:03:35 »
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 :)
ZX80|ZX81+16kB+PandAY|ZX 48k/+/128k+/+2/+2A/+3/Vega/Next|QL+QIDE|JS128|Timex 2048+2040|UK2086|FDD3000+3.5''|AY|ZX HD|Divide2k11/2k14|DivMMC/PicoDivSD|BetaDisk 128|Opus|Masakrator FM|If 1/2/Microdrv|Multiface 1|+2A\B SDI-1|SJS 1/2|ZX Printer|TZXDuino|+3 HxC USB|ZXUno|Omni
Z88|A500/600|PC200|Ent128

tooloud

  • *****
  • Wiadomości: 3185
  • Miejsce pobytu:
    Warszawa
  • mydłem go!
Odp: [tooloud] jakby Oregon Trail
« Odpowiedź #8 dnia: 2018.12.04, 16:07:22 »
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.
dużo sprzętu mało czasu.

tooloud

  • *****
  • Wiadomości: 3185
  • Miejsce pobytu:
    Warszawa
  • mydłem go!
Odp: [tooloud] jakby Oregon Trail
« Odpowiedź #9 dnia: 2018.12.04, 16:12:49 »
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ę.
dużo sprzętu mało czasu.

ZX Freeq

  • *****
  • Wiadomości: 1833
  • Miejsce pobytu:
    Warszawa
Odp: [tooloud] jakby Oregon Trail
« Odpowiedź #10 dnia: 2018.12.04, 16:13:41 »
A taki? Powinien się lepiej kompresować.... tyle że to już dalsza ingerencja.
ZX80|ZX81+16kB+PandAY|ZX 48k/+/128k+/+2/+2A/+3/Vega/Next|QL+QIDE|JS128|Timex 2048+2040|UK2086|FDD3000+3.5''|AY|ZX HD|Divide2k11/2k14|DivMMC/PicoDivSD|BetaDisk 128|Opus|Masakrator FM|If 1/2/Microdrv|Multiface 1|+2A\B SDI-1|SJS 1/2|ZX Printer|TZXDuino|+3 HxC USB|ZXUno|Omni
Z88|A500/600|PC200|Ent128

ZX Freeq

  • *****
  • Wiadomości: 1833
  • Miejsce pobytu:
    Warszawa
Odp: [tooloud] jakby Oregon Trail
« Odpowiedź #11 dnia: 2018.12.04, 16:17:36 »
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ć.
ZX80|ZX81+16kB+PandAY|ZX 48k/+/128k+/+2/+2A/+3/Vega/Next|QL+QIDE|JS128|Timex 2048+2040|UK2086|FDD3000+3.5''|AY|ZX HD|Divide2k11/2k14|DivMMC/PicoDivSD|BetaDisk 128|Opus|Masakrator FM|If 1/2/Microdrv|Multiface 1|+2A\B SDI-1|SJS 1/2|ZX Printer|TZXDuino|+3 HxC USB|ZXUno|Omni
Z88|A500/600|PC200|Ent128

trojacek

  • *****
  • Wiadomości: 6831
  • Miejsce pobytu:
    Warszawa
Odp: [tooloud] jakby Oregon Trail
« Odpowiedź #12 dnia: 2018.12.04, 16:19:12 »
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

tooloud

  • *****
  • Wiadomości: 3185
  • Miejsce pobytu:
    Warszawa
  • mydłem go!
Odp: [tooloud] jakby Oregon Trail
« Odpowiedź #13 dnia: 2018.12.04, 16:19:37 »
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.
dużo sprzętu mało czasu.

tooloud

  • *****
  • Wiadomości: 3185
  • Miejsce pobytu:
    Warszawa
  • mydłem go!
Odp: [tooloud] jakby Oregon Trail
« Odpowiedź #14 dnia: 2018.12.04, 16:21:42 »
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
dużo sprzętu mało czasu.