atarionline.pl
atarionline.pl Atari
Login:
Hasło:
Zapamiętaj mnie
Translate to RSS RSS
Zbigniew Kasprzycki - współtwórca Polskiego Logo z 2024-03-15 22:25 (4)
"Zoltar Cosmic Pirates" w sieci z 2024-03-15 12:21 (6)
KWAS #32 z 2024-02-16 00:08 (39)
Która kolorystyka okładki lepsza? z 2024-02-11 18:30 (36)
Demo gry "Tony: Montezuma's Gold z 2024-02-05 21:09 (53)
Wywiad z Mariuszem Jaroszem z 2024-01-31 11:43 (12)
Nachodzi "Cosmic Hero 2" z 2024-01-28 06:27 (21)
Miniaturowe Atari (FPGA) z 2024-01-26 11:46 (14)
Światowa premiera "Cyborg Warriors"! z 2024-01-17 18:38 (40)
Grel #2 już dostępny! z 2024-01-11 19:21 (29)
Śmierć śmieciom! z 2024-01-06 21:23 (30)
Nowy program kopiujący "Microcop 61KB" z 2024-01-02 17:29 (25)
Wywiad Dracona z Mr. Bacardim z 2023-12-30 19:11 (12)
I po świętach! Kręcimy kołem z 2023-12-28 00:59 (13)
Wesołych Świąt 2023! z 2023-12-23 12:36 (18)
Silly Venture 2023 WE za nami z 2023-12-13 09:16 (17)
Pisma "Atari Fan 8" oraz "Grel 2" z 2023-12-07 17:32 (12)
From PLATO to Fujinet z 2023-11-25 23:16 (12)
Nowy ASAP i RECOIL z 2023-11-23 12:05 (8)
Zapowiedź gry "Goldaktari" z 2023-11-08 02:14 (10)
«« nowszestarsze »»

Pomocnik/Helper
Gry/Games

Katalog gier (konwencja TOSEC)

Opisy gier
"Old Towers" (Atari ST) opisał Misza (19)
Submarine Commander opisał Kaz (11)
Frogs opisał Xeen (0)
Choplifter! opisał Urborg (0)
Joust opisał Urborg (16)
Commando opisał Urborg (35)
Mario Bros opisał Urborg (13)
Xenophobe opisał Urborg (36)
Robbo Forever opisał tbxx (16)
Kolony 2106 opisał tbxx (2)
Archon II: Adept opisał Urborg/TDC (9)
Spitfire Ace/Hellcat Ace opisał Farscape (8)
Wyspa opisał Kaz (9)
Archon opisał Urborg/TDC (16)
The Last Starfighter opisał TDC (30)
Dwie Wieże opisał Muffy (19)
Basil The Great Mouse Detective opisał Charlie Cherry (125)
Inny Świat opisał Charlie Cherry (17)
Inspektor opisał Charlie Cherry (19)
Grand Prix Simulator opisał Charlie Cherry (16)
«« nowszestarsze »»

Katalog gier (konwencja Kaz)
Aktualizacja: 2024-03-16
Liczba katalogów: 8377, liczba plików: 36679
Zmian katalogów: 0, zmian plików: 0

0-9 A B C D
E F G H I
J K L M N
O P Q R S
T U V W X
Y Z inne
zipCałość 2817 MB


Wewnętrzne/Internals



   Nowinki tworzone dzięki CuteNews
Atarowskie "Amaurote" na C64
Dzisiaj u nas nietypowo. Będzie o grze dla Commodore 64! Prima aprilis? Przekonajcie się sami! Ale żeby nie było, że zmieniamy zainteresowania, to jest to temat ściśle związany z Atari, a maczał w tym palce pewien znany Atarowiec.

"Amaurote 128" Jakuba Husaka na Atari XL/XE


Kto, co i w jaki sposób? Tego dowiedziecie się od autora poniższego tekstu, Krzysztofa "Brush" Dąbrowskiego, który napisał dla nas:

"Wszystko rozpoczęło się od mojej wizyty na forum AtarOnline.pl. Przeczytałem tam wątek na temat przyśpieszenia gry "Amaurote" przez Jakuba Husaka. Dawno temu, gdy miałem Atari, zanim przesiadłem się na Commodore, ta gra zawsze mnie w jakiś sposób fascynowała i przyciągała. Miała dla mnie "magiczny" klimat, jak żadna inna na Atari, choć kompletnie nie wiedziałem jak w nią grać. Oryginalna wersja powstała na ZX Spectrum, na C64 nie było dobrej konwersji, ponieważ autorzy uznali, że "nie da się". Powstała zupełnie inaczej wyglądająca grą, nie w rzucie izometrycznym, tak naprawdę jedynie "na motywach" gry " Amaurote". Z oryginałem łączyła ją muzyka Davida Whittakera, która też nie wykorzystywała możliwości SID’a.

Wersja oryginalna "Amaurote" na ZX Spectrum:



Wersja oryginalna "Amaurote" na Commodore 64 (filmik - GADZombie):



Wersja oryginalna "Amautore" na Atari XL/XE (filmik - GADZombie):


W dyskusji na forum oczywiście padło tradycyjnych zdań demotywujących, że "nie da się tej gry przyspieszyć na Atari" oraz, że "nie da się tej gry przenieść na C64". Ponieważ wspomniany Kuba dał się "sprowokować" pierwszemu zdaniu i znacząco przyspieszył grę na Atari - pojawiła się również realna możliwość, by pojawiła się również na C64. Bo z jednej strony "Amaurote" jest dość "wredną" grą do przenoszenia z uwagi na to, że bardzo mocno polega na surowej mocy CPU, ale z drugiej strony, nie używa unikalnych cech sprzętowych Atari XL/XE, więc nie odpada w przedbiegach (żeby podać przykład w drugą stronę: gry na C64, które intensywnie wykorzystują atrybuty kolorów oraz multipleksowane sprajty, raczej słabo nadawałyby się do przenoszenia na Atari). Atari XL/XE ma procesor taktowany 70% szybciej niż C64, więc biorąc pod uwagę, że Kuba przyspieszył grę o 50%, mogłem liczyć, że konwersja na C64 będzie tylko trochę wolniejsza niż oryginalne "Amaurote" na Atari. A to z kolei oznaczało, że gra byłaby w miarę grywalna. Oczywiście potraktowałem to jako wyzwanie dla samego siebie, również po to, by sprawdzić z czym się trzeba zmierzyć, robiąc taki port pomiędzy platformami. Zdawałem sobie sprawę, że nie jest to gra, na którą czekają z wypiekami na twarzy setki graczy na Commodore.

