I po co te nerwy? Pokaz swoj kod to powiem co wykorzystalesskull pisze:hehe, ale ja wykorzystałem tylko to co wkleiłem)))
fade in/out grafiki w multicolorze
-
Sebaloz/Lepsi.De
- Posty: 3964
- Rejestracja: 14 wrz 2008, 00:02
Kółko Bresenhama w ASM'ie, akurat dla trybu tekstowego:
http://codebase64.org/doku.php?id=base: ... s[]=circle
http://codebase64.org/doku.php?id=base: ... s[]=circle
Fade in mozna zrobic tak samo jak fadeouta.
Z tym ze to raczej metoda do dem/kolekcji ale nie gier.
Skoro jest 16 kolorow #$0f ($0x) to mozna dla kazdego koloru wygenerowac prosta 16 bajtowa tabelke przejscia od danego koloru do czarnego (wygaszenie).
Teraz wiaze sie te tabelki ze soba #$0f x #$0f i powstaje #$ff 256 tabelek przejsc kolorow. Tabelki sa niezalezne od siebie.
Mozna je najprosciej rozmiescic w pamieci co 16 bajtow, zajma $1000 bajtow.
Co do make'a procedury wygaszania to wyglada to tak:
- bierzemy bajt z ekranu
- dla bajtu pobieramy adres tabelki fejd ina/auta
- adres wstawiamy do spidkodu
- dla $d800 mozna postapic tak samo, albo ograniczyc adres do tablic
#$0x
- wskazowka: jezeli mamy masywne problemy z pamiecia dobrze aby tabelki z zerem #$0x nie lezaly w pamieci ram $d000-$dfff
fejdin/aut wyglada tak:
lda tabelka_kolorow_dla_danego_bajtu,x
sta screen
cykle:5+4=9*1000 bajtow=9000 cykli, *2 ($d800) = 18000
18000 cykli z 18656 wiec ciezko z odgrywaniem muzyki.
Tu mozna jeszcze zrobic 2 optymalizacje.
Pierwsza dotyczy ekranu, jako ze jest 256 kombinacji a pol ekranu jest 1000 to mozna przeskanowac ekran i sprawdzic ktora kombinacja wystepuje dla ktorych pol ekranu.
np. #$6b powtarsza sie dla screen+$0200, screen+$0234, screen+$344
spidkod wyglada wtedy tak
lda tabelka_kolorow_dla_danego_bajtu,x
sta screen+$0200
sta screen+$0234
sta screen+$0344
W ten sposob 1000 odczytow lda $yyyy,x ograniczamy do 256 odczytow
co daje przyspieszenie o 1000-256=744*5=3720 cykli
3720 cykli/63=59 lini rastra -> czyli jest czas na odgrywanie muzyki
No i to samo zrobic dla $d800 tylko jeszcze kolory $d800 andowac przez #$0f, aha w procedurze make'a nie spidkodzie!.
(czasem niektore edytory/konwertery syfia pamiec kolorow $d800).
Mozna pokusic sie o polaczenie procedury dla ekranu i $d800 ale trzeba
dokladnie sprawdzic ile jej wykonanie zajmie rastrow dla danego obrazka i jak bedzie wygladac odswiezanie.
Ogolnie sam fejd in/out wykonuje sie poprzez zmiane rejestru X i skoku do spidkoda.
Zmieniamy wartosc rejestru X=#$00-#$0f i mamy albo fejd in albo fejd aut.
Ostatnia optymalizacja to przeskanowanie mapy ekranu i mapy kolorow, w celu sprawdzenia ile w rzeczywistosci potrzebujemy tablic kolorow z tych 256
To co opisalem dotyczy wygaszania calosci ekranu jednym indeksem, gdyby wygaszac okregiem, to wtedy trzeba dodatkowa przed "kazdym" bajtem odczytac wartosc rejestru X z komorki ze strony zerowej przyporzadkowanej dla danego okregu.
Dodatkowo mozna zeskanowac komorki ekranu po okregach i wtedy
tylko raz odczytuje sie rejestr X i rysuje wartosci na ekranie okregiem ale
to gryzie sie z optymalizacja opisana wyzej jeden odczyt lda -> kilka sta (komorki moga nalezec do innych okregow).
No mogłem tu zastosować jakieś skróty myślowe także jak coś jest nie jasne to moge coś dopisać.
Z tym ze to raczej metoda do dem/kolekcji ale nie gier.
Skoro jest 16 kolorow #$0f ($0x) to mozna dla kazdego koloru wygenerowac prosta 16 bajtowa tabelke przejscia od danego koloru do czarnego (wygaszenie).
Teraz wiaze sie te tabelki ze soba #$0f x #$0f i powstaje #$ff 256 tabelek przejsc kolorow. Tabelki sa niezalezne od siebie.
Mozna je najprosciej rozmiescic w pamieci co 16 bajtow, zajma $1000 bajtow.
Co do make'a procedury wygaszania to wyglada to tak:
- bierzemy bajt z ekranu
- dla bajtu pobieramy adres tabelki fejd ina/auta
- adres wstawiamy do spidkodu
- dla $d800 mozna postapic tak samo, albo ograniczyc adres do tablic
#$0x
- wskazowka: jezeli mamy masywne problemy z pamiecia dobrze aby tabelki z zerem #$0x nie lezaly w pamieci ram $d000-$dfff
fejdin/aut wyglada tak:
lda tabelka_kolorow_dla_danego_bajtu,x
sta screen
cykle:5+4=9*1000 bajtow=9000 cykli, *2 ($d800) = 18000
18000 cykli z 18656 wiec ciezko z odgrywaniem muzyki.
Tu mozna jeszcze zrobic 2 optymalizacje.
Pierwsza dotyczy ekranu, jako ze jest 256 kombinacji a pol ekranu jest 1000 to mozna przeskanowac ekran i sprawdzic ktora kombinacja wystepuje dla ktorych pol ekranu.
np. #$6b powtarsza sie dla screen+$0200, screen+$0234, screen+$344
spidkod wyglada wtedy tak
lda tabelka_kolorow_dla_danego_bajtu,x
sta screen+$0200
sta screen+$0234
sta screen+$0344
W ten sposob 1000 odczytow lda $yyyy,x ograniczamy do 256 odczytow
co daje przyspieszenie o 1000-256=744*5=3720 cykli
3720 cykli/63=59 lini rastra -> czyli jest czas na odgrywanie muzyki
No i to samo zrobic dla $d800 tylko jeszcze kolory $d800 andowac przez #$0f, aha w procedurze make'a nie spidkodzie!.
(czasem niektore edytory/konwertery syfia pamiec kolorow $d800).
Mozna pokusic sie o polaczenie procedury dla ekranu i $d800 ale trzeba
dokladnie sprawdzic ile jej wykonanie zajmie rastrow dla danego obrazka i jak bedzie wygladac odswiezanie.
Ogolnie sam fejd in/out wykonuje sie poprzez zmiane rejestru X i skoku do spidkoda.
Zmieniamy wartosc rejestru X=#$00-#$0f i mamy albo fejd in albo fejd aut.
Ostatnia optymalizacja to przeskanowanie mapy ekranu i mapy kolorow, w celu sprawdzenia ile w rzeczywistosci potrzebujemy tablic kolorow z tych 256
To co opisalem dotyczy wygaszania calosci ekranu jednym indeksem, gdyby wygaszac okregiem, to wtedy trzeba dodatkowa przed "kazdym" bajtem odczytac wartosc rejestru X z komorki ze strony zerowej przyporzadkowanej dla danego okregu.
Dodatkowo mozna zeskanowac komorki ekranu po okregach i wtedy
tylko raz odczytuje sie rejestr X i rysuje wartosci na ekranie okregiem ale
to gryzie sie z optymalizacja opisana wyzej jeden odczyt lda -> kilka sta (komorki moga nalezec do innych okregow).
No mogłem tu zastosować jakieś skróty myślowe także jak coś jest nie jasne to moge coś dopisać.
i to jest całkiem zbalansowana idea, brawo Fenek (chociaż ja i tak nie jestem nigdy zwolennikiem speedcode)
lda tabelka_kolorow_dla_danego_bajtu,x
sta screen
cykle:5+4=9*1000 bajtow=9000 cykli, *2 ($d800) = 18000
nawet mozna liczyć 4+4
bo lda $aaaa,x zajmuje 5 cykli tylko gdy przekracza stronę pamięci (to w sta $aaaa,x jest 5 cykli)
wnioski: Carrion, jak widzisz z pozoru błachy "efekt" fade-ingu obrazka na c64 nie jest taki prosty, jak się wydaje)))))
A wiec patrzcie na to teraz w demach(może grach), klatkujcie i podziwiajcie albo i nie.
lda tabelka_kolorow_dla_danego_bajtu,x
sta screen
cykle:5+4=9*1000 bajtow=9000 cykli, *2 ($d800) = 18000
nawet mozna liczyć 4+4
bo lda $aaaa,x zajmuje 5 cykli tylko gdy przekracza stronę pamięci (to w sta $aaaa,x jest 5 cykli)
wnioski: Carrion, jak widzisz z pozoru błachy "efekt" fade-ingu obrazka na c64 nie jest taki prosty, jak się wydaje
)))))A wiec patrzcie na to teraz w demach(może grach), klatkujcie i podziwiajcie albo i nie.
Bo pecet to zwykły banan...
Ee dobra to jeszcze coś dopiszę, ale to dotyczy preformatowania obrazka
przed uzyciem go do efektu.
Wyzej napisalem ze jest 256 kombinacji kolorow, no ale mozna to jeszcze przeskoczyc.
Przeszukujemy ekran pamieci kolorow dla pary bajtow zamienionych nybblami czyli np. dla wartosci #$5b szukamy #$b5 i jak znajdziemy #$b5
w pamieci kolorow to bierzemy wartosci bitmapy dla tego pola i podmieniamy kombinacje bitow
Taki skan i podmianke robimy dla calego obrazka i w sumie na ekranie powinno byc to co bylo ale dane sie zmieniaja. Dopiero po tym stosuje sie taki obrazek do dalszych efektow.
Tak poza tym to czasem dla hiresu lub multi warto samemu wygenerowac poprawna mape uzycia kolorow na podstawie bitmapy i wykonywac "czyszczenie" obrazka z nieuzytkow/pozostalosci z edytorow.
przed uzyciem go do efektu.
Wyzej napisalem ze jest 256 kombinacji kolorow, no ale mozna to jeszcze przeskoczyc.
Przeszukujemy ekran pamieci kolorow dla pary bajtow zamienionych nybblami czyli np. dla wartosci #$5b szukamy #$b5 i jak znajdziemy #$b5
w pamieci kolorow to bierzemy wartosci bitmapy dla tego pola i podmieniamy kombinacje bitow
Taki skan i podmianke robimy dla calego obrazka i w sumie na ekranie powinno byc to co bylo ale dane sie zmieniaja. Dopiero po tym stosuje sie taki obrazek do dalszych efektow.
Tak poza tym to czasem dla hiresu lub multi warto samemu wygenerowac poprawna mape uzycia kolorow na podstawie bitmapy i wykonywac "czyszczenie" obrazka z nieuzytkow/pozostalosci z edytorow.
-
Sebaloz/Lepsi.De
- Posty: 3964
- Rejestracja: 14 wrz 2008, 00:02
Warto tez wziazc pod uwage mape kolorow $d800, majac trzy kolory w bloku mozna poszukac ktore kombinacje najczesciej sie powtarzaja i zrobic megaswap na bitmapie i dwoch mapach kolorowfenek pisze:Przeszukujemy ekran pamieci kolorow dla pary bajtow zamienionych nybblami czyli np. dla wartosci #$5b szukamy #$b5 i jak znajdziemy #$b5 w pamieci kolorow to bierzemy wartosci bitmapy dla tego pola i podmieniamy kombinacje bitow
__________________________
Socjopatyczna Legia Commodore
Socjopatyczna Legia Commodore
fenek: świetny tekst - dzieki
już teraz wiem dla czego nie zostałem koderem nie chciało by mi sie tego wszystkiego wymyślać
btw: jeśli jednak wszystko dobrze zrozumiałem to metoda sebaloza aby zrobić precalc 8 faz fade in/out bedzie najłatwiejszy do zakodowania.
mówie 8 faz bo nie wydaje mi się aby 16 faz (przez wszystkie kolory) wyglądalo ok ablo było wogule potrzebne. zgadzam sie z zielokiem że 8 faz (po odcieniach) wystarczy aby to ładnie wyglądało.
i jeszcze raz na koniec - nie jestem przekonany żeby to musiało chodzić co ramkę - 8 odcieni np co drugą ramkę powinno wyglądać równie płynnie i ładnie.
Tak patrząc na ten wątek mam coraz więcej szacunku dla SES'a który skodował fade po okręgu we FLI. (COP 75%/100%)
już teraz wiem dla czego nie zostałem koderem
nie chciało by mi sie tego wszystkiego wymyślać btw: jeśli jednak wszystko dobrze zrozumiałem to metoda sebaloza aby zrobić precalc 8 faz fade in/out bedzie najłatwiejszy do zakodowania.
mówie 8 faz bo nie wydaje mi się aby 16 faz (przez wszystkie kolory) wyglądalo ok ablo było wogule potrzebne. zgadzam sie z zielokiem że 8 faz (po odcieniach) wystarczy aby to ładnie wyglądało.
i jeszcze raz na koniec - nie jestem przekonany żeby to musiało chodzić co ramkę - 8 odcieni np co drugą ramkę powinno wyglądać równie płynnie i ładnie.
Tak patrząc na ten wątek mam coraz więcej szacunku dla SES'a który skodował fade po okręgu we FLI. (COP 75%/100%)
c64portal.pl, retronavigator.com
Takie podsumowanie co do cykli:
Liczac 256 odczytyow bajtow z tabelek i 1000 bajtow do postawienia dla pamieci kolorow
i osobno 15 odczytyow z tabelek kolorow i 1000 bajtow do postawienia dla $d800 wychodzi.
256*4+1000*4+15*4+1000*4=1024+4000+60+4000=9084
9084/18656=0,48 ramki Czyli mniej niz jedna ramka
Carrion: ale i tak bedziesz musial trzymac w pamieci przeliczone dane dla $d800 dla tych 8 faz fadeu.
Te dane bedziesz musial kopiowac na $d800, bo adresu pamieci kolorow nie moze sobie dowolnie wybrac w pamieci.
Liczac 256 odczytyow bajtow z tabelek i 1000 bajtow do postawienia dla pamieci kolorow
i osobno 15 odczytyow z tabelek kolorow i 1000 bajtow do postawienia dla $d800 wychodzi.
256*4+1000*4+15*4+1000*4=1024+4000+60+4000=9084
9084/18656=0,48 ramki
Czyli mniej niz jedna ramka Carrion: ale i tak bedziesz musial trzymac w pamieci przeliczone dane dla $d800 dla tych 8 faz fadeu.
Te dane bedziesz musial kopiowac na $d800, bo adresu pamieci kolorow nie moze sobie dowolnie wybrac w pamieci.
W EoD fade'y są szesnastokolorowe tak apropo.mówie 8 faz bo nie wydaje mi się aby 16 faz (przez wszystkie kolory) wyglądalo ok ablo było wogule potrzebne. zgadzam sie z zielokiem że 8 faz (po odcieniach) wystarczy aby to ładnie wyglądało.
W COP lecą trzy okręgi po jeden na każdą ramkę i nie jest to klasyczny fade po wszystkich luminancjach.
i jeszcze raz na koniec - nie jestem przekonany żeby to musiało chodzić co ramkę - 8 odcieni np co drugą ramkę powinno wyglądać równie płynnie i ładnie.
Tak patrząc na ten wątek mam coraz więcej szacunku dla SES'a który skodował fade po okręgu we FLI. (COP 75%/100%)
-
Sebaloz/Lepsi.De
- Posty: 3964
- Rejestracja: 14 wrz 2008, 00:02
Staram sie zrobic najszybsza procedure do fade in, chodzi o czas rastra. Skanuje pixele w blokach, jesli w bloku mam tylko uzyte dwa kolory to sprawdzam czy sa zapisane w pamieci ekranu, a 0 wrzucam do pamieci koloru. Dzieki temu zostaje np polowa bajtow do zmiany w pamieci kolorow. Ekrany z kolorami ekran wygenerowane, tabelki kolorow wg sposobu Nitro, speedcode wg Fenka w postaci procedury wywolywanej z x-em i zmieniajacej tylko pamiec koloru z bajtami innymi niz 0.fenek pisze:Przeszukujemy ekran pamieci kolorow dla pary bajtow zamienionych nybblami czyli np. dla wartosci #$5b szukamy #$b5 i jak znajdziemy #$b5 w pamieci kolorow to bierzemy wartosci bitmapy dla tego pola i podmieniamy kombinacje bitow
A do scrolli w multicolorze najlepiej wybrac kolor ktory najczesciej sie powtarza np moj ulubiony #$0f i ten kolor jest wrzucany do pamieci kolorow. Jest sa tylko dwa kolory uzyte w bloku to tez wrzucam tam #$0f
tak zeby cala pamiec kolorow byla wypelniona jednym i tym samym kolorem. Jesli sa trzy kolory w bloku i zaden z nich nie jest #$0f to wtedy brute force najblizszego koloru np #$0c lub $07 na #$0f. Dzieki temu nie trzeba w ogole przepisywac $d800 przy przesuwaniu grafiki w multi.
__________________________
Socjopatyczna Legia Commodore
Socjopatyczna Legia Commodore