Conversation

Notices

1. Adrian Cochrane (alcinnz@floss.social)'s status on Friday, 10-Mar-2023 05:02:06 JST Adrian Cochrane

   You may be surprised to learn that 2D vector graphics is more computationally expensive than 3D graphics! While there are people experimenting with how to teach the GPU this, we usually use heavily micro & macro optimized code running on the CPU.

   As mentioned in the first of these threads some early games rewired CRTs to output primitive vector graphics, but the lineage more directly derives from PostScript printers. Which often contained more powerful CPUs than the attached computer.

   1/4?

   • Adrian Cochrane (alcinnz@floss.social)'s status on Friday, 10-Mar-2023 05:08:06 JST Adrian Cochrane

     in reply to

     The public vector graphics APIs typically serve to track globals & gather paths. Those paths are preprocessed using interpolation & matrix transforms typical of computer graphics.

     Also there's geometric simplifications. An iteration removes points imperceptibly close together. A divide & conquer simplifies pathsegments where the furthest point from the approximating straightline makes no perceptible difference.

     Strokes are duplicated, shifted along normal, & connected to become fills.

     2/4?

   • Adrian Cochrane (alcinnz@floss.social)'s status on Friday, 10-Mar-2023 05:12:24 JST Adrian Cochrane

     in reply to

     • requiem 🏴

     @requiem Ah, I just looked up the Vectrex. Not the direction I was heading in, but that's essentially one of those rewired CRTs I mentioned. Add a control unit like you might find in a CPU, with some DACs...

   • requiem 🏴 (requiem@hackers.town)'s status on Friday, 10-Mar-2023 05:12:25 JST requiem 🏴

     in reply to

     @alcinnz 👀 (just recently started studying the Vectrex and want to see where this goes...)

   • Adrian Cochrane (alcinnz@floss.social)'s status on Friday, 10-Mar-2023 05:17:34 JST Adrian Cochrane

     in reply to

     The core logic is in implementing fills, which is done using scanline algorithms! Converting to Run Length Encoded (RLE) bitmaps or axis-aligned trapagons which can be more efficiently filled, using the Tor Scanlines or Bentley-Ottmann algorithms respectively. (note: vector monitors didn't support this)

     Tor Scanlines iterates over the Y-axis to find where the path intersects it. Those results are readily transformed into a RLE-bitmap.

     3/4?

   • Adrian Cochrane (alcinnz@floss.social)'s status on Friday, 10-Mar-2023 05:24:44 JST Adrian Cochrane

     in reply to

     Bentley-Ottmann populates a heap with the path's linesegments as "start" events, whilst tracking which of those line-segments intersects the current scanline in a doubly-linkedlist. Which can readily be transformed into axis-aligned trapagons!

     Upon "start" it inserts the line into the scanline computing the next intersection, if any, with consecutive lines emitting appropriate events. Upon "intersect" it swaps linesegments on the scanline & computes next intersections, if any.

     4/5!

   • Adrian Cochrane (alcinnz@floss.social)'s status on Friday, 10-Mar-2023 05:37:25 JST Adrian Cochrane

     in reply to

     Upon "end" it removes the linesegment from the scanline & tests if its neighbours intersect. All while emitting those trapagons according to the given winding rule.

     These results causes some micro-optimized code (often written in Assembly) to write the computed values from the given "pattern" into the appropriate bytes of the output image, possibly mixing with the previous value.

     5/5 Fin! See also: https://adrian.geek.nz/graphics_docs/cairo.html

     Until recently most productivity UIs were drawn this way.