26 Odpowiedź przez w1k

  • w1k
  • w1k
  • Młodszy Atarowiec
  • Nieaktywny
  • Skąd: slovakia
  • Zarejestrowany: 2009-03-17
  • Posty: 526

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.

https://github.com/viktorcech/

w1k's Strona

27 Odpowiedź przez perinoid

  • Skąd: W-wa
  • Zarejestrowany: 2015-11-20
  • Posty: 4,145

Zależy ile się gra i ile jest założone :-)

Pamięć studenta ma charakter kwantowy - student wie wszystko, ale jednocześnie nic nie pamięta.
- Kilka(naście?) pudełek z klawiszami i światełkami. I jeden Vectrex, żeby nimi wszystkimi rządzić.

28 Odpowiedź przez drac030

  • drac030
  • drac030
  • Swołocz z Atari Area
  • Nieaktywny
  • Skąd: Warszawa
  • Zarejestrowany: 2004-09-12
  • Posty: 4,717
w1k napisał/a:

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 %.

Tak, ja wiem, ile zajmuje rep/sep, i oczywiście, przy całkowicie ośmiobitowym kodzie, nie zawsze się opłaca przełączenie (dla pojedynczej operacji - prawie nigdy). Ale tam są takie oto na przykład ciągi rozkazów 8-bitowych:

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

Nie patrzę całościowo, więc nie wiem, czy ten kawałek ma jakikolwiek wpływ na renderowanie klatek, ale wygląda, jakby danie rep #$20 na początku, a sep #$20 gdzieś na końcu pozwoliło go skrócić o połowę.

Widziałem podobny kawałek kopiujący w podobny sposób z miejsca na miejsce bodaj 12 bajtów przy użyciu 24 rozkazów - 72 bajty, 96 cykli, przy przełączeniu na 16-bitowy akumulator zeszłoby to do 40 bajtów i 14 rozkazów na sumę 66 cykli.

Jakieś ciągi lsr/ror/lsr/ror na dwóch kolejnych bajtach, w pętlach i bez - to wszystko jest do optymalizacji.

Post's attachments

ciag_rozkazow.png 51.65 kb, nikt jeszcze nie pobierał tego pliku. 

Tylko zalogowani mogą pobierać załączniki.
KMK
? HEX$(6670358)

drac030's Strona

29 Odpowiedź przez tebe

  • tebe
  • tebe
  • Podkasetarz
  • Nieaktywny
  • Skąd: Poznań / Mosina
  • Zarejestrowany: 2002-04-06
  • Posty: 3,029

drac030 zapomniał że w1k nie jest programistą, co już w1k wyjaśniał

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

tebe's Strona

30 Odpowiedź przez drac030

  • drac030
  • drac030
  • Swołocz z Atari Area
  • Nieaktywny
  • Skąd: Warszawa
  • Zarejestrowany: 2004-09-12
  • Posty: 4,717

Dzięki za troskę, ale o niczym nie zapomniałem - w1k może to wkleić Claudowi tak samo, jak wkleja tu jego odpowiedzi.

KMK
? HEX$(6670358)

drac030's Strona

31 Odpowiedź przez w1k

  • w1k
  • w1k
  • Młodszy Atarowiec
  • Nieaktywny
  • Skąd: slovakia
  • Zarejestrowany: 2009-03-17
  • Posty: 526

drac030, dzięki, wprowadziłem zmiany, zmiana prędkości jest rzeczywiście tylko kosmetyczna. dziś/jutro opublikuję ostatnią wersję z poprawkami, zanim opuszczę słowację na 10 dni.

https://github.com/viktorcech/

w1k's Strona

32 Odpowiedź przez drac030

  • drac030
  • drac030
  • Swołocz z Atari Area
  • Nieaktywny
  • Skąd: Warszawa
  • Zarejestrowany: 2004-09-12
  • Posty: 4,717
w1k napisał/a:

drac030, dzięki, wprowadziłem zmiany, zmiana prędkości jest rzeczywiście tylko kosmetyczna. dziś/jutro opublikuję ostatnią wersję z poprawkami, zanim opuszczę słowację na 10 dni.

Nie ma pośpiechu, dzięki.

Popatrzyłem sobie jeszcze tu i tam i nadal mi się wydaje, że coś można osiągnąć mikrooptymalizacjami niekoniecznie nawet polegającymi na zastosowaniu 16-bitowego akumulatora, bo i kod czysto ośmiobitowy można ulepszyć, np.

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

Zakładając, że nie ma odwołań z zewnątrz pod $4d60 (a nie widzę, żeby były), reforma da 8 cykli zysku (a ten kawałek kodu jest wywoływany bardzo często).

Co więcej, zawartość akumulatora jest potem (po odgałęzieniu bcc pod $4d66 do rts w $4d76) tracona, więc można zastąpić cmp $1353 przez sec/sbc $1353, a sec i sbc stojące poniżej odgałęzienia zlikwidować całkowicie. To da razem 10 cykli zysku - a cały kawałek od adresu $4d5a do $4d6d ma ich, o ile dobrze liczę, 28.

No, i tak dalej, i tym podobnie, usque ad mortem.

Post's attachments

doom_procedurka.png 9.8 kb, nikt jeszcze nie pobierał tego pliku. 

Tylko zalogowani mogą pobierać załączniki.
KMK
? HEX$(6670358)

drac030's Strona