Wiadomość wysłana przez: c---n w 17 Maja 2010, 09:00
Jak sie robi fade in/out grafiki w multicolorze.
tzn to co mi przychodzi do glowy to czytanie bajta po bajcie z $0400 i z $d800 sprawdzenie koloru a potem pobranie z tablicy fadeow koloru o nizszym poziomie? tak to chyba powinno dzialac ale pytanie jest czy sa na to jakies triki ktore koderzy wypracowali?
Wiadomość wysłana przez: Skull w 17 Maja 2010, 09:56
![\"Smile\"](\"images/smiles/icon_smile.gif\"){kind=icon}
Tez jestem ciekaw, jakie sa \"podejscia\" do tego tematu.
Najgorsza jest zabawa z nibblami (polbajty) - bo informacja o kolorze 1 i 2 zawarta jest razem w pojednynczych bajtach (kolor 0 to d021, a kolor 3 pochodzi z obaszaru $d800-dbe7).
Ja robie tak:
Tablica Fade-ingu dla kazdego z 16 kolorow (zalezna od stopni zanikania, ale zalozmy maks 16) czyli 16x16 =256 bajtow (chociaz czarny mozemy oczywiscie pominac) w notacji bajtow $KOLOR|KOLOR, czyl np czerwony to $22, druga tabelka na indeks dla koloeu w tabeli zanikania - czyli w tym przypadku kolor*16, dla 16 kolorow to 16 elementow - mozna nawet na strone zerowa wyrzucic.
Wzorzec dla kolorow (i ten dla mapy i ten dla $d800) proponuje oczywiscie umiescic w pamieci gdzies oddzielnie, bo na jego podstawie i konkretniej fazy zaniku bedziemy ustalac kolejne kolory (samomodyfikacja pozeralaby mase czasu) dla kwadratow 8x8px.
No i niestety najlepiej to wykonywac jakims efektem(tzn nie wszystko na raz) -bo obraz jest podzielony na 1000 komorek mapy koloru, +1000 dla $d800, i obsluzyc to wszystko w jedej ramce nie jest chyba nawet mozliwe.
Oczywiscie mozna tez dodac jakies warunki przyspieszajace (np pomijac od razu kolor czarny).
Kawalek kodu:
| Kod: |
| : : ldy ColorCell : : : : : ::dla danej komorki koloru lda MapC_colorsSpecimen,y : ::pobierz kolor (:para): oryginalny beq + : : : : : : : ::jesli \'pusty\' to -> bierz sie za nastepny and #%00001111 : : : ::najpierw mlodszy nibble :wpierw badamy mlodszy nibble beq l_starszy-2 : : : ::jak czarny to dalej tax lda _multiTab,x : : : ::pomnoz przez 16 ora FadePhase tax lda _FullFadeTable,x : ::i wez odpowiadajacy dla fazy kolor and #%00001111 : ::tylko dla mlodszego nibble sta _cTmp2+1 : : : ::zapamietaj dalej (:dla OR): : : : : l_starszy lda MapC_colorsSpecimen,y : ::pobierz kolor (:para): oryginalny and #%11110000 : ::teraz starszy nibble beq _cTmp2 : : : ::czarny ? ora FadePhase : : : : : : tax lda _FullFadeTable,x and #%11110000 _cTmp2 : : : :ora #$00 : ::skladamy mlodszy i starszy nibble sta Colors_map,y : : : ::i na ekran + : :iny : : : :nastepna komorka |
Wiadomość wysłana przez: zielok__ w 17 Maja 2010, 11:33
| skull napisal: |
No i niestety najlepiej to wykonywac jakims efektem(tzn nie wszystko na raz) -bo obraz jest podzielony na 1000 komorek mapy koloru, +1000 dla $d800, i obsluzyc to wszystko w jedej ramce nie jest chyba nawet mozliwe. Oczywiscie mozna tez dodac jakies warunki przyspieszajace (np pomijac od razu kolor czarny). |
Nie pamietam dokladnie ale wydaje mi sie to jak najbardziej mozliwe zrobienie w jednej ramce (ale musimy unrollowac kod i oczywiscie korzystac z tabelki z kolorami do wygaszania)
Co do kolorow to najlepiej fadeout robic poprzez zgrupowanie kolorow pod wzgledem jasnosci czyli z bialego do czarnego nie przechodzimy w 15 kropkach ale w 8. Imo lepiej to wyglada.
Reasumujac to co pisal apropo fadeout Carrion jest jak najbardziej OK i nie da sie raczej inaczej tego zrobic.
Co do Fade-in to tutaj musimy rozbijac na dwie 4bitowe wartosci i pobierac dane z tabelki wiec bedzie wolniej ale w 50fps chyba da sie rade to zrobic
Wiadomość wysłana przez: Skull w 17 Maja 2010, 00:00
Cytat: \"zielok\"
Nie pamietam dokladnie ale wydaje mi sie to jak najbardziej mozliwe zrobienie w jednej ramce (ale musimy unrollowac kod i oczywiscie korzystac z tabelki z kolorami do wygaszania)
/quote]
Ale konkrety chlopie, bo jak napisalem sam jestem ciekawy podejscia do tej sprawy - jasniej (unrollowac kod ?).
To czy w jednej ramce da sie obsluzyc efekt, zalezy tez oczywiscie od wielkosci obrazka, jednak chcac obluzyc kazda komorke wydaje sie to nie mozliwe - bo zmienic kazda komorke z tych 2000 to chyba tylko \"lda sta\" zostaje.
312 linii (PAL) * 63 cykle = 19656
- 25*40 (BadLines)
daje to 18656 / 2000 = 9,32 cykla na obsluge jedej komorki pamieci (nie wpominajac o tych z mapy koloru gdzie trzeba rozdzielac na nibble), glupie lda sta to 8 cykli, a co z jakas muzyczka w tle.
Tlumacz bo ja na razie tego nadal nie widze.
Wiadomość wysłana przez: Kisiel w 17 Maja 2010, 14:16
Wiadomość wysłana przez: Nitro__ w 17 Maja 2010, 14:49
Przedstawie idee na cos ciekawszego, poprawcie mnie jesli cos przeoczylem.
Potraktujmy rejestr screen ramu jako state-machine, mamy w nim maksymalnie 256 kombinacji, dla kazdej chcemy uzyskac liczbe w ktorej oba nible zostana w jakis sposob zmodyfikowane. Coz za problem postawic 256 look-up tabelke.
Przykladowo, wartosci w hexach:
31 - z tabelki 20
20 - z tabelki 10
10 - z tabelki 0
0 - z tabelki 0 i sie zapetla tak wiec nie trzeba nic sprawdzac.
Mozna to spokojnie dostosowac do fade\'owania po luminancji.
Wiadomość wysłana przez: Skull w 17 Maja 2010, 15:30
| Nitro napisal: |
| Moj fader dziala na zasadzie przedstawionej w tym watku i zdecydowanie nie jest to moj najlepszy kawalek kodu, bodajze o 3\'ciej w nocy byl napisany. Przedstawie idee na cos ciekawszego, poprawcie mnie jesli cos przeoczylem. Potraktujmy rejestr screen ramu jako state-machine, mamy w nim maksymalnie 256 kombinacji, dla kazdej chcemy uzyskac liczbe w ktorej oba nible zostana w jakis sposob zmodyfikowane. Coz za problem postawic 256 look-up tabelke. Przykladowo, wartosci w hexach: 31 - z tabelki 20 20 - z tabelki 10 10 - z tabelki 0 0 - z tabelki 0 i sie zapetla tak wiec nie trzeba nic sprawdzac. Mozna to spokojnie dostosowac do fade\'owania po luminancji. |
Chyba kojarze zasade, ale wez wpisz klika linii listingu (dla pewnosci)
No i teraz zdalem sobie sprawe, ze mozna \"animowac\" zanik na rejestrze $d018 (mapy kolorow), tyle ze trzeba przed samym efektem wiliczyc 8 map kolorow (zasada analogiczna do FLI) dla kazdej fazy zaniku, a potem tylko co ramke przelaczac rejestr - zostaje jeszcze kwestia $d800, ale tu juz nie powinno byc problemu z wyrobieniem sie. Oczywisty minus tej metody to pamieciozernosc.
Wiadomość wysłana przez: Nitro__ w 17 Maja 2010, 16:11
| Cytat: |
| Chyba kojarze zasade, ale wez wpisz klika linii listingu (dla pewnosci) |
Proste:
ldx $0400
lda lut,x
sta $0400
| Cytat: |
| No i teraz zdalem sobie sprawe, ze mozna \"animowac\" zanik na rejestrze $d018 (mapy kolorow), tyle ze trzeba przed samym efektem wiliczyc 8 map kolorow (zasada analogiczna do FLI) dla kazdej fazy zaniku, a potem tylko co ramke przelaczac rejestr - zostaje jeszcze kwestia $d800, ale tu juz nie powinno byc problemu z wyrobieniem sie. Oczywisty minus tej metody to pamieciozernosc. |
Rowniez skuteczna metoda, zawsze cos musi byc zjedzone, czy to pamiec czy to proc
Wiadomość wysłana przez: Sebaloz w 17 Maja 2010, 17:52
*=$8000
siedem przejsc koloru d800 od najciemniejszego do najjasniejszego,
*=$8000+7
siedem przejsc koloru d801 od najciemniejszego do najjasniejszego,
*=$8000+14
siedem przejsc koloru d802 od najciemniejszego do najjasniejszego,
itd
Potem tylko przelaczalem wygenerowane ekrany od najciemniejszego do najjasnieszego, po pokazaniu sie calego obrazka przelaczalem wygenerowane ekrany od najjasniejszego do najciemniejszego, a po kazdym przelaczeniu ekranu puszczalem przepisanie d800, ktore spokojnie miescilo sie w jednej ramce, mozna bylo puscic na przerwaniach a w tle uzywac loadera KM\'a.
ldx #$00
jsr przelacz-ekran
jsr przepisanied800
inx
cpx #$07
bne *-9
ldx #$05
jsr przelacz-ekran
jsr przepisanied800
dex
cpx #$ff
bne *-9
przepisanied800:
(procedurka zajmuje $1770 pamieci, mozna ja skrocic pomijajac miejsca z czarnym kolorem)
lda $8000,x
sta $d800
lda $8000+7,x
sta $d800+1
lda $8000+14,x
sta $d800+2
itd..
rts
Wiadomość wysłana przez: c---n w 17 Maja 2010, 18:50
1. przelaczanie bankow / obrazkow jest ok jak chcemy zrobic fade calego obrazka - gdy chcemy zrobic np fade wg jakiegos wzoru juz to nie zadziala.
2. Fade co ramke nie koniecznie jest wymogiem.
po zrobieniu tablicy fade\'u mamy 8 odcieni koloru gdy zaczynamy od bialego. zmiana odcienia co ramke poskutkuje takim blyskiem, ktorego nawet nie da sie zauwazyc
![\"Wink\"](\"images/smiles/icon_wink.gif\"){kind=icon}
3. czy tego typu kod umieszcza sie w przerwaniu irq czy raczej nie koniecznie?
btw:
skodowalem to wg mojego pierwotnego pomyslu i nawet dziala.
tyle tylko ze teraz chcialbym aby to pokazywalo sie np po ksztalcie okregu jak w Carrion Oldschool Pixels... tutaj mam nowa zagwozdke.
ps. wzielo mnie na kodowanie dla odmiany jak by kto pytal
Wiadomość wysłana przez: Nitro__ w 17 Maja 2010, 20:16
| Cytat: |
| tyle tylko ze teraz chcialbym aby to pokazywalo sie np po ksztalcie okregu jak w Carrion Oldschool Pixels... tutaj mam nowa zagwozdke. |
Musisz skads znac koordynaty okregu plus wziac pod uwage wychodzenie czesci okregu poza ekran. Tak wiec polecam prekalk i potem te dane ladujesz do swojej procedurki.
| Cytat: |
| 2. Fade co ramke nie koniecznie jest wymogiem. po zrobieniu tablicy fade\'u mamy 8 odcieni koloru gdy zaczynamy od bialego. zmiana odcienia co ramke poskutkuje takim blyskiem, ktorego nawet nie da sie zauwazyc |
IMHO 16 kolorow fade co ramke to standard.
| Cytat: |
| 3. czy tego typu kod umieszcza sie w przerwaniu irq czy raczej nie koniecznie? |
Od tego sa przerwania, pozwalaja wykonac kod powtarzajacy sie latwo i przyjemnie. Nie ladujesz do przerwan kodu, ktory nie powinien sie zatrzymywac tylko dzialac non stop kiedy go przerwania nie stopuja.
Wiadomość wysłana przez: Skull w 18 Maja 2010, 06:23
| Nitro napisal: |
Proste: ldx $0400 lda lut,x sta $0400 |
no ale jesli ma sie to wykonac dla kazdej komorki, oraz dla colorRamu to nadal nie wystarcza czasu w jednej ramce -patrz wylicznia wyzej.
| Cytat: |
| tyle tylko ze teraz chcialbym aby to pokazywalo sie np po ksztalcie okregu jak w Carrion Oldschool Pixels... tutaj mam nowa zagwozdke. |
nie dawno wykorzystalem (z powodzeniem) to:
| Kod: |
| xcircle i ycircle - wspolrzedne srodka :R=30 :XC=0::YC=R :FX=0::FY=8*R::FS=4*R+3 :WHILE FX : :XC=XC+1 : :FX=FX+8 : :IF FS>0 : : :FS=FS-FX-4 : :ELSE : : :YC=YC-1 : : :FY=FY-8 : : :FS=FS-FX-4+FY : :ENDIF :WEND splot8 :plot xcircle+XC,ycircle+YC :plot xcircle+XC,ycircle-YC :plot xcircle-XC,ycircle-YC :plot xcircle-XC,ycircle+YC :plot xcircle+YC,ycircle+XC :plot xcircle+YC,ycircle-XC :plot xcircle-YC,ycircle-XC :plot xcircle-YC,ycircle+XC |
| Cytat: |
| 2. Fade co ramke nie koniecznie jest wymogiem... |
| Cytat: |
| 3. czy tego typu kod umieszcza sie w przerwaniu irq czy raczej nie koniecznie? |
No to wlasnie zalezy od tego, czy ma byc to raz na ramke czy nie, jesli nie to nie umieszczaj w przerwaniu, bo muzyczka bedzie Ci sie ciela.
@Kutfa Nitro daj tu jednak cala procedure tego fadingu
@Sebaloz, czyli wykonales to dokladnie tak, jak napisalem post wczesniej.
Wiadomość wysłana przez: zielok__ w 18 Maja 2010, 06:48
| skull napisal: |
Ale konkrety chlopie, bo jak napisalem sam jestem ciekawy podejscia do tej sprawy - jasniej (unrollowac kod ?). |
Unrollowac kody czyli wygenerowac kod ktory leci ciurkiem zamiast korzystac z petli czyli
lda $xxxx
sta $yyyy
Poza tym nie moge tego sprawdzic bo jestem w pracy a nie mam w glowie ile cykli lda czy sta zajmuje (w koncu jestem co najwyzej przecietniakiem (c) Ramos).
Kolejna kwestia to swoja wiedze opieralem na efekcie ktory kiedys napisalem i w okolo 0,5 ramki zmieniam caly obszar od $0400 do $07e8 (zaznacze, ze NIE PAMIETAM dokladnie ile to trwa bo calkiem mozliwe, ze troche dluzej niz 0,5 frame).
| skull napisal: |
Tlumacz bo ja na razie tego nadal nie widze. |
A gdzie slowo prosze ?
Wiadomość wysłana przez: Skull w 18 Maja 2010, 06:57
| zielok napisal: |
Unrollowac kody czyli wygenerowac kod ktory leci ciurkiem zamiast korzystac z petli czyli lda $xxxx sta $yyyy Poza tym nie moge tego sprawdzic bo jestem w pracy a nie mam w glowie ile cykli lda czy sta zajmuje (w koncu jestem co najwyzej przecietniakiem (c) Ramos). Kolejna kwestia to swoja wiedze opieralem na efekcie ktory kiedys napisalem i w okolo 0,5 ramki zmieniam caly obszar od $0400 do $07e8 (zaznacze, ze NIE PAMIETAM dokladnie ile to trwa bo calkiem mozliwe, ze troche dluzej niz 0,5 frame). |
he,he i po co te nerwy... wszystko wlasnie wyjasniles, i sie nawet zgadza, 0,5 frame na colormap i teraz jeszcze pol frame na color ram = 1 ramka, przy jak nazwales \"unrolowaniu\". No ale taki efekt moim zdaniem \"za duzo kosztuje\", i wykonanie jego bedzie najwyzej \"na styk\" - moze trzeba sie bedzie nawet pozegnac z playerem od muzyczki.
Na samym poczatku napisalem, ze mnie wlasnie ciekawi podejscie do tego tematu, bo uwazam go zwyczajnie za trudny do prostego wykonania.
| skull napisal: |
Tlumacz bo ja na razie tego nadal nie widze. |
| zielok napisal: |
A gdzie slowo prosze ? |
proscie, a bedziecie prosci.
Wiadomość wysłana przez: zielok__ w 18 Maja 2010, 07:26
| skull napisal: |
he,he i po co te nerwy... |
To poco sie denerwujesz? Bo chyba nie twierdzisz, ze ja mam nerwy
Wiadomość wysłana przez: Nitro__ w 18 Maja 2010, 14:12
| Cytat: |
| no ale jesli ma sie to wykonac dla kazdej komorki, oraz dla colorRamu to nadal nie wystarcza czasu w jednej ramce -patrz wylicznia wyzej. |
Prawda, choc nie wziales jednego sposobu pod uwage, puszczenia kodu od dolnej ramki, za kazdym razem bedzie sie troche zwiekszac ale powinno wystarczyc na caly fade.
Ogolnie mowie caly czas o fade oucie ktory jest prostszy bo wartosci wyjsciowe wszystkich komorek sa jednakowe.
Co do fadeinu, to metoda na calkowity precalc screenramow bedzie najlepszym rozwiazaniem, do dwoch bankow bitmapy i voila, mamy 16\'o kolorowy fade.
| Cytat: |
| Kutfa Nitro daj tu jednak cala procedure tego fadingu |
Mowisz o fadeoucie? Jak wyzej.
Wiadomość wysłana przez: Skull w 18 Maja 2010, 14:23
Wiadomość wysłana przez: zielok__ w 18 Maja 2010, 14:39
| skull napisal: |
| dobra juz widze, czyli rewolucji nie bedzie. |
Wykorzystac DMA w REU i bedzie rewolucja
Wiadomość wysłana przez: Sebaloz w 18 Maja 2010, 15:49
| skull napisal: |
| nie dawno wykorzystalem (z powodzeniem) to: |
Trzeba bylo wrzucic linka do calosci
http://atariarea.krap.pl/forum/viewtopic.php?pid=104175#p104175
Wiadomość wysłana przez: Skull w 18 Maja 2010, 16:02
| Sebaloz/Lepsi.De napisal: | ||
Trzeba bylo wrzucic linka do calosci http://atariarea.krap.pl/forum/viewtopic.php?pid=104175#p104175 |
hehe, ale ja wykorzystalem tylko to co wkleilem
)))
Wiadomość wysłana przez: Sebaloz w 18 Maja 2010, 16:19
| skull napisal: |
| hehe, ale ja wykorzystalem tylko to co wkleilem ))) |
I po co te nerwy? Pokaz swoj kod to powiem co wykorzystales
Wiadomość wysłana przez: Nitro__ w 18 Maja 2010, 17:01
http://codebase64.org/doku.php?id=base:bresenham_circle_routine&s[]=circle
Wiadomość wysłana przez: fenek__ w 18 Maja 2010, 18:45
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 moglem tu zastosowac jakies skroty myslowe takze jak cos jest nie jasne to moge cos dopisac.
Wiadomość wysłana przez: Skull w 18 Maja 2010, 19:29
lda tabelka_kolorow_dla_danego_bajtu,x
sta screen
cykle:5+4=9*1000 bajtow=9000 cykli, *2 ($d800) = 18000
nawet mozna liczyc 4+4
bo lda $aaaa,x zajmuje 5 cykli tylko gdy przekracza strone pamieci (to w sta $aaaa,x jest 5 cykli)
wnioski: Carrion, jak widzisz z pozoru blachy \"efekt\" fade-ingu obrazka na c64 nie jest taki prosty, jak sie wydaje
)))))A wiec patrzcie na to teraz w demach(moze grach), klatkujcie i podziwiajcie albo i nie.
Wiadomość wysłana przez: fenek__ w 18 Maja 2010, 19:36
Policzylem ze 5 bo nie pisalem nic o rozmieszczeniu tablic,
mozna spokojnie zejsc do 4 cykli.
Wiadomość wysłana przez: Nitro__ w 18 Maja 2010, 19:43
Wiadomość wysłana przez: fenek__ w 18 Maja 2010, 20:01
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.
Wiadomość wysłana przez: zielok__ w 18 Maja 2010, 20:19
Wiadomość wysłana przez: Sebaloz w 18 Maja 2010, 20:30
| fenek napisal: |
| 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
Wiadomość wysłana przez: c---n w 19 Maja 2010, 08:38
juz teraz wiem dla czego nie zostalem koderem
nie chcialo by mi sie tego wszystkiego wymyslac btw: jesli jednak wszystko dobrze zrozumialem to metoda sebaloza aby zrobic precalc 8 faz fade in/out bedzie najlatwiejszy do zakodowania.
mowie 8 faz bo nie wydaje mi sie aby 16 faz (przez wszystkie kolory) wygladalo ok ablo bylo wogule potrzebne. zgadzam sie z zielokiem ze 8 faz (po odcieniach) wystarczy aby to ladnie wygladalo.
i jeszcze raz na koniec - nie jestem przekonany zeby to musialo chodzic co ramke - 8 odcieni np co druga ramke powinno wygladac rownie plynnie i ladnie.
Tak patrzac na ten watek mam coraz wiecej szacunku dla SES\'a ktory skodowal fade po okregu we FLI. (COP 75%/100%)
Wiadomość wysłana przez: Kisiel w 19 Maja 2010, 09:20
Wiadomość wysłana przez: fenek__ w 19 Maja 2010, 09:21
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.
Wiadomość wysłana przez: Nitro__ w 19 Maja 2010, 10:04
| Cytat: |
| mowie 8 faz bo nie wydaje mi sie aby 16 faz (przez wszystkie kolory) wygladalo ok ablo bylo wogule potrzebne. zgadzam sie z zielokiem ze 8 faz (po odcieniach) wystarczy aby to ladnie wygladalo. |
W EoD fade\'y sa szesnastokolorowe tak apropo.
| Cytat: |
| i jeszcze raz na koniec - nie jestem przekonany zeby to musialo chodzic co ramke - 8 odcieni np co druga ramke powinno wygladac rownie plynnie i ladnie. Tak patrzac na ten watek mam coraz wiecej szacunku dla SES\'a ktory skodowal fade po okregu we FLI. (COP 75%/100%) |
W COP leca trzy okregi po jeden na kazda ramke i nie jest to klasyczny fade po wszystkich luminancjach.
Wiadomość wysłana przez: Sebaloz w 19 Sierpnia 2011, 19:07
| fenek napisal: |
| 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.
Wiadomość wysłana przez: Skull w 19 Sierpnia 2011, 19:29
dawajcie lepiej do opisu, fragmenty listingow,
terminologia/nazewnictwo jest u kazdego z koderow wrecz indywidualne - kod w assemblerze na szczescie nie.