Krzysztof "Brush" Dąbrowski


Całą zabawę rozpocząłem w grudniu 2014 od rozpoznania platformy Atari, o której wiedziałem dość mało. W czasach, gdy miałem Atari, stawiałem dopiero pierwsze kroki w programowaniu, więc odrobinę pamiętałem, ale nie znałem współczesnych narzędzi i nie miałem w głowie mapy pamięci. Na co dzień pracuję na Mac’u, ale na potrzeby ćwiczenia postawiłem maszynę wirtualną z Windowsami i emulatorem Altirra, o którym słyszałem dobre rzeczy. Po kilku godzinach zabawy miałem już jako-taką "orientację w terenie". Udało mi się rozpakować grę "Amaurote+" Kuby, odrzeć ją z inter i tym podobnych elementów, a potem zapisać w formie binarnego zrzutu pamięci tuż przed startem samej gry. Miałem więc "czystą", niespakowaną wersję, z której zrobiłem plik .xex, który mogłem uruchamiać w emulatorze.

Wersja "Amaurote 128" Jakuba Husaka (filmik - Atariteca):



Jako pierwszy cel postawiłem sobie re-assemblację gry i wygenerowanie źródeł, które będę mógł z powrotem assemblować KickAssem, ale nadal uruchamiać na Atari. Rozpoczęła się dość żmudna praca za pomocą Regenerator’a, który jest według mnie najlepszym w tym momencie re-assemblerem do pracy z kodem 6502/6510. "Regenerator" generuje kod źródłowy, który jest kompatybilny z "Turbo Assemblerem", najpopularniejszym natywnym assemblerem na C64, który doczekał się też wersji cross. Ponieważ "64tasm" nie wspierał wówczas Atari, musiałem dopisać sobie swój skrypt, który przerabiał binarkę C64 na atarowskiego .xex’a. Ale miałem w tym momencie assembler, który mógł mi emitować kod albo na C64, albo na Atari, w zależności od tego, jak go uruchamiałem. Praca polegała na tym, że zaznaczałem bloki pamięci, decydowałem co jest kodem, co danymi, a co tabelami z adresami i tym podobne, potem generowałem źródła, a następnie assemblowałem tak powstały kod, generowałem .xex’a i binarnie porównywałem go z moim wzorcowym plikiem z Atari - tak, by cały czas mieć pewność, że niczego nie popsułem. Po mniej więcej tygodniu (wspomagam się tu historią z git’a, bo trochę czasu minęło), miałem już wersję, z której byłem wstępnie zadowolony.

Zazwyczaj na Commodore 64 używam innego, doskonałego cross assemblera KickAssembler i na tym etapie skonwertowałem źródła do jego składni. Oczywiście zweryfikowałem, czy nadal generowany .xex jest binarnie identyczny z wersją na Atari. Od tej pory pracowałem już na tej wersji kodu. Rozpocząłem bardziej zaawansowane "upiększanie" źródeł, tak by dało się z nimi sensownie pracować. Sporo pracy poświęciłem odkrywaniu, do czego służą poszczególne bloki pamięci i kodu, oraz zamienianie etykiet wygenerowanych automatycznie przez "Regeneratora" z takich jak a47bc tudzież j6724 na bardziej czytelnie brzmiące play_music i podobne. Analizując kod odnalazłem też atarowską Display List-ę, co pozwoliło mi zacząć się orientować, jak rozmieszczone są dane graficzne - i zacząć rozplanowywać, jak to poukładam na C64.

Po kolejnym tygodniu udało mi się wreszcie skontaktować z Kubą Husakiem, który był tak miły, że udostępnił mi swoje źródła do "Amaurote", ale do wersji na Atari ze 128kB pamięci RAM - z jednej strony nie mogłem z nich korzystać bezpośrednio, ale z drugiej strony były nieocenionym źródłem informacji o lokalizacjach w pamięci. Mówiąc wprost - tam, gdzie Kuba ustalił, czym zajmuje się jakiś kawałek kodu albo danych i przydzielił mu jakąś czytelną dla człowieka etykietę - tam i ja się już orientowałem i odpowiednio zmieniałem swoje źródła. Pracując nad "Amaurote" dla C64 "z doskoku", mniej więcej w maju przeniosłem do swoich źródeł etykiety od Kuby i mocno popracowałem, by przekonwertować jak najwięcej różnych tabel z adresami z wersji absolutnych na referencje, tak bym mógł mieć kod jak najbardziej relokowalny. W tym momencie musiałem "odpiąć pasy bezpieczeństwa" czyli moje binarne porównywanie z wersją na Atari, użyć "tasaka" i zacząć przerabiać grę, by działała na Commodore.

nowa wersja gry na C64 - ekran tytułowy


