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 :)

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.

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.