| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
line vector cube/parallel lines
hello,
i have a question about line vectors (3d projections) lets take for example a cube with 8 corners rotating around in 3d perspective.. each line of the cube got his parallel line(s). the question i have: does this paralell line use the same line patern as the line it is parallel too, so i only have to calculate (linedrawing) this line only one time and reuse the table for the other (parallel) lines.
a friend of my says that this called a orthogon projecttion and not a perspective projection: when you draw for example a house you see in perspective projection that the lines comes closer when farer away and touch at some point in infinity, becoz of this, each line has i own linepatern,
and so you must calculate each line..
i hope you understand my question
mcd
|
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
your line routine probably doesnt follows the fastest solutions, since those use only one lda # to get the line pattern, as the line-loop is unrolled.
edit: check the c=hacking series on codebase, in the "different perspective.." article series there are various lineroutines discussed. |
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
oswald: i don't know what you mean. i use a unrolled routine to calculate lines and store it into a tabel
so i use two separate routines. one for calulating lines and the other for pasting them... thanks anyway... i know
you are a master in vectors... |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
maybe if you paste your line "pasting" source we can be more of a help. I guess you want to save time by reusing slopes. |
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
well.
the line calculation routine looks like this:
ldx #0
lda #0
clc
adc $40
cmp $41
bmi con
inx
sec
sbc $41
con stx $0f00
clc
adc $40
cmp $41
bmi con2
inx
sec
sbc $41
con2 stx $0f01
enz
you can skip al the clc and sec when the resuls are never
higher dan $ff (the carry doesn't change in this case)
you also can skip the cmp $41 and just test if the number becomes a negative or positive number..
|
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
oops i forgot the write down the paste routine
it is nothing special but here it comes.
ldx #0
lda lobyte kolum,x
sta $a0
lda hibyte kolom,x
sta $a1
lda pixel,x
ldy $0f00 (the tabel with the linedrawing data)
ora ($a0),y
sta ($a0),y
enz
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
you can skip both clc and sec:
you start with height in the accu and carry set:
sbc $width
bcs con ; no underflow skip (result>0)
adc $height ;underflow carry CLEAR now
inx ;adc will set carry high again because overflow (result>255)
con stx $0f00
big slope case:
con sbc $width
inx
bcs con
adc $height
stx $0f00
$width and $height may be to be swapped (incl. accu initialisation), I have now just thrown them in without thinking about their orders.
line drawing, can be more precalculated:
ldy $0f0x
lda $currentcolumn,y
ora #pixel
sta $currentcolumn,y
ldy $0f0x
lda $currentcolumn,y
ora #pixel
sta $currentcolumn,y
ldy $0f0x
lda $currentcolumn,y
ora #pixel
sta $currentcolumn,y
...
you simply jump into the above speedcode at you desired "xstart" coordinate, and selfmod it to an rts to exit at the desired "xend" coordinate. |
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
hell yeah! very cool! thanks a lot! i hope you don't mind asking you something again but: do you also have a clear answer about parallel lines using the same line-drawn patern... or is it an stopid question..
mcd
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
how about:
lda $0f0x,y ;adjust slope for the needed shift horizontally with Y
adc $offset ;adjust slope for the needed shift vertically
tax
lda actcolumn,x
ora #pixel
sta acrcolumn,x
iny
tho if you count the cycles carefully, it will be clear that its faster to calculate the slope each time :)
like this:
lda actcolumn,y
ora #pixels
sta actcolumn,y
txa
sbc $width
bcs con
iny
adc $height
con tax
even faster, but only if you can come up with a division based on log/exp:
lda actcolumn,y
ora #pixels
sta actcolumn,y
txa
adc $slope ;=widht/height or vice versa depending on the case
bcc con
iny
con tax
|
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Quote: hello,
i have a question about line vectors (3d projections) lets take for example a cube with 8 corners rotating around in 3d perspective.. each line of the cube got his parallel line(s). the question i have: does this paralell line use the same line patern as the line it is parallel too, so i only have to calculate (linedrawing) this line only one time and reuse the table for the other (parallel) lines.
a friend of my says that this called a orthogon projecttion and not a perspective projection: when you draw for example a house you see in perspective projection that the lines comes closer when farer away and touch at some point in infinity, becoz of this, each line has i own linepatern,
and so you must calculate each line..
i hope you understand my question
mcd
Sounds like orthographic projection.
|
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
martin piper, do you know if it is possible to make a nice 3d projection with this so called 'orthograpics' or do i miss something here... anyway this week i'am gonna study the different perspective articles in c=hacking..
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
look here: http://en.wikipedia.org/wiki/Orthographic_projection
you might know this as "isometric" (it's not, but it works similar) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
orthographic projection basically means, that after 3d rotation you simply throw away the z coord (you might not even need to 3d rotate it), and use x,y to draw your cube. in this case pairs of lines will be parallel of a cube and you will have no perspective.
perspective will need the Z coord too, and one multiplication for each coordinate. |
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
ok boys! thanks a lot for the help and info..
|
| |
TWW
Registered: Jul 2009
Posts: 545 |
I would like to investigate this a little furter. I will take a little closer look @ Oswalds code-lines earlier in this thread;
First Routine:
txa
sbc $DX
bcs *+5
iny
adc $DY
tax
This totalt to 14 or 10 cycles depending on branch.
Second Routine:
txa
adc $+-slope
bcc *+3
iny
tax
Totals of 11 or 10 cycles depending on Branch.
This means that these two routines at their best potential are same-same and the log/exp-div would cost you more then calculating on the fly. However at their worst (and if you can calculate the slope constant within 3-384 cycles(Depending how long the line is)) the 2nd alternative would be better.
I am unsure about this but how is the accuracy of a log/exp div constant vs. calculating the slope on the fly!? (mayhaps the same i dunno).
So for shorter and more vertical lines 'the on the fly'-method would pay off. Longer and more Diagonal lines the 'slope constant' would pay. Perhaps in the long run it doesent really make much difference(!?)
However I came up with a more elegant solution a while back. This requiers you to splitt a line in 2 and draw them simultaniously one from Y2 -> DX/2 and one from DY/2 -> Y1 using the same slope (Naturally since it's the same frigging line).
Ofcourse this give bigger gain on longer lines and no or negative gain on short lines due to aditional pre-calculations.
ldx $DX
ldy $DY/2
sec
bit1 lda #$00
ora ($fb),y
sta ($fb),y
bit2 lda #$00
ora ($fd),y
sta ($fd),y
dey
bmi end
txa
sbc #DX
tax ;extra due to the loop
bcs bit1
adc #DY
tax
;---------------------------
;-pointers and bitmask calc-
;---------------------------
asl bit1+1
bcc tjo
lda #$01
sta bit1+1
lda $fb
adc #$7f
sta $fb
bcs *+4
dec $fc
tjo asl bit2+1
bcc bit1-1
lda #$01
sta bit2+1
lda $fd
adc #$7f
sta $fd
bcs bit1
dec $fe
jmp bit1-1
end rts
This is a extract from my routine. It is not optimized (hell it's probably buggy too). Though if unrolled the 'slope-algorithm' cycle count would be the same as the first routine above giving an effective 5/7 cycles gain each pixel.
TWW/Creators |
