I druga zapowiedź by Kaz 2008-12-02 01:21:45

Wczoraj była zapowiedź pojawienia się gry Paradroid, konwersji z C64, dzisiaj zaś kolejnej gry, konwersji z Amigi. Właściwie w obu przypadkach to informacje o rozpoczęciu prac - bo autorzy zastrzegają, że prace będą trwały długo, nawet i lata oraz niekoniecznie muszą się zakończyć sukcesem. Są one jednak prowadzone nie po to, żeby osiągnąć końcowy efekt za wszelką cenę, ale żeby spędzić czas na tym, co się lubi - na programowaniu Atari, na zmierzeniu się z własnymi umiejętnościami, na miłym i produktywym spędzeniu czasu z ulubionym retrokomputerem. Dzisiaj wysłuchamy majaczeń niejakiego Tomasza "Irwina" Bogdanowicza, który znalazł swoją idee fixe. Dalszy ciąg tej nowinki to już produkt Tomka :)

"Zeznanie schizofrenika Irwina z dnia trzeciego listopada 2008 roku, z godziny 21:03, taśma 6, sprawa numer XCA-12. Paszli.

01. Gadanie bez ładu i składu czyli historia o tym dlaczego właśnie ta gra o tytule: wiadomość kodowana.

Pewnego dnia Anno Domini 2008, gdy za oknem była świetna pogoda, ja, zamiast siedzieć przykładnie nad emulatorem Atari, poszedłem grać w tenisa. Eeee stop... Następnego dnia, gdy pogoda nie była już tak dobra, wpadł mi do mojej pustej czaszki pomysł, aby nie siedzieć na laurach i pisać bzdurne komentarze na stronce atarionline.pl, tylko samemu zebrać się i coś zrobić dla najlepszego komputera w historii komputeryzacji (jeśli uważasz inaczej, to zakończ czytanie tego tekstu gdyż możesz dostać palpitacji lewego palca u nogi). Postanowiłem pomyśleć - niestety to nigdy nie było moją mocną stroną - i po operacji „myślenie” doszedłem do paru konkretów:

- Porwał go Moriaty...
- Może w nazwisku Moriaty jest ukryta wiadomość...

Zaraz! to nie moja lista. O! Jest:

- koder ze mnie żaden
- grafik ze mnie żaden
- muzyk ze mnie żaden

Po przeczytaniu tych wstępnych ustaleń nie zapowiadało się to zbyt dobrze, ale jak to mówią, pierwsze płoty za koty, więc rozmarzyłem się na tematy, gdy w średniowieczu koło roku 1990-91 próbowałem opanować języki programowania, nawet kupiłem oryginał w LK Avalon ichniego „Quick Assemblera”, ale taśma była zwalona, poskręcana jak obsługa Graph2Font, ale w międzyczasie dorwała mnie hiszpańska gorączka zwana Amigą, więc nie robiłem z tego wielkie halo. Zresztą i dobrze, bo do dziś na sam widok STA czy nawet LDA dostaję drgawki - krótko mówiąc wolę chiński, bo jest prostszy. Tak więc moje próby ograniczyły się jedynie do Atari Basic, który przyswoiłem sobie w stopniu całkowicie niedostatecznym. Udało mi się przerobić grę z „Tajemnic Atari”, „Buisnessman” zdaje się, napisać program do malowania przy pomocy joysticka (w aż dwóch kolorach hiresu mającego aż dwie opcje: malowanie białym i malowanie czarnym czyli niejako kasowanie) oraz tak zwane rozwijane okienka w menu, które zobaczyłem w Workbenchu. I to niestety wszystko.

Analizując powyższe, moja gra, którą mógłbym zaoferować społeczności byłaby w Atari Basic pewnie w trybie tekstowym, bez grafy i muzy, za to z pełnym zestawem błędów i innych cudów. Każdy na jej widok używałby tajemniczej komendy następców „Norton Comandera”, to jest "F8". I nie ma się co dziwić, pewnie i ja sam bym miał podobny odruch obrony na tego typu "maestrię". Tak więc stanowcze NIE! Gry nie będzie! Gasimy światło i do domu! Kaniec filma! End of story!

Hmm... jak widzać, idzie trochę po grudzie, ale przecież jeszcze nic się nie stało, ot jedynie pełna katastrofa - ale nie takie rzeczy jeszcze przed nami. Po przeanalizowaniu powyższego, dodając jeszcze rozważania na temat moich możliwości w dziedzinie muzyki - umiem wgrać jakiegoś music trakera na PC i w gąszczu opcji znaleźć wyjście! Ot co! Oraz grafiki - tu nie piszę, sami widzieliście moje pokraczne "dzieło" w konkursie, postanowiłem więc że gra... BĘDZIE! Ha! włączać światło. Zaczynamy!

Po pierwsze secundo pomyślałem sobie (ach to myślenie), że gra musi dać się prosto napisać w Atari Basic lub Turbo Basic lub w jakimś innym języku wyższym, na przykład Action! (nigdy go na oczy nie widziałem, ale gra w założeniu ma być prosta, więc z gruntu będzie wyglądać podobnie we wszystkich językach wysokiego poziomu, a to oznacza, że jeśli będzie trzeba to Action! łyknę i się nauczę). Wszelkie gry akcji, ze sprajtami i tym podobnymi odpadają, bo nie miałbym pojęcia od czego zacząć.

