| |
TWW
Registered: Jul 2009
Posts: 545 |
SID to calculate line slope
To calculate a slope of a line you can use something like:
lda DeltaX
NoChange:
tax
(Plotpixel)
sec (Might not be neccessary if done right...)
txa
sbc DeltaY (Immediate)
bcs NoChange
(Change shit)
adc DeltaX (Immediate)
jmp NoChange
Which gives 11/15 cycles for each calculation/pixel(Oswald do you agree?^^). If unrolling one would have to add a cycle on the sbc/adc by use of ZP instead of Immediate values which means 12/14 cycles (No jmp if unrolled).
This is pretty good. In fact the two things I see as a possible optimalisation here is getting rid of the SEC by use of clever programming and the ADC DeltaX if you scale the relation between DeltaX and DeltaY so that the largest value = 256. You would require a division and mayhaps you get reduced accuracy (not confirmed though). Looking aside from the div. (tables perhaps?!) you'll end up with 9/11 (10/9 if unrolled(need to watch the branching here and build the routine so that you'd get a 9/10 instead) cycles fully optimized. (Am I missing something?)
However...
I read somewhere (Can't remeber where) that there is a technique where you can use the SID to calculate slopes. The SID is the chip i know the least about so I figgured I'd post here the folowing questions:
#1: Can it be done?
#2: If yes, How?
#3: How much time would the calc. use?
-TWW |
|
... 10 posts hidden. Click here to view all posts....
|
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
So how many cycles per pixel are needed on average if you include EVERYTHING (initialization, slope calculation, changing bitmask, changing gfx pointer for plotting)?
I guess I need about 30-35 cycles per pixel in TOTAL when drawing 12 lines of a cube on a single color 128x128 pixel character screen. I do not unroll the loops and my code does not run in ZP.(For slope calculations I do not use the log/exp method, but just a plain divide. I should change that :-) ). |
| |
Bitbreaker
Registered: Oct 2002
Posts: 504 |
Hard to give exact values, but for a cube in said size it is possible to render it > 50fps while even moving the 16x16 grid across the screen.
With all overhead i need around 9900 cycles per frame (without clear). If you know about the average linelength you can find out how many cycles i need for a pixel :-) |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
Sorry, but I don't understand how 9900 cycles is possible.
ora (ZP),y
sta (ZP),y
for the plotting is already 11 cycles. With the 9/10 cycles mentioned above we have at least 20 cycles per pixel. And this does not include any overhead, changing of bitmask etc.
12 lines times 50 pixels per line times 20 cycles is already 12000 cycles. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11360 |
so you just found out the trick is not doing that per pixel =P |
| |
Bitbreaker
Registered: Oct 2002
Posts: 504 |
There's also horizontal lines and hidden surface removal done, the latter is something i include, but reading again that you draw 12 lines, it seems you draw all lines of the cube.
Also one can forgo on the ora if it is sure that the line is out of reach of other lines (what would cause clashes). |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
I made some improvements to my code and can draw and rotate 12 lines ("a cube") at about 30-35 fps.
Rotations about x,y, or z axes are over a fixed small angle though (of about 7 degrees). This I do to make the rotations fast. The angle is chosen such that sin(phi)=1/8, then cos(phi) is very close to 1-1/128-1/32768. Further, suppose you rotate first around the x-axis and then around the z-axis, then you can write:
x(i+2)=z(i)+(x(i+1)-z(i+1))*cos(phi)
y(i+2)=y(i)+(x(i+1)-z(i+1))*sin(phi)
where e.g. y(i) is the y-coord after the i-th rotation.
Now you need to calculate only 2 cos/sin terms, while with the rotation matrix there are 4 of such terms.
Similar equations can be derived for 2 consecutive rotations around any 2 axes. |
| Previous - 1 | 2 - Next |
