Filled Arc

[SMcNeill]

I've been working on filling in some of the missing tools in my draw library and one thing I noticed that I was missing was a really good filled arc routine.   QB64's method was to draw a circle, choose a point inside the arc, and then use PAINT to fill that circle....

and it didn't work as it never seemed to properly close the arcs and then the paint bled out and colored the entire screen.

The CircleFill that I shared and everyone has used for ages and ages works off LINE statements and thus can never bleed outside the circle itself.  It's fast and lovely and nice.

And so, I thought, can I come up with a similar way to do ARCs?  

After a few different tries, this is what I've came up with -- a scanline polygon fill routine for arcs.

Code: (Select All)

$Color:32

Screen _NewImage(1024, 720, 32)



FilledArc 400, 300, 200, 150, 30, _RGB32(0, 180, 255)

Sleep

Cls , Red

FilledArc 400, 300, 200, 0, 360, _RGBA32(125, 0, 180, 255)

Sleep

Cls , White



' Draw a ring arc from 30 to 300, inner radius 100, outer radius 200

FilledRingArc 400, 300, 150, 200, 30, 300, _RGB32(255, 180, 0)

Sleep

' ---------------------------------------------------------

' TEST DRAWING

' ---------------------------------------------------------



Cls



Color _RGB32(255, 255, 255)



Print "Elliptical Arc / Ring Arc Test"

Print "Press any key to exit."



' Pie slice

FilledEllipseArc 250, 250, 200, 120, 20, 200, _RGB32(0, 180, 255)

Print "(1) Filled Elliptical Arc at (250,250)"



' Ring arc

FilledEllipseRingArc 700, 250, 80, 40, 200, 120, 45, 300, _RGB32(255, 150, 0)

Print "(2) Filled Elliptical Ring Arc at (700,250)"



' Another test arc

FilledEllipseArc 250, 300, 150, 250, 270, 360, _RGB32(0, 255, 120)

Print "(3) Tall Elliptical Arc at (250,300)"



' Another ring arc

FilledEllipseRingArc 700, 500, 50, 100, 180, 250, 0, 180, _RGB32(200, 80, 255)

Print "(4) Vertical Ring Arc at (700,500)"



Sleep

End



Sub FilledRingArc (cx As Long, cy As Long, r1 As Long, r2 As Long, a1 As Single, a2 As Single, col As _Unsigned Long)

    ' Draws a filled ring arc (donut slice)

    ' cx, cy  = center

    ' r1      = inner radius

    ' r2      = outer radius

    ' a1, a2  = start/end angles in degrees

    ' col    = fill color



    Const angStep! = 1! ' smaller = smoother arc

    Dim As Single vx(0 To 2000), vy(0 To 2000), interX(0 To 2000)

    Dim As Single angle, x, y, x1, y1, x2, y2, temp

    Dim As Long count, i, j, n, minY, maxY, yScan



    ' Normalize angles

    If a1 < 0 _OrElse a1 > 360 Then a1 = a1 Mod 360

    If a2 < 0 _OrElse a2 > 360 Then a2 = a2 Mod 360

    If a2 < a1 Then a2 = a2 + 360



    ' ---- Outer arc (A1 ? A2) ----

    For angle = a1 To a2 Step angStep

        x = cx + r2 * Cos(_D2R(angle)): y = cy - r2 * Sin(_D2R(angle)): vx(n) = x: vy(n) = y: n = n + 1

    Next



    ' Ensure exact endpoint

    x = cx + r2 * Cos(_D2R(a2)): y = cy - r2 * Sin(_D2R(a2)): vx(n) = x: vy(n) = y: n = n + 1



    ' ---- Inner arc (A2 ? A1, reversed) ----

    For angle = a2 To a1 Step -angStep

        x = cx + r1 * Cos(_D2R(angle)): y = cy - r1 * Sin(_D2R(angle)): vx(n) = x: vy(n) = y: n = n + 1

    Next



    ' Ensure exact endpoint

    x = cx + r1 * Cos(_D2R(a1)): y = cy - r1 * Sin(_D2R(a1)): vx(n) = x: vy(n) = y: n = n + 1



    ' ---- Scanline fill ----

    minY = vy(0): maxY = vy(0)

    For i = 1 To n - 1: maxY = _Max(maxY, vy(i)): minY = _Min(minY, vy(i)): Next



    For yScan = minY To maxY

        count = 0

        ' Find intersections

        For i = 0 To n - 1

            j = (i + 1) Mod n: x1 = vx(i): y1 = vy(i): x2 = vx(j): y2 = vy(j)

            If (y1 <= yScan And y2 > yScan) Or (y2 <= yScan And y1 > yScan) Then

                If y2 <> y1 Then interX(count) = x1 + (yScan - y1) * (x2 - x1) / (y2 - y1): count = count + 1

            End If

        Next

        ' Sort intersections

        For i = 0 To count - 2

            For j = i + 1 To count - 1

                If interX(j) < interX(i) Then Swap interX(i), interX(j)

        Next j, i

        ' Draw spans

        For i = 0 To count - 2 Step 2

            Line (CLng(interX(i)), yScan)-(CLng(interX(i + 1)), yScan), col, BF

        Next

    Next yScan

