51

Fajnie :) Czytam sobie o tych efektach ale prędzej napiszę demo na PLC/PAC lub DCSa niż Atari ;)

STYMulator JIL ST YM2149 mjuz:k @ gnu/linux
SIUP (SIo2Usb2Pc) - SIO2PC USB Edition
PIN ready logo
3M / InD: ... na kasetach były zabezpieczenia w postaci tzw. "mikropierdnięcie" ...

52

Demo na PLC :D
Ciekawe mogło by być - Hardware'owe :D

"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

53 Ostatnio edytowany przez grzeniu (2013-04-13 21:36:00)

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

STYMulator JIL ST YM2149 mjuz:k @ gnu/linux
SIUP (SIo2Usb2Pc) - SIO2PC USB Edition
PIN ready logo
3M / InD: ... na kasetach były zabezpieczenia w postaci tzw. "mikropierdnięcie" ...

54

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

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

55

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.

Post's attachments

kratka_.png 5.9 kb, nikt jeszcze nie pobierał tego pliku. 

Tylko zalogowani mogą pobierać załączniki.
"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

56

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
*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

57

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.

Post's attachments

kratownica_.png 5.31 kb, nikt jeszcze nie pobierał tego pliku. 

Tylko zalogowani mogą pobierać załączniki.
"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

58

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
*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

59

o zmaganiach w odkrywaniu rotowanej szachownicy :)

http://csdb.dk/forums/index.php?roomid= … irstpost=2

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

60

I to jest to :)

"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

61

dorzuciłem cytat z Barymag-a #2 na temat ZOOM SCROLLA, jest to opis metody realizacji tego efektu

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

62

http://www.pouet.net/prod.php?which=17682

źródła dla C64 (ca65) chessboard zoomer, w 256 bajtach

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

63

nowa strona ze źródłami wielu starych efektów

http://insolitdust.sourceforge.net/code.html

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

64

przykład realizacji KEFRENSBAR

http://madteam.atari8.info/index.php?prod=fx#kefrensbar

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

65

Robi się coraz bardziej zachęcająco :) Super !

STYMulator JIL ST YM2149 mjuz:k @ gnu/linux
SIUP (SIo2Usb2Pc) - SIO2PC USB Edition
PIN ready logo
3M / InD: ... na kasetach były zabezpieczenia w postaci tzw. "mikropierdnięcie" ...

66

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

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

67 Ostatnio edytowany przez tebe (2013-08-25 19:03:00)

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

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

68

twister, w kilku wersjach

http://social.msdn.microsoft.com/Forums … mall-basic

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

69

spora ilość źródeł efektów graficznych w QBasic-u

http://www.ocf.berkeley.edu/~horie/project2.html

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

70

zbiór przydatnych algorytmów, przykłady m.in. w Pascalu i jakimś Basicu

http://edu.i-lo.tarnow.pl/inf/alg/001_search/

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

71 Ostatnio edytowany przez tebe (2015-01-04 15:49:41)

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
*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

72 Ostatnio edytowany przez seban (2015-01-04 16:51:53)

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.

73

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

"Was powinny uzbrojone służby wyciągać z domów do punktów szczepień, a potem zamykać do pi* za rozpowszechnianie zagrożenia epidemicznego" - Epi 2021
"Powinno się pałować tylko tych co tego nie rozumieją. No i nie szmatki i nie chirurgiczne tylko min FFP3, to by miało jakiś sens. U mnie we firmie, to jak przychodzi bezmaskowiec, to stoi w deszczu przed firmą" - Pin 2021

74 Ostatnio edytowany przez seban (2015-01-04 17:04:58)

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ą :-)

75

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

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C