1

Pytanie do koderow:

czy wykorzystywales ten algorytm do rysowania odcinkow. jesli tak to gdzie.

nie interesuje mnie uzywanie algorytmu do wypelniania lub teksturowania, tylko rysowanie odcinkow.

prosze niekoderow o nie podawanie przykladow ze stawianiem punktow EORem. b.pliz.

http://atari.pl/hsc/ad.php?i=1.

2

Drunk Chessboard

https://www.youtube.com/watch?v=jofNR_WkoCE

3

http://www.atari.org.pl/forum/viewtopic … 30&p=5

jest przykład polygon, gdzie jest procka wypełniania linii bajtami

w MadPascalu są procedury HLine, w module GRAPHICS (tryb Hires), moduł FASTGRAPH (tryby kolorowe)

Bart Jaszcz w produkcji Fake Rotation też używa HLine

Post's attachments

Fake_Rotation.zip 32.89 kb, liczba pobrań: 7 (od 2019-09-30) 

Tylko zalogowani mogą pobierać załączniki.
*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

4

dzieki. dobre :-)


mi chodzilo o ten algorytm:

Neat-o Enhanced Chunky Line Drawing Routine
-------------------------------------------

        First we need to be in the right mindframe.  Let's say you're
drawing a line where you move three pixels in x before it's time to take
a step in y.  Instead of plotting all three pixels it would of course
be much more efficient to just stick a number like %00011100 in the
drawing buffer.  But somehow we need to keep track of a) how large the
chunk needs to be, and b) where exactly the chunk is.
        In the above example, we started at a particular x-value:

        %00010000

and we want to keep adding ones to the right of the starting point; three,
to be exact.  Hmmm... we need to somehow rotate the starting bit in a way
that leaves a trail of ones behind it.  Maybe rotate and ORA with the
original bit?  But what happens when you take a step in Y?
        No, we need something far sneakier.  Let's say that instead of
%00010000 we start with

        x = %00011111

Now, with each step in the x direction, we do an arithmetic shift on x.  So
after one step we have

        x = %00001111

and after two steps

        x = %00000111

and at the third step of course

        x = %00000011

Now it is time to take a step in Y.  But now look: if we EOR x with its

original value xold = %00011111, we get

        x EOR xold = %00011100

which is exactly the chunk we wanted.  Moreover, x still remembers where it
is, so we don't have to do anything special each time a step is taken in
the y-direction.

        So here is the algorithm for drawing a line in the x-direction:

        initialize x, dx, etc.
        xold = x
        take a step in x: LSR X
        have we hit the end of a column?  If so, then plot and check on y
        is it time to take a step in y?
        if not, take another step in x
        if it is, then let a=x EOR xold
                       plot a into the buffer
                       let xold=x
        keep on going until we're finished

        This simple modification gives us a substantial speed increase --
on the old filled hires cube3d program, I measured a gain of one frame per
second.  Not earth-shattering, but not bad either!  When faces are not
filled, the difference is of course much more noticable.
        There are a few things to be careful of.  There was a bug in the
old routine when the line was a single point.  In that case dx=dy=0, and
the program would draw a vertical line on the screen.  There are probably
some other things to be careful of, but since I wrote this part of the
code three months ago I really don't remember any of them!
        This takes care of horizontal line chunks -- what about vertical
chunks?  Well, because of the way points are plotted there is nothing
we can do about them.  But, as we shall soon see, if we use an EOR-buffer
to fill faces we will be forced to take care of the vertical chunks!


zrodlo: http://unusedino.de/ec64/technical/c=hacking/ch10.html

http://atari.pl/hsc/ad.php?i=1.