101

(22 odpowiedzi, napisanych Programowanie - 16/32bit)

Cyprian napisał/a:

w międzyczasie wyedytowałem posta:
przemyślałem to jeszcze raz,  w wariancie xCount = 1 może być problem z zastosowaniem EndMask

Hahahhaa :D A ja już się z tobą w międzyczasie zgodziłem. Masek nie rozważałem.

102

(22 odpowiedzi, napisanych Programowanie - 16/32bit)

Cyprian napisał/a:

no tak, ale możesz dać albo:

  xCount = 40 / yCount = 1

albo:

  xCount = 1 / yCount = 40

z tego co pamiętam efekt jest ten sam operacja dokonywana jest na tych samych 40stu słowach.
Oczywiście w zależności od wariantu trzeba odpowiednio ustawić Destination X/Y increment.

Hehehe. A tego to nie wiedziałem. Jak widać zawsze można się czegoś nowego dowiedzieć. :D

Edit: Wystarczy wyjść, stanąć obok i spojrzeć z innej strony. :P Faktycznie wystarczy zmienić x na y i powinno działać.

103

(22 odpowiedzi, napisanych Programowanie - 16/32bit)

Cyprian napisał/a:

faktycznie masz rację z yCount. 
Ale możesz zamienić xCount z yCount (czyli również Destination X increment oraz Destination y increment) dzięki temu xCount będzie tylko raz inicjowany a yCount przed każdym blitem.
Takie rozwiązanie zastosowałem w mojej procedurze dla sprajtów:

;BLiTTER Init
    move.l    #$00020002,(A0)+        ; source X increment / source Y increment
    move.l    A2,(A0)+            ; source address
    move.l    #-1,(A0)+            ; mask 1 /2
    move.w    #-1,(A0)+            ; mask 3
    move.l    #$00080080,(A0)+        ; destination X increment / destination Y increment
    lea        2(A0),A4            ; remember source destination
    move.l    A3,(A0)+            ; destination address
    move.w    #$0005,(A0)+        ; count X surface
    movea.l    A0,A1                ; remember count Y surface
    move.w    D0,(A0)+            ; count Y surface
    move.w    #$0204,(A0)+        ; HOP / LOP
    move.w    D4,(A0)                ; BUSY / HOG / SMUDGE / LINE NUMBER // FXSR / NFSR / SKEW


; Copy MaskSprite to Screen
    move.b    D2,(A0)                ; start blitter

    REPT    3
        lea        2(A3),A3
        move.w    A3,(A4)            ; destination address
        move.w    D0,(A1)            ; count Y surface
        move.b    D2,(A0)            ; start blitter
    ENDR

;
;BLITTER RE-INIT Sprite to Screen
    lea        $FFFF8A3C.w,A0
    move.l    A5,A3
    move.w    #$0207,$FFFF8A3A.w        ; HOP / LOP

; Copy Sprite to Screen
    move.w    A3,(A4)                ; destination address
    move.w    D0,(A1)                ; count Y surface
    move.b    D2,(A0)                ; start blitter

    REPT    3
        lea        2(A3),A3
        move.w    A3,(A4)            ; destination address
        move.w    D0,(A1)            ; count Y surface
        move.b    D2,(A0)            ; start blitter
    ENDR

Pamiętaj Cyprian, że xCount wraz ze wzrostem/skróceniem długości linii zwiększa się lub zmniejsza i trzeba reagować na bieżąco. :) Przy blicie spritea faktycznie można xCounta raz ustawić.
P.S. Piękny kod swoją drogą, wszystko z minimalną ilością cykli. :)

104

(22 odpowiedzi, napisanych Programowanie - 16/32bit)

Cyprian napisał/a:

z tego co widzę to masz parę rejestrów adresowych wolnych.
tak więc, tutaj mógłbyś przypisać każdej masce osobny An i zejść z 24 do 16 cykli:

                    move.w    d0,endmsk1(a6)        ;first line mask
                    move.w    d1,endmsk3(a6)        ;last line mask

tutaj również dedykowany An, dodatkowo nie ma potrzeby zmiany yCount, więc zamiast Longa możesz zapisać Word:

                    move.l    d3,xCount(a6)        ;xcount = d3, ycount = 1 at once

czyli zamiast 16 mamy 8 cykli

tu również dedykowany An:

                    move.b    #$a0,lineNum(a6); HOG   16

zamiast 16 mamy 12 cykle


Czyli z 82 cykli inicjalizacji mógłbyś zejść do 62.