End Sub









Sub FilledArc (cx As Long, cy As Long, r As Long, a1 As Single, a2 As Single, col As _Unsigned Long)

    $Checking:Off

    ' Filled arc (pie slice) using only LINE (scanline polygon fill)

    ' cx, cy  = center of circle

    ' r      = radius

    ' a1, a2  = start and end angles in degrees (0 = right, 90 = up)

    ' col    = color



    Const angStep! = 1! ' angle step in degrees (smaller = smoother arc)

    Dim As Single vx(0 To 720), vy(0 To 720), angle, x, y

    Dim As Single interX(0 To 720), x1, y1, x2, y2

    Dim As Long i, n, count, yScan, j, k, temp, minY, maxY



    ' Normalize angles

    If a1 < 0 _OrElse a1 > 360 Then a1 = a1 Mod 360

    If a2 < 0 _OrElse a2 > 360 Then a2 = a2 Mod 360

    If a2 < a1 Then a2 = a2 + 360



    ' Build polygon: start at center

    vx(0) = cx: vy(0) = cy: n = 1



    ' Arc edge points

    For angle = a1 To a2 Step angStep 'with a higher anglestep we have a less rounded arc and more of a polygon figure

        x = cx + r * Cos(_D2R(angle)): y = cy - r * Sin(_D2R(angle))

        vx(n) = x: vy(n) = y: n = n + 1

    Next angle



    ' Ensure last point exactly at a2

    x = cx + r * Cos(_D2R(a2)): y = cy - r * Sin(_D2R(a2))

    vx(n) = x: vy(n) = y: n = n + 1



    ' Close polygon back to center

    vx(n) = cx: vy(n) = cy: n = n + 1



    ' --- Scanline fill of polygon ---

    minY = vy(0): maxY = vy(0)

    For i = 1 To n - 1: maxY = _Max(maxY, vy(i)): minY = _Min(minY, vy(i)): Next



    For yScan = minY To maxY

        ' Find intersections of scanline with each edge

        count = 0

        For i = 0 To n - 1

            j = (i + 1) Mod n

            x1 = vx(i): y1 = vy(i): x2 = vx(j): y2 = vy(j)

            ' Check if edge crosses this scanline

            If (y1 <= yScan And y2 > yScan) Or (y2 <= yScan And y1 > yScan) Then

                If y2 <> y1 Then interX(count) = x1 + (yScan - y1) * (x2 - x1) / (y2 - y1): count = count + 1

            End If

        Next

        ' Sort intersections (simple bubble sort; count is small)

        For i = 0 To count - 2

            For j = i + 1 To count - 1

                If interX(j) < interX(i) Then Swap interX(i), interX(j)

        Next j, i



        ' Draw horizontal spans between pairs of intersections

        For i = 0 To count - 2 Step 2

            Line ((interX(i)), yScan)-((interX(i + 1)), yScan), col, BF

        Next

    Next yScan

    $Checking:On

