BlendLine-Func

BlitzPlus Forums/BlitzPlus Programming/BlendLine-Func

WillKoh

(Posted 2004) [#1]

[Resolved, see down, other issues in the backwater?]

Beaker

(Posted 2004) [#2]

Not sure why you are not getting it drawing straight down but you might find this interesting:
http://www.blitzbasic.com/codearcs/codearcs.php?code=954

WillKoh

(Posted 2004) [#3]

No, i dont find that interesting because it doesn't create any blending or gradient and it is NOT faster than the built-in line command (nor could it possibly be, right?)

sswift

(Posted 2004) [#4]

"While Int(X#) <> X2"

That's why.

Reccomend you check before you draw to see if the line is vertical or horizontal and then use an optimized function which does not do a readpixel for drawing in those directions since they will not need antialiasing.

I also reccomend that you determine for each pixel individually if said pixel is 100% opaque before doing the readpixel, so you can avoid it if the pixel will be solid. On near vertical and near horizontal lines there may be many pixels which end up being solid.

Thsi leads to azn intereting question though. Diagonal lines too would seem to always want to have all solid pixels. Every point on the true line passes through the center of a pixel.

I suppose the proper thing to do would be to try to draw a 1 pixel wide line inatead of an infinitely thin one, though that would lead to lines which aren't very sharp. But it would be the most accurate method.

WillKoh

(Posted 2004) [#5]

I noticed my func works if only changing the While to
While Int(X#) <> X2 OR Int(Y#) <> Y2

But now there is a color issue. The line, if yet somewhat transparent, is always white-toned...

WillKoh

(Posted 2004) [#6]

AS for what swift said, drawing many of theese lines on each other may sometimes make pixels all solid but it is it really any point checking for that?

WillKoh

(Posted 2004) [#7]

Oh, it depended on setting color with Color command.. and had OnBuffer instead of RGB parametre.. so now it works:

Function BlendLine(X1,Y1,X2,Y2,Color24)
 X# = X1
 Y# = Y1
  Angle# = ATan2#(Y2-Y1,X2-X1)
; DebugLog "Angle: " + Angle#
; DebugLog "Cos/Ang: " + Cos#(Angle#)
; DebugLog "Sin/Ang: " + Sin#(Angle#)
  LockBuffer()
 While Int(X#) <> X2 Or Int(Y#) <> Y2
  X# = X# + Cos#(Angle#)
  Y# = Y# + Sin#(Angle#)
   Pixel = ReadPixelFast(Int(X#),Int(Y#))
  NewR = (GetR(Pixel) + GetR(Color24)) Shr 1
  NewG = (GetG(Pixel) + GetG(Color24)) Shr 1
  NewB = (GetB(Pixel) + GetB(Color24)) Shr 1
   If NewR > 255 Then NewR = 255
   If NewG > 255 Then NewG = 255
   If NewB > 255 Then NewB = 255
  WritePixelFast Int(X#), Int(Y#), GetRGB(NewR,NewG,NewB)
;   DebugLog "X was " + Int(X#) + " , Y was " + Int(Y#)
 Wend
  UnlockBuffer()
End Function

Function GetRGB(R,G,B)
 Return $FF000000 Or R Shl 16 Or G Shl 8 Or B
End Function

Function GetR(RGB)
 Return RGB Shr 16 And %11111111
End Function

Function GetG(RGB)
 Return RGB Shr 8 And %11111111
End Function

Function GetB(RGB)
 Return RGB And %11111111
End Function

sswift

(Posted 2004) [#8]

"AS for what swift said, drawing many of theese lines on each other may sometimes make pixels all solid but it is it really any point checking for that?"

I was not talking about drawing the lines on top of eachother. I was merely referring to those pixels which end up with an alpha of 1.0.

Determining lines that overlap would be exessive optimization and would have a 99% chance of making your code slower rather than making it faster. Unless of course you're intentionalyl drawing lines over the same segemnt of the screen pixel for pixel, thousands of times a frame for god knows what reason. There are always excpetions to the rule.