W rzeczywistym kodzie zostaje mi jeden wolny rejestr adresowy :(, a yCount MUSI być inicjalizowany co blitta. Jednak masz rację, że z 8-12 cykli dało by się w tym kodzie jeszcze urwać.

105

(51 odpowiedzi, napisanych Scena - 16/32bit)

Tak, to lightsourcing... Ale całe demko jest świetne...

106

(22 odpowiedzi, napisanych Programowanie - 16/32bit)

Kurcze. Dzisiaj napiszę sobie to wypełnianie na Motoroli. Wydaję mi się, że zbyt optymistycznie podszedłem do samej prędkości blittera. Wyliczenia są raczej dobre, ale chyba warto sprawdzić to (jak pisał MKM) w praktyce.

107

(22 odpowiedzi, napisanych Programowanie - 16/32bit)

mkm napisał/a:

@Wachu no właśnie miałem podobne obserwacje, aż moje face'y miały relatywnie krótkie linie to nie widziałem ogólnie zysku ze scan line fill na bliterze. przy duuuuzych face'a racja zysk będzie dokładnie jak to udowodniłeś.

:D

mkm napisał/a:

@Adam blitterem można wypełniać kilka obiektów na raz ale nie scan line fill'em tylko eor fill'em. technika jest tu inna. no ale wtedy blitter musi czytać i zapisywać dane przez co działa wolniej. ale jest inicjalizowany raz i tak jak mówisz wypełniasz całą scenę "na raz". wszystko ma swoje wady i zalety:) dodatkowo eor fill'em dostajesz bonus wypełniania obiektów niewypukłych.

Macie gdzieś jakieś materiały o tym?

108

(22 odpowiedzi, napisanych Programowanie - 16/32bit)

Adam Klobukowski napisał/a:

Blitterem można wypełnić kilka polygonów na raz, co powoduje że przy bardziej skomplikowanych scenach (więcej niż jedna bryła), praktycznie zawsze będzie wydajniejszy od CPU.

Jestem zaintrygowany... W jaki sposób?

109

(22 odpowiedzi, napisanych Programowanie - 16/32bit)

mkm napisał/a:

Fajnie:) Mam nadzieję, że w przyszłym tygodniu będę miał trochę czasu by zerknąć dokładniej w kod i go przeanalizować. Z tego co widziałem to jest scan line fill, gdzie wyznaczać X1,x2 dla Y'ków i rysujesz H line blitter'em, tak?

Dokładnie tak.. :D

mkm napisał/a:

Ciekawi mnie czy robiłeś porównanie cpu / blitter dla różnych trójkątów? Robiłem podobny eksperyment kiedyś i dla dużych trójkątów było znacznie szybciej blitter'em, ale już przy małych trójkątach (które są bardziej życiowe o obiektach 3d) inicjalizacja blitter'a była bardziej kosztowna niż zysk z jego prędkości ponad cpu i bardziej opłacało mi się używać cpu dla takich sytuacji. Testy był robiony na szybko więc pewnie dało się tą inicjalizację zrobić szybciej i zniwelować efekt. Ciekaw jestem Twoich odczuć i czy robiłeś takie porównania praktyczne? (nie chodzi mi o teoretyczne timingi)

Spróbujemy jednak teoretycznie na początek, ok? :P Nadmiarowy kod dla blittera to:

    asr.w    #3,d3
    move.w    d1,endmsk1(a6)
    move.l    d4,xCount(a6)
    move.b    #$a0,lineNum(a6); HOG

w przypadku linii poniżej 16 pikseli i

    asr.w    #3,d3  ;8+6
    addq.w    #1,d3  ;4
                   
    swap    d3   ;4
    move.w    d5,d3  ;4

    move.w    d0,endmsk1(a6)  ;12
    move.w    d1,endmsk3(a6)  ;12
    move.l    d3,xCount(a6)     ;16
                   
    move.b    #$a0,lineNum(a6); HOG   16

w przypadku linii powyżej 16 pikseli.

Mamy więc 82 cykle na odpalenie blittera.

Na motorli dochodzi wyliczenie skoku do właściwej długości linii i sam skok. Coś takiego:

        move.l    linesAdr(a4,d3.w),a5  ;20
    jmp        (a5)  ; 8

       and.w   d0,d2   ; maski w linii pierwszej wypełniającej   +4
       and.w   d1,d3  ; maski w linii ostatniej wypałniającej     +4

Rejestry są z czapy, chodzi o wyliczenia :)

Odejmując wszystko wychodzi, że inicjalizacja blittera zabiera o 46 cykle więcej, a to jest  w przybliżeniu 4  "move.w d0,i(a6)" - wypełniania na motoroli. To daje 4*16 = 64 piksele. Tyle w najlepszym przypadku zdąży narysować motorola, zanim blitter weźmie się do pracy. Czyli gdzieś po 80-100 blitter dogoni motorolkę.