End Sub



Sub FilledEllipseArc (cx As Long, cy As Long, a As Long, b As Long, a1 As Single, a2 As Single, col As _Unsigned Long)

    $Checking:Off



    ' Filled elliptical arc (pie slice) using only LINE

    ' cx, cy = center

    ' a, b = ellipse radii (horizontal, vertical)

    ' a1, a2 = start/end angles in degrees

    ' col = color



    Const angStep! = 1! ' angle step in degrees (smaller = smoother arc)

    Dim As Single vx(0 To 2000), vy(0 To 2000), angle, x, y

    Dim As Single interX(0 To 2000), x1, y1, x2, y2

    Dim As Long i, n, count, yScan, j, k, temp, minY, maxY



    ' Normalize angles

    If a1 < 0 _OrElse a1 > 360 Then a1 = a1 Mod 360

    If a2 < 0 _OrElse a2 > 360 Then a2 = a2 Mod 360

    If a2 < a1 Then a2 = a2 + 360



    ' Build polygon: start at center

    vx(0) = cx: vy(0) = cy: n = 1



    ' Arc edge points

    For angle = a1 To a2 Step angStep 'with a higher anglestep we have a less rounded arc and more of a polygon figure

        x = cx + a * Cos(_D2R(angle)): y = cy - b * Sin(_D2R(angle))

        vx(n) = x: vy(n) = y: n = n + 1

    Next angle



    ' Ensure last point exactly at a2

    x = cx + a * Cos(_D2R(a2)): y = cy - b * Sin(_D2R(a2))

    vx(n) = x: vy(n) = y: n = n + 1



    ' Close polygon back to center

    vx(n) = cx: vy(n) = cy: n = n + 1



    ' --- Scanline fill of polygon ---

    minY = vy(0): maxY = vy(0)

    For i = 1 To n - 1: maxY = _Max(maxY, vy(i)): minY = _Min(minY, vy(i)): Next



    For yScan = minY To maxY

        ' Find intersections of scanline with each edge

        count = 0

        For i = 0 To n - 1

            j = (i + 1) Mod n

            x1 = vx(i): y1 = vy(i): x2 = vx(j): y2 = vy(j)

            ' Check if edge crosses this scanline

            If (y1 <= yScan And y2 > yScan) Or (y2 <= yScan And y1 > yScan) Then

                If y2 <> y1 Then interX(count) = x1 + (yScan - y1) * (x2 - x1) / (y2 - y1): count = count + 1

            End If

        Next

        ' Sort intersections (simple bubble sort; count is small)

        For i = 0 To count - 2

            For j = i + 1 To count - 1

                If interX(j) < interX(i) Then Swap interX(i), interX(j)

        Next j, i



        ' Draw horizontal spans between pairs of intersections

        For i = 0 To count - 2 Step 2

            Line ((interX(i)), yScan)-((interX(i + 1)), yScan), col, BF

        Next

    Next yScan

    $Checking:On

End Sub





' Filled elliptical ring arc using only LINE

' cx, cy  = center

' a1, b1  = inner ellipse radii

' a2, b2  = outer ellipse radii

' ang1, ang2 = start/end angles

' col    = fill color