Najważniejszą decyzją, którą musiałem podjąć, było to, jakiego trybu graficznego użyję. "Amaurote" na Atari używa trybu-marzenie: hiresu o rozdzielczości poziomej 256 pikseli tak jak wersja ZX Spectrum. Dla koderów to bajka, bo jest adresowanie liniowe, adresy początkowe linijek regularne co $20, no i zajmuje dokładnie tylko tyle pamięci RAM, ile trzeba. Oczywiście na C64 nie ma takiego trybu, a gdybym użył standardowego hires’u to miałbym sporo wolnego, nie wykorzystanego RAM, ale niestety nieciągłego - miałbym takie "placki" po $40, z którymi ciężko byłoby coś sensownego zrobić. Dodatkowo wiedziałem, że nie mogę sobie pozwolić na marnowanie pamięci, bo pomimo, że miałem jej nieco więcej niż na Atari (na Commodore po wyłączeniu ROM’u i rejestrów mamy dostęp do całych 64kB RAM), to z drugiej strony wstępna analiza kodu pokazała mi, że będę potrzebował maksymalnie dużo wolnej pamięci, ile tylko będzie możliwe, na kod specyficzny dla Commodore. Zdecydowałem zatem, że będę się posługiwał trybem tekstowym, z odpowiednio zdefiniowanymi generatorami znaków, dzięki czemu uzyskam dokładnie taką samą rozdzielczość gry jak wersja Atari, ale bez zbędnych strat w pamięci. Skonwertowałem grafikę z wersji Atari do plików programu "Art Studio", by móc je sensownie obrabiać, a w kodzie zastosowałem makra "KickAssemblera", które w locie, w czasie assemblacji, wczytywały obrazki, wycinały odpowiednie obszary grafiki i konwertowały je na potrzeby generatora znaków.

W tym momencie stało się jasne, że jeden kawałek kodu będzie bardzo trudny do przeniesienia wprost na C64 - muzyka. Pomyślałem, że ten problem rozwiążę później, ale dzięki wyrzuceniu muzyki z bieżącego kodu, uzyskałem kawałek ciągłej pamięci, którego mogłem używać do pisania swoich fragmentów kodu na potrzeby konwersji. Pomimo tego, że 99% kodu wyglądało, jakby było relokowalne, nie chciałem podejmować żadnego niepotrzebnego ryzyka, więc wszystkie modyfikacje starego kodu zachowywały adresy procedur. I jeśli było trzeba, po prostu skakały do mojego kodu, umieszczonego w miejsce muzyczki. A jeśli jakiś stary kod był niepotrzebny, to albo zamieniałem go na NOP-y, albo wycinałem, ale w taki sposób, że kolejna procedura w pamięci nadal była asemblowana pod oryginalny adres. Powstawała najwyżej mała, pusta przestrzeń w kodzie, potencjalnie do wykorzystania później, gdybym musiał gdzieś "powciskać" nowy kod, by z powrotem zrobić miejsce na muzykę.

W pierwszym podejściu napisałem komodorowską wersję procedury obsługi przerwań, za pomocą której mogłem skonstruować ekran. Na C64 musimy na przykład przełączać adresy generatorów znaków w odpowiednim momencie ekranu, co na Atari realizuje się przez Display List. Usunąłem wszystkie zapisy do rejestrów hardware’owych Atari, bo tu i tak by nic sensownego nie zrobiły, a raczej gwarantowałyby problemy. Usunąłem cały kod startowy gry, który w oryginale przestawiał trochę dane w pamięci, czyścił bufory i tym podobne. Miałem to już w kodzie odpowiednio poukładane, więc stało się to niepotrzebne. Zamiast tego uruchamiałem swój setup.


nowa wersja gry na C64 - rozgrywka


No i przyszedł czas na pierwszy start gry. Stosunkowo szybko udało mi się doprowadzić ją do takiego stanu, że uruchamiała się strona tytułowa. Przerobiłem też procedury obsługi joysticka tak, bym mógł próbować uruchamiać właściwą grę. W tym momencie miałem "coś", co się uruchamiało, ale niemiłosiernie śmieciło na całym ekranie. Moja organizacja ekranu tylko wizualnie była taka sama jak na Atari - układ w pamięci był zupełnie inny. Czasem nawet program się zawieszał, co było spowodowane tym, że sam sobie nadpisywał różne struktury danych i kod wariował. Przyjąłem strategię wyłączania jak największych funkcjonalnych kawałków kodu poprzez wstawienie RTS na początku procedury. Tak, by doprowadzić do stanu, w którym uruchomi mi się gra bez wszystkich upiększaczy, przejść, animacji, kasowania sprite’ów oraz z wyłączonym panelem na dole. Potem krok po kroku doszedłem do takiego stanu, że miałem grę, która może nie wyglądała dobrze - ale za to się nie zawieszała i nie śmieciła w pamięci. Grać się oczywiście jeszcze nie dało, ale radość była spora.

W tym momencie historia przestaje być romantyczna, a staje się żmudna i długa. Praca nad doprowadzeniem "Amaurote" do tego, by poprawnie działała, zajęła mi 7 lat... Oczywiście nie pracą ciągłą. Miewałem zrywy, gdzie przez kilka tygodni "inwestowałem" trochę godzin, ale miałem też przerwy na ponad rok. Muszę przyznać, że ugrzęzłem pod koniec na "ostatniej mili". Około dziewięćdziesiąt procent gry działało poprawnie, ale pojawiło się kilka, dość przykrych bugów, których nie mogłem namierzyć. Przez ostatnie 3 lata praca wyglądała tak, że po nowym roku odkopywałem grę, mówiłem sobie, że tym razem się uda. Pracowałem nad nią w styczniu i lutym, dzięki czemu posuwałem pracę do przodu, po czym życie pisało mi inny scenariusz i gra znowu lądowała w archiwum.


nowa wersja gry na C64 - autorzy


