1

(65 odpowiedzi, napisanych Software, Gry - 8bit)

A to jest nawet grywalne, choć przezroczystość ścian wkurza okrutnie. https://kweepa.itch.io/doom6502

2

(65 odpowiedzi, napisanych Software, Gry - 8bit)

>nie ta liga.

Ale to nie jest żadna "liga", tylko slideshow pixeli wielkością pasujących do 2600.
To może od razu zróbcie Wiedźmina 3. Też się da, tylko będzie jedna klatka co 10 sekund :)



https://www.atari.org.pl/forum/misc.php?action=pun_attachment&item=14190

3

(65 odpowiedzi, napisanych Software, Gry - 8bit)

>przeciez to jest rewelacyjne!

Ale odpaliłeś to chociaż na kilka minut? Nie chcę być Panem Marudą, ale to jest niegrywalne. Już chodzenie przy 3-4 fps jest trudne, a walka w dalszym pomieszczeniu z dwoma wrogami (z których każdy ma z tej odległości 2 piksele!) gdzie są 2 fpsy jest po prostu niemożliwa. Tzn jest to bardziej walka z grą i sterowaniem niż z wrogami.

PS. W czasie tej "walki" (na Altirra) wyskoczyły mi glicze grafiki.



https://www.atari.org.pl/forum/misc.php?action=pun_attachment&item=14187

4

(7 odpowiedzi, napisanych Zloty)

I ja też

5

(65 odpowiedzi, napisanych Software, Gry - 8bit)

Zaczyna przypominać mój niedawny port tego: tego: https://github.com/ebenupton/doom
Wymaga 128K. Fire otwiera drzwi.

6

(65 odpowiedzi, napisanych Software, Gry - 8bit)

Dobrze widzę, że faktyczna rozdzielczość pozioma to 40 kolumn?

7

(11 odpowiedzi, napisanych Software, Gry - 8bit)

Fox napisał/a:

Co to za optymalizacja, jeśli oryginalny XEX miał 33 KB, a zoptymalizowany - 257.

Optymalizujemy wydajność za wszelką cenę :)

Kolejne poprawki (ilmenita, solo, moje, a właściwie naszych agentów) czekają na integrację i testy.
Powoli zbliżamy się do +100% FPS.

Spytaj larka. Joycartów już nie produkuje, ale może ma jakieś zapasy cartów i adapterów, lub samych płytek do nich?

9

(11 odpowiedzi, napisanych Software, Gry - 8bit)

Uaktualniłem repo o zmiany Solo/Opus i poprawki Astry do ich wersji:
https://github.com/nosty3/Rescue-on-Fra ... timization

Aktualny, uśredniony zysk względem oryginału:
PAL: +40,04%
NTSC: +43,13%

"Rescue on Fractalus!" jest podobno uważane za świetnie zaprogramowaną grę. Postanowiłem sprawdzić czy uda się wycisnąć więcej FPS przy pomocy AI.
Założenie było jedno: wszelkie optymalizacje mają być bezstratne, czyli niezauważalne dla gracza.

Pracowałem głównie z ChatGPT Astra w trybie średnim i wysokim. Gemini 4 Argon próbował coś dodać, ale jakość jego wstępnych pomysłów była kiepska.

To nie był jeden prompt. Praca była iteracyjna i zajęła kilkanaście godzin. Samo oszacowanie fps okazało się trudne, bo mapa jest generowana losowo i zależnie FPS bardzo się zmieniały z każdym uruchomieniem. W końcu obliczyliśmy, że aby uzyskać dokładność +/- 1%, potrzebne jest 155 przelotów testowych po 1 minucie każdy. A to i tak było to ograniczone badanie (tylko lot prosto).

Cartridge został rozbudowany z 64KB do 128KB by rozwinąć niektóre pętle i użyć dodatkowych tablic.