Sub FilledEllipseRingArc (cx As Long, cy As Long, a1 As Long, b1 As Long, a2 As Long, b2 As Long, ang1 As Single, ang2 As Single, col As _Unsigned Long)



    Const angStep! = 2!



    Dim vx(0 To 4000) As Single

    Dim vy(0 To 4000) As Single

    Dim interX(0 To 4000) As Single

    Dim count As Long

    Dim yScan As Long

    Dim x1 As Single, y1 As Single, x2 As Single, y2 As Single

    Dim j As Long, temp As Single



    Dim minY As Long, maxY As Long

    Dim i As Long



    Dim n As Long

    Dim angle As Single

    Dim x As Single, y As Single



    If ang2 < ang1 Then ang2 = ang2 + 360



    n = 0



    ' ---- Outer ellipse arc (ang1 ? ang2) ----

    For angle = ang1 To ang2 Step angStep

        x = cx + a2 * Cos(angle * _Pi / 180)

        y = cy - b2 * Sin(angle * _Pi / 180)

        vx(n) = x: vy(n) = y: n = n + 1

    Next



    ' Exact endpoint

    x = cx + a2 * Cos(ang2 * _Pi / 180)

    y = cy - b2 * Sin(ang2 * _Pi / 180)

    vx(n) = x: vy(n) = y: n = n + 1



    ' ---- Inner ellipse arc (ang2 ? ang1, reversed) ----

    For angle = ang2 To ang1 Step -angStep

        x = cx + a1 * Cos(angle * _Pi / 180)

        y = cy - b1 * Sin(angle * _Pi / 180)

        vx(n) = x: vy(n) = y: n = n + 1

    Next



    ' Exact endpoint

    x = cx + a1 * Cos(ang1 * _Pi / 180)

    y = cy - b1 * Sin(ang1 * _Pi / 180)

    vx(n) = x: vy(n) = y: n = n + 1



    ' ---- Scanline fill (same as before) ----



    minY = vy(0): maxY = vy(0)

    For i = 1 To n - 1

        If vy(i) < minY Then minY = vy(i)

        If vy(i) > maxY Then maxY = vy(i)

    Next





    For yScan = minY To maxY



        count = 0



        For i = 0 To n - 1

            j = (i + 1) Mod n

            x1 = vx(i): y1 = vy(i)

            x2 = vx(j): y2 = vy(j)



            If (y1 <= yScan And y2 > yScan) Or (y2 <= yScan And y1 > yScan) Then

                If y2 <> y1 Then

                    interX(count) = x1 + (yScan - y1) * (x2 - x1) / (y2 - y1)

                    count = count + 1

                End If

            End If

        Next



        ' Sort intersections

        For i = 0 To count - 2

            For j = i + 1 To count - 1

                If interX(j) < interX(i) Then Swap interX(i), interX(j)

        Next j, i



        ' Draw spans

        For i = 0 To count - 2 Step 2

            Line (CLng(interX(i)), yScan)-(CLng(interX(i + 1)), yScan), col, BF

        Next



    Next yScan

End Sub

It does all the math first and calculates all those points which make up the edges of the circle and the lines of the sides of the arc, and then it draws the lines which makes up the circle.

This seems to work for me, and it seems to work nice and fast enough as to be usable in any program I might have.

You math guru's make take a look at this, go over it with a fine tooth comb like everyone did the CircleFill routine and see what might be improved with it, and share your thoughts with us, if you would.  Without a whole lot of other versions to compare against, I don't know whether to call this really speedy or not.

At the moment, it seems suitable for my personal usage.  I dunno if others have better or faster versions which do the same thing.  If so, please share and let's compare!