Ale, jak obecnie widać, nie poddałem się i w 2022 osiągnąłem przełom - wszystkie poważne błędy usunąłem! Tydzień spędziłem próbując usunąć błąd, który - jak się okazało - był też w oryginalnym kodzie na Atari. Powodował czasem śmiecenie na ekranie. Tyle, że w Atari był to nieużywany fragment RAM i nie było widać skutków. Natomiast u mnie były tam dane graficzne, więc wynik był dość spektakularny. Po tygodniu poddałem się i poświęciłem $200 RAM-u, poprzestawiałem dane tak, by również mieć wolne miejsce tam, gdzie procedura rysowania obiektów lubi sobie czasem pośmiecić. W taki sposób dotarłem do punktu, w którym miałem w pełni działającą grę, z jednym bugiem nie przeszkadzającym w grze (jeśli przy wejściu do nowej dzielnicy wylosujemy muchę na pierwszym ekranie, to zostawi ona ślad gdy się ruszy, ślad ten znika, gdy przejdziemy Arachnusem dalej) oraz wyłączonym efektem wybuchu przy trafieniu muchy lub obiektu przez bombkę. Oryginalna procedura jest skomplikowana i zmuszałaby mnie do konwertowania adresów w locie na organizację ekranu C64, co spowodowałoby, że byłaby bardzo wolna. Uznałem więc, że gra niewarta świeczki oraz nie chciałem podejmować ryzyka, że program znowu na rok wyląduje w archiwum, jak tylko skończy mi się noworoczny zapał.

Finalnie poprzestawiałem jeszcze dane tak, by uzyskać jak największe ciągłe obszary pamięci, bo trzeba było na powrót zmieścić muzykę. Zamiast oryginalnej, nową ścieżkę dźwiękową napisał Michał "Randall" Hoffmann z grupy Elysium. Jest świetna, a do tego używa player’a oszczędnego, jeśli chodzi o czas rastra. Co w przypadku "Amaurote" jest krytyczne, bo jak najwięcej czasu procesora musi być dostępne na rysowanie grafiki. W wersji C64 jest też nowy obrazek tytułowy, który namalował James "Joe" Svärd z grupy Wrath Design. Podobnie jak w wypadku muzyki - jest to wysokiej jakości grafika, która w pełni wykorzystuje możliwości Commodore 64, ale jednocześnie stylistycznie nawiązuje do oryginału. Jako dodatkowy bonus przygotowałem dwie specjalne wersje gry! Jeśli "Amaurote" uruchomimy na Commodore 128 (w trybie C64), gra wykorzysta tryb 2MHz procesora (poza ekranem), co daje 30% wzrostu prędkości gry i wszystko zaczyna być już naprawdę dość płynne. Wybierając odpowiednią opcję w czasie startu można też uruchomić wersję przeznaczoną na akceleratory SCPU, Turbo Chameleon oraz Ultimate64 - wszystkie w trybie 20MHz. W tym wypadku musiałem grę nieco spowolnić, by dało się grać oraz przepisać procedurę przerwań konstruującą ekran, by wszystko poprawnie się wyświetlało. To jedyna wersja "Amaurote" na platformy 8-bitowe bez spowolnień.


Nowa wersja "Amaurote" dla Commodore 64 (filmik - Elysium):



Na końcu opisu moich zmagań z portem gry, chciałem przekazać kilka podziękowań. Przede wszystkim Jakubowi Husakowi, bo to dzięki jego pracy nad przyśpieszeniem "Amaurote" na Atari ten port w ogóle był możliwy. Parafrazując Isaaca Newtona, "jeśli widzę dalej, to tylko dlatego, że stoję na ramionach olbrzyma"! Dziękuję Randall’owi za to, że najpierw napisał ścieżkę dźwiękową, później czekał 7 lat, a na koniec napisał jeszcze jedną, gdy dowiedział się, że mam za mało pamięci, by zmieścić tą pierwszą (ale nie pozwoliłem jednak się zmarnować dobrej muzyce i usłyszycie ją w czasie pokazywanie obrazka tytułowego oraz w pliku z manualem do gry) - uwielbiam Cię, mistrzu! Ukłony dla Joe za obrazek tytułowy, grafikę do manuala do gry, testowanie oraz za pomysł na jedyny sensowny trainer do gry - spowalnianie much. Praca z Tobą nad dowolną produkcją to czysta przyjemność, a Twój profesjonalizm i tempo pracy mnie nieustannie zawstydzają. A na koniec pozdrowienia dla wszystkich z Elysium, którzy pewnie do dzisiaj nie rozumieją, po co mi ten port w ogóle był, a zwłaszcza dla Diggera, który regularnie mówił, żebym zamiast tego "demo robił" :).

Tyle od kolegi Brusha. Grę dla C64 każdy może pobrać pod adresem amaurote.elysium.pl. Premiera na AtariOnline.pl równocześnie z Zzap64. Dla zainteresowanych grą odsyłam ponadto do opisu gry w naszym serwisie, są tam też porady praktyczne - jak grać skutecznie. Dodam również, że historię poprawek Jakuba Husaka w "Amaurote" można było śledzić na Forum Atarum w tym wątku oraz tym wątku. Tak powstała najpierw wersja "Amaurote +", której podsumowanie i wyszczególnienie zmian było w tym artykule.

Tam właśnie Kuba wspomina o wyzwaniu, które zostało mu rzucone: "Amaurote to była jedna z gier, które śniły mi się po nocach. Uważałem ją za majstersztyk programistyczno-graficzny. Jednak w wyniku zbytniego spowolnienia, w przypadku dużej ilości owadów goniących Arachnusa, zniechęciłem się do niej zbyt (być może) szybko. Czas minął, rany dzieciństwa się zabliźniły, wspomnienia przyszarzały. Odżyły dopiero w wyniku dyskusji i tezy at0mica, że na Atari nie da się przyspieszyć tej gry! Ta. No jasne! Nie da się! No ale no jak to? Ja nie zrobię? Wziąłem w dłonie stare, dobre "dis6502" i zacząłem analizować grę. Od razu rzucił mi się w oczy ogrom kodu, jaki w tej grze jest upchnięty. W trakcie analiz okazało się, że autorom szybciej było kod skopiować, niż napisać go w sposób uniwersalny. Dało to przyczynek do Wielkiego Skracania Kodu." Potem powstała wersja "Amaurote 128", z dodatkowymi animacjami i grafiką tytułową, które Kuba upchnął w 128 KB pamięci. Wszystkie trzy wersje na Atari są dostępne w naszym archiwum gier: oryginalna, plus, 128.

