fbGFX: BUG in Paint statement

General FreeBASIC programming questions.
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: fbGFX: BUG in Paint statement

Post by counting_pine »

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.
dodicat
Posts: 7976
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: fbGFX: BUG in Paint statement

Post by dodicat »

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.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: fbGFX: BUG in Paint statement

Post by fxm »

@counting_pine,
You can correct directly in wiki my added notes as you like (it's the simplest).
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: fbGFX: BUG in Paint statement

Post by fxm »

But I try anyway another proposal (reworded each previous note):
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.
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.
[edit]
- 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.
dodicat
Posts: 7976
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: fbGFX: BUG in Paint statement

Post by dodicat »

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.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: fbGFX: BUG in Paint statement

Post by fxm »

See my updated proposal.
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: fbGFX: BUG in Paint statement

Post by counting_pine »

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.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: fbGFX: BUG in Paint statement

Post by fxm »

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.
In this case, it may be better to put the remark back as a "Note" (instead of "Warning") on the Line/Circle pages.
=> See new proposal update.
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: fbGFX: BUG in Paint statement

Post by counting_pine »

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.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: fbGFX: BUG in Paint statement

Post by fxm »

counting_pine wrote:But as far as I know, full circles shouldn't have any overdraw issues.
No.
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.
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: fbGFX: BUG in Paint statement

Post by angros47 »

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.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: fbGFX: BUG in Paint statement

Post by fxm »

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
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: fbGFX: BUG in Paint statement

Post by MrSwiss »

@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"]
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: fbGFX: BUG in Paint statement

Post by fxm »

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"]
What does dodicat (a Scottish) think about this wording problem that I copied from his proposal (viewtopic.php?p=259931#p259931)?
(I do not want to offend anyone)
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: fbGFX: BUG in Paint statement

Post by MrSwiss »

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).
Post Reply