W końcu uzyskaliśmy wydajność o około 19% lepszą od oryginału, co uważam za sukces. (EDITED: to już nieaktualna wartość - patrz niżej).

Czy da się lepiej? Pewnie tak. Może ktoś sprawdzi to z Opus 5.5.
Pomijałem też pomysły, które wymagały sporej przebudowy, a dawały oszczędności szacowane na mniej niż 0.05 FPS.

Proszę też fanów tej gry o testy, czy faktycznie jest w 100% wierna oryginałowi.

W repozytorium jest do pobrania obraz cartridga "Rescue on Fractalus! - optimized 128KB.rom", oraz dokładne opisy zrealizowanych optymalizacji i porzuconych pomysłów.
Dokumentacja jest po polsku i po angielsku.

https://github.com/nosty3/Rescue-on-Fra ... timization

Dobrej zabawy!

EDITED:
Uzupełniłem repozytorium o zmiany wykonane przez Solo z agentami Opus, oraz kolejne poprawki Astry.
Do pobrania jest zarówno obraz cartrdiga, jak i poprawiony xex (wymaga rozszerzonej pamięci).

Aktualna poprawa względem oryginalnej gry, przy użyciu dokładniejszej metody badania FPS wynosi:


https://www.atari.org.pl/forum/misc.php?action=pun_attachment&item=14071


https://www.atari.org.pl/forum/misc.php?action=pun_attachment&item=14072

11

(9 odpowiedzi, napisanych Software, Gry - 8bit)

Gdy to zobaczyłem pomyślałem, że pomysł jest debilny, ale pograłem i... to jest nawet grywalne! Tyle, że za łatwe. No i po kilkunastu pomieszczeniach spadając z podestu utknąłem w ścianie :( No i te szklane ściany bardzo psują zabawę.

Źródła Atari Boy i szczegółowe notatki techniczne (TECHNICAL-CONTEXT.md)
https://github.com/nosty3/AtariBoy

Wiesz, żaden emulator nie jest idealny. Spotkałem się też z różnymi ROM-ami, gdzie jeden działał, a inny nie, lub nieprawidłowo.

@marc458- wybacz, musiało mi to umknąć. Dopiero teraz przyjrzałem się dokładnie projektowi HamesterOS. Jeśli dobrze, rozumiem, to ziggystar próbuje stworzyć pewne środowisko, standard, obsługujący (min.) A8PicoCart. Idea jest niezła: po co żonglować firmware'ami do cartridga, albo kupować kilka, skoro można stworzyć swój własny firmware łączący te gry korzystające z Pico, które chce się mieć i jeszcze odpalać z wygodnego, nowoczesnego systemu operacyjnego.

Problemy widzę dwa:
1.
Atari Boy to nie jest gra. Owszem sam program dla Pico zajmuje mniej niż 300kB, a flash'u w Pico jest 16MB. Ale poza rezerwacją 1MB, pozostałe 15MB przeznaczone jest na dysk, czyli na gry z GameBoya i Atari. Ciężko więc współdzielić miejsce z HamsterOS i innym softem. Ale oczywiście, jest to wciąż teoretycznie możliwe. Przecież można zmniejszyć trochę ten dysk, dopasować się do OS ziggystar'a i dorzucić jeszcze jakiś inny soft używający Pico. Ale... patrz punkt 2.

2.
Ja nie chcę już rozwijać Atari Boy'a. Przykro mi. Oczywiście, gdyby pojawił się jakiś gruby błąd w najbliższych dniach, to postaram się go naprawić. Ale dziś zamierzam udostępnić repozytorium ze źródłami + 80 kb notatek technicznych GPT (na moją prośbę prowadził je przez cały projekt) i przejść do realizacji kolejnych projektów dla Atari.

Poświęciłem Atari Boy'owi miesiąc (hahaha CAŁY miesiąc! ;) przed epoką AI byłyby to pewnie 2 lata) i uważam projekt za skończony i satysfakcjonujący mnie. Inne wyzwania czekają. Będę szczęśliwy słysząc, że komuś będzie się chciało poprawiać go czy przerabiać pod swoje potrzeby.

@realszopen - a włączyłeś tryb turbo w opcjach? :) W niektórych grach przy standardowym taktowaniu klatki spadają z 60 do 52 - 56i to przekłada się też na jakość dźwięku. W turbo praktycznie wszystkie gry trzymają 60fps