(Note that you can really see the polygon code in action if you change the CONST inside the routine.  Heck, there might even be times where you WANT to do so, for some particular reason or the other.  Change it to something like 10! or 20! and then see how our circle looks.  It'll be obvious with those values as to what it's doing for us.  (You can also make the routine *faster* if desired by going with a rougher circle.  Change the value to 2 or 5 and it's not that visually different, but it changes our polygon count by that step.)

CircleFill is nice and fast.  This is my attempt to see if I can do the same style fastness for an ArcFill.  Let me know what you guys think about it. 

---

EDIT:  Condensed version which wraps all commands to the main routine can be found here: https://qb64phoenix.com/forum/showthread...6#pid39566

I'll leave the original up here so folks can just grab whatever they need from it with each routine holding independent, but I honestly recommend just using the one routine to do it all.  It's all you honestly need now.

[SMcNeill]

   

Images of the above filled ellipses and thick elliptical arcs.

[SMcNeill]

Updated the first post to offer two more routines which now give us a total of:

Filled Arcs
Thick Ring Arcs
Filled Elliptical Arcs
Thick Elliptical Ring Arcs

The post above has an image of the elliptical arcs and rings.

[Pete]

That's AMAZING! How did Noah ever fill his arc without Steve?

It was fun working on the ellipse fill project. I still remember Bill nearly had a coronary at my approach, but it worked and it worked faster. I suppose if I needed to fill arcs, I'd just use that ellipse formula and figure out how to eliminate the part to not fill. Now to fill an ark, I think you need FreeBASIC for that, two of them. 

Pete

[bplus]

Personally I think going Counter Clockwise with start and end angles is Inconsistent with Trig Functions that go clockwise thus is bad foundation to build from. Even Terry followed CW direction, if I recall correctly. Though his 0 degrees is due North which is even more Clock Wise but less math convention wise.

But this direction would make old code compatible and continue to make learning Sin Cos that much more confusing along with sorting out radians and degrees from start. And makes learning Tangents and Arc Tangents for finding line directions hell because that is next step up with Trig functions.

If you makeover the arcs then make them consistent with Trig functions. Bad enough Basic screen graphic y axis increases going down. That was a wrong move that caused the illogical Counterclockwise direction to begin with, a half assed lazy solution making Basics an unpopular tool for math and engineer types.


Like QWERTY keyboard standard, bad conventions are hard to over come.

Just an opinion from a low level binary operator. 

[SMcNeill]

Feel free to mod them to whatever coordinate system suits you best.  I'm afraid this is what I was taught in school and how my brain looks at things.  When I see 45 degrees, that should be a diagonal to the up and right.  Anything else makes my brain spin.  

Converting coordinate systems isn't usually that hard.  It's basically just a case of rotating the angles until they match however you like to work with them. 

[bplus]

Yeah I've already made my modifications to arc drawing and pie slices:
https://qb64phoenix.com/forum/showthread...3#pid29203 It's here is case any one might be interested.
but Rings and Ring Arcs are a good addition to that set, so kudos for those. I still need to study your methods of exectuing I am sure it will be interesting stuff from Steve the Amazing (TM)

Before making my criticism about your arc start and end angles, I did a consider a whole graphics library remake rememberig STxAxTIC's coodinate shifting attempts. #1 change is point the freak'n y axis up! The cause of all BASIC's trouble with graphing started there! Oui what allot of thankless work tempted to write off, but doing my own GUI and my own Editor and my own Interpreter are fun and challenging projects for growth of experience, so I put it on my ever expanding ToDo Wish List in QB64.

[The Joyful Programmer]

WALTER'S EDIT: Updated where the spoiler tag is placed. It's funny. I have never seen you do this to anyone else's long posts, Steve, so it appears that you are picking on me because of our past. But, that's Stevie for you.

STEVE EDIT:  As this is a very long post and requires a lot of scrolling and large images, I tossed [ spolier ] tags around it so it won't be as hard to navigate past once read once.  Click the spoiler box below to expand it.

I've been working on filling in some of the missing tools in my draw library and one thing I noticed that I was missing was a really good filled arc routine.   QB64's method was to draw a circle, choose a point inside the arc, and then use PAINT to fill that circle....

and it didn't work as it never seemed to properly close the arcs and then the paint bled out and colored the entire screen.

The CircleFill that I shared and everyone has used for ages and ages works off LINE statements and thus can never bleed outside the circle itself.  It's fast and lovely and nice.

And so, I thought, can I come up with a similar way to do ARCs?  

After a few different tries, this is what I've came up with -- a scanline polygon fill routine for arcs.

It does all the math first and calculates all those points which make up the edges of the circle and the lines of the sides of the arc, and then it draws the lines which makes up the circle.

This seems to work for me, and it seems to work nice and fast enough as to be usable in any program I might have.

You math guru's make take a look at this, go over it with a fine tooth comb like everyone did the CircleFill routine and see what might be improved with it, and share your thoughts with us, if you would.  Without a whole lot of other versions to compare against, I don't know whether to call this really speedy or not.

At the moment, it seems suitable for my personal usage.  I dunno if others have better or faster versions which do the same thing.  If so, please share and let's compare!

(Note that you can really see the polygon code in action if you change the CONST inside the routine.  Heck, there might even be times where you WANT to do so, for some particular reason or the other.  Change it to something like 10! or 20! and then see how our circle looks.  It'll be obvious with those values as to what it's doing for us.  (You can also make the routine *faster* if desired by going with a rougher circle.  Change the value to 2 or 5 and it's not that visually different, but it changes our polygon count by that step.)

CircleFill is nice and fast.  This is my attempt to see if I can do the same style fastness for an ArcFill.  Let me know what you guys think about it. 

I remember when I taught you and the community in 2014 on how to add keywords to QB64. The first keyword I added in a copy of QB64, which I still have, was the filled circle. I remember the "Circle War" we had at that time, trying to come up with the fastest way of filling a circle. I still have screenshots of all of that. Those were the days of fun and good competition.

The filled circle keyword I added, "FCIRCLE", was coded in C and used scanlines to draw them. Each line drawn in the circle actually used QB64's LINE keyword, at least the internal version of it.

On the CPU, scanlines are the fastest and best way to fill polygons of any shape, including circles. Michael Abrash taught this technique in his books in the 1990s, which some had been compiled into his one big book: "Graphics Programming Black Book: Special Edition".

Once you get the hang of scanlines, then rendering glyphs from fonts becomes easy since they are nothing more than complex polygons, as seen in the following screenshot:

Show Content

Spoiler
   

 

That demo was created on my Android phone and uses the SDL2 library. It simply drew lines from one point to another, skipping the control points, which defines the Bezier curve used to curve the edges of the glyph. Here is a screenshot of a glyph with the Bezier curves being drawn:

Show Content

Spoiler
   

 

Of course, coding on a small Android phone can lead to more mistakes because typing is extremely slow unlike on a PC keyboard. An example of that is when I did a filled glyph with scanlines, and the first iteration had an issue. Can you spot the issue in the following screenshot?

Show Content

Spoiler
   

Here's a screenshot showing the points and control points of a glyph:

Show Content

Spoiler
   

 

You could do scanlines on the GPU as well. Have the scanlines generated by a Compute shader and stored in a buffer, and use fragment shaders to render those lines. However, that would use a substantial amount of memory and GPU power when it isn't needed.

You could do what QB64 does internally and convert the glyphs into a spritesheet and draw each glyph as needed with a quad (two triangles - think two _MAPTRIANGLEs to make a box in QB64), and draw those images to the screen as needed. By that too takes up more memory and GPU power than it really needs to. If you're drawing with textured triangles, it is better to use a single, but larger triangle than two triangles. This is a technique I am using in my GPU visual projects. Since I got to the visual aspect of the web browser project I am working on, it was time to get back to the graphical parts of my "Starship BASIC" and "Star Quest BASIC 45" projects, which will also be used as parts of the web browser project.

I have shared a simple QB64 demo where I convert a full-color image to a palette-index colored image, which you can find at https://qb64phoenix.com/forum/showthread.php?tid=4139. I finally rewrote the conversion and dithering aspects of that demo into its GPU counterpart. For the sake of brevity, I'll post more about that GPU project in that thread instead of here. However, here is a screenshot showing the demo:

Show Content

Spoiler
   

 

That screenshot shows the demo being rendered in full-color mode and has four layers being rendered, though the first one is hidden by the second (game) layer.

The following screenshot shows the 1st layer being rendered behind the game layer. The game layer is at 95% transparency.

Show Content

Spoiler
   

 

If you look at the title bar of that demo, you will see that it is being rendered in palette-index mode, using 256 perceptual colors. To make it more interesting, the following screenshot shows the demo being rendered using 16 perceptual colors.

Show Content

Spoiler
   

 

The next screenshot shows the demo being rendered with 256 colors, using the VGA256 original palette colors:

Show Content

Spoiler
   

 

The next screenshot shows the demo using the same VGA256 256-color palette, but with each pixel being draw as 4x4 pixels.

Show Content

Spoiler
   

 

With all that is going on and being rendered, the demo still runs at 60 FPS.

On a side note, the circular demo being drawn behind the game layer looks like this by itself:

Show Content

Spoiler
   

 

That is a shader I found on ShaderToy.com. No scan lines used in the making of that demo.

Also, each layer is rendered to a single triangle which is larger than the window itself. This demonstrates what I was talking about earlier.

Now, touching on the subject of speed. The way QB64 is rendering text to the screen works well with older GPUs (video cards). However, with more modern video cards, it's no longer necessary. Matter of fact, it is an archaic way of doing things.

For example, my PC has a NVIDIA GeForce GTX 1650 video card installed, which was first released in April 2019. It has 4GiB or RAM and supports OpenGL v4.6, Vulkan v1.4, and DirectX 12.1. It can render over 1.6 Billion colored triangles per second, which means at 60 FPS, that's nearly 27 million triangles per frame. The resolution my monitor currently supports is 1920x1080. If we continue with the math and want to fill that resolution with the common 9x16 font (9 pixels wide by 16 pixels high), we would need to draw 14,552 characters on the screen. Let's say that each glyph (character) is built with an average of 100 triangles (without tessellation), that's 1,452,200 triangles that need to be rendered, which is only 5% of the total number of triangles that can be rendered on screen per frame.

Since modern GPUs offer tessellation, which breaks triangles up into multiple triangles, which in turn can be manipulated, can increase the rendering speed even more. Let's not forget about instancing, which can draw multiple triangular objects (of the same type), like a glyph (character), at one time, which in turn, also speeds up rendering. The sphere of cubes demo I shared before in the https://qb64phoenix.com/forum/showthread.php?tid=3945 thread uses instancing to speed up rendering.

The main reason I can think of for drawing text on screen with triangles on modern GPUs is scalability. You can scale the text to any size without losing quality. Other features you can create with triangulated glyphs are 3D text, faster outlining and special effects, and rotated text, like you would see in a Star Wars intro demo.

I hope this post provides some inspiration to people.


Walter W. Whitman
The Joyful Programmer (tm)
AstroCosmic Systems (tm)
etc...

[The Joyful Programmer]

I will admit that the image turned out larger than I expected, so I can see why the post was super long. However, there was no need in wrapping everything up in a SPOILER tag. However, I went ahead and put those images in a spoiler tag themselves so only they are hidden, not the text. The text should never be hidden.

Also, the things I mentioned were not designed to bring up any past wars, and nothing I stated did such a thing. If what I stated brought up some old wounds for you, then I want you to know it was not my intention to do so. So, let's keep the peace here and get back to enjoying coding.



Walter W. Whitman
The Joyful Programmer (tm)
AstroCosmic Systems (tm)
etc...

[bplus]

WALTER'S EDIT: Updated where the spoiler tag is placed. It's funny. I have never seen you do this to anyone else's long posts, Steve, so it appears that you are picking on me because of our past. But, that's Stevie for you.

@The Joyful Programmer
Don't take it personally Walter this is new thing started at this forum to reduce the length of long post made from quoting someone's previous post only to add a sentence at the end for comment. It was getting pretty crazy with guys automatically hitting the quote button for a reply for post above it we just read.

But like all changes it has its plus and minus qualities, one size rarely fits all tastes or situations!

Well take this a little personal, you often rant about how poorly you were treated in previous forums or about all this stuff you do know, to the point of boring people like me. But if you truely want to inspire others (a really good goal like being joyful) answer me this:

Hey what's a scanline? straight up and down lines or across or both? and why might they be so much faster. I think I know a little but I missed the age of 8 bit computing, its a hardware thing I suspect.