Fajnie :) Czytam sobie o tych efektach ale prędzej napiszę demo na PLC/PAC lub DCSa niż Atari ;)
SIUP (SIo2Usb2Pc) - SIO2PC USB Edition
PIN ready logo
3M / InD: ... na kasetach były zabezpieczenia w postaci tzw. "mikropierdnięcie" ...
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
atari.area forum » Programowanie - 8 bit » demo effects
Strony Poprzednia 1 2 3 4 5 6 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
Fajnie :) Czytam sobie o tych efektach ale prędzej napiszę demo na PLC/PAC lub DCSa niż Atari ;)
Demo na PLC :D
Ciekawe mogło by być - Hardware'owe :D
Odgłosy styczników + lampki sygnalizacyjne ;)
Kiedyś napisałem Ponga, dwa enkodery i całość zwizualizowana na ledach karty z 32 inputami :)
Aha... nie w żadnym FBD, ST, IL czy innym badziewiu ;) tylko w zwyczajnej drabince :)
Można na HMI, ale komu by się chciało ;)
sprawdziłem możliwość optymalizacji tego chess zoomrotatora, tzn. dla bloków piksli 4x8 (odpowiednik znaku Atari) powstaje za dużo kombinacji poza pojemnością zestawu znakowego, podobnie dla bloków 4x4, natomiast dla 2x4 (ćwiartka znaku) jest lepiej ale i tak za dużo bo liczba niepowtarzalnych bloków dochodzi do 164
dla bloku 2x2 piksle powstaje stała liczba kombinacji 16, niezależnie czy mamy 64 fazy obrotu dla danej skali powiększenia czy 128 liczba niepowtarzalnych bloków jest stała =16
00,00,00,00
00,00,00,FF
00,00,FF,00
00,00,FF,FF
00,FF,00,00
00,FF,00,FF
00,FF,FF,00
00,FF,FF,FF
FF,00,00,00
FF,00,00,FF
FF,00,FF,00
FF,00,FF,FF
FF,FF,00,00
FF,FF,00,FF
FF,FF,FF,00
FF,FF,FF,FF
innymi słowy dla 64 faz obrotu o zadanej skali powiększenia dla każdego bloku obrazu o rozmiarze 2x2 piksle istnieje 64 bajtowa tablica z informacją o 16 różnych kombinacjach bloków
Przemyślałem sprawę jeszcze raz i oto do czego doszedłem
Pisze o konkretnym przypadku przytoczonym przez gorgh'a. Jest tam użyty tryb antica 7 (graphics 2) 20 znaków w linii 8x8 pixli podwójnej wysokości. Ekran mieści się w 2 zestawach znaków, ale pisane jest po zestawie znaków jako pamięci ekranu.
Spójrzmy na to tak, że tak powiem od dupy strony:
Nie optymalizować algorytmu, tylko wykorzystać właściwości sprzętu i szachownicy.
Obracamy kwadrat.
Kwadrat po obrocie o 90 stopni ... jest takim samym kwadratem. Wiec z 64 faz obrotu zostaje już tylko 16.
Zamiast obracać kwadrat obróćmy teraz jego boki przedłużone w nieskończoność, i okazuje się że mamy już prawie szachownicę. Wystarczy teraz proste powielić ... i mamy kratownicę (prawie szachownicę). Trzeba ją tylko pokolorować.
Idąc dalej, aby narysować KRATOWNICĘ, wystarczy obliczyć, korzystając ze skali i kąta obrotu odległość w poziomie i pionie pomiędzy kolejnymi liniami. (podstawy trygonometrii z liecum) i narysować rzędy równoległych linii.
Teraz trzeba wykorzystać trochę szachownicę.
Jakakolwiek linia dzieląca pola szachownicy, w bitowym odwzorowaniu ekranu w zakresie 1 bajtu, ma po jednej stronie same zera a po drugiej same jedynki lub odwrotnie.
Czyli jest całe 8 możliwych wartości (0b00000000, 0b00000001, 0b00000011, 0b00000111, 0b00001111, 0b00011111, 0b00111111, 0b01111111, 0b11111111) i drugie 8 w drugą stronę najzwyczajniej w świecie zanegowane wszystkie bity.
Ustawiając te patterny w odpowiedniej kolejności można uzyskać linie nachylone pod każdym kątem.
Extremalny przypadek, węzeł czy jak to nawać miejsce gdzie spotykają się 2 linie (Pamiętając że jest to szachownica). w najgorszym przypadku, będzie to coś w rodzaju 0b00111000 co jest niezwykle łatwe do obliczenia.
2 linie:
pierwsza linia 0b00111111
druga linia 0b00000111
------------
eor na bitach: 0b00111000
Nie ma możliwości, przy założeniu że linie nie zbliżą się do siebie na mniejszą odległość niż jakieś 9 pixli w poziomie aby w 1 bajcie pamięci ekranu pojawiła się inna wartość niż zera-jedynki-zera, jedynki-zera, zera, lub ich negacja.
Idąc dalej, wszystko sprowadza się do nałożenia na siebie i eor'owania 2 pasów śćiśle ze sobą powiązanych. (nachylonych względem siebie o 90 stopni)
Przykład dla zobrazowania bo sam się zamotałem nieco:
1 pas
. . . . . . . o
. . . . . . o o
. . . . . . o o
. . . . . o o o
. . . . . o o o
. . . . o o o o
. . . . o o o o
. . . o o o o o
2 pas (zawsze obrócony o 90 stopi wzgeldem 1 szego)
. . . . . . . .
. . . . . . . .
o . . . . . . .
o o o . . . . .
o o o o o . . .
o o o o o o o .
o o o o o o o o
o o o o o o o o
Wynik eorowania:
. . . . . . . o
. . . . . . o o
o . . . . . o o
o o o . . o o o
o o o o o o o o
o o o o . . . o
o o o o . . . .
o o o . . . . .
Korzystając z gotowych patternów linii nachylonych pod jednym z 16 kątów + eor'owanie ich można uzyskać efekt operując na bajtach nie na pixelach.
Nie analizowałem jak program działa, przyjrzałęm się tylko zgrubnie że działanie polega na kopiowaniu patternów i ich wzajemnym eorowaniu. Resztę wymyśliłem w trakcie pisania.
Zamieniając patterny na patterny z ustawionym tylko 1 bitem, oraz eor na or, powinno się dać uzyskać efekt 'kartki w kratkę'.
Zmieniająć 1 bajt w powyższym demie z $ff na $01 w generatorze patternów uzyskałem rządany efekt :) No prawie :D ale idee widać. Potwierdza to trafność metody.
Co ciekawe generator paternów generuje 8 bajtów danych, korzystając z 11 bajtów kodu.
Qrde może dema zaczne pisać :D
Whisky wyszła czas iść spać.
Pozdrawiam
Willy.
całkiem sensowne, zobaczę jak "rysuje" się takimi eor-owanymi patternami
dodam też że istnieje kolejna możliwość optymalilzacji ze względu na symetryczność górnej i dolnej części szachownicy, dolną cześć trzeba przekopiować "wspak" względem górnej, czyli wyrysowanie szachownicy sprowadza się tylko do połowy obrazu
for j = 0 to height div 2 - 1
for i = 0 to width - 1
Pixels[width-i-1,height-j-1] := Pixels[i,j]
next i
next j
I taki nie.
Ten algorytm uwzględnia symetrię względem punktu leżącego na środku ekranu. W przypadku szachownicy takich punktów symetrii jest znacznie więcej. Teoretycznie jest to każdy róg kwadratu. Praktycznie zastosowanie tego do obrazów w wysokiej rozdzielczości da dość dobry efekt. Przy 8 bitowej grafice obraz będzie zauważalnie powtażalny i nienaturalny.
Ponadto złożoność obliczeniowa takiego algorytmu w przypadku 8bit jest zbyt duża .. trzeba to pixel po pixelu robić, lub obracając szachownicę trzymać się tego aby 'centrum symetrii' lezało przynajmniej na granicy 8 pixli w poziomie, aby na bajtach można było operować. Ale tu znowu efekt będzie nienaturalny i trzeba będzie odwracać kolejność bitów.
W końcowym rozrachunku okaże się że na 8bit opłaci się narysować cały ekran korzystając z opisanej powyżej metody niż cokolwiek kopiować
BTW, zmieniłem jeszcze jeden bajt z $ff na 0 aby wyłączyć wypełnianie i w efekcie otrzymałem zwykłą kratkę. Efekt w załączniku.
kopiowanie w pionie zrealizuje program Antic-a, w poziomie jedna tablica w stylu
ldx bajt_obrazu,y
lda tablica_wspak,x
sta bajt_obrazu+height/2,y
o zmaganiach w odkrywaniu rotowanej szachownicy :)
http://csdb.dk/forums/index.php?roomid= … irstpost=2
I to jest to :)
dorzuciłem cytat z Barymag-a #2 na temat ZOOM SCROLLA, jest to opis metody realizacji tego efektu
http://www.pouet.net/prod.php?which=17682
źródła dla C64 (ca65) chessboard zoomer, w 256 bajtach
nowa strona ze źródłami wielu starych efektów
http://insolitdust.sourceforge.net/code.html
przykład realizacji KEFRENSBAR
http://madteam.atari8.info/index.php?prod=fx#kefrensbar
Robi się coraz bardziej zachęcająco :) Super !
uaktualniony CHESS ZOOMROTATOR, zamiast testu kolejnych zakresów wystarczy operacja 'and $10' lub 'and 8' itp.
http://madteam.atari8.info/index.php?prod=fx#chzoom
szybki BLUR, poniżej link do opisu kilku szybkich metod blurowania
http://www.gamasutra.com/view/feature/3 … ng_in_.php
na Atari można szybciej jeśli rozdzielimy nasz efekt na dwa bufory których wartości będziemy uśredniać
w pierwszym przebiegu wypełniamy bufor1, następnie blur bufor1 = (bufor1 + bufor2) / 2, wyświetlamy bufor2
w drugim przebiegu wypełniamy bufor2, następnie blur bufor2 = (bufor1 + bufor2) / 2, wyświetlamy bufor1
dwie operacje dodawania 'bufor1 + bufor2' to najszybciej jak się da, zamiast '/2' najlepiej stworzyć tablicę z przeliczonymi wartościami 0..255 * jakiś ułamek typu 0.457
sposób w dwoma buforami jest zdecydowanie szybszy niż uśrednianie wartości wokół piksla
twister, w kilku wersjach
http://social.msdn.microsoft.com/Forums … mall-basic
spora ilość źródeł efektów graficznych w QBasic-u
http://www.ocf.berkeley.edu/~horie/project2.html
zbiór przydatnych algorytmów, przykłady m.in. w Pascalu i jakimś Basicu
http://edu.i-lo.tarnow.pl/inf/alg/001_search/
zauważyłem w różnych przykładach że dla uzyskania przesuwu poziomego scrolla sugeruje się przestawienie bajtów w takim buforze, w stylu
.rept 48
lda bufor+1+#
sta bufor+#
.endr
jeśli takich wierszy byłoby więcej, tracimy tylko czas CPU, a przecież można oszczędzić czas kosztem pamięci (2 strony na linię/wiersz), stosując taki RING BUFFER (http://en.wikipedia.org/wiki/Circular_buffer)
zapis naszego znaku, lub kolumny znaków dokonujemy na końcu i początku bufora linii/wiersza, wartość rejestru X to młodszy bajt adresu wyświetlanej linii/wiersza, którą zwiększamy o 1 i o nic więcej nie musimy dbać, samo się zrobi
sta bufor+SCREEN_WIDTH,x
sta bufor+SCREEN_WIDTH-256,x
innymi słowy jest to okno szerokości SCREEN_WIDTH które przesuwamy w obszarze -$ff..$ff
jeśli zadbamy o przekręcanie się licznika na końcu strony i odpowiednio zapiszemy znak początkowy/końcowy to powinno udać się zejść do 1 strony pamięci na linię/wiersz
poniżej przykład niekończącego się scrolla dla bufora korzystającego z dwóch stron pamięci
org $600
dlist dta $70,$70,$70 ; 24 puste linie ($70 = 8 pustych linii)
dta $42|$10 ; rozkaz ANTIC-a LMS ($42) dla trybu $02 + $10 dla HSCROL
adres dta a(text) ; adres scrolla
dta $41,a(dlist) ; zakończenie programu ANTIC-a
main mwa #dlist 560 ; ustawiamy nowy adres programu ANTIC-a
loop
lda tmp ; płynny scroll, przepisanie wartości TMP do rejestru HSCROL
sta hscrol ; koniecznie przed poniższą pętlą opóźniającą
lda:cmp:req 20
dec tmp ; zmniejszenie komórki TMP [3,2,1,0]
bpl loop ; pętla
mva #3 tmp ; odnowienie wartości komórki TMP
inc adres ; scroll zgrubny
ldx adres
lda scroll
ascrol equ *-2
sta text+48,x
sta text+48-256,x
inw ascrol
cpw ascrol #end_scroll
scc
mwa #scroll ascrol
jmp loop
tmp dta 3 ; pomocnicza komórka pamięci TMP
scroll dta d'to jest tekst przykladowy, scrolla z buforem ulegajacemu zapetleniu'
end_scroll
org $a000
text :48 dta d' '
run main ; adres uruchomienia tego przykładu
Hej!
Prawdę mówiąc sądziłem że ta metoda (bufor pierścieniowy) jest powszechnie stosowana... większość scroll-i w produkcjach Code3 czy Slight jest realizowana tą metodą, nie ma żadnego przepisywania... tylko zapis w dwa miejsca bufora, i zmiana adresu w DL.
Szkoda czasu CPU na przepisywanie ton znaków w pamięci RAM, szczególnie wtedy gdy "logo scroll" jest duży, albo ten czas trzeba poświęcić na coś innego... ( http://a8.fandal.cz/detail.php?files_id=970 ) To jedyna słuszna metoda w/g mnie.
Na ten sposób wykonania scrolla naprowadził mnie kiedyś SoTe, po sprawdzeniu oczywiście okazało się ze to działa doskonale.
Bufory w przypadku naszych scrolli były różne od 128 bajtów do 256 bajtów w zależności od rodzaju scrolla.
Napisalem w zyciu moze ze 2 skrole wiec nie jestem godzien :) , ale nigdy nie przepisywalem znakow, zawsze korzystalem z tej metody - tylko wtedy nie wiedzialem ze to sie nazywa ring buffer :)
Oj... ileż to ja się RAM-u "naprzepisywałem" w początkowej fazie nauki kodowania :D ileż to czasu CPU zmarnowałem na przepisywanie tych ton bajtów we wszelakich logo-scrollach :D dopiero jak poznałem SoTe to bardzo szybko mnie uświadomił że jest inna metoda :D
Moja nauka w tamtych czasach polegała na podglądaniu jak to zrobili inni... uwierz mi... 90% produkcji z logo scroll-ami przepisuje jak tylko może gdy HSCROLL osiągnie wartość końcową :-)
osobiście też najczęściej stosowałem tą "złą" metodę obciążającą CPU, i nadal stosują ją inni, np. strona z przykładami efektów dla C64, etykieta MOVE0
http://codebase64.org/doku.php?id=base: … ng_message
Strony Poprzednia 1 2 3 4 5 6 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Programowanie - 8 bit » demo effects
Wygenerowano w 0.066 sekund, wykonano 28 zapytań