Bufor Z

[zielok__]

Wektorowka, wektorowka ale nie mam pomyslu jak rozwiazac sprawe bufor\'a Z na c64? Jakies pomysly?

[wegi]

Jezeli chodzi Ci o rysowanie tylko widocznych scian, to sprawdzalo sie po wierzcholkach kierunek jej rysowania - jak w prawo to widoczna, jak w lewo to niewidoczna. Byl jakis wzor - nie pamietam go...

[zielok__]

Usuwanie nie widocznych scian to wiem jak... Chodzi mi o bufor Z czyli ukrywanie czesci nie widocznej (a nie calej sciany)

[Nitro__]

Ogolnie, to mysle, ze trzeba bedzie znacznie improwizowac, prawdziwy z-buffer to bedzie za duzo dla komodorka. W demie Coma Light 10 jest chyba cos, o co Ci chodzi, jesli lubisz patrzenie na kod innych mozesz probowac to skopiowac. Jeszcze chyba w ktoryms Legolandzie, 3? byla czesc z z-bufferem.

[fenek__]

Moze przejrzyj te dema:
Applause
http://noname.c64.org/csdb/release/?id=4019
Oneder
http://noname.c64.org/csdb/release/?id=11692

http://noname.c64.org/csdb/release/?id=36663

http://noname.c64.org/csdb/release/?id=4605
w nich chyba tez cos bylo.
Musialbys sprecyzowac czy chodzi Ci o z-buffer do rozdzielczosci zoom4,
czy do efetktow w multi np. logos fonty 16x16 czy bitmapa.

[Sebaloz]

http://artur.ejsmont.org/blog/content/implementacja-z-buffer-w-c-borland-builder

[zielok__]

Dokladnie chodzi mi o cos takiego (Altered States 50%)



Efekt chcialbym uzyskac na bitmapie i/lub na fontach (16x16). To w zaleznosci od szybkosci jaka osiagne. Wypelniac, eliminowac nie widoczne powierzchnie wiem jak. Z-Bufor w sam sobie tez wiem jak uzyskac tylko na c64 wydajnosc byla by fatalna. A jak widac da sie.

W one-der tez bodajze jeden obiekt ma z-bufer (Applause oczywiscie takze). Powiem szczerze czyjegos kodu nie chce mi sie rozgryzac bardziej chodzi o idee jak to szybko zrobic na c64 (tzn aby bylo wydajne).

Po prostu tak samo jak wypelnianie na c64 jest przez eor\'owanie a opisach dotyczacych pc jest to zazwyczaj inaczej rozwiazywane. z Z-buforem pewnie bedzie tak samo.[/img]

[fenek__]

Nie pamietam jak wyglada caly part z Altered States, ale bazujac na powyzszym obrazku zauwaz ze w danej fazie masz doczynienia z bryla w dwoch kolorach, przy czym jeden kolor jest na sciane widoczna a drugi na sciany (normalnie niewidoczne) to jest to zwykly eor-filled albo inaczej glenz
w ktorym 3 kolor jest taki sam na sciane widoczna.
Rysujesz wszystkie sciany, najpierw niewidoczne potem widoczna.
Przy eorze nastapi blad w kawalkach wspolnych scian niewidoznych i widocznej i wystarczy dla tej kombinacji podmienic kolor na czerwony.

[zielok__]

                   

fenek napisal:

Nie pamietam jak wyglada caly part z Altered States, ale bazujac na powyzszym obrazku zauwaz ze w danej fazie masz doczynienia z bryla w dwoch kolorach, przy czym jeden kolor jest na sciane widoczna a drugi na sciany (normalnie niewidoczne) to jest to zwykly eor-filled albo inaczej glenz w ktorym 3 kolor jest taki sam na sciane widoczna. Rysujesz wszystkie sciany, najpierw niewidoczne potem widoczna. Przy eorze nastapi blad w kawalkach wspolnych scian niewidoznych i widocznej i wystarczy dla tej kombinacji podmienic kolor na czerwony.

O kurna, dobre to:) Kurde jakos nie przyszlo mi to do glowy a tu taki prosty myk. Dzieki.
Bo w Applause to biorac pod uwage speed to chyba bufor z jest chyba po pixelach sprawdzany (aczkolwiek nie wiem:))

[fenek__]

Jezeli interesuje cie wypelniana wektorowka, to pamietam ze podobal
mi sie kolorowy part z obiektem z dziurka bodajze w dentrze
Outbreak/Smash Design.
http://noname.c64.org/csdb/release/?id=11690

Efekt jest krotko pokazywany, wielokolorowy dziurawy szescian na gorze
ekranu.

Tam jest to chyba jeszcze inaczej rozwiazane, aby uzyskac wiecej kolorow scian mozna sciany niewidoczne rysowac na fontach, a widoczne na sprajtach. Dodatkowo ustawic priorytet dla sprajtow jako \"nad grafika\".
Istnieje jeszcze jedna metoda, mozna zrobic 3 warstwy:
logos 12x12:
1 warstwa sprajtow 4 x ilestam w pionie
2 warstwa sprajtow 4 x ilestam w pionie
Tylko tu sa potrzebne proce czyszczenia i eorow na dane warstwy.

