Jeśli ktoś sądził, że Mariusz Wojcieszek zwolnił ostatnio tempo przygotowywania konwersji, to się mylił: kolejną grą, w którą już możemy dzięki niemu zagrać na Atari, jest jeden z jego osobistych faworytów, izometryczny Gunfright z 1985 roku.
Na razie mamy do czynienia jeszcze z wersją roboczą, przeniesioną głównie za pomocą rekompilatora Z80 → 6502 autorstwa Mariusza. W związku z tym kilka spraw trzeba jeszcze poprawić – przede wszystkim dotyczy to tych elementów gry, które na ZX Spectrum uzyskiwane są za pomocą atrybutów koloru (np. naboje w bębenku). Także prędkość rozgrywki jest jeszcze do poprawienia. Docelowo również powinna pojawić się muzyka grana przez POKEY-a, a nie beeper.
Grę zaczynamy od strzelania do woreczków z pieniędzmi, dzięki celnym trafieniom zwiększamy początkową sumę pieniędzy na amunicję. Potem akcja przenosi się do miasteczka Black Rock, w którym nasz bohater jest szeryfem. Celem gry jest wytropienie i wyeliminowanie gangu bandytów (jednego po drugim).
Podstawowe sterowanie klawiszowe: Ruch do przodu: klawisze A-F Obrót w lewo: B Obrót w prawo: N Strzał: klawisze 1-0 Zmiana kąta ustawienia kamery: Z
Można też grać dżojstikiem, zmieniamy sterowanie klawiszem 2 w głównym menu.
Plik z grą można pobrać stąd, a kod źródłowy znajdziecie tu. Miłej zabawy!
2016-06-12 21:56 by "Adam"
komentarzy: 96
xxl @2016-06-12 22:03:57
Mariusz. nie przestawaj
:)
xxl @2016-06-12 22:04:58
chwila... nie widze opcji generowania wyniku dla HSC. karygodne zaniechanie.
Adam @2016-06-12 22:08:27
To na razie tylko przymiarka do wersji finalnej ;)
Dla mnie fantastyczne jest to, że ta krosskompilacja domyślnie nie powoduje zwalniania. Wynik 2x wolniej jest rewelacyjnym wynikiem.
jhusak @2016-06-13 23:06:56
Oczywiście 2x wolniej niż na spektrusiu.
mariuszw @2016-06-14 07:55:18
@jhusak: wypuszczona wersja ma zoptymalizowane trzy podstawowe procedury: czyszczenie bufora 3D, kopiowanie bufora 3D, rysowanie budynków do bufora 3D. Bez tego było dużo wolniej. W tej chwili szybkość jest podobna do Spectrum kiedy widać budynki, natomiast gdy ich nie widać (oraz przy strzelaniu do worków) jest pewnie dwa razy wolniej. Pomoże optymalizacja rysowania obiektów, choć nie jestem pewien, czy uda się osiągnąć prędkość ZX Spectrum.
xxl @2016-06-14 08:46:11
niesmiertelne przy takich okazjach... co bedzie nastepne :-)
mariuszw @2016-06-14 10:01:46
A jakie są oczekiwania jeśli chodzi o następne porty ze Spectrum? ;)
xxl @2016-06-14 10:21:18
moje? niepohamowane
the fender @2016-06-14 10:30:12
Proponuję: Action Force 2.
Bruno @2016-06-14 10:41:40
Koncert życzeń? Savage R-type Athena
;)
bocianu @2016-06-14 11:19:01
Ja od 20 lat czekam na port Laser Squad. Tam nie powinno być problemów z szybkością, bo to gra turowa, a jest genialna...
Adam @2016-06-14 11:30:54
Ach, Laser Squad :) Bardzo lubię.
the fender @2016-06-14 12:19:18
No tak, Laser Squad. Mocna pozycja. Ale Action Force II z dobrze dobranymi duszkami (a nawet i bez) jest teoretycznie w zasięgu Atari.
Castlevania - uwielbiam serię, a ta gra ze Spectrum jest świetna. Pytanie jak by to wyglądało w grafice mono, bo duszki by tu chyba nie pasowały? Laser Squad - nie grałem, ale widzę, że gra jest ceniona. Możnaby przenieść wersję z C64 by oszczędzić rekompilacji, natomiast potrzebowa grafika, który przygotuje całość na Atari. Action Force 2 - bardziej podoba mi się Hammerfist. R-type - jak najbardziej. Athena - to jest ciekawe, gra mi się podoba, a grafika mono, więc bez problemu poszłoby na Atari. Silkworm - grałem u kolegi na C64 i mu zazdrościłem, teraz bym sobie odbił grając na Atari ;) Ant Attack - wersja C64 jest byle jaka. Ale wersja ze Spectruma jest fajna. Back To Skool - tu może być łatwiej, bo jest dostępna pełna disasemblacja.
Z gier które przeglądałem: Joe Blade 3 (bo lubiłem Joe Blade 1 i 2 na Atari) Batman (bo to klasyk gier izometrycznych) i jeszcze kilka innych.
Konkretnie co do planów: jest w przygotowaniu (właściwie w planowaniu) Exolon. Inne tytuły mocno zależą od moich umiejętności analizy kodu Spectrum - tu się okazuje, że niektóre gry są bardzo łatwe (np. Joe Blade 3), a inne gry jak np. Renegade na dzisiaj niemożliwe do zrobienia - kod jest tak skomplikowany (to znaczy w tak dziwny sposób obsługuje skoki), że nie sposób znaleźć co jest kodem a co danymi.
@the fender: do manic miner też brakło a wygląda ok. Porównaj screeny ze spectrum i atari - nie wszystko jest tak kolorowe jak w oryginale. Kolorujesz jak fabryka dała - co się da, a co się nie da to nie.
the fender @2016-06-15 09:02:05
@wieczór: no tak, tylko sęk w tym że o ile w takim Manic Miner praktycznie tego nie widać o tyle w grach które bardzo mocno korzystają z atrybutów (+na spritach) będzie to mocno widoczne.
@mariuszw: nieprzypadkowo dałem Action Force II, ponieważ gra wydaje się nie być zbytnio obciążająca jeśli chodzi o obliczenia i atrybuty, a jednocześnie bardzo miodna (osłaniamy ludzika, który maszeruje przez planszę aby uwolnić więźniów). Hammerfist to inna rozgrywka.
Widać, widać :) Ale trzeba zrobić to dobrze i będzie dobrze. Każda gra na każdej jednej platformie wyglada inaczej - i dobrze. Poza tym można włożyć więcej pracy i przy konwersji zejść z tego hiresu - tylko ktoś musi popracować nad dostosowaniem grafiki. Ale dyć to wszystko to drugorzędny wodotrysk.
the fender @2016-06-15 09:20:22
No cóż, zmiana rozdzielczości to nie tylko zmiana (czy jak piszesz konwersja) grafiki - gra będzie wymagała sporej zmiany kodu (kolizje itd) i przypuszczam że tutaj naprawdę nikt tego nie zrobi przez multiplikację roboczogodzin i stopnia trudności. A przynajmniej nikt tego nie zrobi w megaturbo tempie Mariusza :)
the fender @2016-06-15 10:02:20
(po namyśle): zresztą nie będę tutaj udawał mądrego bo nie koduję. Mnie się może wydawać, że tutaj trzeba cały kod przerobić (rysowanie plansz, tory ruchu, kolizje, synchro, inne sprawy) a może to się załatwia jakimś konwerterem ;)
@the fender: nie, nie wymaga sporej zmiany kodu :) Tak naprawdę jest to jedynie optymalizacja grafiki (bo automatyczna konwersja wyprodukuje badziew, który potem trzeba ręcznie poprawić).
Więcej - wszystkie obliczenia w kodzie nadal mogą odbywać się jak dla hi-resu - po prostu różni się warstwa wizualizacji i tyle. O wiele większa jest różnica w rysowaniu na Atari i Spectrum - wręcz diametralna. Jeśli to nie wymagało wielkiej zmiany w kodzie, tzn że i zmiana trybu nie spowoduje.
xxl @2016-06-15 10:59:59
wystarczy ze kolizje sa obliczane na podstawie grafiki albo czesc grafiki (np.pociski) jest realizowana nie na zasadzie spritow programowych - co jest bardzo czeste :D i cala Twoja teoria sie sypie. poza tym zmiana grafiki to nie tylko zmiana trybu ale takze czesto zmiana organizacji pamieci ekranu.
Na szczęście nie w Atari i nie przy tych dwóch trybach :) Poza tym dwie rzeczy: jeśli coś jest obliczane na podstawie grafiki, to znaczy, że nie jest to robione najlepiej ;) A jeśli już z jakichś powodów musi być, to różnica pomiędzy tymi trybami wymaga małych korekt jedynie. Na samym dnie operujesz nie na przestrzeni X/Y ale na adresach - a te będą dla tych samych miejsc takie same. Po prostu pixel zamiast 1 bita zajmuje 2. Więcej, można nawet zrobić to w sposób przezroczysty, engine gry nadal operuje na 320x200, a przekłada się to na 160x200.
Poza tym raczej nie sądzę, bo różnice w organizacji pamięci między hiresem Atari i Spectrum są takie, że jeśli ta gra opierałaby się na grafice to najbardziej poważne zmiany w kodzie już zostały zrobione.
@the fender: to nie teoria tylko właśnie twarda praktyka.
Jak się tworzy oprogramowanie komercyjnie, to się je konstruuje w ten sposób, aby wszelkie zmiany czy konwersje były jak najmniej czasochłonne bo to kosztuje. Zwróć uwagę, że te wszystkie gry wychodziły na kilku różnych platformach. Teraz pada przed wydaniem decyzja - zmieniamy grafikę. Albo robimy konwersję na drugą platformę. I co? Kilka miesięcy pracy w kubeł. A to kosztuje, tym ludziom ktoś za ich pracę płaci. Właśnie dlatego robi się to warstwami - engine, interfejs, wizualizacja, model gry - również po to, aby konieczne czasem modyfikacje jednej nie pociągały konieczności kosztownej modyfikacji innych.
Ujmę to tak: jak się robi amatorsko w ramach hobby grę, dla konkretnej platformy, jedną przez parę lat, to można sobie takie błędy popełniać - to nie kosztuje.
mariuszw @2016-06-15 12:12:40
Ja osobiście za konwersję gry z konwersja grafiki hires -> lores bym się nie brał. Za dużo rzeczy może się skomplikować i zepsuć, a nakład czasu potrzebny na znalezienie i naprawę problemu bardzo by wzrósł. Przy tym jak ja robię konwersje ze Spectrum nie muszę wiedzieć gdzie w kodzie oryginalnej gdy jest rysowanie grafiki, sprawdzanie kolizji, logika, itd. - wystarczy, że zadbam o to, by każda pojedyncza instrukcja Z80 został przetłumaczona na odpowiedni ciąg instrukcji 6502, które dadzą dokładnie taki sam efekt (czyli np. odczyt czy zapis odpowiedniego miejsca w pamięci). Dzięki takiemu podejściu można to zrobić szybko i efektywnie.
mariuszw @2016-06-15 12:15:14
@pin: finalna gra ma mieć PMG overlay, co by dodać jej trochę kolorów. Projekty już są gotowe i wygląda to nieźle. Nie planuję specjalnej wersji pod VBXE. Co do działania na 65c816 - w finalnej wersji będzie synchronizacja z ramką, co by gra nie latała za szybko.
Ok, zajrzałem przez debuger i już sobie odpowiedziałem :) No, sprytnie :)
xxl @2016-06-15 12:30:26
@wieczor: nie miales okazji sprawdzic jak wyglada od srodka ta sama gra dla dwoch roznych platform, nie zrobiles nigdy zadnej konwersji gry... miej dla siebie troche litosci i przestan bajdurzyc. praktyka wyglada troszke inaczej niz Twoje wyobrazenia.
Jak wygląda praktyka, to akurat trochę wiem. A w Twojej wypowiedzi, jak zwykle żadnych konkretów tylko personalne wycieczki bez pokrycia :)
xxl @2016-06-15 12:59:06
sprawdzam.
the fender @2016-06-15 17:10:32
@wieczór: prezentujesz podejście nowoczesne. W tej chwili gra to projekt w np. Unity, który kompiluje się dla różnych środowisk. Podobnież wcześniej pisało się w C, C++ i zmieniało tylko biblioteki oraz sposoby obsługi dźwięku, obrazu, urządzeń we-wy. Ale kiedyś ... oj panie. Wolna amerykanka. Dostawała grupa osób opis gry w formie papierowej, pewnie jakieś konkretniejsze informacji + automat arcade na jakiś czas. Cel - zróbcie konwersję :D I tak też te gry powstawały. Nie wiem wieczór ile rzeczy zaprogramowałeś, zakodowałeś, możliwe że znasz się na tym lepiej ode mnie. Możliwe, że w tym momencie ja lamer próbuję dyskutować z doświadczonym koderem. Niemniej z mojego doświadczenia i z tego co wyczytałem oraz usłyszałem - no tak to wygląda jak opisuję. Wg mnie zrobienie wersji 2x1 gry w hiresie w praktyce sprowadzało by się do napisania tego od nowa w oparciu o kod źródła (np logika). Kawał żmudnej roboty.
jhusak @2016-06-15 17:29:03
@wieczór, myślę, że zdajesz sobie sprawę, że w przypadku gier typu Knight Lore (tak rozbudowanych) liczy się każdy bajt. Nikt nie będzie pisał gry z celem przenośności, aby potem utknąć z powodu końca pamięci. Pierwszeństwo przy pisaniu gier: - jak to zmieścić w pamięci - optymalne procedury graficzne - logika ... - przenaszalność. Akurat w przypadku Knight Lore udało się na podstawie wciąż podrasowywanego silnika tworzyć nowe gry, ale tylko na tę samą architekturę. Na szczęście się to zmienia i możemy sobie w spektrumową gierkę pograć na Atari :)
@the fender: oczywiście, że trzeba było pisać od początku, bo pisało się w assemblerze, a ten na każdym sprzęcie był inny. Ja mówię o czymś zupełnie innym - uzależnienia logiki gry od struktury ekranu. To nie ma najmniejszego sensu. Logikę gry opiera się o X / Y a nie o konkretne położenie elementów w pamięci. I nie, separacja wcale nie musi zajmować więcej pamięci. A jeśli logika jest niezależna od struktury ekranu to i zmiana rozdzielczości nie owocuje "olbrzymimi zmianami w kodzie" a jedynie kosmetycznymi poprawkami ze względu na inne granice (160 a 320 na przykład). I szczerze mówiąc do dość trudno jest zrobić to tak, żeby stanowiło to wielki problem. Tu nie chodzi nawet o przenaszalność, ale nawet o zmiany grafiki czy np. trybu. Rysowaniem i wykrywaniem kolizji zajmują się osobne procedury, a te można z powodzeniem napisać tak, że logika dla 320 kwadratowych pikseli będzie działać na 160 prostokątnych.
Mariusz pisze o czym innym - jest w stanie zrobić konwersję szybko dlatego, że w ogóle nie wnika w logikę gry - przygotował strukturę ekranu w pamięci taką jak jest na Spectrum, nieliniową - akurat na Atari Antic to umożliwia - w przypadku np. C-64 już by nie było tak prosto.
the fender @2016-06-15 18:27:20
@wieczór: czekaj czekaj, bo albo Ty coś plączesz albo kompletnie się nie zrozumieliśmy. Pisałem od początku o tym co Ty sformułowałeś teraz :) Że tak zacytuję swoją wypowiedź:
quote:
No cóż, zmiana rozdzielczości to nie tylko zmiana (czy jak piszesz konwersja) grafiki - gra będzie wymagała sporej zmiany kodu (kolizje itd) i przypuszczam że tutaj naprawdę nikt tego nie zrobi przez multiplikację roboczogodzin i stopnia trudności. A przynajmniej nikt tego nie zrobi w megaturbo tempie Mariusza :)
I Twoją odpowiedź:
quote:
@the fender: nie, nie wymaga sporej zmiany kodu :) Tak naprawdę jest to jedynie optymalizacja grafiki (bo automatyczna konwersja wyprodukuje badziew, który potem trzeba ręcznie poprawić).
No i wszystko się zgadza. Zmiany jakich trzeba dokonać w kodzie nie są jakieś potężne czy wywracające wszystko do góry nogami. Nie napisałem że nic zmieniać nie trzeba - no trochę trzeba :)
Powiem więcej - chociaż tego jeszcze nie sprawdzałem - że na bank logika i interakcje między obiektami, gry takiej jak Gunfright na pewno nie rozgrywa się w oparciu o to, co jest na ekranie - jest odwrotnie.
the fender @2016-06-15 19:40:09
Czyli zakładasz z góry, że kod po deasemblacji będzie czytelny, z wyraźnie zaznaczonymi fragmentami (etykiety) które odpowiadają za logikę grę i które będzie można zostawić a resztę przepisać nie wywracając wszystkiego do góry nogami ? :)
Czekam z niecierpliwością, może xxl coś tu jeszcze napisze, albo jhusak, albo ktoś inny parający się konwersją gier.
@the fender: nie bardzo rozumiem pierwszy akapit Twojej wypowiedzi... A gdzie ja coś takiego napisałem? :) Etykiety po deasemblacji? O czym Ty piszesz? Może jeszcze dokumentacja kodu Ci powstanie i komentarze autorów? :)
Jeśli przerabiasz grę tzn. dostosowujesz ją do nowego środowiska i wymaga to zmian np. obsługi ekranu, to musisz ZNALEŹĆ i ZROZUMIEĆ miejsca gdzie się to dzieje - no nie ma innej opcji. Chyba że masz możliwość dostosowania środowiska do warunków wyjściowych - tak jak powyżej. Co ma czytelność kodu do wielkości zmian jakie trzeba w nim wykonać? Tego się nie robi losowo - a tu zmienię cyferkę i zobaczymy co wyjdzie :)
Ja po prostu zakładam i nie biorę tego założenia z sufitu - że jeśli tworzysz coś bardziej złożonego logicznie niż pong albo tetris, to ekran pełni rolę usługową i gdzieś jest logika gry a gdzieś wizualizacja stanu. Może nawet i faktycznie ekran być używany jako model do pewnego stopnia, ale nie bezpośrednio piksele - takie podejście nie ma najmniejszego sensu i uzasadnienia bo: zamiast gry tworzysz wtedy półinteraktywną animację (wygląda znajomo?), nie masz kontroli na współczynnikami i zależnościami obiektów w grze, bo Twój model robi się bardziej skomplikowany i w końcu - takie właśnie podejście wcześniej czy później doprowadzi do pamięciożernośći produktu - bo siłą rzeczy dużo elementów będzie się duplikować. Inna jest sytuacja, gdy model jest prosty i płaski - np. pacman, tetris, czyli pamięć znakowa jest jednocześnie modelem - ale tu z kolei nie ma żadnego dylematu jak obiekt będzie wyglądał, w jakim będzie trybie i czy będzie kolorowy czy biały na czarnym, bo Twoją jednostką logiczną jest znak i nie obchodzi Cię jak on właściwie wygląda :)
the fender @2016-06-15 20:23:33
Oczywiście, że nie napisałeś - to była celowa i perfidna hiperbola z mojej strony :D Po prostu sądzę, że to wszystko jest trudniejsze i bardziej zagmatwane niż Ty to opisujesz. Oczywiście eksperymentów Gonza nie bierzemy tutaj pod uwagę. Jestem typem, że dla mnie szklanka zawsze jest w połowie pusta a dla Ciebie pełna. No ale przecież to nie jest nic złego, dwa podejścia. Najlepsze w tym wszystkim jest to że u mnie na gadaniu się (niestety) kończy. A u Ciebie? :)
szeryf @2016-06-15 20:36:47
Chcac nie chcac musze stanac w obronie Wieczora, ze o ile moze konwersji nie robi (chyba ze mnie poprawi) to z kodowaniem na Atarke daje rade (czemu czasem daje upust) o ile moge sie na ten temat wypowiadac, chociaz straszny z niego filozof i... wystarczy ;)
Przy odpowiedniej atomizacji procedur i pilnowaniu o implementacji w odpowiednich warstwach kazda konwersje mozna sprowadzic do latwo rozwiazywanych kwestii lub przemyslanych kompromisów, ale wystarczy troche podziabac na 8 bit zeby wiedziec ze w przypadku kodowania na tych maszynkach jest dokladnie tak jak napisal jhusak i z czym akurat kolega Wieczor zdaje sie juz nie polemizowac, zreszta slusznie :)
the fender @2016-06-15 21:06:29
No okej, w takim razie nie będę więcej polemizował w tym temacie :)
Żeby naprostować parę kwestii - nie twierdzę, że jest to zadanie trywialne - największym wyzwaniem jest zorientowanie się w obcym kodzie i dojście gdzie co się znajduje. Taka inżynieria wsteczna, wymaga zdolności detektywistycznych, ale przede wszystkim cierpliwości, bo jest to po prostu żmudne. Wypowiedziałem się jedynie na temat komplikacji etapu drugiego - tzn. faktycznej modyfikacji - np. trybu graficznego. I rozmiaru modyfikacji, jakie musimy uczynić, oraz komplikacji TEJ właśnie operacji :) Pozwoliłem tu sobie popolemizować z hipotezą, jakoby tryb graficzny był uwikłany w grę tak bardzo, że jego zmiana okaże się jakąś rewolucyjną rekonstrukcją.
Przy czym wcale nie zamierzam nikogo za bardzo namawiać na podjęcie tego wysiłku :)
Prof. zw. dr hab. Stanisław Rumianek @2016-06-15 21:37:09
Zrobiła nam się wspaniała filozoficzna dyskusyja. Więcej proszę.
Był tu kolega Smaku który miał patent na szybką konwersje dowolnego tytułu na Atari. To musieliście go pogonić! Cenna inicjatywa była a wy go zniszczyliście.
Interceptor @2016-06-15 23:55:45
Nie było innego wyjścia. Istniało uzasadnione ryzyko, że po konwersji wszystkich programów na Atari rynek współczesnych komputerów całkiem się załamie.
@maly_swd: wcale niekoniecznie. Atari tak naprawdę pozwala w wielu punktach na znacznie więcej niż inne 8-bitowce. Chociażby możliwość uzyskania prawie dowolnej struktury pamięci obrazu. Oczywiście padną tu zaraz argumenty o commodorowskich sprite'ach, mapach kolorów i tym podobnych pierdołach :) Ale to jest absolutnie nieistotne. Metodyka działania jest niezależna od platformy. Ale to już jest dyskusja bardziej o projektowaniu gier niż o konwersjach. Ja myślę, że Twoja wypowiedź powinna się odnosić nie tyle do Atari, co do atarowców :)
the fender @2016-06-16 09:15:39
quote:
Był tu kolega Smaku który miał patent na szybką konwersje dowolnego tytułu na Atari. To musieliście go pogonić! Cenna inicjatywa była a wy go zniszczyliście.
Czy aby na pewno ? :)
bocianu @2016-06-16 11:04:15
Widzę że ktoś mnie uprzedził.
Właśnie chciałem Was uświadomić, że cała ta dyskusja, pomimo tego, że jest merytoryczna i ciekawa, to byłaby absolutnie bezprzedmiotowa, gdybyśmy dali szansę na zastosowanie legendarnego FILTRA by SMAKU. Ale komuś tutaj przeszkadzały jego rewolucyjne pomysły i teraz mamy co mamy... Ale z drugiej strony, wtedy Mariusz nie miałby już nic do roboty :)
A tak na serio, to chętnie bym się sam zabrał za jakieś konwersje, ale jeszcze długa droga przede mną. Za to chętnie bym pomógł przy jakiejś konwersji Mariuszowi (a najchętniej właśnie Laser Squad).
xxl @2016-06-16 11:18:14
wyprzedzil swoj czas
the fender @2016-06-16 11:25:21
xxl miszcz :D
kris3d @2016-06-16 23:06:43
@bocianu, ty już przestań z tym smaku bo to sesu nie ma;) A tak serio, jeśli bocianu chce pomóc przy kodzie, to ja mogę przy grafice, może coś razem zwojujemy:)
mariuszw @2016-06-17 22:53:43
@bocianu,@kris3d: możemy spróbować z Laser Squad. Która wersja gry powinna być użyta jako baza - ZX Spectrum czy C64? (wyglądają prawie identycznie, ale może są jakieś różnice w rozgrywce?). Można by też spróbować przygotować koncepcję graficzną - spróbować podkolorować w G2F parę screenów z gry.
bocianu @2016-06-18 01:00:44
Wersja na c64 miała więcej map. Przynajmniej tak było jakieś 25 lat temu. Rozgrywka była identyczna, grafika prócz kolorów też, chociaż w spectrum mapa miała widoczne pole o rozmiarze 11 bloków, w c64 viewport mapy miał 13 bloków. Wiecej różnic nie pamiętam.
Jezeli chodzi o kolorowanie, to mam nawet pomysł jak to zgrabnie zrobić :) Ja jestem chętny!
kris3d @2016-06-18 13:19:25
Ja też:)
mariuszw @2016-06-18 18:26:19
@bocianu,@kris3d: To do roboty Panowie ;) Czekam na propozycje. Ja zacząłem przeglądać kod wersji C64. Proponuję użyć AtariAge do kontaktu i założyć tam prywatny wątek. Dajcie mi znać, jak Was znaleźć na AtariAge.
the fender @2016-06-18 20:20:01
No wreszcie! :) 3mam kciucki.
bocianu @2016-06-18 22:35:44
ok, odezwałem sie na atari age na priva ;) do roboty!
Goonies76 @2016-08-19 13:18:44
Skonwertujcie spectrumowe Green Beret! Dodać parę kolorków i mamy HIT! :-) Marzenia ścietej głowy...
Całość 2817 MB
0-9