A na koniec kilka słów od Kuby na temat wydania na C64: "Ze swej strony napiszę, że Krzysiek do mnie napisał zaraz po premierze Amaurote w grudniu 2014. Ponieważ nie zadbałem o źródła 64k (o ich opisanie, który kod jest dobry), to musiałem mu wysłać 128k. Cieszę się, że mogły się przysłużyć. Krzysiek miał wiele pytań głównie dotyczących znalezionych przez niego błędów, starałem się odpowiadać zgodnie z pamięcią, lub wymyślałem jakieś bzdety na poczekaniu (żart :). Bardzo się cieszę, że projekt dobiegł końca i rzeczywiście, Amaurote w wersji na C64 zacnie pomyka dzięki dwóm osobom - jednej, która wierzyła, że SIĘ NIE DA, i drugiej - która uwierzyła, że SIĘ DA"."

okładka oryginalnej wersji C64 praktycznie niczym się nie różniła od atarowskiej czy spectrumowej, ale sama gra była zaskakująco odmienna... do dziś!


2022-04-01 22:51 by Kaz
komentarzy: 36
SuN @2022-04-01 23:33:56
ta, jasne...
jhusak @2022-04-01 23:43:44
Co jasne?
Bca @2022-04-02 02:22:20
WOW wreszcie przecież w GR.* na rubinie każdy miał inne kolory!
mono @2022-04-02 08:49:02
Super! Wreszcie Amaurote jest takie, jak należy. Bardzo ładny ekran tytułowy.
gorgh @2022-04-02 09:21:32
fascynująco się to to czytało, tytaniczna praca ale i pewnie duża satysfakcja
Usagi Yojimbo @2022-04-02 09:57:36
Kurde podziwiam. Fajna konwersja. Dla mnie to cos jak "Doom" na Amigę. Myślę że osiągnięcie porównywalne do "Dredda".
Cyprian @2022-04-02 13:59:36
quote:

Atari XL/XE ma procesor taktowany 70% szybciej niż C64


procesor taktowany o 70% szybszym zegarem ale w hiresie (320x200 2 kolory) XL jest 'tylko' 32% szybsza niż C64 w tym samym trybie:
http://atarionline.pl/forum/comments.php...


tak czy siak, gratulacje udanej konwersji
mariuszw @2022-04-02 14:55:09
Gratuluję bardzo udanej konwersji! Przy okazji: moje konwersje C64 -> Atari są tworzone w dokładnie taki sam sposób.
Brush @2022-04-02 15:34:37
70% vs 32%. It's complicated. Po pierwsze ta gra nie używa hiresu 320x200 na Atari tylko 256x200 więc ANTIC zjada tam mniej cykli. + na c64 użyłem sprajtów w paru miejscach a one z kolei na c64 zjadaja rastertime.
Jeżeli ktoś z was ma ochotę to możemy zrobić ultra prosty test. Napiszcie kawałek kodu który: 1. włącza ten tryb graficzny na Atari 2. czeka na VBL 3. uruchamia pętlę opóźniającą.
A potem wydłużcie tą pętle tak by zajęła na styk cały ekran.
I policzcie ile cykli CPU idało się "przepalić". Na c64 w ten sposób (z wyłaczonymi sprajtami) jest do dyspozycji około 18.800 cykli.
Jak ktoś mądry napiszę to co powyżej na Atari, policzy cykle i poda wynik to sobie to podzielimy i empirycznie zamkniemy dyskusję raz na zawsze :)
Brush @2022-04-02 15:37:52
mariuszw: Dzięki za miłe słowa. Wiesz.. gdybyś tylko przenosił z c64 na atari te gry, które przenosisz to bym powiedział - szacun. Ale to co zrobiłeś przy konwersji z ZX na Atari powoduje że mogę tylko powiedzieć: Mistrzu, nie gram w twojej lidze :)
Kaz @2022-04-02 15:48:18
Słyszałem nie raz, że konwersja to prosta sprawa i dlatego nie powinniśmy ich doceniać. Nie zgadzam się. Owszem, znacznie trudniej zrobić dobry oryginał niż dobrą konwersję, i autorów oryginalnych gier trzeba bardzo szanować, ale i konwersje wymagają twórczego podejścia, szczególnie takie, o których "mówiono, że się nie da". Tak było przecież choćby z "Prince of Persia" czy "Stunt Car Racer" na Atari czy właśnie "Amaurote" na C64. Na powyższym przykładzie, a także przykładzie gier xxl-a, mariuszaw, fandala i innych - widać, że nie jest to łatwa dyscyplina działań, więc mam również wielki szacunek do programistów zajmujących się konwersjami. I wydaje mi się to działalność wręcz idealna dla koderów, którzy lubią skupić się wyłącznie na kodzie / nie chcą się angażować w robienie grafiki i muzyki / być zależni od zespołu - bo właściwie grafika czy muzyka są już gotowe w oryginale.
pirx @2022-04-02 16:16:55
Oh noes, koment nie wszedł, jeszcze raz:
wielki szacun, ogromna robota. Mam taki propozal - w 2015 Triad zrobiło kawałek Scorched Earth na C64, ale nigdy nie dokończyli - nie dziwię się, bo to mnóstwo kodu do wklepania.
Nasz (z pecusiem) skorcz jest otwarty i na pewno ma lepsze labelki, niż dekompilat :)
Od początku robiliśmy to tak, żeby było w miarę łatwo przenieść na inną platformę. W zasadzie są 2 procki zależne od sprzętu - PLOT i stawianie znaku na ekranie graf.
Jakby zrobić wersję komplikującą się na komodę, to o rząd wielkości większa scena C64 pewnie by pomogła...
github.com/pkali/scorch_src
Cyprian @2022-04-02 18:47:40
jakiś czas temu zrobiłem test dekompresji LZ4 dla wyłączonego ekranu - XE ma w nim 164,6% mocy C64:
http://atarionline.pl/forum/comments.php...



