[continued from previous message]   
      
   >>>> process and convert them into another set of files, usually inside   
   >>>> of some sort of VFS image or similar).   
   >>>>   
   >>>> Design is much more simplistic than something like SVG and I am   
   >>>> 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   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)