07.04 00:00
[#152]
Re: Mortal Kombat 3 na Amigę
@Artur Jarosik, post #150
Rzucilem, ale chyba zle zrozumialem, ze zero to zamiana w zero tez bedzie.
Bo tak to by mozna bylo zamienic tablice z 256 bajtow na 128KB i byloby duzo szybciej.
Wszystko zalezy czy to jest jakas stala wartosc bajtowa wtedy.
Bo odczyt i zapis bajt po bajcie to slaby pomysl jak to ma byc szybkie.
Byc moze eor.l by mogl zostac uzyty, ale ja tej instrukcji nie uzywalem.
Musze to jakos przemyslec, albo wiecej informacji posiadac.
Bo tak to by mozna bylo zamienic tablice z 256 bajtow na 128KB i byloby duzo szybciej.
Wszystko zalezy czy to jest jakas stala wartosc bajtowa wtedy.
Bo odczyt i zapis bajt po bajcie to slaby pomysl jak to ma byc szybkie.
Byc moze eor.l by mogl zostac uzyty, ale ja tej instrukcji nie uzywalem.
Musze to jakos przemyslec, albo wiecej informacji posiadac.
07.04 11:49
[#154]
Re: Mortal Kombat 3 na Amigę
@Don_Adan, post #153
W oryginalnej formie nie kompiluje się, po poprawieniu przez GPT grafika jest zepsuta.
Cała odpowiedź GPT:
Ostatnia aktualizacja: 07.04.2026 11:58:15 przez Artur Jarosik
Cała odpowiedź GPT:
Kierunek jest dobry, ale tego kodu nie wrzucałbym as-is. Plusy: to jest sensowny pairlut fast path branchless transparency przez and/or z LUT może być szybsza niż per-pixel dla flip_h to ma większy sens niż dalsze dłubanie w C Ale są 4 ważne problemy: Obsługuje tylko parzyste szerokości. lsr.l #1,d7 ucina ostatni piksel. Dla w=1 nic nie narysuje, dla w nieparzystego zgubi ogon. Zakłada specjalny układ LUT. (a2,d1.w*4) z .w używa indeksu ze znakiem. To działa tylko jeśli a2 wskazuje środek 256 KB tabeli. Jeśli nie, indeksy 0x8000..FFFF pójdą w złe miejsce. Trzeba mieć pewność co do kolejności bajtów pary. move.w -(a4),d1 na BE ładuje parę w kolejności pamięci, niekoniecznie w takiej, jakiej oczekuje LUT dla flip_h. Jeśli LUT nie jest zbudowany dokładnie pod ten układ, piksele w parze będą zamienione. and.w d1,(a0) + or.w d1,(a0)+ to dwa read-modify-write na pamięci. Na 68060 to może być gorsze niż: move.w (a0),d3 and.w d1,d3 swap d1 or.w d1,d3 move.w d3,(a0)+ Czyli moja ocena: tak, to ma sens jako -wyspecjalizowany fast path -nie, nie w tej postaci jeszcze Ja bym to zrobił tak: zostawić ten path tylko dla w >= 2 policzyć pairs = w >> 1 dodać scalar tail dla w & 1 jawnie opisać, że map wskazuje środek LUT sprawdzić, czy LUT jest indeksowany w dobrej kolejności dla flip_h zamienić memory and/or na operacje w rejestrze i jeden zapis Najkrócej: pomysł dobry, implementacja jeszcze wymaga doszlifowania. Jeśli chcesz, mogę od razu przepisać ten wariant do bezpieczniejszej wersji z tail-handlingiem i jednym store na parę.
Ostatnia aktualizacja: 07.04.2026 11:58:15 przez Artur Jarosik
07.04 13:47
[#157]
Re: Mortal Kombat 3 na Amigę
@Artur Jarosik, post #154
A2 ma wskazywac srodek tabeli LUT, a nie poczatek, przeciez tak napisalem na EAB.
Moze wskazywac poczatek tabeli, ale wtedy trzeba dodac jedna instrukcje moveq #0,Dx do petli, lub uzyc 1 wiecej rejestr Dx, i go wyzerowac przed petla.
A to ma byc szybkie, wiec to jest taka jakby podwojna tablica, dodatnie wartosci (input) sa powyzej adresu A2,
ujemne wartosci (input) sa ponizej wartosci A2.
Pytalem sie kiedys czy moga byc wartosci nieparzyste w takiej petli jako length/cnt uzywane, i zebys to sprawdzil np. daj komende "illegal" w odpowiednim miejscu petli, to po prostu sie petla wywali.
Jezeli moga byc to trzeba dodac obsluge na koncu.
Wedlug mnie raczej nie powinno ich byc, bo tu chyba jest grafika, a grafika na Amidze to sa wielokrotnosci 2, czyli zawsze parzyste wartosci.
Ale nie jestem ekspertem od grafiki. Moze na PC-cie jest inaczej?
Dla tabeli nie ma znaczenia czy input bedzie jako LE czy BE.
Bo to i tak jest konwersja bajt w bajt.
Chyba, ze chodzi o szybsze tworzenie tabeli.
W tabeli sa 4 bajtowe wartosci output, dla kazdej 2 bajtowej wartosci input.
W dolnym slowie jest maska, mozliwe sa 4 wartosci czyli $00000000,$0000ffff,$ffff0000,$ffffff
Jak jest 0000 to destynacja jest zerowana, jak jest ffff to jest niezmieniana.
W gornym slowie sa wartosci ze starej tabeli "map", czyli tej 256 bajtowej plus pierwszy bajt to ma byc zero.
Ogolnie to wszystkie procedury bajtowe , powinienes zmienic na podobny kod, bedzie wtedy duzo szybciej.
A co do read modify and write w wersji na 68060, to koder z 68060 musialby sie wypowiedziec, czy szybsza bedzie wersja AI (5 instrukcji), czy moja (3 instrukcji).
Na moje oko to bedzie chyba tak samo, albo moja szybsza, ale ja nigdy nie tworzylem kodu specjalnie dla 68060.
A jesli szybkosc jest taka sama, to zawsze nalezy wybierac krotsza wersje, bo 4 bajty cache i 4 bajty pamieci sie oszczedza.
Ostatnia aktualizacja: 07.04.2026 13:59:47 przez Don_Adan
Moze wskazywac poczatek tabeli, ale wtedy trzeba dodac jedna instrukcje moveq #0,Dx do petli, lub uzyc 1 wiecej rejestr Dx, i go wyzerowac przed petla.
A to ma byc szybkie, wiec to jest taka jakby podwojna tablica, dodatnie wartosci (input) sa powyzej adresu A2,
ujemne wartosci (input) sa ponizej wartosci A2.
Pytalem sie kiedys czy moga byc wartosci nieparzyste w takiej petli jako length/cnt uzywane, i zebys to sprawdzil np. daj komende "illegal" w odpowiednim miejscu petli, to po prostu sie petla wywali.
Jezeli moga byc to trzeba dodac obsluge na koncu.
Wedlug mnie raczej nie powinno ich byc, bo tu chyba jest grafika, a grafika na Amidze to sa wielokrotnosci 2, czyli zawsze parzyste wartosci.
Ale nie jestem ekspertem od grafiki. Moze na PC-cie jest inaczej?
Dla tabeli nie ma znaczenia czy input bedzie jako LE czy BE.
Bo to i tak jest konwersja bajt w bajt.
Chyba, ze chodzi o szybsze tworzenie tabeli.
W tabeli sa 4 bajtowe wartosci output, dla kazdej 2 bajtowej wartosci input.
W dolnym slowie jest maska, mozliwe sa 4 wartosci czyli $00000000,$0000ffff,$ffff0000,$ffffff
Jak jest 0000 to destynacja jest zerowana, jak jest ffff to jest niezmieniana.
W gornym slowie sa wartosci ze starej tabeli "map", czyli tej 256 bajtowej plus pierwszy bajt to ma byc zero.
Ogolnie to wszystkie procedury bajtowe , powinienes zmienic na podobny kod, bedzie wtedy duzo szybciej.
A co do read modify and write w wersji na 68060, to koder z 68060 musialby sie wypowiedziec, czy szybsza bedzie wersja AI (5 instrukcji), czy moja (3 instrukcji).
Na moje oko to bedzie chyba tak samo, albo moja szybsza, ale ja nigdy nie tworzylem kodu specjalnie dla 68060.
A jesli szybkosc jest taka sama, to zawsze nalezy wybierac krotsza wersje, bo 4 bajty cache i 4 bajty pamieci sie oszczedza.
Ostatnia aktualizacja: 07.04.2026 13:59:47 przez Don_Adan
07.04 15:32
[#158]
Re: Mortal Kombat 3 na Amigę
@Don_Adan, post #157
Oczywiscie maska to jest slowo/word, czyli jedna z 4 wartosci $0000,$00ff,$ff00,$ffff.
A nie jak podalem 4 wartosci longword.
Edycja.
I przed 256KB tabela "map", daj dyrektywe, cnop 0,4.
Czyli
Tak, zeby tablica byla zawsze w pamieci na adresie podzielnym przez 4.
Ostatnia aktualizacja: 07.04.2026 15:40:12 przez Don_Adan
A nie jak podalem 4 wartosci longword.
Edycja.
I przed 256KB tabela "map", daj dyrektywe, cnop 0,4.
Czyli
cnop 0,4 Map ds.b $10000×4
Tak, zeby tablica byla zawsze w pamieci na adresie podzielnym przez 4.
Ostatnia aktualizacja: 07.04.2026 15:40:12 przez Don_Adan
07.04 17:01
[#159]
Re: Mortal Kombat 3 na Amigę
@Don_Adan, post #158
No i chyba AI ma racje z tym read modify and write, bo to 2 instrukcje tego typu sa.
Opcjonalnie, mozna tez sprawdzic taka wersje:
Ale to chyba bedzie taka sama szybkosc, co wersja AI.
Chyba, ze w jakiejs kombinacji 2 instrukcje sa w 1 cyklu wykonywane na 68060 lub 68080.
Opcjonalnie, mozna tez sprawdzic taka wersje:
and.w (a0),d1 move.l d1,d3 swap d3 or.w d3,d1 ; lub add.w d3,d1 move.w d1,(a0)+
Ale to chyba bedzie taka sama szybkosc, co wersja AI.
Chyba, ze w jakiejs kombinacji 2 instrukcje sa w 1 cyklu wykonywane na 68060 lub 68080.
07.04 17:23
[#161]
Re: Mortal Kombat 3 na Amigę
@Don_Adan, post #159
Obie wersje dają 2 fps w sensie nie dodają tylko ogólnie jest 2 fps...
; mk3_blit8_mapped_rect_flip_h_pairlut_mem_68k -- experimental pairlut variant ; using memory read-modify-write on destination words. ; ; void mk3_blit8_mapped_rect_flip_h_pairlut_mem_68k(uint8_t* dst0, ; const uint8_t* src0, int w, int rows, int dst_pitch, int src_pitch, ; const uint32_t* pairlut_mid, const uint8_t* map_tail); ; =========================================================================== mk3_blit8_mapped_rect_flip_h_pairlut_mem_68k: _mk3_blit8_mapped_rect_flip_h_pairlut_mem_68k: movem.l d2-d7/a2-a4,-(sp) move.l 40(sp),a0 ; dst0 move.l 44(sp),a1 ; src0 move.l 48(sp),d7 ; w move.l 52(sp),d6 ; rows move.l 56(sp),a3 ; dst_pitch move.l 60(sp),d2 ; src_pitch move.l 64(sp),a2 ; pairlut_mid move.l 68(sp),a4 ; map_tail tst.l d6 beq.w .mrfpm_done tst.l d7 beq.w .mrfpm_done sub.l d7,a3 ; dst_pitch - w move.l d7,d5 lsr.l #1,d5 ; pairs move.l d7,d4 and.l #1,d4 ; tail subq.l #1,d6 .mrfpm_row: lea (a1,d7.l),a4 ; src_after_end for this row tst.l d5 beq.s .mrfpm_tail move.l d5,d0 subq.l #1,d0 .mrfpm_loop2: move.w -(a4),d1 move.l (a2,d1.w*4),d1 and.w d1,(a0) swap d1 or.w d1,(a0)+ dbra d0,.mrfpm_loop2 .mrfpm_tail: tst.l d4 beq.s .mrfpm_next_row moveq #0,d1 move.b -(a4),d1 beq.s .mrfpm_tail_skip move.l 68(sp),a4 ; map_tail move.b (a4,d1.w),(a0) .mrfpm_tail_skip: addq.l #1,a0 .mrfpm_next_row: adda.l a3,a0 adda.l d2,a1 dbra d6,.mrfpm_row .mrfpm_done: movem.l (sp)+,d2-d7/a2-a4 rts =========================================================================== ; mk3_blit8_mapped_rect_flip_h_pairlut_reg_68k -- experimental pairlut variant ; using register merge and one destination store per pair. ; ; void mk3_blit8_mapped_rect_flip_h_pairlut_reg_68k(uint8_t* dst0, ; const uint8_t* src0, int w, int rows, int dst_pitch, int src_pitch, ; const uint32_t* pairlut_mid, const uint8_t* map_tail); ; =========================================================================== mk3_blit8_mapped_rect_flip_h_pairlut_reg_68k: _mk3_blit8_mapped_rect_flip_h_pairlut_reg_68k: movem.l d2-d7/a2-a4,-(sp) move.l 40(sp),a0 ; dst0 move.l 44(sp),a1 ; src0 move.l 48(sp),d7 ; w move.l 52(sp),d6 ; rows move.l 56(sp),a3 ; dst_pitch move.l 60(sp),d2 ; src_pitch move.l 64(sp),a2 ; pairlut_mid move.l 68(sp),a4 ; map_tail tst.l d6 beq.w .mrfpr_done tst.l d7 beq.w .mrfpr_done sub.l d7,a3 ; dst_pitch - w move.l d7,d5 lsr.l #1,d5 ; pairs move.l d7,d4 and.l #1,d4 ; tail subq.l #1,d6 .mrfpr_row: lea (a1,d7.l),a4 ; src_after_end for this row tst.l d5 beq.s .mrfpr_tail move.l d5,d0 subq.l #1,d0 .mrfpr_loop2: move.w -(a4),d1 move.l (a2,d1.w*4),d3 move.w (a0),d1 and.w d3,d1 swap d3 or.w d3,d1 move.w d1,(a0)+ dbra d0,.mrfpr_loop2 .mrfpr_tail: tst.l d4 beq.s .mrfpr_next_row moveq #0,d1 move.b -(a4),d1 beq.s .mrfpr_tail_skip move.l 68(sp),a4 ; map_tail move.b (a4,d1.w),(a0) .mrfpr_tail_skip: addq.l #1,a0 .mrfpr_next_row: adda.l a3,a0 adda.l d2,a1 dbra d6,.mrfpr_row .mrfpr_done: movem.l (sp)+,d2-d7/a2-a4 rts
07.04 18:07
[#163]
Re: Mortal Kombat 3 na Amigę
@Artur Jarosik, post #161
Jesli obie daja tyle samo, to wybierz krotsza wersje, czyli moja.
Tyle, ze FPS to nie jest dokladny pomiar, musisz uzyc timera.
No i jesli testujesz na 68080 to moze nie byc roznicy w szybkosci dzialania.
Bo Gunnar wszystko zoptymalizowal co sie dalo w 68080.
Test musi byc na 68060 zrobiony.
A jezeli wynik bylby taki sam, to mozna jeszcze na 68040 i wybrac szybsza wersje.
No i w kodzie widze, ze sa te tail czyli nieparzyste dlugosci.
Wedlug mnie to jest zbedne, ale moze sie myle?
Uzyj czegos takiego, czyli dodaj illegal do kodu
skompiluj
zagraj
jak sie wywali to ogonek jest potrzebny
jak sie nie wywali to jest zbedny.
No i ogolnie przekazywanie parametrow przez stos wyglada bardzo slabo.
Nie da sie ustawic w kompilatorze, zeby przekazywal parametry przez rejestry ?
Tyle, ze FPS to nie jest dokladny pomiar, musisz uzyc timera.
No i jesli testujesz na 68080 to moze nie byc roznicy w szybkosci dzialania.
Bo Gunnar wszystko zoptymalizowal co sie dalo w 68080.
Test musi byc na 68060 zrobiony.
A jezeli wynik bylby taki sam, to mozna jeszcze na 68040 i wybrac szybsza wersje.
No i w kodzie widze, ze sa te tail czyli nieparzyste dlugosci.
Wedlug mnie to jest zbedne, ale moze sie myle?
Uzyj czegos takiego, czyli dodaj illegal do kodu
skompiluj
zagraj
jak sie wywali to ogonek jest potrzebny
jak sie nie wywali to jest zbedny.
mrfpr_tail:
tst.l d4
beq.s .mrfpr_next_row
illegal
moveq #0,d1
move.b -(a4),d1
beq.s .mrfpr_tail_skip
move.l 68(sp),a4 ; map_tail
move.b (a4,d1.w),(a0)
.mrfpr_tail_skip:No i ogolnie przekazywanie parametrow przez stos wyglada bardzo slabo.
Nie da sie ustawic w kompilatorze, zeby przekazywal parametry przez rejestry ?
07.04 19:58
[#164]
Re: Mortal Kombat 3 na Amigę
@Artur Jarosik, post #149
@Mufa dostał wersję naprawiającą brak postaci.
Ok, pobrałem beta 12 oraz 12.5, jest o tyle lepiej, że w zasadzie za każdym razem udaje mi się uruchomić walkę. Niestety po kilku sekundach wyskakuje Grim Reaper (wstępnie wygląda na to, że za każdym razem, kiedy Liu Kang ma wystrzelić pocisk).
Co ciekawe, w wersji 040 na moim Sam nie widać Sub-Zero, za to w wersji 060 po wybraniu Liu Kanga, a przed wybraniem planszy, animacja zwycięstwa nie jest odtwarzana w całości, tylko po chwili rozpoczyna się od nowa - i tak dopóki nie wybiorę scenerii (w wersji 040 ta animacja odtwarza się poprawnie).
nowa opcja do skalowania
U mnie w trybie wyświetlania w oknie skaluje się tylko w poziomie. Podobnie jak @Mufa, używam rozdzielczości 2560x1440, więc ochoczo ustawiłem skalowanie na 4 i... miałem niezłą panoramę
07.04 21:22
[#169]
Re: Mortal Kombat 3 na Amigę
@Artur Jarosik, post #166
Jedyne co mi przychodzi na mysl, ze odczyt lub zapis do chip ramu jest i to wielokrotny.
Lub ze ta tablica map (256KB) jest generowana za czesto (z kazdym razem?)
To drugie jest bardziej prawdopodobne.
Tablica powinna byc generowana raz na jakis czas, a nie ciagle.
Bo wtedy ten pomysl nie ma sensu, i tablica 256 bajtowa jest lepsza, bo jest po prostu szybciej generowana.
Lub ze ta tablica map (256KB) jest generowana za czesto (z kazdym razem?)
To drugie jest bardziej prawdopodobne.
Tablica powinna byc generowana raz na jakis czas, a nie ciagle.
Bo wtedy ten pomysl nie ma sensu, i tablica 256 bajtowa jest lepsza, bo jest po prostu szybciej generowana.
08.04 12:27
[#171]
Re: Mortal Kombat 3 na Amigę
@Don_Adan, post #169
Ogolnie grafika to nie moja specjalnosc, ale optymalizacja ciezkostrawnego kodu moze byc niewystarczajaca.
Ja to bym taka gre widzial tak.
Jak jest juz wybrany przeciwnik i konkretna lokacja to przeliczyc wszystko co sie da do buforow w pamieci fast.
A potem tylko te dane odtwarzac/wykorzystywac za pomoca c2p lub zwyklego kopiowania.
Tak zeby w czasie walki nie liczyc niczego niepotrzebnego, a cala moc procesora uzywac na AI przeciwnika oraz na wykorzystywanie przeliczonych (w inicie danej planszy) danych.
Wtedy sama walka bedzie dzialala szybko, a oczekiwanie w inicie walki bedzie zalezne od szybkosci procesora, ale raczej bedzie to strawne dla kazdej 68060, byc moze 68040 tez.
Ewentualnie spytac sie ChatGPT, co by proponowal, w tym temacie.
Bo wedlug mnie trzeba raczej zmienic podejscie, moze zmiksowac wszystkie uzywane tla w inicie planszy?
Ostatnia aktualizacja: 08.04.2026 12:27:57 przez Don_Adan
Ja to bym taka gre widzial tak.
Jak jest juz wybrany przeciwnik i konkretna lokacja to przeliczyc wszystko co sie da do buforow w pamieci fast.
A potem tylko te dane odtwarzac/wykorzystywac za pomoca c2p lub zwyklego kopiowania.
Tak zeby w czasie walki nie liczyc niczego niepotrzebnego, a cala moc procesora uzywac na AI przeciwnika oraz na wykorzystywanie przeliczonych (w inicie danej planszy) danych.
Wtedy sama walka bedzie dzialala szybko, a oczekiwanie w inicie walki bedzie zalezne od szybkosci procesora, ale raczej bedzie to strawne dla kazdej 68060, byc moze 68040 tez.
Ewentualnie spytac sie ChatGPT, co by proponowal, w tym temacie.
Bo wedlug mnie trzeba raczej zmienic podejscie, moze zmiksowac wszystkie uzywane tla w inicie planszy?
Ostatnia aktualizacja: 08.04.2026 12:27:57 przez Don_Adan
08.04 13:20
[#172]
Re: Mortal Kombat 3 na Amigę
@Don_Adan, post #171
Właśnie robię cache tła i mam już +10 fps w porówaniu do beta 12.5 na arenie Tower czyli tej z największą teksturą tła na AGA.
Przynajmniej na moim testowym konfigu ale trudno testować na prawdziwym 060 jak się go nie ma..
Ostatnia aktualizacja: 08.04.2026 13:21:54 przez Artur Jarosik
Przynajmniej na moim testowym konfigu ale trudno testować na prawdziwym 060 jak się go nie ma..
Ostatnia aktualizacja: 08.04.2026 13:21:54 przez Artur Jarosik
09.04 21:23
[#179]
Re: Mortal Kombat 3 na Amigę
@Pawelek, post #177
BETA 13:
- Dodano cache dla sprite’ów tła, co daje zauważalny wzrost wydajności. Dodano też nowe opcje do sterowania tym cache w mk3.ini.
Np. enable_subway_cache_bkgd=1 włącza cache dla areny Subway, a new_bkgd_subway_planes=0,3,4,5,6,7 wybiera, które plany mają być cache’owane.
Nie należy dodawać planów animowanych, bo wydajność wtedy wyraźnie spada.
- Wyłączono obsługę myszy dla gracza 2.
- background_quality=1/2 automatycznie włącza obniżenie jakości tła podczas scrollu, żeby go przyspieszyć.
- Dodano opcjonalne, asm-owe przyspieszenie odtwarzania zapisanych fragmentów cache tła przez copy_runs_asm, a copy_runs_asm_threshold ustawia minimalną długość kopiowanego fragmentu, od której zamiast ścieżki C używane jest mk3_memcpy_move16_68k.
- Dodano frameskip_at_scroll_only=1, które włącza ustawioną wartość frameskip tylko wtedy, gdy cache wyłącza się podczas scrollu.
https://mega.nz/folder/l4lFDAQb#46ZRQRxL6IK2Saez9i19tw
- Dodano cache dla sprite’ów tła, co daje zauważalny wzrost wydajności. Dodano też nowe opcje do sterowania tym cache w mk3.ini.
Np. enable_subway_cache_bkgd=1 włącza cache dla areny Subway, a new_bkgd_subway_planes=0,3,4,5,6,7 wybiera, które plany mają być cache’owane.
Nie należy dodawać planów animowanych, bo wydajność wtedy wyraźnie spada.
- Wyłączono obsługę myszy dla gracza 2.
- background_quality=1/2 automatycznie włącza obniżenie jakości tła podczas scrollu, żeby go przyspieszyć.
- Dodano opcjonalne, asm-owe przyspieszenie odtwarzania zapisanych fragmentów cache tła przez copy_runs_asm, a copy_runs_asm_threshold ustawia minimalną długość kopiowanego fragmentu, od której zamiast ścieżki C używane jest mk3_memcpy_move16_68k.
- Dodano frameskip_at_scroll_only=1, które włącza ustawioną wartość frameskip tylko wtedy, gdy cache wyłącza się podczas scrollu.
https://mega.nz/folder/l4lFDAQb#46ZRQRxL6IK2Saez9i19tw