Hi Thomas,
Yeah, looks pretty good! But a few comments (on your first piece of code)...
ThomasHarte wrote:
Code:
.SetTable
equb 128, 64, 32, 16, 8, 4, 2, 1
.GetTLAddressForXY
{
lda #248
equb $8f ;
equw temp1 ; "sax temp1", so temp1 = x&~7 (x offset to 8x8 block)
equb 128, 64, 32, 16, 8, 4, 2, 1
.GetTLAddressForXY
{
lda #248
equb $8f ;
equw temp1 ; "sax temp1", so temp1 = x&~7 (x offset to 8x8 block)
Quote:
Code:
lda #0
sta temp2
tya
and #248 ; temp2:a = (y >> 3)*8
pha
pla
asl a
rol temp2
asl a
rol temp2
asl a
rol temp2 ; temp2:a = (y >> 3)*64
sta temp3
lda temp2
sta temp4
lda temp3 ; temp2:a copied to temp4:temp3
asl a
rol temp2
asl a
rol temp2 ; temp2:a = (y >> 3)*256
adc temp3
sta address ; add low byte of (y >> 3)*64 to low byte of (y >> 3)*256, store as low byte of address to modify
lda temp2
adc temp4
adc #(ScrBuffer DIV 256)
sta address+1 ; add high byte of (y >> 3)*64 to high byte of (y >> 3)*256 and screen buffer start address
; store as high byte of address to modify
rts
}
sta temp2
tya
and #248 ; temp2:a = (y >> 3)*8
pha
pla
asl a
rol temp2
asl a
rol temp2
asl a
rol temp2 ; temp2:a = (y >> 3)*64
sta temp3
lda temp2
sta temp4
lda temp3 ; temp2:a copied to temp4:temp3
asl a
rol temp2
asl a
rol temp2 ; temp2:a = (y >> 3)*256
adc temp3
sta address ; add low byte of (y >> 3)*64 to low byte of (y >> 3)*256, store as low byte of address to modify
lda temp2
adc temp4
adc #(ScrBuffer DIV 256)
sta address+1 ; add high byte of (y >> 3)*64 to high byte of (y >> 3)*256 and screen buffer start address
; store as high byte of address to modify
rts
}
Code:
tya
lsr a
lsr a
lsr a
tax
lda scraddrlo,x
sta address
lda scraddrhi,x
sta address+1
lsr a
lsr a
lsr a
tax
lda scraddrlo,x
sta address
lda scraddrhi,x
sta address+1
Quote:
Code:
; subtract deltay from error
sec
sbc y2
bcs noyinc ; don't increment y if error >= 0
clc
sec
sbc y2
bcs noyinc ; don't increment y if error >= 0
clc
Quote:
Code:
lsr pixelmask+1 ; shift the pixel mask right one, so that the next plot will be to the next pixel along
pha
lda x1 ; check if x just crossed an 8 pixel boundary
and #7
bne noxoverflow
pha
lda x1 ; check if x just crossed an 8 pixel boundary
and #7
bne noxoverflow
Quote:
Code:
sta x1 ; reset pixel mask to 128 if so, and add 8 to the current screen address
lda #128
sta pixelmask+1
clc
lda address
adc #8
sta address
lda address+1
adc #0
sta address+1
lda #128
sta pixelmask+1
clc
lda address
adc #8
sta address
lda address+1
adc #0
sta address+1
Code:
clc
lda address
adc #8
sta address
bcc nocarry
inc address+1
.nocarry
lda address
adc #8
sta address
bcc nocarry
inc address+1
.nocarry
You don't actually need the clc either. You know carry will always be set following the lsr pixelmask+1 (it will have shifted out a 1), so omit the clc, and adc #7 instead.
Using pha...pla to preserve A around a block of code is not optimal; you get slightly better performance from storing to a zp location and loading it back - or even just writing:
Code:
sta preserveme+1
...
...
...
.preserveme
lda #0
...
...
...
.preserveme
lda #0
I think that ensuring that you always plot from left to right (by ensuring startx <= endx) is a good plan, and then self-modifying the code to inc or dec in y. Another possible optimisation in the routine where dx > dy might be to only do the lda/ora/sta to screen memory when you are moving to the next byte, and meanwhile to build up an image of the entire byte to be ORed separately (because (indirect,Y) addressing is slower, especially for sta).
Of course, if you were targeting the Beeb, you'd save a lot by shrinking the screen to 32 columns wide, thereby giving you 256 byte wide screen rows
One thing you should consider right from the start, by the way, is clipping - assuming that you might sometimes need to render lines which clip off the side of the screen. If it's a full 3D game, then probably you will hold your vertex coordinates as 16-bit values anyway. You then have two choices as to how to plot arbritrarily clipped lines:
* Pass 16-bit values to your line plotter, and let it determine whether the line is totally offscreen (for a quick reject), otherwise run the Bresenham algorithm in 16-bit, and skip plotting for any coordinates where the x or y are out of range. This is a robust method, but is computationally wasteful if you know that everything you plot is going to be within screen bounds (if, for example, a simple bounding box check has shown all the coordinates to be in range).
* Do your clipping before you call your line plotter, and feed it in-range 8-bit coordinates, as you are now. This will involve you probably needing to do some division (you could do repeated subtraction, like Bresenham does, but this will be slower), something like:
Code:
if startx < 0:
startx_clipped = 0
starty_clipped = starty - (dy/dx) * startx
if endx > 255:
endx_clipped = 255
endy_clipped = endy - (dy/dx) * (endx - 255)
...and so on.startx_clipped = 0
starty_clipped = starty - (dy/dx) * startx
if endx > 255:
endx_clipped = 255
endy_clipped = endy - (dy/dx) * (endx - 255)
Hope there's something of use there for you
(Edit: just read your caveat about clipping in the 2nd paragraph - looks like you've already got this one wrapped up then!)