Synchronet now requires the libarchive development package (e.g. libarchive-dev on Debian-based Linux distros, libarchive.org for more info) to build successfully.

  1. 23 May, 2021 5 commits
  2. 22 May, 2021 16 commits
  3. 21 May, 2021 9 commits
    • Deucе's avatar
      Add a new RIP utility library · 3eee7f7a
      Deucе authored
      Currently, this has RIP.supported which returns true if RIP is
      supported by the client, and rip.loadicons(archive) which sends
      all the icons (and .RIP files) in the specified archive (either
      an Arcive object or a filename) to the remote if they don't
      already have them.
      
      If you have a RIP enabled door, a small JS script as a pre-run
      command like this:
      
      require("rip.js", "RIP");
      rip.loadicons('/sbbs/xtrl/lord/lordicns.zip');
      
      Will automatically send all the icon files in the arcive to the
      user if the user doesn't already have them.  For SyncTERM as of
      this commit, they will be placed in the cache directory for that
      BBS (and only be available for that BBS).
      
      On *nix, the cache dir is ~/.syncterm/cache/<bbsname>
      On Win32 it's something like:
      C:\Users\User\AppData\Local\Microsoft\Windows\INetCache\SyncTERM\cache\<bbsname>
      
      No ideal what it is on macOS.
      3eee7f7a
    • Deucе's avatar
      Fix newly-introduced memory leak... · a7a1c268
      Deucе authored
      I was going to start keeping the old rect around again, but that
      idea didn't pan out.  This massive memory leak is what I get for
      not doing more commits while tuning.
      a7a1c268
    • Deucе's avatar
      05b3074f
    • Deucе's avatar
      Fix auto-transfers · 04017243
      Deucе authored
      04017243
    • Deucе's avatar
      Try to remove the extra "SyncTERM" from the BBS cache path on Win32 · ef44d78a
      Deucе authored
      Reported by Booch (Thanks!)
      ef44d78a
    • Rob Swindell's avatar
    • Rob Swindell's avatar
      Have movefile() leave the original file with the delete attribute · 4c912de9
      Rob Swindell authored
      This has the effect of the file being listed as absent/deleted in the listing that's in memory. As requested by Phil, plt via irc.
      
      Moving a file after this change did result in a crash once, but I couldn't reproduce it with a debugger attached.
      4c912de9
    • Deucе's avatar
      Fix bug in last commit · a40cda0c
      Deucе authored
      Pixes set via setpixels() were only set in the "blink off" screen
      and not in the "blink on" screen... so they all reverse blinked.
      a40cda0c
    • Deucе's avatar
      Optimizations: · b5488bb3
      Deucе authored
      1) Keep a rectangle updated per-screen rather than regenerate each time
      2) Strip palette info when putting pixels into rectangles rather than
         during scaling
      3) Tighten up the screen locks a bit
      4) Don't require a full resend of both screens on an update request
      5) Only force a redraw for cursor movement when the cursor is visible
         (And force it whenever the cursor changes)
      6) Avoid doubles in interpolation
      7) Heavily optimize interpolate_height()
         interpolate_width() likely doesn't need it because it's generally not
         used and also it reads from the next pixel in memory making the
         prefetchers job easier.
      8) Fix some memory-leak-on-error issues
      9) For ARGB8 XImages, manipulate the data directly rather than through
         XPutPixel()
      
      At this point, the scaling and X11 output time is heavily dominated by
      cache misses.  The only really effective way to reduce this hit is to
      spread the work across all the L3 caches in the system or move it into
      the GPU.
      
      With the latest updates, at the SyncTERM menu, over 90% of the time is
      spent in the rendering pipeline, and over 90% of that time is spent
      thrashing the caches... the only real easy win left is vectorizing, but
      that's highly compiler specific.
      
      To that end, I've switched to -O3 for release builds.  There was a comment
      that -finline-functions broke Baja "badly", but that's clearly false since
      -f-inline-functions has been part of -O2 for quite a while now, and Baja
      doesn't seem any more broken that it ever was.
      b5488bb3
  4. 20 May, 2021 10 commits