Komentowana treść: Nowa, szybka konwersja chunky-to-planar
21.11.2015 18:10
[#151]
Re: Nowa, szybka konwersja chunky-to-planar
@MDW, post #142
heh, w sumie, kiedy ekscytowaliśmy się, że na Amigę powstało coś, co jest git grą 3d bez kompleksów, jakoś mnie to nie zastanawiało ;) nawet znajoma pecetowca była pod wrażeniem. Rzeczywiście, kiedy urok nieco minął takie rzeczy zaczynaja być widoczne. Dziwi mnie to jednak nieco - tzn. te "kwadraty", bo w sumie jak robiliśmy jakieśtam śmieszne produkcje, to właśnie "było wiele radości" (cytując Monty Pythona ;)), z tego, że udało się coś "zfake'ować" jakimś banalnym trickiem, co wyglądało na coś więcej, niż nim było ;) stąd też zastanawiało mnie dlaczego chłopaki w Breathless'ie nie "złamali" jakkolwiek tej "architektury" - nawet nie zmieniając tych prostych kolizji, jeśli masz rację a'propos przyczyny tego ograniczenia, hmmm.
PS. a w ogóle mam nadzieję, że mimo "kopania sięz koniem" w naszym wspaniałym systemie
masz ten promil czasu na "zmarnowanie", który pozwala wciąż zrobić po cichu jakąś hardkorową produkcję 
PS. a w ogóle mam nadzieję, że mimo "kopania sięz koniem" w naszym wspaniałym systemie
masz ten promil czasu na "zmarnowanie", który pozwala wciąż zrobić po cichu jakąś hardkorową produkcję 22.11.2015 13:06
[#153]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #110
Podaję teraz wyniki po wprowadzeniu obsługi danych liniowych chunky. Zapis odbywa się do CHIP. Te wyniki można już porównywać z innymi c2p. Podajcie proszę wyniki innych c2p, jeśli znacie.
Procedura konwertuje piksele 2x1.
Zapis do CHIP w ramach testu w tej chwili odbywa się do jednej komórki, nie ma aktualizacji wskaźnika, ale to poprawię.
Dla 68030/50MHz wyglądają one tak:
Ekran 320x256 (40960 pikseli): 28 ms.
Ekran 320x128 (20480 pikseli): 14 ms.
Zamieszczam kody źródłowy: procedury testującej oraz procedury c2p. Test odbywa się 1000 razy.
Przy okazji wyszło na jaw skąd wzięły się te wcześniejsze wahania obliczeń. Wynikały one z tego, że wyłączałem przerwania (funkcją Disable()). Obecnie już nie wyłączam przerwań.
Procedura konwertuje piksele 2x1.
Zapis do CHIP w ramach testu w tej chwili odbywa się do jednej komórki, nie ma aktualizacji wskaźnika, ale to poprawię.
Dla 68030/50MHz wyglądają one tak:
Ekran 320x256 (40960 pikseli): 28 ms.
Ekran 320x128 (20480 pikseli): 14 ms.
Zamieszczam kody źródłowy: procedury testującej oraz procedury c2p. Test odbywa się 1000 razy.
Przy okazji wyszło na jaw skąd wzięły się te wcześniejsze wahania obliczeń. Wynikały one z tego, że wyłączałem przerwania (funkcją Disable()). Obecnie już nie wyłączam przerwań.
15.09.2017 09:22
[#161]
Re: Nowa, szybka konwersja chunky-to-planar
Hejka, opracowałem nową, zgrabną i przejrzystą procedurę konwersji chunky-to-planar. Zajęło mi to kilka dobrych dni.
Konwertuje liniowe 32 piksele 1:1 używając tylko i wyłącznie rejestrów procesora (również wszystkie maski)! Brak pośrednich buforów.
Jeszcze gruntownie nie testowałem prędkości, ale na pewno jest poprawna (sprawdzałem pod Asm-One). Wygląda jednak na to, że jest szybka.
Zawsze można też zrobić szybszą wersję na pikselach 2:1.
Nota: Procedura może być używana do prostej konwersji 32 pikseli w rejestrach, lub w pętli. W przypadku pętli do dyspozycji pozostaje jeden wolny rejestr - A6, pod który można podpiąć dowolne dane/adresy itp. oraz stos - A7, gdzie można np. odkładać rejestry.
Na końcu pętli są wolne dwa rejestry danych: D0 i D1.
Wynik obliczeń jest w tych rejestrach:
A2: plan 0
A0: plan 1
A3: plan 2
A1: plan 3
D2: plan 4
D4: plan 5
D5: plan 6
D3: plan 7
Rozlokowaniem uzyskanych danych mógłby zajmować się np. Blitter, ale też procesor.
Oto kod źródłowy. Postaram się za jakiś czas porobić gruntowne testy (teraz jestem zajęty).
Kod jest freeware, proszę używać tylko w całości i nadmienić autora.
Jeśli ktoś dysponuje teraz jakimś testem, proszę śmiało go zrobić.
http://coreprogramming.pl/chunky/c2p.txt
Ostatnia aktualizacja: 15.09.2017 09:39:37 przez Hexmage960
Konwertuje liniowe 32 piksele 1:1 używając tylko i wyłącznie rejestrów procesora (również wszystkie maski)! Brak pośrednich buforów.
Jeszcze gruntownie nie testowałem prędkości, ale na pewno jest poprawna (sprawdzałem pod Asm-One). Wygląda jednak na to, że jest szybka.
Zawsze można też zrobić szybszą wersję na pikselach 2:1.Nota: Procedura może być używana do prostej konwersji 32 pikseli w rejestrach, lub w pętli. W przypadku pętli do dyspozycji pozostaje jeden wolny rejestr - A6, pod który można podpiąć dowolne dane/adresy itp. oraz stos - A7, gdzie można np. odkładać rejestry.
Na końcu pętli są wolne dwa rejestry danych: D0 i D1.
Wynik obliczeń jest w tych rejestrach:
A2: plan 0
A0: plan 1
A3: plan 2
A1: plan 3
D2: plan 4
D4: plan 5
D5: plan 6
D3: plan 7
Rozlokowaniem uzyskanych danych mógłby zajmować się np. Blitter, ale też procesor.
Oto kod źródłowy. Postaram się za jakiś czas porobić gruntowne testy (teraz jestem zajęty).
Kod jest freeware, proszę używać tylko w całości i nadmienić autora.Jeśli ktoś dysponuje teraz jakimś testem, proszę śmiało go zrobić.
http://coreprogramming.pl/chunky/c2p.txt
Ostatnia aktualizacja: 15.09.2017 09:39:37 przez Hexmage960
15.09.2017 14:36
[#162]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #161
Zrobiłem mały skoroszyt, żeby obliczyć koszt i wyniki są naprawdę ciekawe:
Na razie wyniki teoretyczne.
Wyniki są dla procesora MC68020 i przeciętnego przypadku:
Procedura zużywa zaledwie 14,25 taktów zegara na jeden piksel.
Jeden ekran 320x200 konwertuje przy zegarze 50MHz w ciągu 18,24 milisekund (ms) co daje 54 FPS.
Jednak w realnych warunkach wskaźnik FPS dla takiego ekranu jest trochę mniejszy niż 50 (przy włączonych przerwaniach i wielozadaniowości), przynajmniej dla procesora MC68030.
Ale przy odrobinie mniejszym ekranie pełne 50 FPS można bez problemu osiągnąć.
Procesor wówczas będzie miał spory zapas mocy, by obsłużyć algorytmy o podobnym koszcie (adekwatnie do liczby pikseli).
Przypominam, że Doom został napisany dla 30 FPS. Przy takim "framerate" ekran spokojnie może być nawet 320x256.
W każdym razie procedura się przyda. Trzeba ją tylko opakować w procedurę wyświetlającą.
Ma ktoś pomysł i doświadczenie do czego można jej użyć? Ja jestem zielony w temacie efektów chunky (nigdy nie robiłem efektów do dem).
Ostatnia aktualizacja: 15.09.2017 14:56:15 przez Hexmage960
Na razie wyniki teoretyczne.
Wyniki są dla procesora MC68020 i przeciętnego przypadku:
Procedura zużywa zaledwie 14,25 taktów zegara na jeden piksel.
Jeden ekran 320x200 konwertuje przy zegarze 50MHz w ciągu 18,24 milisekund (ms) co daje 54 FPS.
Jednak w realnych warunkach wskaźnik FPS dla takiego ekranu jest trochę mniejszy niż 50 (przy włączonych przerwaniach i wielozadaniowości), przynajmniej dla procesora MC68030.
Ale przy odrobinie mniejszym ekranie pełne 50 FPS można bez problemu osiągnąć.
Procesor wówczas będzie miał spory zapas mocy, by obsłużyć algorytmy o podobnym koszcie (adekwatnie do liczby pikseli).
Przypominam, że Doom został napisany dla 30 FPS. Przy takim "framerate" ekran spokojnie może być nawet 320x256.
W każdym razie procedura się przyda. Trzeba ją tylko opakować w procedurę wyświetlającą.
Ma ktoś pomysł i doświadczenie do czego można jej użyć? Ja jestem zielony w temacie efektów chunky (nigdy nie robiłem efektów do dem).
Ostatnia aktualizacja: 15.09.2017 14:56:15 przez Hexmage960