[continued from previous message]   
      
   >> Granted, one could argue maybe it could make scope that asset-   
   >> processing is its own tool, then one converts it to a format that the   
   >> compiler accepts (WAD2 or WAD4 in this case) prior to compiling the   
   >> main binary (and/or not use resource data).   
   >>   
   >> Still, IMO, an internal WAD image is still better than the horrid/   
   >> unusable mess that Windows had used (where anymore most people don't   
   >> bother with the resource section much more than storing a program icon   
   >> or similar...).   
   >>   
   >> But, realistically, one does still want to limit how much data they   
   >> stick into the EXE.   
   >>   
   >> ...   
   >>   
   >>   
   > My forays into the world of graphics formats are pretty limited. I tend   
   > to use libraries already written by other people. I assume people a lot   
   > brighter than myself have come up with them.   
   >   
      
   I usually wrote my own code for most things.   
      
   Not dealt much with FLIC.   
      
      
   In the past, whenever doing animated stuff, had usually used the AVI   
   file format. A lot of time, the codecs were custom.   
      
   Both AVI (and BMP) can be used to hold a wide range of image data,   
   partly as a merit of using FOURCCs.   
      
   Over the course of the past 15 years, have fiddled a lot here.   
      
      
      
   A few of the longer-lived ones:   
      BTIC1C (~ 2010):   
        Was a modified version of RPZA with Deflate compression glued on.   
      BTIC1H:   
        Made use of multiple block formats,   
          used STF+AdRice for entropy coding, and Paeth for color endpoints.   
        Block formats, IIRC:   
          4x4x2, 4x2x2, 2x4x2, 2x2x2, 4x4x1, 2x2x1, flat   
            4x4x2: 32-bits for pixel selectors   
            2x2x2: 8 bits for pixel selectors   
      BTIC4B:   
        Similar to BTIC1H, but a lot more complicated.   
        Switched to 8x8 blocks, so had a whole lot of block formats.   
      
   Shorter-Lived:   
      BTIC2C: Similar design to MPEG;   
      IIRC, used Huffman, but updated the Huffman tables for each I-Frame.   
        This sort of thing being N/A with STF+AdRice,   
          which starts from a clean slate every time.   
      
      
   1C: Was used for animated textures in my first 3D engine.   
      
   1H and 4B could be used for video, but were also used in my second 3D   
   engine for sprites and textures (inside of a BMP packaging).   
      
      
   My 3rd 3D engine is mostly using a mix of:   
      DDS (mostly DXt1)   
      BMP (mostly 16 color and 256 color).   
      
   Though, in modern times, things like 16-color graphics are overlooked,   
   in some cases they are still usable or useful (or at least sufficient).   
      
   Typically, I had settled on a variant of the CGA/EGA color palette:   
      0: 000000 (Black)   
      1: 0000AA (Blue)   
      2: 00AA00 (Green)   
      3: 00AAAA (Cyan)   
      4: AA0000 (Red)   
      5: AA00AA (Magenta)   
      6: AA5500 (Brown)   
      7: AAAAAA (LightGray)   
      8: 555555 (DarkGray)   
      9: 5555FF (LightBlue)   
      A: 55FF55 (LightGreen)   
      B: 55FFFF (LightCyan)   
      C: FF5555 (LightRed)   
      D: FF55FF (Violet)   
      E: FFFF55 (Yellow)   
      F: FFFFFF (White)   
      
   I am not sure why they changed it for the default 16-color assignments   
   in VGA (eg, in the Windows 256-color system palette). Like, IMO, 00/AA   
   and 55/FF works better for typical 16-color use-cases than 00/80 and 00/FF.   
      
   Sorta depends on use-case: Sometimes something works well as 16 colors,   
   other times it would fall on its face.   
      
      
      
   Most other designs sucked so bad they didn't get very far.   
      
   Where, I had ended up categorizing designs:   
      BTIC1x: Designs mostly following an RPZA like path.   
        1C: RPZA + Deflate   
          Mostly built on 4x4x2 blocks (32 bits).   
        1D, 1E: Byte-Encoding + Deflate   
          Both sucked, quickly dropped.   
          Both were like RPZA both with 48-bit 4:2:0 blocks.   
          Neither great compression nor particularly fast.   
            Deflate carries a high computational overhead.   
        1F, 1G: No entropy coding (back to being like RPZA)   
          Major innovations: Variable-size pixel blocks.   
        1H: STF+AdRice   
          Mostly final state of 1x line.   
      BTIC2x: Designs mostly influenced by JPEG and MPEG.   
        Difficult to make particularly fast.   
        1A/1B: Modified MJPEG IIRC.   
          Technically, also based on my BTJPEG format (*1).   
        2C: IIRC, MPEG-like, Huffman-coded.   
          Well influenced by both MPEG and the Xiph Theora codec.   
        2D: Like 2C, but STF+AdRice   
        2E: Like 2C, but byte stream based   
          Was trying, mostly in vain, to make it faster.   
          My attempts at this style of codecs were mostly, too slow.   
        2F: Goes back to a more JPEG like core in some ways.   
          Entropy and VLN scheme borrows more from Deflate.   
            Though, uses a shorter limit on max symbol length (13 bit).   
            13 bit simplifies things and makes decoding faster vs 15 bit.   
          Abandons DCT and YCbCr in favor of Block-Haar and RCT.   
            Later, UPIC did similar, just with STF+AdRice versus Huffman.   
      BTIC3x:   
        Attempts to hybridize 1x and 2x   
        Nothing implemented, all designs too complicated to bother with.   
      BTIC4x:   
        4A: RPZA-like but with 8x8 blocks and multiple block sizes.   
        4B: Like 4A but reusing the encoding scheme from 1H.   
      BTIC5x:   
        5A: Resembled a CRAM/QOI hybrid, but with 8-bit indexed colors.   
          No entropy coding.   
        5B: Like 5A, but used differential RGB555 (still QOI like).   
          Major innovation was to use a 6-bit 64-entry pattern table.   
          Optionally, can use per-frame RP2 or TKuLZ compression.   
            Used if doing so results in a significant savings.   
      
      
   *1: BTJPEG was an attempt at making a more advanced image format based   
   on tweaking the existing T.81 JPEG format in a way that sorta worked in   
   existing decoders. The more widespread use (and "not totally dead"   
   feature) being to allow for an embedded alpha channel as essentially   
   another monochrome JPEG inside the APP11 marker.   
      
   I had tried a bunch of other ideas, but it turned into a mess of   
   experimental tweaks, and most of it died off. The surviving variant is   
   basically just T.81+JFIF with an optional alpha channel (ignored by a   
   non-aware JPEG decoder).   
      
   Some other (mostly dead) tweaks were things like:   
   Allowing multi-layered images (more like Paint.NET's PDN or GIMP's XCF,   
   mostly by nesting the images like a Matryoshka doll), where the   
   top-level image would contain a view of all the layers rendered together;   
   Allowing lossless images (similar to PNG) by using SERMS-RDCT and RCT   
   (where SERMS-RDCT was a trick to make the DCT/IDCT transform exactly   
   reversible, at the cost of speed).   
      
      
   In the early 2010s, I was pretty bad about massively over-engineering   
   everything.   
      
   Later on, some ideas were reused in 2F and UPIC.   
   Though, 2F and UPIC were much less over-engineered.   
      
   Did specify possible use as video codecs, but thus far both were used   
   only as still image formats.   
      
   The major goal for UPIC was mostly be to address the core use-cases but   
   also for the decoder to be small and relatively cheap. Still sorta JPEG   
   competitive despite being primarily cost-optimized to try to make it   
   more viable for use in programs running on the BJX2 core (where JPEG   
   decoding is slow and expensive).   
      
   As for Static Huffman vs STF+AdRice:   
      Huffman:   
        + Slightly faster for larger payloads   
        + Optimal for a static distribution   
        - Higher memory cost for decoding (storing decoder tables)   
        - High initial setup cost (setting up decoder tables)   
        - Higher constant overhead (storing symbol lengths)   
        - Need to provision for storing Huffman tables   
      STF+AdRice:   
        + Very cheap initial setup (minimal context)   
        + No need to transmit tables   
        + Better compression for small data   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)