Po drugie primo będzie to konwersja. Dlaczego? Bo mimo, że historię sam mógłbym wymyślić, to jednak zawsze tę grę (jaką grę? o tym później) lubiłem - nie wiedzieć czemu. Grałem w nią i ukończyłem na Amidze, potem na PC, a ostatnio na emu w wersję na Atari ST (najgorsza wersja, potraktowana wyjątkowo po macoszemu). Kiedyś przez przypadek natrafiłem na forum C64 i tam dowiedziałem się, że jest też wersja na C64. I nawet w angielskiej Wikipedii tak stało. Lecz po moim dochodzeniu worek wszedł do szydła i okazało się że "na C64? in your dreams maybe...". Tak więc wpis na temat wersji C64 w Wikipedii skasowałem (co można sprawdzić w historii). Na czym to ja skończyłem? Acha, na niepodaniu tytułu tej gry. No dobrze podaje, taadam: Plan 9 from Outer Space.



Plusy dodatnie i plusy ujemne takiego rozwiązania.
Zady:
Walety:

Algorytm gry (samej gry - menu jest proste jak budowa cepa) będzie takowy:



Ciekawostka: kiedyś w około 1993 roku sam tłumaczyłem grę na polski bezpośrednio w edytorze dyskowym (hexy) było to trudne gdyż należało uważać aby się nie pomylić i nie nadpisać tekstu, bo wychodziła kaszana lub gra w ogóle się nie wgrywała, także z tego względu iż w języku angielskim zdania z reguły są krótsze. Dodatkowo mój angielski był tak samo marny jak dziś ;-) Przetłumaczyłem około 50% gry i... nastąpiła zmiana kompa na 386 40mhz.

To taki uproszczony schemat (jest parę trudniejszych miejsc (save game) ale się nie zrażam, nikt mnie nie goni, jakoś się rozwiąże wszelkie problemy. Ale jak widać, gra nie wymaga takich hop siupów cudów niewidów jak choćby „Bomb Jack” czy inne gry z wykorzystaniem sprajtów czy szybkiej grafiki. Założenie jest takie: gra ma działać na 64k (wczytywane będzie partiami po parę obrazków). Możliwe, że będzie wersja dla przebrzydłych kapitalistów i dłubiących śróbokrętem pod pokrywą Atari, mających więcej RAM-u, gdzie będzie można wczytać więcej, ale to jeszcze długa droga. Ogólnie stan prac programowania: jeszcze nie wybrano języka czyli raczej bliski zeru ;-)

O samej grze:
Plan 9 from Outer Space to gra, która bazuje bardzo luźno na filmie pod tym samym tytułem, który zgodnie uznawany jest za najgorszy film w historii kina. Oczywiście to tylko taki mit, jest cała rzesza gorszych filmów, zwłaszcza obecnie. Jednak po prawdzie film jest słaby. Ale tego typu filmy klasy C z lat 50-tych i 60-tych mają wielu fanów. To można by powiedzieć: klasyka kiczu. Jeśli nie widziałeś (jest darmowy – choćby tutaj) to polecam najpierw obejrzeć film "Ed Wood" z 1994 z Johnem Deepem który przedstawia koleje życia reżysera filmu Eda Wooda granego przez Deepa, pracy m.in. nad właśnie tym filmem i jego przyjaźni z niedocenionym aktorem Belą Lugosi - co ciekawe odwórca roli Beli - Martin Landau dostał w 1994 roku Oskara za rolę drugoplanową w tym filmie.



Próbowałem kontaktować się z autorami owej gry i jedynie udało mi się to z autorem wersji na Amigę i Atari ST Thomasem Rolfsem. Gra pierwotnie wyszła na PC napisana w Borland C, a Thomas zrobił wersje w asemblerze na dwie wspomniane wyżej platformy. Niestety mimo iż szukał źródeł, to jedynie co znalazł i mi podesłał to kod źródłowy kodeka wideo z tej gry w wersji dla Amigi. Tak czy siak dla mnie absolutne mambo-jambo, a i tak dla Atari XE nieprzydatne. Fragment tej poezji:

include hardware/custom.i
ciaapra EQU $bfe001

XDEF _animate
XDEF _fixfilm

Planesize = 40*200
buf_width EQU 24
buf_height EQU 100
buf_size EQU buf_width*buf_height


SECTION fisrt,Code

_animate: link a6,#0
movem.l d1-d7/a0-a5,-(sp)

move.l 8(a6),FirstPlane
move.l 12(a6),a0
move.l 16(a6),d0...