Zmiana wypełniania z blittera na motorolkę jest w sumie banalna, więc można sobie napisać procedurę i zobaczyć, czy wyliczenia się potwierdzą. :)

Wydaje mi się, że 1-bitplanowe trójkąty wykorzystuje się jednak do wypełniania prostych (i dużych) figur, bo jeśli chcemy mieć skomplikowany obiekt (który prawdopodobnie nie zmieści się jednej ramce), to warto rozważyć użycie wieloplanowego wypełniania, żeby obiekt odpowiednio pokolorować.

110

(51 odpowiedzi, napisanych Scena - 16/32bit)

Dzięki za linka. Pomysł ciekawy, wykonanie niezłe, chociaż na mono taki dither będzie działał szybciej.

111

(51 odpowiedzi, napisanych Scena - 16/32bit)

sqward napisał/a:

W Amoku są goraudy mono.. znaczy na jednym bitplanie.

Muszę sobie w takim razie spojrzeć...

112

(22 odpowiedzi, napisanych Programowanie - 16/32bit)

Zgodnie z obietnicą wrzucam trójkąta na blitterze. Można pokombinować z flagą "blitMode" - 0 oznacza tryb HOG, 1 - tryb współdzielenia szyny (dzięki sprytnemu restartowaniu blittera i tak mamy 90% szybkości trybu HOG). Wypełnienie trójkąta o współrzędnych 0,0 -> 319,199 -> 0,199 zajmuje około 30% czasu ramki.

113

(51 odpowiedzi, napisanych Scena - 16/32bit)

Cyprian napisał/a:
Tomasz Wachowiak napisał/a:

Może gouraud pod mono? Chyba jeszcze nikt tego nie zrobił? :P Kiedyś napisałem sobie na PieCa całkiem fajną procedurę do ditheringu. Można by ją przenieść na mono STeka. :)

w Mono? Brzmi ciekawie.
Ditherowany gouraud widziałem tylko w ST-LOW w demie: http://www.pouet.net/prod.php?which=19628 i w grze Interphase: https://www.youtube.com/watch?v=DtUfQEp8lNQ&feature=player_detailpage#t=16

To pierwsze zrobił Martin Griffiths, źródła są dostępne w sieci. Jakby co to je mam.

To zdecydowanie najlepsze gouraudy na STeka. Źródłami jestem jak najbardziej zainteresowany :D

114

(12 odpowiedzi, napisanych Scena - 16/32bit)

skrzyp napisał/a:
Tomasz Wachowiak napisał/a:

Niech w jakąś chmurę wrzuci

Od kiedy to dowolny serwer plików używający proto HTTP nazywa się chmurą? ;_;

Hehehheh. Bo to teraz takie trendy jest... :P

115

(137 odpowiedzi, napisanych Scena - 16/32bit)

Pod względem kodu naprawdę wysoko demko poleciało. A jeśli chodzi o muzę, to powiedzenie "De gustibus not disputandum est" będzie zdecydowanie najlepsze. :)

116

(12 odpowiedzi, napisanych Scena - 16/32bit)

skrzyp napisał/a:

Pan mono (czy tam stereo), może wystawić po FTP/SFTP/HTTP/NFS/RSync/cokolwiek, po czym ja ściągnę do siebie na VPS, skompresuję .xz'em i jakoś to dopcham do siebie ;)

Niech w jakąś chmurę wrzuci i da linka... :P Też jestem chętny. :)

117

(98 odpowiedzi, napisanych Scena - 16/32bit)

No właśnie - bez trolowania. :) Panowie. Zaczyna mi się marzyć polskie demko A.D. 2015... :)

118

(51 odpowiedzi, napisanych Scena - 16/32bit)

Może gouraud pod mono? Chyba jeszcze nikt tego nie zrobił? :P Kiedyś napisałem sobie na PieCa całkiem fajną procedurę do ditheringu. Można by ją przenieść na mono STeka. :)

119

(3 odpowiedzi, napisanych Programowanie - 16/32bit)

Cyprian napisał/a:

tak na szybko, to mi nie działa:

cmp.b    #$1d,$fffffc02.w

jak zamienię to na klawisz "1" to działa ok:

cmp.b    #$02,$fffffc02.w

poza tym niezły kod, właśnie w go wgryzam

Pewno pod emulatorem działasz - też tak miałem i musiałem ustawienia joysticka zmienić, bo "fire" pod Ctrl był. :D
Jutro albo pojutrze wrzucę fillera 1-planowego pod blittera - muszę tylko część wypełniającą zmienić. Do takich rzeczy blitter nadaje się znakomicie. :)

120

