hm, nie zauważyłem żadnej zmiany fps po kompilacji, może kilka cykli mniej, ale jest ona uwzględniona:)

Dzięki drac030, wziąłem twoje pliki. zgodnie z twoimi zmianami stworzyłem nowy SKILL (wcześniej przestałem używać to, bo AI obciążało je balastem, ale w takich sytuacjach jest to prawdopodobnie konieczne).
Naprawiono również błąd z zawieszaniem się NOWEJ GRY.
Zoptymalizowałem kilka innych plików zgodnie z twoimi sugestiami: mapę, menu, weapons, itp.

FPS 5.26 -> FPS 5.88

http://turiecfoto.sk/atari/doom-test/doom9-9-2026.zip

Już czekam na samolot ..

ok, tu: http://turiecfoto.sk/atari/doom-test/doom31-08-2026.zip

github aktualny

F - FPS count

Zdecydowanie nie o to chodzi. Próbuję oszukać AI, żeby pomyślała, co piszesz, a konkretnie skopiowała i wkleiła Twoją reakcję. Pracuję nad tym, tak :)

fps 2.94 - 3.12

http://turiecfoto.sk/atari/doom-test/doom.zip

benche.. + SPEEDUP_LOG.md (jest napisane po słowacku)

drac030: Zrobiłem dużo testów, ale niewiele to pomogło.. Od samego początku staram się maksymalnie zoptymalizować grę, przez kilka tygodni robiłem tylko pomiary, testy, przyspieszenia i nie wiem co to wszystko.. :D

16-bit A: cały silnik = max 6,1 % klatki (0,35 fps przy 5,7) - para rep/sep kosztuje 6 cykli, tyle samo, ile oszczędza jedno 16-bitowe dodawanie; przerobiony blok w paint_col dał netto 1 cykl, drugi wywalił boot. clc/adc #1 = 0,1 %.

mvn/mvp: w klatce nie ma czego przenosić - te lda/sta to próbkowanie tekstur, nie kopiowanie bloku. Jedyna pętla kopiująca (spr_fcopy) chodzi przy ładowaniu, a jej cel to 4 KB okno VBXE, które trzeba przebankowywać co 4 KB, więc mvn musiałby iść bank po banku: 341 ms na wczytanie poziomu, zero fps.

To od AI:
Założenie, że "BCB jest tutaj zablokowany" jest cechą Altira, a nie VBXE. Altira wywołuje LoadBlitter() bezpośrednio w procedurze obsługi BLITTER_START (vbxe.cpp:1361, z komentarzem dokładnie o tym, że dema nadpisują pierwszy rekord bez czekania). Prawdziwy rdzeń efektów pobiera te 21 bajtów BCB z pamięci VRAM w cyklach, które daje mu wyświetlacz - a te dwie instrukcje (~10 cykli, znacznie mniej w systemie Rapidus) wyprzedzą to pobieranie.

Rezultat:
- cm_flush - kopia kolumny źródłowej będzie miała szerokość 1 zamiast cm_n, więc wszystkie bliźniaki z wyjątkiem pierwszego pozostaną stare → dokładnie te paski o długości 2-5 kolumn.
- bg_blit - wypełnienie tła będzie miało szerokość 1 kolumny zamiast bg_w → szersze "odbijające się fragmenty" w lukach, które BSP pozostawił otwarte.

To wyścig, więc zdarza się sporadycznie i nie może się zdarzyć w emulatorze. To pasuje do "tylko na prawdziwym sprzęcie".

Poprawka

Usunąłem oba wpisy po BL_START (pod .if !TEX_RUNS z powodu martwej gałęzi z draw_vspan). Niezmiennik "return BCB to 1 px" nie ma już czytnika: przy TEX_RUNS=1 cm_flush jest jedynym użytkownikiem TWALL BCB, a bg_blit jest jedynym użytkownikiem slotu 0 VLINE BCB, i oba ustawiają BCB_WIDTH przy każdym wywołaniu. Blok skurczył się o 8 bajtów, wszystkie zabezpieczenia ert przeszły pomyślnie.

No cóż, nie wiem, może to pomoże.

galiba.. ponieważ nie mam akceleratora, nie wiem jak to sprawdzić, ale naprawię to.

Trochę się w tym gubię, mam w domu Antonię II i jeszcze jedno Atari, ale muszę kupić jeszcze jeden vbxe na testy..