Thomas nie widzi przeciwskazań próby freewareowej konwersji, ale to nie on jest posiadaczem praw, a Gremlin Graphics. Próby kontaktu z innymi nie przyniosły rezultatu. Tak na przykład odpowiedzialna za grafikę Nicola Sedgwick styk z grami miała jedynie w 1992 i jedynie przy tej jednej grze, a potem jej drogi z grafiką w grach się całkowicie urwały – obecnie maluje obrazy. Jako ciekawostka: nikt, nawet Thomas Rolfs, nie wie kto zrobił muzykę do gry, nigdzie na wszelkiego rodzaju bazach danych (na przykład tu czy MobyGames nie ma informacji, kto ją zrobił. Thomas stwierdził tylko, że mu ją dostarczono, a skąd – nie wiadomo. Tak czy siak na razie kwestia praw to temat dla mnie odległy.

02. Muzyka czyli piski z pokładu Pokey'a, o zgrozo zwanego przez niektórych nawet układem dźwiękowym

Tutaj krótko: w grze występują dwa moduły. Tytułowy zajmujący 190KB - nieużyteczny, bez klimatu. Drugi w grze, 43KB, bardzo nastrojowy, krótki. Autor/autorzy nieznani - ktokolwiek widział, ktokolwiek wie...

Wadą jest to, że gra kontrabas, a tego instrumentu nijak Pokey naśladować nie może - jeśli w ogóle jakikolwiek może (na boku: nie jestem fanem Pokeya ;-). Widziałem jednak, czy to na YouTube czy to w ASMA, możliwość użycia na jednym kanale sampli. To by było świetne i po wstępnym sprawdzeniu całość nie zajęłaby więcej niż 7-8KB (przekonwertowany moduł w RMT jakieś 2kb plus jeden sampel 4bitowy 4-5kb). Co jeśli się tak nie da? Hmm... ostatnio widziałem i rozłożyło mnie to dokumentnie „Vicious SID” z Party X na C64. Scroll, animowane VU-meter i animowane napisy na pół ekranu i... gra 4-kanałowy 8 bitowy, powtarzam: 8 bitowy! moduł z super jakością. Zresztą sami sprawdźcie. Tak więc Atari musi dać sobie radę z 1kanałem 4bitowym - jeśli nie, to myślę że w ogóle nie będzie muzyki w grze. Stan prac - przy pomocy RMT wgrałem i poprawiłem ten modulik, aby znośniej grał, ale jak powyżej - bardzo konieczne byłoby wykorzystanie tego kontrabasu na jednym z kanałów. Wtedy to jest nastrój - inaczej po dwóch minutach użytkownik zamiast nastroju dostanie rozstroju.

03. Video DivX na Atari XE? Na 64k? A jedzie mi tu czołg?

Jak wiadomo, lub nie ;-), celem gry jest odnalezienie sześciu rolek filmu, które zostały skradzione. Filmy te są realistyczne, przedstawione w grze jako krótkie 5-30 sekundowe sekwencje wideo. Aby zmieściły się w rozsądnej ilości dysków (w wersji na Amige, Atari ST zajmują jedną dyskietkę, na PC 1MB na HDD) zostały potraktowane kompresją. Jest to jedna z pierwszych gier, które posiadają takie wstawki. Ta kompresja w rzeczywistości nie wygląda za dobrze (to znaczy dziś, bo kiedyś to szczęka była na ziemi), gdyż odtwarzane są w specyficzny sposób – na przykład jeśli na ekranie postać po lewej stronie coś robi to cały środek i prawa część ekranu przez parę, paręnaście klatek jest w bezruchu. Filmy są w rozdzielczości około 150 na 95 pikseli, w około 5 klatkach na sekundę. Zdobycie ich jest niejako celem gry, więc absolutnie muszą być też w wersji na Atari.

Problem jednak brzmi - jak tego typu filmy wyświetlić na Atari? W szczególności jak wyświetlić na Atari 64KB? Jest „TIP Animator” TeBe-go, ale ma on trzy dyskwalifikujące go do mojego projektu wady:



Dlatego już przy pierwszym artykule, w którym opisałeś ów program, pokazałem jakby to można zrobić inaczej, a mianowicie - kompresja wektorowej kwantyzacji VQ. Za przykład podałem stronę, na której jeden z użytkowników C64 zaprezentował wersję na ów komputer. XXL napisał wówczas "Irwin, jest tylko mały problem... na Atari możesz zdefiniować o połowę mniej kształtów w zestawie znaków". Ja jednak się nie poddaje tak łatwo ;-) i postanowiłem się temu przyjrzeć szczegółowo. Mimo, że nie znam się na metodach kompresji zbytnio, to zadałem sobie trud, aby zrozumieć co pod tym groźnym VQ się kryje. Otóż schemat działania - w wersji na C64 - opiera się na takich krokach:

Skoro XXL pisze "Irwin jest tylko mały problem... na Atari możesz zdefiniować o połowę mniej kształtów w zestawie znaków" to znaczy to jedynie tyle, że baza znaków będzie musiała być częściej wymieniana, co spowoduje jedynie zmniejszenie kompresji, a powiększenie pliku. Jednak absolutnie nie oznacza, że tej metody nie da się zastosować na Atari. Gdyż po prawdzie, aby jakość wideo nie spadła znacząco, baza znaków tak czy siak musi być co jakiś czas wymieniana.

Postanowiłem więc napisać do Naveeda, autora tej metody, aby opisał, na co mniej więcej możemy liczyć. Oto odpowiedź: "If I was to use the similar VQ method using your example (160x100 x 25fps for 4 seconds) it would use around 27k (0.25k per frame) and 2k for the codebook. However for improvement in quality, the VQ routine can either be improved or multiple codebooks can be used." Cóż to oznacza? Że 4-sekundowy film 160x100 odtwarzany z prędkością 25fps zajmie na Atari jakieś 32 góra 35kb (z uwagi na częstsze zmiany bazy znaków). Gdy zamiast 25fps ustawimy 8fps (co przy 5fps w wersji na Atari ST czy Amigę jest i tak dużo) a wykorzystamy powiedzmy 53kb pamięci Atari to mamy około 20-22 sekundy filmu w 160x100 w 8fps, ze zmianami na całym obrazie, a nie tylko w częściach, jak na Amidze czy Atari ST.

Ponadto, co istotne, takie 6 filmów mogłoby się zmieścić na dwóch dyskach 130KB, tym bardziej, że jak pisze autor "video data can be further compressed using LZ compression etc. If there are similarities between each frame or less data than it can be compressed even further." Można też zrobić wersję w większej ilości klatek, płynniejsze, lub/oraz w większej rozdzielczości dla maszyn 320KB. Ale co istotne, wykorzystując tę metodą można realnie myśleć o wykorzystaniu filmów wideo w grach na Atari, nawet tych z najmniejszą ilością pamięci.

Oczywiście odpowiednia procedura dekompresji musiałaby być napisana, na podstawie źródła od Naveeda, przez kogoś kto zna assmebler i potem dołączona do programu Action! czy TurboBasic do wykorzystania dla mniej zdolnych w programowaniu. Lub w ogóle po wybraniu odpowiedniej opcji gra odegrałaby taką animację (xex), po czym znów powróciłaby do gry (ładując obrazki, które musiałby wcześniej ustąpić miejsca animacji).