(3 odpowiedzi, napisanych Programowanie - 16/32bit)

Poprawiam się i źródła wrzucam do właściwego działu. :)

121

(51 odpowiedzi, napisanych Scena - 16/32bit)

AS... napisał/a:

Tomek,
pooglądaj produkcje Dhs-ów.
Szczególnie Drone:
https://www.youtube.com/watch?v=nM3EQSzQg_E

Oni zawsze się wyróżniali. Świetny design, świetny kod. Może wspólnymi siłami udałoby się coś chociaż w połowie tak dobrego zrobić?

122

(51 odpowiedzi, napisanych Scena - 16/32bit)

erOS napisał/a:

Witamy syna marnotrawnego ;)

Wachu,
QuaST'96 z Insomią (no i Asskickerem na 8bit) moje pierwsze party.
Fajno, że stara gwardia odczuwa nostalgię, powraca i jeszcze
przypomina sobie ASMa na ST. W grudniu 2014 interko wypuścił Acid Maker.
Inny koder, który gdzieś w 1997 przeszedł na scene PC niedawno stwierdzil,
że z ASMem na ST jest jak z jazdą na rowerze ;)
ale w Polsce obecnie jest stosunkowo mało ludzi piszących dema,
jak już tu inni wspominali pewnie są to tylko: MKM, Sqward i Bober.

Przez te 2 dekady trochę się działo... i trochę się zmieniły gusta i efekty
paralaxy, usunięte ramki, scrolle itd raczej to już typowy "old skool" ;)

Niektóre dema designem i kodem zabijają. Acid tradycyjnie w świetnej formie. :D Kurde, to może ja zrobię interko "Lots of polys"? :P
Podsyłam obiecaną procedurę na 4-bitplanowego fillera. Biorąc pod uwagę, że proste wymazanie ekranu na 4 bitplanach zajmuje około 40%, to mój trójkąt na cały ekran w jednej ramce też nie prezentuje się nie najgorzej :) Filler maskuje wszystkie plany, więc wyrysowanie trójkąta w jednym kolorze na drugim nie spowoduje dziwnych efektów kolorystycznych. Dopisałem sporo komentarzy w kodzie, więc łatwo będzie można całość łyknąć.
Pozdrawiam

123

(51 odpowiedzi, napisanych Scena - 16/32bit)

erOS napisał/a:

Witamy syna marnotrawnego ;)

Wachu,
QuaST'96 z Insomią (no i Asskickerem na 8bit) moje pierwsze party.
Fajno, że stara gwardia odczuwa nostalgię, powraca i jeszcze
przypomina sobie ASMa na ST. W grudniu 2014 interko wypuścił Acid Maker.
Inny koder, który gdzieś w 1997 przeszedł na scene PC niedawno stwierdzil,
że z ASMem na ST jest jak z jazdą na rowerze ;)
ale w Polsce obecnie jest stosunkowo mało ludzi piszących dema,
jak już tu inni wspominali pewnie są to tylko: MKM, Sqward i Bober.

Przez te 2 dekady trochę się działo... i trochę się zmieniły gusta i efekty
paralaxy, usunięte ramki, scrolle itd raczej to już typowy "old skool" ;)

Niektóre dema designem i kodem zabijają. Acid tradycyjnie w świetnej formie. :D Kurde, to może ja zrobię interko "Lots of polys"? :P
Podsyłam obiecaną procedurę na 4-bitplanowego fillera. Biorąc pod uwagę, że proste wymazanie ekranu na 4 bitplanach zajmuje około 40%, to mój trójkąt na cały ekran w jednej ramce też nie prezentuje się nie najgorzej :) Filler maskuje wszystkie plany, więc wyrysowanie trójkąta w jednym kolorze na drugim nie spowoduje dziwnych efektów kolorystycznych. Dopisałem sporo komentarzy w kodzie, więc łatwo będzie można całość łyknąć.
Pozdrawiam

124

(51 odpowiedzi, napisanych Scena - 16/32bit)

skrzyp napisał/a:
Tomasz Wachowiak napisał/a:

(bo młodych, to już chyba nie ma, prawda? :P)

Uprzejmie pragnę się nie zgodzić… :>

Dobra nasza. Rośnie nam atarowski narybek... :D

125

(51 odpowiedzi, napisanych Scena - 16/32bit)

Bober napisał/a:

Witamy :).
A ile RAMu tablice zajmują?
I czy są jakieś ograniczenia?
Odnośnie społeczności ST - więcej się dzieje na zachodzie. Trochę fajnych rozmów toczy się na IRCu - kanał #atariscne.

Dwie tablice po 64 kilo. Punkty ograniczone w wartościach od -64 do 64.