New DOUBLE LORES test converts gradient-80x48.bmp with "DL N" and
diffs against the checked-in GRADIENT.DLORES reference. Add a
.gitignore for the built binary and generated .SLO/.DLO outputs.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BCcEM6zYoVcXQt5YfvFo16
The glyph row was plotted before the bounds check, and the
post-increment test (y++ > 191) only breaks after row 192 has
already been plotted — indexing one past the end of the 192-entry
HB[] table and writing through a garbage offset. A 32-line title
text file triggers this (line 32 plots glyphs at y=187/188, whose
rows reach 192-193), silently corrupting the output image. Use a
pre-increment so the loop stops after plotting row 191; plotted
output for in-bounds glyphs is unchanged (verified byte-identical
for a 31-line title file).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BCcEM6zYoVcXQt5YfvFo16
ConvertMono seeks to the stored row for image line 2y, but read the
second line of the pair sequentially — which in a bottom-up BMP is
the stored row above (image line 2y-1), not below; the pos -= packet
only updated the variable. Output line 0 averaged the top line with
a read past EOF, every other line averaged with the previous line
instead of the next, and the bottom source line was never read —
a half-line vertical phase shift in 560x384 color mono conversions.
Seek to the decremented pos so the pair is image lines 2y and 2y+1.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BCcEM6zYoVcXQt5YfvFo16
In the tags-off, non-MSDOS naming branch, the mono mainfile/auxfile
names were copy-pasted from the tags-on branch complete with #062000
suffixes, so "b2d img.bmp mono A" produced IMGM.BIN#062000 and
IMGM.AUX#062000 even though the T option was never given.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BCcEM6zYoVcXQt5YfvFo16
The 40x48/80x48 and 160x96 mixed text/graphics cases used
(jyoffset > -1 || jyoffset < 9), which is always true, unlike the
&& used by every parallel branch. With J given but JT unset (or out
of range), jyoffset became 9 (or negative) and ResizeBMP's unguarded
offset += jyoffset * packet seeked past the pixel data, producing
shifted or garbage rows. Out-of-range values now fall through to the
top-justified default like the other branches.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BCcEM6zYoVcXQt5YfvFo16
DLR conversion produces an 80x48 source bitmap, then needs to output
even columns of pixels for the aux memory half and odd columns of
pixels for the main memory half. The conversion was incorrectly
processing just the first 40 pixels of each row twice.
Tweak the coordinate lookups during the output pass to get the correct
pixels.
Dagen BrockandClaude Fable 5
Dagen Brock
Joshua Bell