Stan prac: próby znalezienia metody by mieć filmy na 64k - opisane jak powyżej, dalsze działania w toku. Ponadto korzystając ze stosownego programu Naveeda, VirtualDubb i paru innych programów do obróbki wideo, zrobiłem wersję „jak mogłoby to wyglądać”. Czcze gadanie nie daje takiego wyobrażenia jak efekt wizualny. W załączeniu dwa pliki: 20-sekundowe wideo w 160x120 (a raczej 80x120) w 8 fpsach (więcej niż w wersji np na Atari ST, żródło to wersja DVD filmu), która zajmowałaby jakieś circa 55kb na Atari XE (kierując się danymi od Naveeda). Plik w załączniku zajmuje 9MB, bo są to full uncompresed frames, po to by dość wiernie oddać efekt. I drugi plik: 15-sekundowy (jakieś 42kb na Atari). Są też dwa pliki xex, żeby zobaczyć wstępnie jak to wygląda przy zestawie znaków Atari (128 sztuk).



04. Grafika czyli VBXE wysiada

Po pierwsze grafika stanowi niejako 95% gry, jest w niej około 90 (dokładnie nie wiem ;-) screenów w rozdzielczości 196x122 pikseli. Chodzi mi tylko o te ekrany wewnątrz, bo całość, jak to przystało na 16-bitowce ma więcej - 320x200 na PC i Atari ST oraz 320x256 (no 320x248 dokładnie rzecz ujmując, na Amidze). Wersja PC jest najładniesza bo 256 kolorów robi swoje, ale i Amigowa w 32 kolorach wygląda ładnie, gdyż grafik posiedział przy konwersji i zredukował jej niedokładności. Ponadto ma lepszy ekran około-wnętrza (menu nagrobkowe, stojąca wampira) i to na niej się opierałem, gdyż Atari XE ma te swoje 240 pikseli. Wersja na Atari ST - szkoda gadać, zero przyłożenia, dosłownie konwersja do 16 kolorów z Floydem-Steinbergiem.

Wersja na Atari XE będzie działać w rozdz. 168x240px (czyli 336x240) a ekrany wewnętrzne powinny być w 98x122 (196x122 z powyższych kompów) ale postanowiłem je trochę powiększyć do 106x132 (212x132). Są większe co lepiej rzutuje na grę. Zresztą początkowo wersji było od groma, a i nadal mam w głowie kilka projektów – ale wszystkie dotyczą już tylko jednego ekranu okołownętrzowego (mam nadzieję, że łapiecie, co mówię, bo ja nie ;-) Początkowo były na nim 3 kolory: czarny i dwa niebieskie do oddania tła, bo jak widziałem wersje 2 kolor (czarny i jeden niebieski) na Atari ST to mnie zemdliło ;-). Potem z uwagi na praktycznie unicestwienie sobie kolorów musiałem zrezygnować z jednego koloru niebieskiego, ale zastąpiłem go ditheringiem i mam nadzieję - lepiej niż grafik na Atari ST, co można porównać. Ostatnio jednak coraz częściej mam chęci, aby w ogóle pozbyć się niebieskiego koloru po bokach obrazka wewnętrznego, ino czarny zostawić. Ale jakoś nie mogę... te małe latające ufa - żal kasować ;-). Nie wiem, póki co korzystam z tego niebieskiego ile się da w samym obrazku.

Jeden z duszków-pocisków będzie używany jako wskaźnik joya (myszki) i być może (na 90%) będzie zmieniał kształt, tak jak w wersji na 16-bitowce, na przykład na kształt lupy przy „Look” („Look” jest zamiast „Examine” – żeby nie było za dużo liter na nagrobku ;-) czy ręki przy „Take”. Mimo, iż posiadane przedmioty widziane są jedynie jako nazwy z boku, to chyba w wersji na XE zrobię osobny ekran inventory - każdy kolor na wagę złota, a używanie zmieniających się przy każdym obrazku kolorów - gdyż nie zawsze będzie przecież biały - nie wygląda ładnie. Będą wyświetlanie także jako napisy, ale wewnątrz okna na specjalnym obrazku inwentory.

Myślę, że cała gra razem z animacjami, muzyką, tekstami (tu uwaga: teksty będą podzielone na te co są zawsze obecne i te które będą dotyczyły tylko danego obrazka - opisy przedmiotów, pomieszczenia, teksty rozmów - jest tu z 50KB tekstu, więc nie ma co ładować je naraz) i tonami obrazków powinna zająć około 1MB czyli trzy dyskietki 360kb (lub 2 x 180KB lub 8 dyskietek x 130KB lub... inne kombinacje dyskietek ;-). A ponadto plik 1MB jako HDD dla SIO2SD. Chcę aby nikt potem z C64 nie powiedział "Eeee, ta gra zajmuje 50MB, nikt by tego kiedyś nie wydał."

Stan Prac: Przy obrazkach jest najwięcej roboty (to nie VBXE). Wiem Kaz, że mi mówiłeś, że najpierw kod - ale ta gra to przede wszystkim grafika i to zajmuje sporo czasu. Narazie siedemnaście obrazków jest gotowych. Właściwie "prawie gotowych”, bo zawsze do nich wracam i coś poprawiam, szmat jeszcze przede mną, zwłaszcza te trudniejsze. W załączniku kilka ze zrobionych, prawie ...;-). Jeden z nich pokazuje duszka "lupa" na ręczniku i wyświetlony opis, oraz na górze, na żółto, jak na maszynach 16bitowych, wyświetlanie gdzie prowadzą drzwi. Oczywiście, gdy na nie wskażemy - tutaj akurat wskaźnik jest na ręczniku, więc napisu "go to corridor" być nie powinno ale to tylko przykład.

