Dzięki Panowie! Mi szczególną radość przyniosły rozgrywki najpierw z Grzybsonem a potem z Sikorem w trybie po OPTION. I chociaż obie przegrałem (tzn. poddałem się nie widząc szansy na dogonienie przeciwnika w punktach) to mam satysfakcję z samej przeróbki bo w tym trybie gra się naprawdę zajefajnie.

Zdaje się Jellonek, że opuściłeś party już w piątek a ja dostałem samochodzik w sobotę, więc jesteś absolutnie poza kręgiem "podejrzanych". :-)

@Jacques: Będziesz na WAP-NIAKu? Spróbujemy to może naprawić.
@Pin: Dokładnie. Problem istnieje również w oryginałach. Ja uważam to za cechę szczególną i nawet to lubię. Nie chcę tego zmieniać/poprawiać.
@Fox: W oryginałach w image'u gry (w stanie pamięci po załadowaniu ale przed uruchomieniem przez skok do $2708) jest dokładnie 10 miejsc, gdzie obie gry się różnią. Jedna najbardziej zauważalna różnica to treść napisu wyświetlanego na dole ekranu w trybie demo. W WKC są same spacje. Pozostałe 9 wynika z różnic między wersjami dla PAL i NTSC - prędkość animacji, odliczania czasu, odtwarzania muzyki, odtwarzania samplowanych odgłosów (w dwóch miejscach) oraz drobne różnice w użytych kolorach na dwóch ekranach - Pekin i Fujiyama (w sumie cztery miejsca). Co do tych różnic w kolorach to nie jestem w pełni przekonany czy to wynika z różnic w paletach kolorów. Są to zbyt drobne zmiany i raczej wygląda mi to na różnice w designie.
Co do remisu to chodzi o to, że w oryginale w momencie jego zaistnienia walka jest natychmiastowo urywana. Na C64 jest inaczej. Kiedyś opiszę to dokładnie. Myślę, że jak będzie okazja to opowiem też o tym na WAP-NIAKu.

W kwestii wersji plikowych IK i WKC proszę spojrzeć tu.

Oszeleję, jeżeli jeszcze raz ktoś zapyta po co konverter RGB->S-video do VBXE. Ludzie, jest cała masa monitorów/telewizorów tudzież np. urządzeń video capture, które posiadają wyłącznie wejścia composite albo S-video. Do nich także przydałoby się móc podłączyć z VBXE. Przykładowa sytuacja. Ja mam telewizor z wejściem scart (rgb), który stoi w salonie i nie mam na co dzień możliwości podłączania do niego Atari. Zazwyczaj pracuję w innym pokoju, gdzie mam małe biurko a nim laptopa i Atari. I na tym zestawie staram się coś developować. Obraz z Atari podłączony jest do laptopa przez EasyCapa, który ma tylko composite i s-video. Chciałbym mieć możliwość pisania pod VBXE na takim zestawie. Nie muszę mieć super jakości obrazu, żeby sprawdzić, czy mój program działa. Ale muszę widzieć obraz do k... nędzy.

:-)
Właśnie przyszło mi do głowy, że to niezły temat do "Pogromców mitów". Nie róbcie tego sami w domu.

No właśnie. Wysunąłeś ciężki zarzut, że piszę szkodliwe bzdury i że mierzę jakiś przebieg, a metoda, którą rzekomo stosuję może dawać bezsensowne wyniki. Próbuję ustalić jaki przebieg miałeś na myśli. Pomimo tego, że niczego nie mierzyłem inaczej niż tylko programowo, chciałbym zrozumieć co było podstawą tak ciężkiego zarzutu. Czy miałeś na myśli właśnie sygnał z wyjścia monitorowego?

Napiszę jeszcze raz. Ja mierzę długość HBLANK programowo. To znaczy przy użyciu odpowiednich programów wykonywanych przez CPU w Atari. Nie używam zewnętrznych przyrządów pomiarowych, więc nie jestem narażony na taki typ błędu pomiarowego, o którym piszesz. Ponadto dokładność tylko co do cyklu koloru jest wystarczająca, przynajmniej do opisu działania GTIA jak i na potrzeby opisu zachowania GTIA w warunkach rozgrzania. Nawet dokumentacja GTIA, FGTIA i CGIA pochodząca od firmy Atari (dostępna w sieci w formacie pdf) podaje długość HBLANK z dokładnością do cyklu. Ta dokumentacja podaje, że HBLANK zajmuje dokładnie 40 cykli. Programowa metoda pomiaru polega na ustawianiu dwóch duszków (PMG) w zadanej pozycji (która odpowiada konkretnemu cyklowi koloru w linii ekranu z zakresu 0-227) i sprawdzeniu czy wykrywana jest kolizja. Oczywiście duszki są spreparowane tak, że mają szerokość 1 piksela w najmniejszej szerokości duszka czyli jednego cyklu koloru. W ten sposób można wyznaczyć dokładnie w których pozycjach/cyklach działa wykrywanie kolizji. Z dokumentacji układu GTIA wiem, że wykrywanie to nie działa w obszarze HBLANK. Z dokumentacji GTIA wiem też, że HBLANK zajmuje dokładnie 40 cykli koloru. Moje pomiary wykonywane opisaną metodą potwierdzają to co mówi dokumentacja. Pokazują, że w dokładnie 40-u pozycjach/cykla wykrywanie kolizji nie działa. Pokazują też, które konkretnie to są cykle. Tą samą metodą (tymi samymi programami) sprawdzam wykrywanie kolizji PMG w warunkach podgrzanego GTIA. Pomiary pokazują, że teraz HBLANK jest o jeden cykl krótsze. Oczywistym jest, że tą metodą nie uzyskam dokładności większej niż co do jednego cyklu koloru. Ale też nie ma sensu mierzyć tego dokładniej. Chodzi o to by poznać długość HBLANK w cyklach. Nie w nanosekundach. Jak już pisałem, sama dokumentacja od Atari podaje długość HBLANK w cyklach. Być może w rzeczywistości HBLANK trwa np 40,1 cykla. Ale część ułamkowa nie ma znaczenia dla opisu samej zasady działania GTIA. Ja stwierdzam, że przy rozgrzaniu GTIA długość HBLANK zmniejsza się o jeden cykl, czyli do 39 cykli. Być może w rzeczywistości trwa wtedy np 39,1 cykla. Tu część ułamkowa również nie ma znaczenia dla opisu działania GTIA w warukach rozgrzania.

Przeczytaj proszę dokładnie. Ja nie piszę o HSYNC tylko o HBLANK. To nie jest tożsame. HBLANK to czas wygaszenia do poziomu czerni ale nie sam impuls HSYNC. Długość HBLANK mierzę programowo sprawdzając, w jakich pozycjach PMG działa wykrywanie kolizji. Długość HSYNC jest podana w dokumentach o GTIA, CGIA i FGTIA i wynosi 16 cykli koloru dla PAL/NTSC i bodajże 16,5 dla SECAM, ale o tym nigdzie nie wspominałem.

Czy ten xegs ma GTIA z uszkodzonymi trybami GTIA? Ja mam jedno 130XE z takim właśnie GTIA i na tym komputerze nie udało mi się uzyskać efektów DGF. Nawet mocne podgrzewanie nic nie dawało.

Ładne.