[zielok__]

Dzieki Fenek. Genialne w swojej prostocie. Jednak ciagle nie przestawilem sie na commodorowskie myslenie

[smiglo .::.__]

Z-Buffer jest oczywiscie dosyc kosztowny i dlatego nawet na grzybie lepszym rozwiazaniem wydaje sie posortowanie wielokatow po sumie wspolrzednych Z wierzcholkow, i rysowanie scian w kolejnosci od tych polozonych najdalej do najblizszych obserwatorowi. Chyba calkiem dobra realizacja takiego podejscia jest zastosowanie sortowania pozycyjnego - algorytm jest elegancki i wzglednie prosty w implementacji.

Tutaj jakies przykladowe info: http://www.cubic.org/docs/radix.htm

[Nitro__]

Ma to niestety swoje ograniczenia, tam na csdb byl o tym watek i przy statku sie procedura krzaczyla, ale w przypadku prostych obiektow powinno hulac.
Apropo sortowania, to w wielu przypadkach takich jak ten idealnym rozwiazaniem jest tzw. OCEAN sort, z ktorego sam korzystam, nie sortuje on liczb za kazdym razem od nowa, tylko ponownie sortuje istniejaca liste, jesli mamy na niej malo zmian, to sortowanie jest bardzo szybkie.
                   

Cytat:

2.1.5 The \"Ocean\" sorting Named this way because it can be found from many Ocean/Imagine games, like Green Beret or Midnight Resistance. A similar algorithm is also in Dragon Breed. This sort routine is different from all previously mentioned. It uses an order- array that is not resetted each time, therefore each sorting operation is a continuation of the previous and if not much changes have happened (sprites not moving past each other in Y-direction much) it will be very fast as it doesn\'t have to do almost anything. However, there\'s the possibility that on some frame it\'ll eat a lot of time, when there\'s a lot of changes in the sprite order. First, performed only once in the beginning of the program, we need to set an initial state for the sort order array. One choice is all the sprite numbers going from 0 to maximum: for (sprite = 0: sprite < maximum_sprites: sprite++) {   sortorder[sprite] = sprite: } Then the sorting routine. Note one curious thing: What if the amount of sprites onscreen changes, how can the sortroutine deal with it? Obviously, it can\'t, directly. Therefore we must use for example the maximum Y-coordinate value 255 to mark unused sprites: these will fall to the bottom of the sorted list when sorted and cause no trouble (the actual sprite display code can then easily notice the first unused sprite and exit) sprite1 = 0: while (true) {   if (spry[sortorder[sprite1+1]] < spry[sortorder[sprite1]])   {     sprite2 = sprite1:     while (true)     {       swap(sortorder[sprite2], sortorder[sprite2+1]):       if (sprite2 == 0) break:       sprite2--:       if (spry[sortorder[sprite2+1]] >= spry[sortorder[sprite2]]) break:     }   }   sprite1++:   if (sprite1 == maximum_sprites - 1) break: } Here\'s the ASM implementation:       ldx #$00 sortloop:     ldy sortorder+1,x            lda spry,y                 ldy sortorder,x                 cmp spry,y                 bcs sortskip                 stx sortreload+1 sortswap:     lda sortorder+1,x                 sta sortorder,x                 sty sortorder+1,x                 cpx #$00                 beq sortreload                 dex                 ldy sortorder+1,x                 lda spry,y                 ldy sortorder,x                 cmp spry,y                 bcc sortswap sortreload:   ldx #$00 sortskip:     inx                 cpx #MAXSPR-1                 bcc sortloop So, the abovementioned sorting loop produces a sorted index array of the sprites. This array can now be walked through and sprites be copied to the sortsprx, sortspry etc. arrays and rejected if necessary. I really feel this is the overall best algorithm (for game use, at least) I\'ve got to know so far. I\'m definitely going to use this in the future.

[wegi]

zielok - przyznaj sie - ty chcesz na z-buforze gorauda zrobic odalone czesci zaciemniac kolorek:)

[Jacek31]

WOW Z-bufer na C64. Hm.. ciezko moze byc, przynajmniej w klasycznym jego wykonaniu, bo ten mechanizm jest raczej pamieciozerny, a C64 raczej nadmiaru RAMu nie ma. Pewne rozwiazanie przyspieszenia Z-B wymyslila firma ATI i nazwala to Hyper Z-bufer. Ogolnie troche to podobne do tego co proponowal NITRO, czyli nie czyscimy Z_bufa dla nastepnej klatki, tylko niejako, porownujemy go tylko z nowymi wspolrzednymi i modyfikujemy w razie potrzeby. wszystko ladnie pieknie tylko ze przewaznie Z-bufor jest 16-bitowy, a C64 to 8-bitowe dzieciatko, co niestety dociaza niezle proc.
PS. Nie wiem czy nie przydalo by sie tu sprobowac zaimplementowac czegos na niestandardowych instrukcjach 6502, poniewaz niektore w dzialaniu przypominaja cos na wzor MMXa z Pentium (choc tak naprawde te rozwiazanie juz stosowano w 8048 w 1984 roku), czyli mozna dokonywac jednoczesnie operacji logicznej/arytmetycznej i przeslania zawartosci rejestru.