05. Reasumując będzie tu nie lada zakończenie

Co aktualnie się dzieje: niedużo, zawiesiłem na razie pikslowanie kosztem czytania, przeglądania i sukcesywnego rozgryzania Action!, gdyż stwierdziłem, że chyba w tym języku da się grę zrobić porządnie. Dużo pomogły linki które ktoś na atarionline.pl zapodał. Przy okazji mam podobne problemy [http://atariarea.krap.pl/forum/viewtopic.php?id=6404]Nosty[/link].

Kontakt z Naveedem wyjaśnił ten skomplikowany kod kodeka. Po prawdzie wcześniej sam do tego doszłem, ale moje przypuszczenia potwierdził potem sam Naveed. Te czary-mary Vector Quant nie są tak straszne jak je Irwin maluje ;-). Otóż kod to po prostu wyświetlenie owych znaków, charsetu na ekranie, tyle że zamiast tekstu wyświetlane są stosownie ułożone znaki, przygotowane przez encoder. Czyli niejako po prostu wyświetlanie tekstu, 8 klatek na sekundę w określonym miejscu ekranu. Z tym podejrzewam nawet Atari Basic sobie poradzi. Jak sam autor mówi, cała filozofia, cała praca to dobrze działający encoder czyli program na pc, który odpowiednio przygotuje owe klatki i zestawy znaków. W obecnej fazie nie jest on odpowiednio dopracowany (w czym przyznałem mu rację ;-), często przy swoich demkach musiał manualnie poprawiać, co już przy paru klatkach jest uciążliwe, a co dopiero przy setkach. Ponadto Naveed zaofiarował pomoc, że sam przygotuje owe animacje do mojej gry, jeśli bardzo zależy mi na czasie. Ponieważ czasu mam dużo ;-), a animacje dołoży się gdy będzie do czego je dołożyć, podziękowałem i dodałem, że poczekam na nowszą wersję encodera, gdyż wspomniał że się ona robi (głównie ma poprawiać automatyczne porównywanie bloków oraz chce dodać tryb 16 kolor – na C64). Oczywiście od razu poprosiłem go, aby dodał do niego bardziej użyteczny tryb prac z animacjami mającymi więcej niż kilka klatek, wybór rozdzielczości (na razie jest tylko 320x200) oraz możliwość ustawienia wielkości charsetu na inną niż ta, która obowiązuje w C64, dla innych 8bitowców w szczególności oczywiście wymieniłem Atari XE/XL ;-).

To tyle na ten etap prac - nie dużo - wiem, ale to mój projekt na lata ;-) i zamierzam przy tym dłubać - no może pod koniec 2009? Moje możliwości jak i wiedza o Atari są bliskie zeru - ale za to checi są, póki co. Więc ten poemat w swej naturze przedstawia raczej Don Kichota, który podejmuje nierówną walkę z wiatrakami, to jest programowaniem. Bo potem niektórzy mogą szybko wytknąć różne nieprzewidziane rzeczy - z uwagi właśnie na braki w mojej wiedzy. Ja nie xxl czy Mono, magikiem nie jestem ;-).

Sesja zakończona taśma się skończyła. To był zapis stenografu sesji z pacjentem szpitala psychiatrycznego Irwinem z dnia 3 listopad 2008, z godziny 23:28, taśma 6 koniec. Przewiń taśmę do początku. Podpisał i stemplem opatrzył: Doktór Zenobiusz Cymbał. Uprasza się o nie rozpowszechniania powyższego stenogramu jak i dodanych do niego obiektów wizualnych."
Kaz 2008-12-02 01:34:14

Irwin - swietny pomysl moim zdaniem, bo wlasnie takie gry nie wymagaja nie wiadomo czego (pomijajac problem filmikow, ale one sa tu tylko dodatkiem). To kontynujacja takich gier jak Sexmisja czy Klatwa, ale z "uwspolczesniona" grafika i interfejsem uzytkownika. Jestem bardzo za.

Mam nastepujace uwagi do grafiki: nagrobek powinien byc podniesiony nieco wyzej, zeby ostatnie napisy na dole (DROP i LOOK) nie wypadaly w ostatnich wierszach obrazu. Na niektorych TV beda niewidoczne, ze o NTSC nie wspomne.

Druga uwaga jest taka, ze na jednym pocisku moze i zrobisz kursor, ale na pewno nie o roznych ksztaltach, w szczegolnosci lupy. Pocisk ma dwa piksele szerokosci. Albo musisz zuzyc gracza albo kilka pociskow. No chyba, ze masz na mysli bardzo zaawansowane wykorzystanie pocisku - i poszatkowac go w sposob wrecz niemilosierny (co linie). Ttak, jest to mozliwe, ale czy to bedzie Ci dzialac plynnie i dynamicznie?
mono 2008-12-02 01:54:36

Trzymam kciuki Irwin! Powodzenia i dużo zapału! Ciekawy projekt.
miker 2008-12-02 06:49:02

No, jakoś zmęczyłem ten artykuł... :]

Pomysł wygląda ciekawe, chociaż niektóre grafy można by było jeszcze podorabiać. Filmiki - za dużo tam "kaszy", podejrzewam, że jakby je nieco "oczyścić", to więcej klatek by weszło (ale dobra - nie jestem grafikiem). Co do muzyki - może POKEY kontrabasu nie potrfi, ale równie mroczne dźwięki potrafi z siebie wydać. Poza tym uprzedzony jesteś do niego - co widać, ale to już Twój problem (w Seksmisję grało się fajnie bez muzy, może i tu martwa cisza będzie pasować jak ulał). ;)

