c64scene.pl

fenek pisze: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.

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.

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

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