@takron27 - nie mam pojęcia jak obsłużyć drugi fire z pada od Segi. Sądzę, że bez przejściówki obsługującej standard 2B+ by się tu nie obyło, ale to Larek jest naszym specem w tym temacie. Może skomentuje

Ad 2. Masz wyświetlanie FPS pod klawiszem f. Naciśnij łąskawie HELP i będziesz miał całą klawiszologię.

Ukrywania po 5 sek. nie zamierzam dorabiać, szkoda mi tokenów, sorry ;)
Ale jutro zamierzam udostępnić źródła, więc każdy będzie mógł sobie przerobić co chce.

Trochę bałem się, że ktoś przypadkowo zmieni i zapomnij jak wystartować emulator :D
Na stronie tytułowej emulatora jest info o tym, a w sofcie A8PicoCart nie ma.
No i Atari Boy był dla mnie ważniejszy i pierwszoplanowy ;) Możliwość uruchamiania A8PicoCart dodałem później.

@takron27 Film był w niedzielę. 3 dni w epoce AI to kawał czasu ;) Od tego czasu doszło trochę poprawek i zmian. Min posłuchałem podpowiedzi by wymienić firmware A8PicoCart na najnowszy

@takron27 - do udostępnionego buida Atari Boy'a wrzuciłem najnowszy firmware A8PicoCart z repo ascrnet'a

@xxl da się zrobić zapis screenshota na dysk. Dodaję do listy do kolejnego builda.

Inne emulatory mnie nie interesują. Ale pewnie ktoś zrobi ;)

stRing - nie, ustawień nie zapisuje się na każdej stronie osobno :)

Choć faktycznie, jest to odrobinę skomplikowane. Możesz zapisać ustawienia jako "global" - klawiszem Option. Wtedy zapisywane są ustawienia i wracasz do gry. Ale możesz też zapisać je tylko dla aktualnie granej gry (klawiszem S). Jeśli to zrobisz, to te ustawienia "dla gry" zawsze będą ładowane gdy odpalasz tę grę. Jeśli odpalisz inną, to wczytają się ustawienia "global".

Są też takie ustawienia, które niejako z definicji są globalne. Np. opcja automatycznego odpalenia ostatnio granej gry po włączeniu Atari.

Zapraszam do testowania Atari Boy - emulatora Game Boy dla Atari XL/XE z A8PicoCart (z 16MB FLASH).

Załączony .uf2 to wkład do zaprogramowania cartridga A8PicoCart.


Garść informacji:

Emulowany jest oryginalny Game Boy, nie Game Boy Color ani Game Boy Advance.

Cart został przetestowany na komputerach 800XL, 65XE, 130XE, zarówno PAL jak i NTSC. Testowano współpracę z Ulitimate1M, VBXE, QMEG, stereo.
Mimo testów, jest to wciąż wersja rozwojowa v.0.90b i mogą wystąpić jakieś błędy.

Po wgraniu nowego programu wewnętrzny dysk cartridga o pojemności 15MB pozostanie nienaruszony, czyli jeśli masz tam jakieś pliki, to nie stracisz ich.
I możesz nadal używać A8PicoCart do wgrywania programów Atari - wystarczy, że włączysz komputer trzymając wciśnięty klawisz "A".

Emulator obsługuje obrazy gier z Game Boy z rozszerzeniem .gb. Należy je wgrać na wewnętrzny dysk przez USB, dokładnie tak samo jak wgrywa się gry dla Atari.