P.S. gdzie "poszłeś"? :P
dhor 2008-12-02 07:43:14

Dla mnie bomba.
Idealnym rozwiązaniem byłaby możliwość wyboru języka - dla naszych zagranicznych przyjaciół granie po polsku niekoniecznie będzie interesujące. My, istoty wyższe, po angielsku sobie poradzimy :), ale miło by też mieć wersję polskojęzyczną.
MaW 2008-12-02 10:55:22

ja bym pomęczył Naveeda o to, by dodał tryb 160x4 kolory. Na pewno by lepiej wyglądało niż ta kaszana b/w, a praktycznie jest do zrealizowania z przeniesieniem 1:1.
Kaz 2008-12-02 11:37:41

Miker - wybacz mu w sprawie Pokeya, to przeciez wariat :)
xeen 2008-12-02 11:51:55

wow,
bardzo klimetyczna grafa
niebieskie tło kojarzy mi się z the goonies, nie wiem dlaczego
MaW 2008-12-02 12:05:14

fakt, ale to raczej nie tło, a te cienie postaci w dolnej części ekranu
Kaz 2008-12-02 12:14:37

Irwin - w sprawie filmikow napisalem Ci maila, ale i tu wkleje:

Co prawda nie da sie wcisnac wiecej niz jednego zestawu znakow (128 sztuk) w jeden wiersz, ale jak wiesz, mozna zmieniac zestaw znakow nawet co wiersz. Gdyby program Needveda byl w stanie w kazdym wierszu (albo w co drugim, albo ile tam wystarczy - trzeba by potestowac) - uzyc innego zestawu znakow, to taka gotowa animacja zajmowalaby stosunkowo niewiele miejsca wiecej (kazdy dodatkowy zestaw znakow to 1KB wiecej), ale za to jakosc filmu powinna sie podniesc jakosc gigantycznie! Teoretycznie moze byc przeciez 30 zestawow znakow (3840 znakow) - co wiersz inny, dokladnie dobrany przez enkoder zestaw.

W praktyce wystarczy jednak duzo mniej! Po pierwsze obraz nie musi miec wysokosc 30 wierszy (240 pikseli) tylko na przyklad 25 (200). Po drugie na jeden wiersz potrzeba 40 znakow, jezeli nie bedziemy korzystac z zadnych kompresji, uzywania wiecej niz jednego znaku, itd. Czyli zestaw fontow wystarczy na 3 wiersze, co pozwala wyliczyc potrzebne na calosc: maksymalnie 10 zestawow - 10 KB. Tak jak jest w G2F. G2F daje tez mozliwosc optymalizacji i czesto wystarczaja 3-4 zestawy. To jest chyba droga, ktora nalezy isc... 3-4 KB wiecej, za to animacja lepszej jakosci niz na C64.

I jeszcze jedno - tutaj bawiles sie trybem 4-kolorowym, co pewnie wynika z tego, ze algorytm pochodzi z C64 i dotyczy podobnego trybu. Ale na Atari do tej konkretnie gry i do tych filmikow idealnie pasuje GR.9 - 16 odcieni.
irwin 2008-12-02 12:26:27

Wszelkie uwagi, pomoce, wskazówki a nawet groźby mile widziane.
Odpowiadając na pytania:
- zmęczenie przy czytaniu tego tekstu - Oooo! ja jestem kryty, to wina Kaz'a że chciał to koniecznie zamieścić ;-) Ja broniłem się jak mogłem, ale nic to nie dało.
- polska wersja też będzie, zdaje sie że nawet pisałem o tym.
- Kaz - twoje uwagi odnośnie grafiki - jak najbardziej słuszne przyjąłem i poprawię co się da.
- filmiki mają właśnie 4 kolory a nie b&w. A co do kaszany ;-) Atari ma 64k pamięci tak więc cudów nie oczekujcie. Przy 15 sekundach mówimy o około 3,5-4 kb na sec - to naprawdę mało nawet dla współczesnych kodeków które wymagają o wiele większych mocy i skomplikowanych obliczeń niż stareńkie 8bit 1,79mhz - Pamiętacie chyba co za układy są pod naszym pokładem. ;-) W każdym razie zaręczam że nie jest to jeszcze ostatnie słowo w tej kwestii. Już powstała mniej "kaszanna" wersja animacji, bez ditheringu która zajmuje jedynie 36kb a więc sporo jeszcze można ulepszyć. Ponadto - Ot w tej chwili dostałem kolejne genialne podpowiedzi od Kaz'a i w weekend postaram się je wprowadzić w życie (teraz trochę mało czasu)
- Nie jestem uprzedzony do pokeya, no może troszkę ;-) w każdym bądź razie wiele gier na Atari jest marnie udzwiękowionych - może dlatego. Jednak utwory wielu muzyków także a może przede wszystkim ;-) twoje Miker, które są znakomite i pokazują co Atari potrafi. Tak więc nie zrażaj się moimi osądami gdyż w dziedzinie muzyki jestem całkowite zero.

Wszelka pomoc mile widziana. Aha "poszłem spać" ;-)
Dzięki wszystkim za pochlebne opinie, ok narazie spadam bo Doktór Zenobiusz Cymbał idzie z obchodem ;-)
observer 2008-12-02 12:59:38

