@powersoffour Oh, interesting! No, I haven't, but that looks amazing! I know that @JuliaMinamata has done some stuff in the past matching embroidery thread to CGA/EGA palettes which looks so awesome! But i'll definitely file this away for a rainy-day!
New blog-post up where I break down the algorithm that you may have seen me using recently for generating watercolor-like effects. If you are interested in how its done and some of the maths behind it, then I do my best to break it all down with interactive examples.
Spent way more time of this today, but I'm actually pretty happy with the way its turned out so far. Here is quick illustration of the relationships between different generative composited layers for PIC.022 from the SCI0 King's Quest remake.
1. The wash layer 2. The color gradient 3. The marker/ink layer 4. The sketch/pencil layer
@powersoffour Oh for sure, one could definitely say that ICEMAN (and by extension Conquests of Camelot) took custom dithering pairs a little *too far*, a common critique of those titles' graphics.
But you can see Doug Herring's work on Colonels Bequest, that in the right hands, its quite powerful. It's a beautiful EGA-era game
On the tech side, by the time you get to QfG2, some of those backgrounds have 4 variants: day/night in two different cities. A EGA palette swapping feat!
@powersoffour But also, you can look at those early SCI0-era games, and kinda see where those limitations had affected the "style". And how they could have (probably would have) looked a little different given some future advancements. Thats not a "knock" on them, as games, but its interesting to see how they adapted to those constraints.
@powersoffour There are contemporary accounts of Peter Ledger's (artist on Camelot) frustration over some of the limitations of EGA and engine. Ledger was a traditional artist with a background in comic books and illustration. Some of the artwork in Conquests of Camelot is really impressive—like better than anything else from the era, tbh—even given the frustrating constraints for him as an artist. He tragically passed away in 1994.
So, you might be asking yourself: "What was up with that colorization action on the 'copter?!" Well, you might be asking yourself that if you are weirdo like me.
It fills with a Black/Green dither, and then manually draws magenta lines over the black to get a "manual" Green/Magenta dither... A natural question to ask is "Why didn't it just fill with Green/Magenta in the first place?", something if you look at the "spec" for SCI0 and ScummVM/other-implementations would allow!
…and if this game was released in '89, it probably *would* have done that.
However, LSL2 released in Oct '88, it was the immediate follow-up to Sept's KQ4.
Its important to remember that the SCI0 engine wasn't an atomic "thing", instead it was constantly evolving behind the scenes. In this case, the SET_PALETTE commands hadn't been implemented yet. They do not appear *at all* KQ4, LSL2, or PQ2. Meaning, they pretty much were stuck with the default palette.
Dark-green/dark-magenta dither is not an option! But, that was the dither pairing that the artist was going for, so... they just drew the dither *manually* across a ton of commands! Easily way more "expensive", in terms of bytes-on-disk than a palette command, but i'm sure there were other "risks" involved with updating the engine itself to support that.
By PQ2 you start to see some of the PALETTE_UPDATE commands (which alter single palette entries)
You don't start to see the full palette reassignments until Codename: ICEMAN and Colonel's Bequest in late 1989.
Hero's Quest (QfG1) would use that feature *extensively* for its rendering of day/night cycles, so it definitely exists by then. But yea... KQ4 and LSL2 definitely didn't have access to that tooling, and so you see weird stuff like this in the byte-stream.
@powersoffour Actually, I didn't have the numbers off-hand, but they are easy enough to calculate. I wrote up a quick script for Quest for Glory 2.
On *average*, compressing the PIC data with the Huffman compression it uses results in ~1.2∶1 ratio (or savings of around 16.0%).
The PIC that benefits the *most* from the Huffman compression is PIC.190, which scores a whopping 1.5∶1 compression ratio. Saving nearly 3k (10,045 bytes to 6,806 bytes)
@powersoffour However, that doesn't tell the *entire* story, because the PIC data is already a way more efficient format than the raw 320×190 4-bit images they represent. If you squash two 4-bit pixels into each byte, then it takes 30,400 bytes for each full background.
So, on *average* the savings is closer to a compression ratio of 6.6∶1 (or around a 84.8% reduction) over totally uncompressed EGA screens. Which is pretty impressive overall.
It might not look like much, but I'm actually super happy with this... I've been meaning to take a crack at it for a quite a while, and finally made some progress on a WebGL-based renderer output for my javascript SCI0 renderer. This incorporates both configurable barrel-distortion and vignetting. It's not cranked up to something ridiculous, but I think provides a nice "feel". There is still more that I want to work on/prototype out. But its really satisfying to get to this point.
Developer ∪ Designer, pixel artist, digital archaeologist of Sierra On-Line games, retro IBM PCjr developer, baker. An Ernie in a world of Berts. (They/them)