Niezależnie od wydajności, chętnie bym więcej poczytał o kompilowaniu tego samego kodu na C64 i XL, chodzi o uwzględnienie sporych jednak różnic sprzętowych.

Jeśli chodzi o narzędzia to z tego co pamiętam to Kick Assembler wspiera też Atari. Nie było by łatwiej programować na C64 i XL pod nim?

Rzuciłem okiem na wspomniany przez Ciebie Regenerator17. Nie znałem tego narzędzia, całkiem zacne, oznaczanie myszką całego bloku kodu jako DATA jest kozackie.
bob_er @2022-04-02 20:13:38
MADS potrafi* generować binarki commodorowskie. Obok C64 można pomyśleć jeszcze o pełnym trybie C128 - tam mamy 2MHz pod maską bez spowalniaczy (ale za to z pokręconym obrazem na VDC ;) ).

Dla niewiedzących: w C128 CPU może chodzić na 2MHz, ale VIC nie potrafi tak szybko działać, więc wymyślono 2 sposoby, co z tym fantem zrobić:
1. olać VIC i użyć VDC (drugi układ graficzny, potrafi w 80 kolumn) - mało kto tego używa,
2. jak VIC skończy rysować obraz (początek dolnej ramki) to przełączamy CPU na 2MHz, i spowalniamy go dopiero pod koniec górnej ramki, jak VIC będzie zaczynał rysować obraz. Z opisu wynika, że Amaurote128 robi taki trik.

* do pełni szczęścia brakuje tylko tekstowego wstawiania wartości labelki, ale może to już jest ino w dokumentacji nie znalazłem.
Brush @2022-04-02 20:49:52
Jeśli chodzi o kickassa i atari to tu nie ma żadnego problemu. Z tego co pamiętam wypluwa już atarowskie binarki a jesli nawet nie to wystarczy prosty skrypt taki jak ja napisałem i mamy gotową binarkę. Kwestia różnic w architekturze nie ma za bardzo nic wspólnego z assmblerem - to raczej kwestia naszego kodu i czy chcemy robić sobie dziesiątki/setki warunków w kodzie (lub pre-procesorze).

C128 i VDC... Doświadczenie mam zerowe ale jeden rzut oka w dokumentacje pokazał że o ile jak się ma dane graficzne w pamięci VDC to wszystko idzie szybko i zgrabnie o tyle przepisywanie danych z pamięci c64 do RAMu vdc idzie już wolniej a w wypadku Amaurote będzie to konieczne. Niczego nie obiecuję ale prowadzę rozmowy z jednym z ludzi którzy się odezwali dzisiaj, który doświadczenie ma i może coś z tego wyjdzie.

Alternatywnie można pomyśleć jeszcze o Commodore +4. 2mhz ale brak sprajtów i sid'a.
bob_er @2022-04-02 21:35:14
W temacie C128 i VDC - gdzieś na sieci znalazłem info, że jeśli do VDC wrzucamy dane w momencie wygaszania pionowego, to w zasadzie nie trzeba czekać na flagę w $d600, bo ustawia się ona od razu (tzn - pierwszy 'bit' już przechodzi).
Ból tylko taki, że VDC nie potrafi w przerwania, i trzeba najpierw znaleźć moment, kiedy przerwanie się zaczyna, a potem (o ile dobrze pamiętam, bo ten sprzęt jednak znam słabo - wiadomo - ja to druga strona barykady ;) ) na zegarach.
Święty @2022-04-02 22:40:09
Pozdrowienia Brush od atarowców z pałacu młodzieży w tarnowie - mieliśmy okazję się poznać na party i w firleju ;)

Szacun za konwersję oraz ilość pracy włożonej w to , jakoś mnie nie dziwi ilość poświęconego czasu - sam teraz konwertuję VicDooma na atari xl/xe z commodore vic20 i powiem tak - po miesiącu spędzania każdej minuty wolnego czasu na deassemblacji oraz przepisywaniu kolejnych procedur mam dopiero 70% działającego kodu w asmie a resztę nadal wczytuję z zrzutu pamięci z Vic20.
Może się porwałem na za gruby projekt ale każdy kto pisze że to nie jest problemem powinien sam zrobić coś podobnego
Pozdrowienia od Świętego :)
Brush @2022-04-02 23:34:57
Jeśli chodzi o kickassa i atari to tu nie ma żadnego problemu. Z tego co pamiętam wypluwa już atarowskie binarki a jesli nawet nie to wystarczy prosty skrypt taki jak ja napisałem i mamy gotową binarkę. Kwestia różnic w architekturze nie ma za bardzo nic wspólnego z assmblerem - to raczej kwestia naszego kodu i czy chcemy robić sobie dziesiątki/setki warunków w kodzie (lub pre-procesorze).

C128 i VDC... Doświadczenie mam zerowe ale jeden rzut oka w dokumentacje pokazał że o ile jak się ma dane graficzne w pamięci VDC to wszystko idzie szybko i zgrabnie o tyle przepisywanie danych z pamięci c64 do RAMu vdc idzie już wolniej a w wypadku Amaurote będzie to konieczne. Niczego nie obiecuję ale prowadzę rozmowy z jednym z ludzi którzy się odezwali dzisiaj, który doświadczenie ma i może coś z tego wyjdzie.

Alternatywnie można pomyśleć jeszcze o Commodore +4. 2mhz ale brak sprajtów i sid'a.
Brush @2022-04-02 23:36:04
@Święty: Dziękuję i oczywiście pamiętam :)
Dla mnie przeniesienie tej gry było po prostu doświadczeniem, którego wcześniej nie miałem i które chciałem zdobyć. Szczerze mówiąc gdyby to była moja praca, i robiłbym to codziennie po 8-10 godzin tak jak kiedyś pracowali programiści nad grami w szczycie popularności 8 bitowców to jestem teraz w stanie zrozumieć jak można było kiedyś takie porty robić w 3-4 miesiące. Mając jeszcze być może dostęp do autorów wersji oryginalnej, którzy cokolwiek pamiętają.

