c64scene.pl

skull pisze:hehe, ale ja wykorzystałem tylko to co wkleiłem )))

I po co te nerwy? Pokaz swoj kod to powiem co wykorzystales

Kółko Bresenhama w ASM'ie, akurat dla trybu tekstowego:
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ć.

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.

Heh, no wlasnie mialem o tych cyklach dopisac.
Policzylem ze 5 bo nie pisalem nic o rozmieszczeniu tablic,
mozna spokojnie zejsc do 4 cykli.

fenek:+1 za rozpisanie tematu, mi z dzisiejszego zaspania coś się pokręciło i uznałem fadein za trudny bo tabelki by zajeły 64kb

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.

Na Fenka zawsze można liczyć. Brawo za to, że ci się chciało to wszystko opisać.

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

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 kolorow

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

co drugą ramkę 0,32 sekundy ? Będzie coś widać?

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.

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 EoD fade'y są szesnastokolorowe tak apropo.

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

W COP lecą trzy okręgi po jeden na każdą ramkę i nie jest to klasyczny fade po wszystkich luminancjach.

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

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.

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.

Wiecie co...
dawajcie lepiej do opisu, fragmenty listingów,
terminologia/nazewnictwo jest u każdego z koderów wręcz indywidualne - kod w assemblerze na szczęście nie.