Bufor Z

[zielok]

Wektorowka, wektorówką ale nie mam pomysłu jak rozwiązać sprawę bufor'a Z na c64? Jakieś pomysły?

[wegi]

Jeżeli chodzi Ci o rysowanie tylko widocznych ścian, to sprawdzało się po wierzchołkach kierunek jej rysowania - jak w prawo to widoczna, jak w lewo to niewidoczna. Był jakiś wzór - nie pamiętam go...

[zielok]

Usuwanie nie widocznych ścian to wiem jak... Chodzi mi o bufor Z czyli ukrywanie części nie widocznej (a nie całej ściany)

[Nitro]

Ogólnie, to myślę, że trzeba będzie znacznie improwizować, prawdziwy z-buffer to będzie za dużo dla komodorka. W demie Coma Light 10 jest chyba coś, o co Ci chodzi, jeśli lubisz patrzenie na kod innych możesz próbować to skopiować. Jeszcze chyba w którymś Legolandzie, 3? była część z z-bufferem.

[fenek]

Może 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 też coś było.
Musiałbyś sprecyzować czy chodzi Ci o z-buffer do rozdzielczości zoom4,
czy do efetktów w multi np. logos fonty 16x16 czy bitmapa.

[Sebaloz/Lepsi.De]

http://artur.ejsmont.org/blog/content/i ... nd-builder

[zielok]

Dokładnie chodzi mi o coś takiego (Altered States 50%)



Efekt chciałbym uzyskać na bitmapie i/lub na fontach (16x16). To w zależności od szybkości jaka osiągnę. Wypełniać, eliminować nie widoczne powierzchnie wiem jak. Z-Bufor w sam sobie tez wiem jak uzyskać tylko na c64 wydajność była by fatalna. A jak widać da się.

W one-der też bodajże jeden obiekt ma z-bufer (Applause oczywiście także). Powiem szczerze czyjegos kodu nie chce mi się rozgryzać bardziej chodzi o idee jak to szybko zrobić na c64 (tzn aby było wydajne).

Po prostu tak samo jak wypełnianie na c64 jest przez eor'owanie a opisach dotyczących pc jest to zazwyczaj inaczej rozwiązywane. z Z-buforem pewnie będzie tak samo.[/img]

[fenek]

Nie pamiętam jak wygląda cały part z Altered States, ale bazując na powyższym obrazku zauważ że 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]

Nie pamiętam jak wygląda cały part z Altered States, ale bazując na powyższym obrazku zauważ że 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 jakoś nie przyszło mi to do głowy a tu taki prosty myk. Dzięki.
Bo w Applause to biorąc pod uwagę speed to chyba bufor z jest chyba po pixelach sprawdzany (aczkolwiek nie wiem:))

[fenek]

Jeżeli interesuje cię wypełniana wektorówka, to pamiętam że podobał
mi się kolorowy part z obiektem z dziurką bodajże 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]

Dzięki Fenek. Genialne w swojej prostocie. Jednak ciągle nie przestawiłem sie na commodorowskie myślenie

[śmigło .::.]

Z-Buffer jest oczywiście dosyć kosztowny i dlatego nawet na grzybie lepszym rozwiązaniem wydaje się posortowanie wielokątów po sumie współrzędnych Z wierzchołków, i rysowanie ścian w kolejności od tych położonych najdalej do najbliższych obserwatorowi. Chyba całkiem dobrą realizacją takiego podejścia jest zastosowanie sortowania pozycyjnego - algorytm jest elegancki i względnie prosty w implementacji.

Tutaj jakieś przykładowe info: http://www.cubic.org/docs/radix.htm

[Nitro]

Ma to niestety swoje ograniczenia, tam na csdb był o tym wątek i przy statku się procedura krzaczyła, ale w przypadku prostych obiektów powinno hulać.
Apropo sortowania, to w wielu przypadkach takich jak ten idealnym rozwiązaniem jest tzw. OCEAN sort, z którego sam korzystam, nie sortuje on liczb za każdym razem od nowa, tylko ponownie sortuje istniejącą listę, jeśli mamy na niej mało zmian, to sortowanie jest bardzo szybkie.

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 się - ty chcesz na z-buforze gorauda zrobić odalone części zaciemniać kolorek:)

[Jacek31]

WOW Z-bufer na C64. Hm.. ciężko może być, przynajmniej w klasycznym jego wykonaniu, bo ten mechanizm jest raczej pamięciożerny, a C64 raczej nadmiaru RAMu nie ma. Pewne rozwiązanie przyśpieszenia Z-B wymyśliła firma ATI i nazwała to Hyper Z-bufer. Ogólnie trochę to podobne do tego co proponował NITRO, czyli nie czyścimy Z_bufa dla następnej klatki, tylko niejako, porównujemy go tylko z nowymi współrzędnymi i modyfikujemy w razie potrzeby. wszystko ładnie pięknie tylko że przeważnie Z-bufor jest 16-bitowy, a C64 to 8-bitowe dzieciątko, co niestety dociąża nieźle proc.
PS. Nie wiem czy nie przydało by się tu spróbować zaimplementować czegoś na niestandardowych instrukcjach 6502, ponieważ niektóre w działaniu przypominają coś na wzór MMXa z Pentium (choć tak naprawdę te rozwiązanie już stosowano w 8048 w 1984 roku), czyli można dokonywać jednocześnie operacji logicznej/arytmetycznej i przesłania zawartości rejestru.

[k.]

to głębokie...

[wackee]

Bo w Applause to biorąc pod uwagę speed to chyba bufor z jest chyba po pixelach sprawdzany (aczkolwiek nie wiem:))

Czy mam wykonać kontrolny telefon do kolegi Browara?

[snerg]

Też mnie to ciekawi więc może wyślij tam człowieka

[Jacek31]

Szkoda że kolega zielok nie napisze konkretnie co chce zrobić ? Mnie co prawda temat interesuje pod nieco innym kontem niż samo C64, bo ja akurat kombinuję nad algorytmami dla ATMegi 162 (16KB FLASH i 1 KB RAM+ 32KB ERAM, 8 MHz) i LCD z N3510, więc mam ok 10x szybszy proc, ale zasoby pamięciowe równie marne jak w C64, jeżeli nie marniejsze (RAM). natomiast taki tradycyjny Z-Buf to raczej algorytm porównywania osi Z, powiązany z mechanizmem nakładania tekstur, niż algorytm sortujący. Więc metoda sortowania jako alternatywny Z-Buf tez mnie interesuje.

[zielok]

Szkoda że kolega zielok nie napisze konkretnie co chce zrobić ?

Ja się tylko tak z ciekawości interesowałem. Nie mam w planach nic z tym zrobić. OT zastanowiło mnie to od strony teoretycznej gdyż nie potrafiłem wpaść na to jak został ten bufor z osiągnięty.