Gdyby nie to, że już NAPRAWDĘ chciałem w końcu wydać tą grę oraz że praktycznie skończyła mi się pamięć - miałem jeszcze z 1-2 pomysły na przyśpieszenie.
Brush @2022-04-02 23:36:36
A jeśli @jhusak chciał jeszcze kiedyś wrócić do wersji na atari128 (zakładam, że tam ramu by się trochę znalazło) to rzecz, która powinan dać kolejne kilka % może nawet przyśpieszenia to zapisanie danych sprajtów z przeplotem. Teraz w pamięci każdy sprajt ma 3 bajty szerokości i jest zapisany liniowo: 3 bajty pierwszego wiersza, 3 bajty drugiego wiersza etc.
Te sprajty są później kopiowane do bufora "offscreen" o szerokości 32 bajtów. Więc trzeba w czasie kopiowania utrzymywać 2 indeksy i niezależnie je "popychać" do przodu.
Jeśli by zapisac sprajty tak by każdy wiersz zaczynał się nie zaraz po poprzednim a z przesunięciem o właśnie 32 bajty -> wtedy można by mieć jeden i ten sam indeks, uzywać 1 rejestru i uprościć procedurę przepisująca.
A przeplot po to by nei marnować ramu i w wolne miejsce wstawiać kolejne dane sprajtów. Co koniec końców wyglądałoby tak: 1sza linijka 1szego sprajta, 1sza linijka drugiego sprajta, 1sza linijka 3ciego sprajta itd. aż do 10 sprajta. potem 2 bajty puste, i 2ga linijka 1szego sprajta, 2ga linijka drugiego sprajta itd.
Na c64 tego już tego nie zmieszczę bo przez te 2 bajty dodatkowe oraz to że sprajtów jest trochę więcej i na koncu straciłbym jeszcze więcej (przy ostatniej paczce sprajtów, która byłaby dodatkowo niepełna jeszcze więcej).
Uff. Rozpisałem się :) Ale to tak dla sportu, by pokazać niedowiarkom, że wszystko się da przyśpieszyć. Nawet przyśpieszone Amaurote :) Pytanie tylko w którym momencie prościej i szybciej byłoby napisać cały engine od początku :)
jhusak @2022-04-03 02:08:33
Dzięki za tip, może nie w takiej postaci, ale popróbuję.
jhusak @2022-04-03 02:25:06
eeee, nie. Co to szczegółu, że 8 sprajtów w poziomie, bo sprajt ma 4 bajty w tym wymiarze. Te 8 cykli na linię to w sumie jakies 200 cykli na sprajta, co przy 5 sprajtach na raz przyspieszy niezauważalnie, gdy 1 ramka generuje się wówczas ca 1/5 sekundy, czyli ca 300000 cykli. 1-1.5% przyspieszenia.
Brush @2022-04-03 08:13:22
“Sprajt” to tutaj skrót myśliwy. Każdy obiekt rysowany przeciez na mapie jest “blitowany” w taki sam sposob, wiec technika z przeplotem działa na wszystko co rysujemy: na podłogę, na budynki i na muchy. :)
+ czuję, że majac tak uproszczone adresowanie -> dałoby się więcej nic 8 cykli na linię wycisnać. Może możnaby przy wyzszych sprajtach zrezygnować w ogóle z adresowania via strona zerowa, dać 4 przepisywania zamiast 1 w petli, wrzucic inner loop na strone zerowa (miejsce jest) i będzie dobrze. Trzeba by policzyc dla ilu pixeli wysokosci ten unroll sie “spłaca” ale nawet bez niego - inner loop na stronie zerowej usuwa ci adresowanie pośrednie przy odczycie i tylko z tego mamy kolejne 4 cykle do przodu na każdej linijce.
Shanti77 @2022-04-03 09:54:27
@Brush

W Amaroute+ w ramce można wykonać ~26058 cykli (Altirra Unhalted Cycles).
Brush @2022-04-03 11:10:34
@Shanti77 o proszę! Dzięki! Czyli wychodzi na to, że (nie licząc tego co tracę przez sprite’y) Atari jest o okolo 38% szybsze w tej konfiguracji ekranu. Case closed :)
innuendo @2022-04-03 12:18:50
Nowy ekran tytułowy jest piękny! Brawa dla autorów konwersji.
Kaz @2022-04-04 08:42:59
TDC i atakujacy TDC-a - proszę swoje problemy rozwiązywać gdzie indziej. W komentarzach obowiązuje odnoszenie się do tematu nowinki oraz w sposób kulturalny. Tak jak już wielokrotnie uprzedzałem - jeżeli uznam, że ktoś przekracza te granice w sposób nieuzasadniony - komentarz usuwam.
R.Dudek @2022-04-04 22:20:29
imponowala mi grafika tej gry, mono, ale na tamte czasy wysoka rozdzielczosc, szkoda ze tak malo gier bylo robiobych w grafice mono
Kaz @2022-04-05 08:37:19
R.Dudek - to prawda, to była niesamowicie klimatyczna grafika i dźwięk. Z takich gier izometrycznych w mono był jeszcze, np. "Molecule Man", ale bez takiego klimatu. Oraz "Chimera", ale nie w grafice mono.
mono @2022-04-07 15:03:38
Head over heels
Tower Toppler
Aztec
Shanghai
Kult
Artefakt przodków
Kupiec
z późniejszych konwersji:
Alien 8
Knight Lore
Nightshade
Fairlight
Highway encounter
szeryf @2022-04-07 15:24:45
Dla mnie jakieś 60%-70% funu z tej gry w wersji Atarowskiej to bardzo dobra muzyka, która trafia się może raz na 100 gier.