Irwin... przeczytałem tekst i jestem pod wielkim wrażeniem. Twoja determinacja i zawziętość jest godna podziwu. Jeśli już to trwa od jakiegoś czasu to myśle, że tak łatwo nie odpuścisz i w końcu ujrzymy jakieś beta-demo twojej gierki.
Z twojego tekstu jednak wynika, że dużo łatwiej napisać tą gierkę Ci byłoby na c64 - masz już gotowe rozwiązania techniczne.
Jakbyś się nawet kiedyś załamał przy projekcie spróbuj chociaż na tej innej platwormie. A skoro zaczynasz programowanie, może nawet od razu rób dwie wersje - co da Ci podwójną chwałę, a wiedzę wykorzystuj z/na "obu frontach". Szkoda żeby tyle wysiłku gdzieś bezpowrotnie przepadło.
Kaz 2008-12-02 13:21:57

Irwin - nie genialne, tylko elementarne :). Skoro ja to wiem, to tym bardziej dowolny koder.

Observer - dobra mysl z podwojna gra, ale to nie ma juz koderow na C64? Wlasciwie co sie stalo z tym projektem na C64? Irwin - badales sprawe to wiesz, napisz.
pin 2008-12-02 14:40:14

Mam serdeczną prośbę, tytułem pewnych standaryzacji :) - Jeśli gra ma składać z większej ilości plików, to czy:

* może działać pod kilkoma, co bardziej popularnymi dosami?
* ... i czy odwołania do filesystemu bedą kierowane do D:, a nie D1: o zgrozo. Pozwoli to na bezproblemowe korzystanie z dysku twardego.
* jeśli będzie użyta mysz, to czy będzie możliwość ustawienia w grze portu na którym powinna ona działać, oraz prośba o wsparcie dla dwóch standardów - czyli atari/amiga.
* uprasza się o legalne korzystanie z OS'a :)
* no i ewentualność nie zniszczenia loadera dosa w czasie ładowania gry jest mile widziana :)

to jest tylko moja drobna prośba, czy sugestia. Umożliwi ona być może zwiększenie grona potencjalnych graczy, bo osobiście przyznam - są tytuły dobre w które jednak nie gram wyłącznie dlatego, że ich uruchomienie wiąże się ze zbytnimi restrykcjami :)
Kaz 2008-12-02 17:08:30

I jeszcze bardzo dobra uwaga od Mono:
"Odnośnie algorytmów, popytajcie Epiego - on przecież zrobił program do odgrywania mpeg2 w realtime na Atari XL/XE za pomocą generatorów znaków. Robił też dobieranie optymalnego kształtu znaku zależnie od rozkładu."
pin 2008-12-02 18:45:52

oczywiście, ale kurczowo trzymając się 64kB ram można takie sprawy odłożyć pomiędzy bajki. Każdy z odpowiedników gry na wyższe platformy wymaga większej ilości ramu - co jest też oczywiście powiązane z zapotrzebowaniem na "ten że właśnie". Nawet upraszczając (co jest oczywiste) grafikę do możliwości Atari najprawdopodobniej potrzeba by relatywnie i tak więcej, niż podstawa ilość pamięci gwarantowanej przez producenta sprzętu :). Epi nie miał żadnego ograniczenia w kwestii ilości pobieranych danych, bo ograniczeniem była pojemność dysku twardego. Dane z czego pamiętam zajmowały w okolicach 30% tego, co w "naturze" - czyli w postaci rozkompresowanej. Program nazywa się R0l0 Player i działa wyłącznie z kontrolerem KMK/JŻ, lub IDEa, oraz wymaga specjalnego przygotowania dysku. Ostateczna i finalna wersja z czego wiem chyba nie jest jeszcze ukończona, a koncepcja opiera się o filesystem, na którym można uzyskać prędkość odczytu taką, jak po sektorach 512B wprost. Oczywiście kontroler jest dla takiej partycji w takim właśnie trybie, a organizacyjnie prędkości zapewniał klaster :) - o pojemności 128kB. Muszę chyba pomęczyć Epiego, bo zabawa z filmikami była przednia.

Dodatkowo program potrafi odpalić sampla o parametrach: 22.5kHz stereo, próbki po 8 bit na COVOX. Zresztą, kto bywa na party ten widział i słyszał to niejednokrotnie - min. w okolicach godziny 5:00 rano :)- hihihihihi
Kaz 2008-12-02 19:18:12

Pin - akurat 64KB do takiej gry wystarcza w zupelnosci (i do tych filmikow), choc wiaze sie to oczywiscie z wachlowaniem dyskietkami. Nie zapominajmy jednak, ze i posiadacze PC, Amigi i ST tez w swoim czasie musieli w przypadku nowszych gier, z wieksza iloscia danych, niezle sie napocic w zmienianiu dyskietek. Tuz przed rozpowszechnieniem sie gier na CD gry zajmowaly po 5-6 dyskow, niektore nawet wiecej. Malo ktory Amigowiec czy ST-kowiec mial wtedy twardziela (nie mowie o scenowcach czy fanach, tylko o zwyklych userach).

Zreszta Irwin podchodzi do tego, moim zdaniem slusznie - bedzie wersja dyskietkowa, zeby potem nie bylo glupich komentarzy jak przy np. Bomb Jack, ze "na standardowym Atari" to nie chodzi, i wersja wygodna, w jednym duzym pliku dla posiadaczy twardzieli, kart pamieci czy rozszerzonej pamieci, itd.
pin 2008-12-02 19:37:07

tylko, czy na dużych kompach nie działa to tak, że jeśli mamy standardową ilość ramu, to wachlujemy co chwile a jak mamy więcej - wachlujemy raz, bo programy częstokroć wykrywały ram opcjonalnie go wykorzystując? :)- dobra, daje sobie spokój, bo autor ma prawo zrobić to tak, jak mu się podoba. Jednakże, jeśli można grę napisać ze wsparciem moich wcześniejszych postulatów - propozycji, byłoby myślę - wszystkim łatwiej :)
Kaz 2008-12-02 19:48:13

