1. Forum
  2. FidoNet
  3. SYNC PROGRAMMING

  • src/syncterm/ripper.c

    From Deucе@1:103/705 to Git commit to main/sbbs/master on Wednesday, April 01, 2026 23:54:25
    https://gitlab.synchro.net/main/sbbs/-/commit/679e5bae93abe08984256ab6
    Modified Files:
    src/syncterm/ripper.c
    Log Message:
    With the help of Claude, exactly match RIPTERM ellipses

    I had assumed they used McIlroy for Ellipses, so could only get
    close... they had actually used the two-region Bresenham, the reason
    I didn't get that to match was that they apparently scale by 100 to
    "avoid rounding", so my truncation was wildly different.
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to Git commit to main/sbbs/master on Thursday, April 02, 2026 01:31:45
    https://gitlab.synchro.net/main/sbbs/-/commit/d1c27d856bf669d666f637a8
    Modified Files:
    src/syncterm/ripper.c
    Log Message:
    And fix arcs too!

    We actually needed to extract the trig tables BGI uses to get this
    to work out right... fighting with floating point was not the way.
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to Git commit to main/sbbs/master on Thursday, April 02, 2026 15:55:01
    https://gitlab.synchro.net/main/sbbs/-/commit/7e79e2c43826ac8dedb24347
    Modified Files:
    src/syncterm/ripper.c
    Log Message:
    Much better bezier match

    replace per-iteration step/cnt division with accumulated
    t += 1.0/cnt.

    This produces the SAME ERROR I see from the RIPterm across obvious
    test vectors.

    The old code was "too correct", RIPterm appears to accumulate error
    and never correct for it.
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to Git commit to main/sbbs/master on Thursday, April 02, 2026 18:19:25
    https://gitlab.synchro.net/main/sbbs/-/commit/81b7dd81d2a640500ae7961f
    Modified Files:
    src/syncterm/ripper.c
    Log Message:
    Mostly cleanup stuff...

    Clean up old use of a hack bit, use the new polyfill for the RIP
    command, clean up some comments, and get XOR working properly
    everywhere.
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to Git commit to main/sbbs/master on Thursday, April 02, 2026 19:20:37
    https://gitlab.synchro.net/main/sbbs/-/commit/179725429e08522795487d5f
    Modified Files:
    src/syncterm/ripper.c
    Log Message:
    Some more button fixups.

    1. !|1U missing <res> field - no longer draws the button (per RIPterm)
    2. Recessed inner corner pixels - removed explicit cc-colored corner
    pixels on inner recess border (RIPterm lets the bg lines overlap naturally) 3. Chisel inset height off-by-one — y2 - y1 + 1 → y2 - y1 since box.y2 is
    exclusive
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to Git commit to main/sbbs/master on Thursday, April 02, 2026 22:12:09
    https://gitlab.synchro.net/main/sbbs/-/commit/fadd8eb62fe426eee68a0964
    Modified Files:
    src/syncterm/ripper.c
    Log Message:
    Handle thick ellipses better.

    It looks like when drawing a thick ellipse, it draws multiple thick
    line segments. Now that we have the Borland cos/sin tables, we can
    do that ourselves as a special case.
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to Git commit to main/sbbs/master on Friday, April 03, 2026 08:52:32
    https://gitlab.synchro.net/main/sbbs/-/commit/9684acff780621441b3c1194
    Modified Files:
    src/syncterm/ripper.c
    Log Message:
    Fix parse_mega() buffer overreads

    Many places were calling parse_mega() without checking the return
    value, then calling parse_mega() on the string AFTER the previous
    one. This means that on truncated invalid RIP sequences, ripper
    would read past the end of the allocation.

    This fix was complicated by the fact that the "last" item in a
    parameter list can be truncated as long as it has at least one
    valid byte in it.

    This now uses a vararg function and parses them all at once (mostly).
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)