[continued from previous message]   
      
   >>> currently assuming its use for mostly hand-edited files. Unlike SVG,   
   >>> it also assumes drawing to a pixel grid rather than some more   
   >>> abstract coordinate space (so, its abstract model is more like "MS   
   >>> Paint" or similar); also SVG would suck as a human-edited format.   
   >>>   
   >>> 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.   
   >   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)