Pin - no toz wlasnie tutaj tez tak ma byc - gra i buczy jak jest malo RAM i mala dyskietka, a jak jest wiecej RAM albo wiekszy dysk - to tez hula, tylko ze lepiej :). A postulaty poprzednie oczywiscie jak najbardziej sluszne, zeby nie bylo tak, jak juz sie kiedys zdarzalo - ze program dziala tylko na komputerze autora :).
sikor 2008-12-02 20:11:11

A ja po prostu życzę powodzenia i wiele samozaparcia. Z mojej strony mam małą prośbę: w trakcie prac powstaną pewne uniwersalne procedurki (czy będziesz pisał w Action!, czy w TB XL, czy w czymś innym - nieważne). Może można by zrobić u Kaza taką małą bibliotekę przydatnych procedur, aby ponownie nie trzeba było wyważać drzwi ;) O ile oczywiście się Irwin zgodzi...
irwin 2008-12-02 20:22:03

@pin - bez obaw postaram się zrobić wersje dla gołych atari z 64k, stacją dysków i parą kapci ;-) jak i tych którzy mają mocno rozbudowane kompy z 320kb ram z toną przelotek, wylotek i innego całkowicie niepotrzebnego osprzętu ;-) Jak coś już będzie to zgłosze się do ciebie abyś przetestował czy u ciebie pójdzie bo chyba nikt nie ma bardziej rozbudowanego Atari niż Ty. ;-)

@observer - najpierw wersja na Atari, potem jeśli mi się po pierwsze uda grę zrobić - bo narazie to czcze gadanie ;-) to być może i konwersja na C64. Ale narazie to jeszcze hen za horyzontem ;-)
Dlaczego Plan9 nie powstał na C64? ponoć z dwóch przyczyn - nastała era 16bitowców jaki i faktu że to zbyt duża w sensie graficznym gra na C64. Ale mit pozostał był nawet wpis na wikipedii a do dziś na niektórych stronach informacyjnych o grach pisze że gra jest na C64. np tu: http://tinyurl.com/65l4ob

@mono - Tak czytałem o playerze Epi'ego - ale zadaje się filmy do niego zajmują kosmiczne wielkości i spowodowałby wyświetlenie komunikatu "insert disk 2513" ;-)

Na reszte pytań to już Kaz odpowiedział wyręczając mnie, dodam że gra musi pójść na 64k i nie będę specjalnie tylko z powodu filmików zwiększał wymagań.
irwin 2008-12-02 20:25:10

@sikor - wg mnie to świetny pomysł, mam nadzieję że i Kaz tak sądzi - przecież do tej pory powstało sporo właśnie takich procedur i zgromadzenie ich w jednym miejscu byłoby całkiem niezłym pomysłem.
pin 2008-12-02 22:58:24

Chętnie zajmę się testowaniem programu, zresztą od jakiegoś czasu takie rzeczy zdarzają mi się to coraz częściej :)
vega 2008-12-03 00:49:18

Do tej gry idealnie nadawałby się cartridż 1MB

tworzenie filmu odbywałoby się wg. schematu:
1. co wiersz na ekranie byłby wybierany odpowiedni bank 8KB ($8000-$9FFF) oraz jeden z 8 zestawów znakowych w tym banku,
2. dane wyświetlanych klatek(ich znaki) byłyby pobierane z banków włączanych w obszarze 8KB ($A000-$BFFF)

Reszta pamięci podstawowej(ok. 45KB) to byłaby muzyka+kod gry.

Całość ładnie by działała na ATARI z 64KB.....tak mi się wydaje przynajmniej:)
tebe 2008-12-03 01:19:30

jeśli Antic ma dostęp do takiej dodatkowej pamięci to i owszem, JEŚLI
andys 2008-12-03 06:23:20

Jesli grafika powyzej jest z atari to gratuluje konwersji. W koncu patrzac na obrazek nie powiem "to atari" i te oblesne 4 kolory szarosci ktore namietnie w kolko wykorzystywano. No i czekam na rezultat prac;p
irwin 2008-12-03 09:27:55

@vega - podobny pomysł już mi podsunięto, tyle że zamiast jeden z osmiu zestawów to tylko jeden na wiersz - dzieki czemu całość zmieściłaby się w ramie a wtedy Antic nie mógłby sie do niczego doczepić ;-) A sama idea cartridża - się pomyśli jak już będzie nad czym myśleć ;-)
@andys - to atari, racja mamy znakomity G2F czas go wykorzystać do gier do których doskonale się nadaje.
marekp 2008-12-03 09:38:54

Podoba mi się pomysł vegi - gra na kardridżu była by idealnym rozwiązaniem.
@pin "tylko, czy na dużych kompach nie działa to tak, że jeśli mamy standardową ilość ramu, to wachlujemy co chwile a jak mamy więcej - wachlujemy raz(...)"
Moje doświadczenie z STE 4MB ram:
W trochę gier "wielodyskietkowych" pograłem i _żadna_ z nich nie była łaskawa dostrzec większej ilości ramu.
@irwin - powodzenia!
Rastan 2008-12-03 14:31:18

Grafika bardzo ładna. Gratuluję ! Ile takich statycznych screenów zawiera gra ?
pin 2008-12-03 14:35:30

mialem na mysli bardziej Amige :)
irwin 2008-12-03 15:11:25

@Rastan - około 90 sztuk
miker 2008-12-03 21:20:11

@irwin:
to może podziel się jeszcze jakims filmikiem - takim może mniej "kaszaniącym" się. :)