Post

thirty-two
@j.holmes.codes

Today, I'm finally working on implementing the HERCMONO.DRV render filter for my javascript SCI0 parser, needed up "de-optimize" my nearest-neighbor scaler, so that it works with non-integer scale factors (which is all I needed before). Its time to extract actual dithers, from the test pattern

thirty-two@j.holmes.codes

Doing some more research on the Sierra SCI "undocumented" mono commands. Think this is a "correct" implementation: - Setting VISUAL *always* sets MONO to PAL mode of the same pal index - Clearing VISUAL *always* clears MONO

thirty-two
@j.holmes.codes

so, got all the values defined, but my mapping is not right somewhere, going to have to double check the decoder to make sure i'm resolving the correct dither when generating the mono layer.

thirty-two
@j.holmes.codes

lol, i had one extra comma in my patterns definition which was injecting an empty pattern into the set, throwing off my mappings! left is my rendered, the right is reference i think i also tweaked the nearest-neighbor scaler to round the same way the reference implementation does too.

thirty-two
@j.holmes.codes

There. fixed up the two patterns that I had just transcoded incorrectly into bits and we get a render that mostly matches, plus-or-minus some offset errors in the bitmasks, but i think its *pretty* right, lets try re-rendering our reference scene again

thirty-two
@j.holmes.codes

Alright, after a few offset tweaks, I think i found the right bit-layout, needed coordinate adjustment of [+1, -1], but i dont immediately see any pixels that are off, without doing a pixel by pixel check

thirty-two
@j.holmes.codes

So aside from nearest-neigbor scaling weirdness (and generally other rounding errors/liberties that my renderer takes), the should be *pretty accurate* to the original reference implementation at this point.

thirty-two
@j.holmes.codes

Now, I just need to let you customize the phosphor color, comp it to the correct resolution and do pixel-aspect correction. Then I get to think about ways we can abuse this for *other* rendering types.

thirty-two
@j.holmes.codes

Like I said when I started this, I dont know if anybody has *actually* ever implemented this in a modern engine—I mean, I see why, who's playing 1989 Sierra games with a deep nostalgia for the relatively unpopular Hercules graphics mode, even back then!—but, I know for a fact that ScummVM doesn't.

0 reposts1 like

thirty-two
@j.holmes.codes

but i don't think any of the other decoders/engines/tools i've seen *also* do it. so... maybe this is first? hard to say!

thirty-two
@j.holmes.codes

but its a shame that more people didn't get to appricate the work that Douglas Herring and Gerald Moore put in to Colonels Bequest to ensure that their game looked good in pure monochrome. It looks like the only game that used this feature of the engine, and every picture has MONO codes it.

thirty-two
@j.holmes.codes

It was obviously something they were passionate about doing, for a very limited market, even at the time. Even the iconic PIC.028, your first introduction to Misty Acres is lovingly crafted for monochrome and not a straight-up "easy" mapping of EGA 16 color to black and white.