Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Altirra 4.50 test 21 Phaeron opublikował kolejną kompilację testową Altirra 4.50 test 21 z poprawkami dla napędów i DOS 2.
GEM na Atari XL/XE Niezwykły port środowiska GEM z warstwami VDI i AES dla mocno rozbudowanych maszyn Atari XL/XE.
Atari800 7.2.0 Nowa wersja popularnego emulatora Atari800 przynosi lepszą emulację POKEYa i nowe opcje.
BMA8 v0.1.0 - emulator Atari dla RPI Nowy bare-metal emulator Atari 400/800/XL/XE dla Raspberry Pi startuje w około sekundę bez systemu.
Atari System Emulator v1.12 Wydano Atari System Emulator w wersji 1.12 z obsługą napędu B, nowymi trybami wyświetlania i usprawnieniami.
atari.area forum » Software, Gry - 8bit » Doom (AI, VBXE, Rapidus/Antonia)
Strony Poprzednia 1 2 3 4
Zaloguj się lub zarejestruj by napisać odpowiedź
Tu jest film o Doomie na różnych modelach Atari ST: https://www.youtube.com/watch?v=RhrLe2Xy5uY
Od piętnastej minuty z groszami zaczyna się prezentacja na 1040ST, Medze ST, gołym Falconie030 itd.
Myślę, że nie jest źle, dajemy radę.
tak, widziałem to już jakiś czas temu, ciekawe... mój port nadal ma połowę rozdzielczości... i nie wiem, gdzie gra pozwoliłaby nam uzyskać większą fps :)
Ale za to nie ma tego brzydkiego ditheringu z wersji ST :-)
i nie wiem, gdzie gra pozwoliłaby nam uzyskać większą fps :)
Na pewno da się jeszcze trochę przyśpieszyć wersję dla Antonii wykorzystując na szerszą skalę sprzętowe mnożenie (makro qsmul i procedury go używające, procedura smul32) i dzielenie (procedura udiv16). Każ mu pod tym kątem napisać nowe wersje math.asm, paint.asm, textures.asm i tw_setup.asm i zobaczymy.
Byle tylko nie porzucić Rapidusa jakby miały być jeszcze jakieś inne zmiany.
Jak z wprowadzeniem kodów IDKFA i IDDQD? Są "kultowe" ;-) tak samo MLI w Wolfie.
Ogólnie ten program jest nieco dziwnie skonstruowany. Np. próbuje się cały kod upchnąć w pierwszych 64k, co i tak się nie udaje, w dodatku przydzielając poszczególnym blokom kodu stałe miejsca w pamięci i pilnując, czy się nie przepełniają.
Na dodatek pamięć obrazu ma 16k, ale okno do niej, mające 4k, umieszczone jest pod, o ile dobrze rozumiem, adresem $9000 - co powoduje, że na Rapidusie cały blok 16k od $8000 do $BFFF działa z prędkością 1,77 MHz.
Słowem, można byłoby (chyba?) pod $8000-$BFFF włączyć okno 16k VRAM-u dla ekranu 160x100/256 kolorów na stałe, bez bawienia się w przełączanie kawałków po 4k, a cały kod, który zawala pierwsze 64k i ledwie się tam mieści, przenieść do drugiego bloku 64k, od $010000 do $01FFFF - gdzie też jest FastRAM i nawet jest częściowo wykorzystany na kod.
Zwolniwszy w ten sposób mnóstwo pamięci w pierwszych 64k można byłoby bardzo wiele zmiennych, które w chwili obecnej są zadeklarowane jako 8-bitowe albo 24-bitowe, przedeklarować na 16 albo 32 bity, oraz ewentualnie poupychać tam tablice, które się teraz w nim nie mieszczą.
To z kolei pozwoliłoby może uprościć kod dokonujący obliczeń przez ograniczenie przełączeń na 8 bitów tylko po to, żeby nie nadpisać adresu zmienna+3, gdzie może być już coś innego.
To tylko takie luźne myśli, decyzje i tak należą do w1k.
To jest dość wymagające, pracuję nad tym od rana i zasadniczo muszę za każdym razem przekonywać AI, żeby kontynuowała, ponieważ pyta mnie, jaką ścieżką chcę podążać, mimo że ma wszystkie informacje jasno przekazane jej przez ciebie... to zajmie trochę czasu.
AI:
Przeniosłem prawie cały kod do $010000-$01FFFF. W pierwszych 64 KB zostało tylko to, co musi tam być: start przed przełączeniem w tryb natywny, obsługa przerwań, wywołanie SIO i nakładki menu.
Okno MEMAC-A ma teraz na stałe 16 KB pod $8000-$BFFF i w tym bloku nie wykonuje się już żaden kod. Ekran ma jednak 160×200, czyli 32 KB, więc okno pokazuje stronę z listami XDL i blokami blittera, a nie sam ekran.
Zwolniona pamięć posłużyła do przedeklarowania części zmiennych na 16 i 32 bity. Kilka przełączeń na 8 bitów zniknęło, a obraz jest identyczny bajt w bajt.
Zysk jest niewielki, w modelu około 2% (z 6,61 na 6,73 fps), a w emulatorze gra ma na starcie około 6 fps. Najwolniejsze pozostają zapisy do VBXE przez szynę Atari, których ta zmiana nie usuwa.
Czy chodziło Ci o ekran 160×100 na stałe w oknie, kosztem połowy rozdzielczości w pionie?
Zysk jest niewielki, w modelu około 2% (z 6,61 na 6,73 fps), a w emulatorze gra ma na starcie około 6 fps.
Bardzo dobrze, zysk, to zysk, a poza tym uporządkowanie kodu też się liczy, może da się tam jeszcze coś ręcznie wycisnąć.
Zauważyłem wczoraj, że w wersji na Antonię II, mimo że licznik FPS-ów pokazuje na pierwszej scenie 4.76, czasami przeskakuje na 4.87 - różnica pomiędzy jednym a drugim to około 2%.
Czy chodziło Ci o ekran 160×100 na stałe w oknie, kosztem połowy rozdzielczości w pionie?
Nie, szczerze mówiąc, zaskoczony jestem, że rozdzielczość to 160x200, bo wydawało mi się tak na oko, że 160x100. Mój błąd, powinienem był obejrzeć XDL. No, ale nawet jeśli, to i tak jest lepiej: dwa banki MEMAC to lepiej niż osiem.
Na to, że dane do VBXE idą przez wolną szynę 1,77 MHz, nic się nie da poradzić: sprzętowcy (autorzy) od Antonii II i VBXE musieliby nad tym usiąść razem, a to raczej mało prawdopodobne.
będą pewne zmiany..
Na to, że dane do VBXE idą przez wolną szynę 1,77 MHz, nic się nie da poradzić: sprzętowcy (autorzy) od Antonii II i VBXE musieliby nad tym usiąść razem, a to raczej mało prawdopodobne.
gdyby Antonia 2 miała kanał DMA przenoszący dane z fastramu do VBXE to procesor mógły zająć się wyłącznie przygotowaniem grafiki.
Niewykonalne. To już by wymagało gruntownej przebudowy samej bazy (np. wywalić DRAM, potem żeby Antic nie generował cykli odświeżania i nie blokował szyny, itp. itd.).
Niewykonalne. To już by wymagało gruntownej przebudowy samej bazy (np. wywalić DRAM, potem żeby Antic nie generował cykli odświeżania i nie blokował szyny, itp. itd.).
chodzi o najprostsze wyjście - korzystanie z dostępnych cykli, tak jak w sumie FPGA Antonii już robi. Prosty mechanizm DMA chyba by nie zajął w FPGA zbyt dużo miejsca, a znacznie odciążyłby 816.
Istnieją dużo prostsze koncepcje, które też nie znalazły powszechnego zrozumienia, np. przyśpieszenie rozkazów move'ów blokowych do 2 cykli na bajt.
ciekawe czy Simius w ogóle ma możliwość zmian w rdzeniu 65816
ciekawe czy Simius w ogóle ma możliwość zmian w rdzeniu 65816
W ogóle ma.
następnie więcej optymalizacji kodu.
fps 7.14
http://turiecfoto.sk/atari/doom-test/doom-15-9-2026.zip
coś jeszcze dla zabawy:
Altirra: 5.26-5.40 FPS
Antonia: 5.40-5.55 FPS (wersja na Antonię: 5.71-5.88)
Ciekawe, skąd ta różnica.
Ale w ogóle chyba jest błąd, patrz obrazek: za tymi oknami nie powinno być tak czarno i w poprzedniej wersji rzeczywiście nie było.
Czerń powstała przez przesunięcie sufitu. Teraz powinien być obraz, tło. W e3l1 był błąd, przez który sufit był obniżony. Po jego naprawieniu powstała czarna przestrzeń - nie ma czym jej wypełnić. Zobaczę, czy wstawię tam obraz, czy nie.
Jeśli chodzi o FPS, mierzę go, gdy naciskam F - na samym początku mieliśmy 4-5, teraz jest ponad 7.
Jeszcze jedno: wersja na Antonię nie działa dobrze.
spróbuj tego:
http://turiecfoto.sk/atari/doom-test/doom9-9-2026a.zip
edit: reupload 21:34
Teraz jest lepiej, jest krajobraz zamiast czarnego tła, a zakłócenia w wersji na Antonię zniknęły.
EDIT:
Jeśli chodzi o FPS, mierzę go, gdy naciskam F
Ja też, wyniki są z samego początku, zaraz po załadowaniu. Jeszcze raz:
Altirra 14 MHz: 5.26-5.40
Antonia II: 5.40-5.55 (wersja ogólna), 5.71-5.88 (wersja specjalna)
Rapidus 20 MHz: 7.69-8.00
Rapidus 40 MHz: 11.11-11.76
Czy byłby duży spadek FPS-ów, gdyby sam dolny panel zrobić w średniej rozdzielczości VBXE (tj. 320 pikseli w poziomie)?
dzięki, dobry pomysł, zrobiłem to
http://turiecfoto.sk/atari/doom-test/doom10-9-2026.zip
320 hud, zużywa tylko około 0,003 fps
Teraz jest elegancko, dzięki.
Strony Poprzednia 1 2 3 4
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Software, Gry - 8bit » Doom (AI, VBXE, Rapidus/Antonia)
Wygenerowano w 0.027 sekund, wykonano 61 zapytań