Adam Klobukowski napisał/a:Blokowanie szyny podczas pracy (nawet w trybie HOG),
a który blitter tak nie robi? Pamięć RAM ma to do siebie że na raz korzystać z niej może tylko jedno urządzenie. Więc 68000 w zależności od sytuacji blokowany jest przez MMU/Shiftera, ACSI, FDC no i blittera.
Ale chyba wiem co chciałeś powiedzieć - w trybie HOG blitter przejmuje szynę danych na cały proces blittowania. W trybie Blit-mode dzieli się szyną z procesorem w czasie pracy.
Zgaduję że problemem w/g ciebie jest współdzielenie szyny 64/64 (64 cykle dla blittera i 64 dla procesora) w Blit-mode.
No nie wiem, dla mnie to jest ok. Oczywiście pewnie Atari mogło lepiej rozwiązać współdzielenie szyny w Blit-mode ale dla "chcącego nic trudnego". Jakieś 7 lat temu na Atari-Forum dodałem skromy wpis, w jaki sposób używać CPU i blitter równocześnie.
Tutaj np. masz screen z 3D Full Leonarda/Oxygene. Jest to overscan połączony z obiektem 3d wypełnianym blitterem:
Adam Klobukowski napisał/a:nie do wyeliminowania trzaski a dźwięku DMA itp.
szczerze mówiąc nigdy nie słyszałem o tym problemie. masz może jakiś konkretny przykład? jakieś demo, aplikację?
jury napisał/a:Znaczy się, że np jeśli chciałbym skopiować zwykłą bitmapę 32x64 pikseli procesorem i blitterem, to blitter zrobiłby nieporównywalnie ( bo "wielokrotnie" tak rozumiem ) szybciej?
ok, chcemy tylko przekopiować sprite 32x64.
Mój kod, licząc samą pętlę zrobi to w 3072 cylki:
lea Dane(PC),A0
lea Dane+1000(PC),A7
moveq #63,D0
Petla3
move.l (A0)+,(A7)+ ;20 cycles
lea 156(A0),A0 ;8 cycles
lea 156(A7),A7 ;8 cycles
dbra.w D0,Petla3 ;12 cycles
Blitter w 1024 cykle
Jeśli jednak chcemy przesuwać sprite po ekranie to trzeba go rolować. Poniższy kod roluje o 3 pikseli w prawo i zajmuje mu to w 4224 cykli
lea Dane(PC),A0
lea Dane+1000(PC),A7
moveq #63,D0
Petla4
move.l (A0)+,D1 ;12 cycles
ror.l #7,D1 ;24 cycles
move.l D1,(A7)+ ;12 cycles
lea 156(A0),A0 ;8 cycles
lea 156(A7),A7 ;8 cycles
dbra.w D0,Petla4 ;12 cycles
Blitter potrzebuje 1024 cykle
maciekm napisał/a:1) czyścisz ekran na wszystkich 4 bitplanach. jestem w stanie napisać do tego szybki kod CPU: movem na wzystkich rejestrach z ujemnym indeksowaniem oraz z unrollowanym loop'em. To jest już dość szybkie. Blitter będzie szybszy, ale różnica biorąc pod wzgląd, że kodujesz cały efekt a to tylko jakiś element nie będzie znacząca.
blitter czyści lub wypełnia paternem pamięć w tempie jedno słowo na 4 cykle.
Tutaj właśnie widać zaletę blittera vs unrolowany kod. Blitter zrobi to szybciej no i procedura zajmie zaledwie parę bajtów.
maciekm napisał/a:moja osobista opinia ogólna jest taka, że blitter od strony technicznej używa się łatwo i przyjemnie (oprócz paru problemów które napisał Adam), ale cieżko jest znaleźć dla niego zastosowanie praktyczne w efektach. tzn napisać efekt tak by byl z założenia oparty na blitterze i był jako całość 2 razy szybszy niż na CPU. nie mówię, że się nie da (patrz cieniowanie o którym pisał Cyprian), ale jest to trudne. dlatego częściej jest używany imho tylko pomocniczo... (gdzie w Amidze koder dostawał od razu szybkie rysowanie linii, wypełnianie polygonów itp)
czyli nie mowię tutaj o matematycznej różnicy szybkości operacji... a raczej o praktycznych obserwacjach, które ja mam.
Nie znam się na scenowym programowaniu (chyba się zapiszę na lekcje do Ciebie :) ), nie będę się więc wypowiadał na temat konkretnych efektów.
Wiem tylko że blitter nie jest odpowiednikiem np. CPU czy GPU - nie jest uniwersalny. Został zaprojektowany do ściśle określonych prostych zadań. Najważniejsze żeby mieć pomysł jak go wykorzystać.
Co do czyszczenia pamięci, to nie myślałeś wykorzystać do tego blitter i Makra?
Jedno makro inicjujące blitter na początku programu, drugie uruchamiające operację blittera ?