W czasie gry wypróbuj klawisze OPTION i HELP by wyświetlić opcje i skróty klawiaturowe. Tam są wszystkie niezbędne informacje.
ESC pozwala wybrać inną grę bez wyłączania komputera.

Emulator pozwala na zapis i odczyt stanów gry.
Konfigurację można zapisać jako ogólną, lub przypisaną do danej gry.
Pliki stanu i opcji są zapisywane na dysku w katalogach .saves i .options i po połaczeniu przez USB można je ręcznie backupować i kasować.

Jeśli Atari wyposażone jest w dwa Pokey'e (stereo), to automatycznie zosanie ustawiony dźwięk stereo.

Domyślnie emulator pracuje w trybie standard, gdzie procesor jest taktowany 250 MHz. Dla niektórych gier jest to za mała wydajność (szczególnie z Atari NTSC) i nie osiągają 60 fps jakie generował Game Boy. Można to sprawdzić wyświetlając FPS na ekranie (klawisz F). Można zmienić taktowanie procesora z trybu Standard na Turbo (300 MHz). Nie ustawiałem tego jako standard, bo nie jestem pewny stabilności działania przy takim overclokingu.


Prezentacja Atari Boy:
https://youtu.be/HSlbrIAWdxM?t=4210


Znane błędy:

W czasie testów dwukrotnie natrafiono na problem z obsługą transferu gier przez USB: transfer plików spadał do 10KB/s lub występowały błędy transmisji. Najprawdopodobniej problem wynika z tego, że usuwanie plików zwalnia ich miejsce w FAT, ale nie usuwa mapowań danych w warstwie FLASH i przy większej rotacji plików może to spowodować spowolnienie. Jeśli taki problem wystąpi w Opcjach w zakładce DISK dodano możliwość optymalizacji dysku (żadne dane nie są usuwane), a jeśli to nie pomoże to wyczyszczenia danych na dysku (program pozostaje nienaruszony).

Emulator nie jest doskonały i niektóre gry nie działają prawidłowo. Do tej pory znalazłem: Bubble Bobble, Adams Family, Street Fighter 2. Będzie to diagnozowane.

EDITED:
Źródła Atari Boy i szczegółowe notatki techniczne (TECHNICAL-CONTEXT.md)
https://github.com/nosty3/AtariBoy

23

(6 odpowiedzi, napisanych Zloty)

Będę

24

(16 odpowiedzi, napisanych Software, Gry - 8bit)

Dzięki, akurat się przyda. Będzie testowane :)

Javalonde napisał/a:

Dlaczego Alien 3? Bo jest dostępne repo, pełny kod, sprite-y itp dla C64.

Dla najnowszych modeli źródła już nie są konieczne. Analizują binarkę w kilka minut. Zerknij: https://www.atari.org.pl/forum/viewtopi ... 78#p326978

To zrobił GPT-6 Astra w przeglądarce, w trybie Work, nawet bez Codexa, bez żadnych skilli. Sam sobie zbudował środowisko ściągając asembler, emulator i sam testował to co robił.


Akurat Alien 3 z C64 wymagałoby chyba sporo pracy (i to pewnie w dużej części ludzkiej) nad grafiką, bo widzę tam sporo kolorów.
Ostatnio powstaje mnóstwo portów na różne platformy, produkowanych przez AI prawie maszynowo. Działają i to poprawnie, dają radość tym, którzy się bawią w to portowanie, ale często jest tam też sporo błędów i niedociągnięć, bo poprawienie ich wymaga już 5x więcej pracy, a często też sporo wiedzy.

Ja się nie podejmę, mam z AI inne wyzwania na tapecie, równie ambitne (w tym jeden port).
Co z tego, że zrobiłbym Ci na jutro działającą wersję Alien 3, skoro wyglądałaby jak gówno, przy wersji z C64? To bez sensu, bo słaby port tylko szkodzi Atari.