Gratuluję udanej konwersji kodu i grafik na C64.
mono @2022-04-07 15:34:29
Zapomniałem o Starquake. A wczoraj w to grałem :)
Kaz @2022-04-08 11:43:17
O właśnie, miałem wspomnieć wśród hiresowych izometrycznych o "Head over Heels". Ale jej w dzieciństwie nie miałem. W sumie nie wiem czemu. Czyżby z tego powodu, że plik to ponad 50KB, więc znacznie później zaczęły powstawać kopiery zdolne to skopiować?
Kocur @2022-04-10 15:51:12
W 1989 roku po przesiadce z 65XE na C64 ( ze względu na lepsze gry i dźwięk) oprócz braku Alley Cat`a i Nadral`a commodorowskie Amaurote było dla mnie dużym rozczarowaniem więc dziękuję serdecznie za port :))) Swoją drogą wypada żałować że nie wyszła ona na Amigę czy ST w wersji mono. Pozdrawiam
mono @2022-04-15 23:16:14
I jeszcze Pentagram.
Brush @2022-04-17 10:07:18
nickname
e-mail / website (opcjonalnie)
Aktualne tematy
GTIA2DVI (68)
ostatni: 19-03-2024 00:45, st_man
PTODT Stereo II (91)
ostatni: 18-03-2024 22:19, mcgregor
Rzeczy które chciałbyś w MADSie a... (122)
ostatni: 18-03-2024 22:01, jhusak
Muzycy scenowi... (60)
ostatni: 18-03-2024 20:41, jhusak
padnięta maszyna - temat do zamkn... (3)
ostatni: 18-03-2024 20:40, Ataripuzzle
Scorch - pełna gra (398)
ostatni: 18-03-2024 17:49, Mq
Poszukiwana solucja do Artefakt P... (5)
ostatni: 18-03-2024 14:20, Vidol
Program do losowania totolotka (13)
ostatni: 18-03-2024 04:27, pirx
Pismo "Grel" (34)
ostatni: 17-03-2024 21:29, Kaz
AVG Cart (121)
ostatni: 17-03-2024 19:43, sun
RMT hacking (166)
ostatni: 17-03-2024 17:21, emkay
Moje materiały wideo z grami na A... (191)
ostatni: 17-03-2024 14:02, nowy80
Pomoc - dom dziecka (1)
ostatni: 17-03-2024 13:37, maly_swd
Nowe okładki gier - kasety zestaw... (249)
ostatni: 17-03-2024 11:20, lexx
Książka Gorgha o asemblerze (42)
ostatni: 17-03-2024 09:59, TheFender

Kategorie Forum Atarum

Użytkowników: 2769
Ostatnio zarejestrowany: Atari1040
Postów ostatniej doby: 29

Spotkania i zloty / Meetings & Parties

Najbliższe imprezy
link do naszych spotkań online, zapraszamy do odwiedzenia kanału zoom również przez kod QR:

KWAS

Kalendarz AOL


Społeczność/Community


Rozmawiali
Wywiad z Mariuszem Jaroszem i Kaz (12)
Wywiad Dracona z Mr. Bacardim i Kaz (12)
Tomasz Dajczak i Kaz (21)
Lech Bąk i "Świat Młodych" i Kaz (26)
Michał "Mike" Jaskuła i Kaz (6)
F#READY i Dracon (22)
Daniel „Arctus” Kowalski i Dracon (25)
KATOD i TDC (15)
Mariusz Wojcieszek i "Adam" (17)
Romuald Bacza i Ramos (16)
Śledzenie Amentesa i Larek (9)
Leszek Łuciów i Charlie Cherry (17)
TO JUŻ ZA TOBĄ: rozmowa z Bobem Pape i cpt. Misumaru Tenchi (39)
Rob Jaeger i Emu (53)
Jacek "Tabu" Grad i Dracon (0)
Alexander "Koma" Schön i Kaz (0)
Maciej Ślifirczyk i Charlie Cherry (0)
Jarek "Odyniec1" Wyszyński i Kaz (0)
Marek Bojarski i Kaz (0)
Olgierd Niemyjski i Ramos (0)
«« nowszestarsze »»

Stragan
Nowe, pojemniejsze RAM-Carty oferuje Kaz (21)
"mouSTer" czyli myszka ST oferuje Kaz (30)
Atari USBJoy Adapter oferuje Jakub Husak (0)
Programy: Kolony 2106 oferuje Kaz (7)
Sprzęt: rozszerzenia oferuje Lotharek (23)
Gadżety: naklejki, pocztówki oferuje Sikor (11)
Sprzęt: cartridge RAM-CART oferuje Zenon (7)
Miejsce na drobne ogłoszenia kupna/sprzedaży oferuje Kaz (58)
Sprzęt: interfejs SIO2IDE oferuje Piguła (0)
Sprzęt: interfejs SIO2SD oferuje Piguła (33)

Użytki/Utils
Sprzęt/Hardware

Wynalazki
Atari i Bluetooth napisał Kaz (34)
SIO2PC-USB napisał Larek (45)
Nowe SIO2SD napisał Larek (0)
SIO2SD w CA12 napisał Urborg (12)
Ratowanie ATMEL-ów napisał Yoohaas (12)
Projektowanie cartów napisał Zenon (12)
Joystick do Atari napisał Larek (54)
Tygrys Turbo napisał Kaz (11)
Testowałem "Simple Stereo" napisał Zaxon (5)
Rozszerzenie 1MB napisał Asal (20)
Joystick trzyprzyciskowy napisał Sikor (18)
Moje MyIDE oraz SIO2PC na USB napisał Zaxon (16)
Jak wykonać płytkę drukowaną? napisał Zaxon (26)
Rozszerzenie 576kB napisał Asal (36)
Soczyste kolory napisał scalak (29)
XEGS Box napisał Zaxon (13)
Atari w różnych rolach napisał Różyk (9)
SIO2IDE w pudełku napisał Kaz (5)
Atari steruje tokarką napisał Kaz (15)
DarkMouse napisał Kaz (7)
«« nowszestarsze »»