fbGFX: BUG in Paint statement
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: fbGFX: BUG in Paint statement
The documentation notes should be specific that the problem occurs in conjunction with GFX_ALPHA_PRIMITIVES. It would be better to phrase the problem as overdraw, chaing the resulting colour of affected pixels. It should try not to make any implication that it will behave in these ways, only that they might.
The specific problem about corner overdraw isn't mentioned. Drawing a border with GFX_ALPHA_PRIMITIVES should simply be strongly advised against, since we don't really make any guarantees about the exact result when blending colours, although unexpected overdraw within a single statement is still worthy of a bug report, and maybe a warning in the documentation that it "may" happen.
The specific problem about corner overdraw isn't mentioned. Drawing a border with GFX_ALPHA_PRIMITIVES should simply be strongly advised against, since we don't really make any guarantees about the exact result when blending colours, although unexpected overdraw within a single statement is still worthy of a bug report, and maybe a warning in the documentation that it "may" happen.
Re: fbGFX: BUG in Paint statement
Here is an auto get border colour function for different transparent line(),(),b colours (to make a transparent box via paint) with different background colours.
Code: Select all
Function BorderColour(c As Ulong) As Ulong
Var r2=Cast(Ubyte Ptr,@c)[2],g2=Cast(Ubyte Ptr,@c)[1],b2=Cast(Ubyte Ptr,@c)[0]
Dim As Single a=Cast(Ubyte Ptr,@c)[3]/256:dim as ubyte alf=Cast(Ubyte Ptr,@c)[3]
Dim As Uinteger b
Screencontrol 13,,b
Var r1=Cast(Ubyte Ptr,@b)[2],g1=Cast(Ubyte Ptr,@b)[1],b1=Cast(Ubyte Ptr,@b)[0]
If Sizeof(Integer)=4 Then
alf=(((Cast(Ubyte Ptr,@c)[3])*alf)+(Cast(Ubyte Ptr,@b)[3]*(255-alf))) Shr 8 +1
End If
Return Rgba(Int(a*r2+(1-a)*r1), _
Int(a*g2+(1-a)*g1), _
Int(a*b2+(1-a)*b1), _
alf)
End Function
Screen 19,32,,64
#define range(f,l) Int(Rnd*(((l)+1)-(f))+(f))
Dim As Long x1,y1,x2,y2
Dim As Ubyte rd,gr,bl,alf
Do
x1=range(20,300)
y1=range(40,200)
x2=range(500,799)
y2=range(400,599)
rd=Rnd*255
gr=Rnd*255
bl=Rnd*255
alf=50+Rnd*200
Dim As Ulong box=Rgba(rd,gr,bl,alf)
Color rgb(0,0,0), Rgb(Rnd*255,Rnd*255,Rnd*255)
Cls
Line(x1,y1)-(x2,y2),box,b
Dim As Ulong p=(Point(x1+2,y1)) 'for comparison
Dim As Ulong b= BorderColour(box)
Draw String(360,300),"HELLO"
Paint(x1+5,y1+5),box,b 'just inside the box
Print "rgba(";rd;",";gr;",";bl;",";alf;")","box colour"
Print "rgba("; Cast(Ubyte Ptr,@p)[2];",";Cast(Ubyte Ptr,@p)[1];",";Cast(Ubyte Ptr,@p)[0];",";Cast(Ubyte Ptr,@p)[3];")","from point"
Print "rgba("; Cast(Ubyte Ptr,@b)[2];",";Cast(Ubyte Ptr,@b)[1];",";Cast(Ubyte Ptr,@b)[0];",";Cast(Ubyte Ptr,@b)[3];")","from function"
Sleep
Loop Until Multikey(1)
Sleep
Last edited by dodicat on Apr 10, 2019 17:33, edited 1 time in total.
Re: fbGFX: BUG in Paint statement
@counting_pine,
You can correct directly in wiki my added notes as you like (it's the simplest).
You can correct directly in wiki my added notes as you like (it's the simplest).
Re: fbGFX: BUG in Paint statement
But I try anyway another proposal (reworded each previous note):
- Updated according to dodicat's remark below.
- Updated according to counting_pine remarks below
fxm wrote: - On the PAINT page:Warning: If the border is drawn with a transparent color (in conjunction with the GFX_ALPHA_PRIMITIVES option flag) and some pixels are overdrawn on it, the resultant (blending) color of these overdrawn pixels can cause a leak point through which the fill color escapes outside the border. So drawing a border with a transparent color is not recommended.
Note: If the border is drawn with a transparent color and some pixels overlap, it causes a multiple-blending of color on these pixels and the resulting color of blending is not the one expected on these singular points. Those off color pixels (one does it) will lead to a 'leak-pixel', through which fill color escapes the bordering line!
fxm wrote: - 0n the LINE page:Note: Either chained use or boxes drawn with Line can induce pixels overdrawn at some locations. Thus, the resultant (blending) color of these overdrawn pixels is affected if a transparent color (in conjunction with the GFX_ALPHA_PRIMITIVES option flag) is used.
Note: Chained uses of Line usually induce (one or more) overlapping pixel(s) at locations which will cause a overflow of Paint's fill color if a transparent color is used for the border.
[edit]fxm wrote: - On the CIRCLE page:Note: Curves drawn with Circle can induce pixels overdrawn at some locations. Thus, the resultant (blending) color of these overdrawn pixels is affected if a transparent color (in conjunction with the GFX_ALPHA_PRIMITIVES option flag) is used.
Note: Circle usually induces (one or more) overlapping pixel(s) at locations which will cause a overflow of Paint's fill color if a transparent color is used for the border.
- Updated according to dodicat's remark below.
- Updated according to counting_pine remarks below
Last edited by fxm on Apr 11, 2019 16:33, edited 22 times in total.
Re: fbGFX: BUG in Paint statement
Perhaps
If the border is drawn with a transparent color (in conjunction with the GFX_ALPHA_PRIMITIVES option flag) and some pixels on it are overdrawn, the resultant (blending) color of these overdrawn pixels can cause a leak point, through which the fill color escapes outside the border.
...
An actual border color will be the addition (blending) of a given border color with the screen background color.
Example: a green border color rgba(0,200,0,100) on a solid black background color rgb(0,0,0) will result in a border color rgba(0,78,0,100)
This new border color can be retrieved via freebasic's point function.
If the border is drawn with a transparent color (in conjunction with the GFX_ALPHA_PRIMITIVES option flag) and some pixels on it are overdrawn, the resultant (blending) color of these overdrawn pixels can cause a leak point, through which the fill color escapes outside the border.
...
An actual border color will be the addition (blending) of a given border color with the screen background color.
Example: a green border color rgba(0,200,0,100) on a solid black background color rgb(0,0,0) will result in a border color rgba(0,78,0,100)
This new border color can be retrieved via freebasic's point function.
Re: fbGFX: BUG in Paint statement
See my updated proposal.
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: fbGFX: BUG in Paint statement
Thanks fxm.
Now I look back at my words, probably it's enough to say "not recommended", rather than "strongly advised against".
I think the recommendation should go on Paint's page only - my personal feeling is that it's not needed to talk specifically about Paint on the Line/Circle pages. I'm wary about making the wiki more verbose than it needs to be.
Now I look back at my words, probably it's enough to say "not recommended", rather than "strongly advised against".
I think the recommendation should go on Paint's page only - my personal feeling is that it's not needed to talk specifically about Paint on the Line/Circle pages. I'm wary about making the wiki more verbose than it needs to be.
Re: fbGFX: BUG in Paint statement
In this case, it may be better to put the remark back as a "Note" (instead of "Warning") on the Line/Circle pages.counting_pine wrote:I think the recommendation should go on Paint's page only - my personal feeling is that it's not needed to talk specifically about Paint on the Line/Circle pages.
=> See new proposal update.
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: fbGFX: BUG in Paint statement
Thanks, this is looking better.
It occurs to me that full Circles are drawn differently from partial ones - the former uses the Bresenham algorithm, while the latter use an unsophisticated Sin/Cos based approach. (It would be great to fix this some time..) But as far as I know, full circles shouldn't have any overdraw issues. I don't know if anyone's specifically tested though..
I think we can reduce the wording on Line - just saying that either chained use or boxes drawn with Line can cause the given effect.
My personal recommendation is to avoid drawing blended borders for Paint in general, because the exact colour/alpha value can be hard to predict.
It occurs to me that full Circles are drawn differently from partial ones - the former uses the Bresenham algorithm, while the latter use an unsophisticated Sin/Cos based approach. (It would be great to fix this some time..) But as far as I know, full circles shouldn't have any overdraw issues. I don't know if anyone's specifically tested though..
I think we can reduce the wording on Line - just saying that either chained use or boxes drawn with Line can cause the given effect.
My personal recommendation is to avoid drawing blended borders for Paint in general, because the exact colour/alpha value can be hard to predict.
Re: fbGFX: BUG in Paint statement
No.counting_pine wrote:But as far as I know, full circles shouldn't have any overdraw issues.
See the previous post of dodicat: viewtopic.php?p=259831#p259831
(overdrawn pixels at top and bottom)
Other example:
Code: Select all
Const As UShort wid = 800, hei = 600, cd = 32, pg = 2, sflg = 64
ScreenRes(wid, hei, cd, pg, sflg) ' sflg = GFX_ALPHA_PRIMITIVES
Width wid \ 8, hei \ 16
Color(&hFF000000, &hFFFFFFFF) : Cls ' black (fg) on white (bg)
Line (wid \ 2 - 1, hei \ 2 - 1)-Step(2, 2), &hBFFF0000, BF ' 25% transparent border
Circle (wid \ 2, hei \ 2), iif(wid < hei, wid \ 2 - 128, hei \ 2 - 128), &hBFFF0000 ' 25% transparent border
Locate 2
Print " Color of circle's center pixel: "; Hex(Point(wid \ 2, hei \ 2)); " (reference)" '' C3FF4040
Print
Print " Color of circle's top pixel : "; Hex(Point(wid \ 2, hei \ 2 - iif(wid < hei, wid \ 2 - 128, hei \ 2 - 128))) '' C3FF1010
Print " Color of circle's right pixel : "; Hex(Point(wid \ 2 + iif(wid < hei, wid \ 2 - 128, hei \ 2 - 128), hei \ 2)) '' CFFF4040
Print " Color of circle's bottom pixel: "; Hex(Point(wid \ 2, hei \ 2 + iif(wid < hei, wid \ 2 - 128, hei \ 2 - 128))) '' C3FF1010
Print " Color of circle's left pixel : "; Hex(Point(wid \ 2 - iif(wid < hei, wid \ 2 - 128, hei \ 2 - 128), hei \ 2)) '' CFFF4040
Sleep
Last edited by fxm on Apr 12, 2019 6:29, edited 2 times in total.
Re: fbGFX: BUG in Paint statement
A command like PAINT was supposed to work either in B/W or in a 16 color mode (it was used on BASIC dialects supposed to work on home computers like the MSX, or on PC with a CGA, or at best an EGA). Under Quick Basic it was much less useful in 256 color mode, since it was unable to recognize a border drawn in a gradient color, for example.
Drawing programs (like PaintBrush) featured a paint function, too, that worked more or less like the one featured in BASIC. Nowadays, software like Photoshop or GIMP cannot rely any more on such a primitive feature, and instead use an algorithm that works on layers, and allow to specify a tolerance (instead of just specifying a border color, it also allow to specify how close the color must be to the border color)
Modern graphic libraries don't have anything equivalent to the basic PAINT: they just provide a command to draw an already filled shape (like the F option in FreeBasic commands like LINE or CIRCLE). This approach works much better for textured objects, too, because it allows to scale the texture with the object (this would never be possible with a PAINT command).
For these reasons, a command like PAINT makes no sense in a screen mode that features real colors and alpha channel. It shouldn't even be used, in these modes. It's a command intended for 16 color mode, and for retrocompatibility with legacy BASIC code. I would recommend to avoid using it, if possible, in new programs.
Drawing programs (like PaintBrush) featured a paint function, too, that worked more or less like the one featured in BASIC. Nowadays, software like Photoshop or GIMP cannot rely any more on such a primitive feature, and instead use an algorithm that works on layers, and allow to specify a tolerance (instead of just specifying a border color, it also allow to specify how close the color must be to the border color)
Modern graphic libraries don't have anything equivalent to the basic PAINT: they just provide a command to draw an already filled shape (like the F option in FreeBasic commands like LINE or CIRCLE). This approach works much better for textured objects, too, because it allows to scale the texture with the object (this would never be possible with a PAINT command).
For these reasons, a command like PAINT makes no sense in a screen mode that features real colors and alpha channel. It shouldn't even be used, in these modes. It's a command intended for 16 color mode, and for retrocompatibility with legacy BASIC code. I would recommend to avoid using it, if possible, in new programs.
Re: fbGFX: BUG in Paint statement
Update documentation again:
- KeyPgPaint → fxm [Reworded "Note" paragraph and turned into a "Warning" paragraph]
- KeyPgCircle → fxm [Reworded "Note" paragraph]
- KeyPgLinegraphics → fxm [Reworded "Note" paragraph]
according to viewtopic.php?p=259930#p259930
- KeyPgPaint → fxm [Reworded "Note" paragraph and turned into a "Warning" paragraph]
- KeyPgCircle → fxm [Reworded "Note" paragraph]
- KeyPgLinegraphics → fxm [Reworded "Note" paragraph]
according to viewtopic.php?p=259930#p259930
Re: fbGFX: BUG in Paint statement
@fxm,
there has been a grammatical issue introduced, with the last changes:
"the resultant (blending) color" portion, should read:
"the resultant (blended) color" [it is "past tense"]
there has been a grammatical issue introduced, with the last changes:
"the resultant (blending) color" portion, should read:
"the resultant (blended) color" [it is "past tense"]
Re: fbGFX: BUG in Paint statement
What does dodicat (a Scottish) think about this wording problem that I copied from his proposal (viewtopic.php?p=259931#p259931)?MrSwiss wrote:there has been a grammatical issue introduced, with the last changes:
"the resultant (blending) color" portion, should read:
"the resultant (blended) color" [it is "past tense"]
(I do not want to offend anyone)
Re: fbGFX: BUG in Paint statement
You can't just copy from a different sentence (... the addition (blending) of a ...). Is correct.
The context there, is different (which impacts grammar!).
Even if you reword a bit:
... the resulting (blended) color ... (blending is finished, before you 'have' a result).
Grammar is either correct, or not ... (doesn't offend anyone).
The context there, is different (which impacts grammar!).
Even if you reword a bit:
... the resulting (blended) color ... (blending is finished, before you 'have' a result).
Grammar is either correct, or not ... (doesn't offend anyone).