Eee tam, drobne poprawki, zwłaszcza w monitorze, który jest w dużej mierze jednak niezależny, można by robić.

Ale, wróćmy do tematu: TeBe, próbowałeś moich sugestii? Pomogło to coś? Zasadniczo, dopóki nie sprofilujecie kodu, ciężko powiedzieć co warto optymalizować...

Ha, pewnie używasz Windows, to tam Ci nie pomogę - może ktoś nakierować TeBe jak to zrobić???

Cygwin i GCC?

Hej!

A nie można zapatchować i skompilować źródeł atari800-2.0.3 dostępnych na sf.net przy pomocy Visual Studio Express 8 (jest za free przecież). W katalogu atari800-2.0.3/src/win32/msc jest makefile do Microsoftowego nmake który jest dołączony do VS8 Express. Na chwilę obecną nie mam za bardzo czasu aby się w to bawić ani się specjalnie na tym nie znam... ale czy ktoś bardziej obeznany mógłby pomóc?

Seban

w KL wykorzystywane są bitmapy szerokości 2,3,4 bajtów, wykorzystałem tą właściwość i rozpisałem kopiowanie i przesuwanie bitów dla tych szerokości

dodatkowo udało się zintegrować tablice przesunięć bitów z tablicą odbicia lustrzanego

dla testowej bitmapy 32x38 pixli wersja standardowa zajmowała ok. 40000 cykli, aktualna ok. 12000 (napisałem taki mini emulator 6502 aby wykonał oba testowe programy i zliczył cykle)

i co z tego skoro po tych poprawkach szybkość gry nadal nie jest w 100% zadowalająca, coś tam jeszcze pożera zachłannie cykle

plik wraz ze źródłami można pociągnąć stąd http://madteam.atari8.info/gry/knightlore.7z

gre można uruchomić tylko przez XRLoader, wersja dla emula (min 128 dodatkowej pamięci) w katalogu ..\asm\xrload.obx

na potrzeby testów gra wykorzystuje pamięć dodatkową, normalnie zajmuje obszar $0000..$BFFF, muzyki i efektów dźwiękowych brak, zostały wycięte dla maksymalnej szybkości działania (program DLI też jest krótszy i szybszy pare cykli)

Zająłem się tylko i wyłącznie próbą sprofilowania tego.

http://eru.nutki.com/a8/prof
pograłem kilka sekund, i zrzuciłem profil gdzie idzie czas (w kolumnach: adres / numer instrukcji / ilość cykli). Warto to sobie posortować po drugiej lub trzeciej kolumnie, pomaga zidentyfikować "intensywne" obszary

http://eru.nutki.com/a8/game.asx
http://eru.nutki.com/a8/game.lst
http://eru.nutki.com/a8/game.lab
oryginalny game.asx rozszerzony o makra definiujące interesujące nas obszary - obszary brałem patrząc na prof

Wyniki (tylko obszary >1%, adres lo/hi, liczba cykli, udział procentowy, nazwa; obszary się nakładają, patrz lo/hi):

982a 9850    513250   1.06  NMI
2147 2188   1633402   3.39  E_214D
1be0 1bf5   1674630   3.47  E_1BFA
1b44 1bb7   1725336   3.58  E_1B92
1bd1 1c2e   2052481   4.25  BMPMIRROR
bd97 be32   2497068   5.18  SHFBMP3
21b9 22c4   5178095  10.73  E_21BF
1b2c 1b3a   9763442  20.24  E_1B7B
0000 0044  12227423  25.35  PUTSHAPE
1874 1c80  15759503  32.67  CODE_E_18C6_E_1C86
1607 1c80  15864855  32.89  CODE_E_1659_E_1C86
1c80 2d90  16314202  33.82  CODE_E_1C86_E_2D96
1607 2d90  32179057  66.71  CODE_E_1659_E_2D96
0000 ffff  48238851 100.00  GLOBAL

Szybka analiza:
- pushape warto optymalizować dalej

- e_1b7b zajmuje dużo bardzo. Kod wygląda tak:

E_1B7B    mva    (E_0049),y    E_0400,x
    mva    (E_004B),y    E_0500,x
    iny
    inx
    bne E_1B7B

może warto zamienić to na

E_1B7B    mva    adres1,x    E_0400,x
    mva    adres2,x    E_0500,x
    inx
    bne E_1B7B

poprzez na sztywno ustawienie adres1 i adres2

- cześć cykli idzie nie wiadomo gdzie jeszcze (zwłaszcza te z obszaru e_1c86_e_2d96 - tam  mamy zidentifikowane ~15% z ~34%), wymaga więcej profilowania, ale to jest trudne jak kod jest tak strasznie nieczytelny :)

- ogólnie, nie widać, żeby dało się przyspieszyć całość znacząco modyfikując jeden kawałek kodu :(

dzieki Eru, teraz widać gdzie trzeba drążyć

Proponuję następującą zmianę w procedurze PUTSHAPE:

0012 wstawiam CLC

potem tak jak było:
LDA $xxxx,Y
AND $xxxx,X
ORA $xxxx,X
STA $xxxx,Y

teraz zmiana, zamiast kombinacji z INX i NOP (5 bajtów, 10 cykli):
TXA
ADC #$x ; gdzie x to ilość INX z poprzedniej wersji
TAX
(4 bajty, 6 cykli)

Skoki do 0012 od teraz wykonywane są pod adres 0013.
Reszta bez zmian.

Pozdrawiam.

Proponuję kolejną poprawkę:

$0023 DEC $45 zamieniłbym na CPX #$xx.

Program inicjujący PUT SHAPE musiałby wyliczyć szerokość * wysokość (dane pobierane z tablicy), dodać początkowe X (to które trafia do $0005), a wynik wpisać do $0024.

Zysk znikomy: tylko 1 cykl na każdy kopiowany bajt, więc może nie pokryć strat spowodowanych obliczaniem końcowego X.

Poprawka moich ostatniech poprawek PUTSHAPE:

TXA
ADC #$xx
BCS $0032 ; X nie może być większy od 255
TAX


wypada fragment:
DEC $45
BEQ $0032

Jeżeli niczego nie pokręciłem to w sumie wynik -9 cykli na każdy kopiowanym bajcie.

http://madteam.atari8.info/gry/knightlore.7z

dzięki Magnus, Twoja poprawka jak najbardziej działa, dodatkowo zamieniłem JSR PUTSHAPE na JMP PUTSHAPE i RTS na JMP PUTSHAPE_RETURN

można wprowadzić jakiś limit ramek, jeśli liczba ramek nie przekroczyła 3 to czekaj do 3 ramek, w przeciwnym wypadku leć dalej i nie oglądaj się za siebie

eee działa, tylko trzeba wypełnić do pełnej strony tak aby etykieta E_0100 zaczynała sie od adresu $0100

rejestr X ustawiany jest tak, że koniec bufora E_0400, E_0500 przypada na ich ostatni bajt (E_0400+$ff, E_0500+$ff)