make_edit_distance
- use MASKED_DOTS since it does not have a simple relationship to the
HEADER_BITS/BODY_BITS for HGR
- try disabling transposition distances for Damerau-Levenshtein, this
may give better quality
screen
- introduce separate notion of MASKED_DOTS which is the number of
(coloured) pixels we can extract from MASKED_BITS. For HGR this is
not the same.
- fix bug in _fix_array_neighbours that was not fixing headers for HGR
- don't cache everything in byte_pair_differences, it's effectively
unbounded. Using 1M for LRU size seems to work just as well in
practise, without leaking memory.
- fix bug in _diff_weights when comparing content, we want to evaluate
the effect of storing content byte in each offset separately, not
cumulatively.
- add a consistency check function (not currently wired up) to assert
that headers/footers are in sync across columns
- HGR should have 16 body bits, this was causing headers not to
propagate correctly to/from neighbouring column
- add test case for this bug
video
- Use 8 random bits consistently, using 16 in some places may have
introduced bias
- ignore palette bit when comparing 0x00 and 0x7f in sanity check
- Only compute the upper triangle since the matrix is symmetrical and
we can reconstruct the rest cheaply at load time
- Compute edit distances for HGR as well by making use of the fact that
the masked representation is 14-bit but still sparse.
- Add sanity checks for various invariants of the edit distance matrices.
- naive version of NTSC artifacting, it uses a sliding 4-bit window to
assign a nominal (D)HGR colour to each dot position. A more
sophisticated/correct implementation would model the YIQ signal
directly.
- Switch DHGRBitmap implementation to use a 34-bit representation of
the 4-byte tuple, comprised of a 3-bit header and footer, plus
4*7=28-bit body. The headers/footers account for the influence on
neighbouring tuples from the 4-bit NTSC window.
- With this model each screen byte influences 13 pixels, so we need to
precompute 2^26 edit distances for all possible (source, target)
13-bit sequences.
- Checkpointing not-yet-working HGR implementation.
- Add new unit tests but not yet all passing due to refactoring
IIGS palettes.
Move the palette diff_matrix generation into make_data_tables.py since
that is the only place it is used.
Demand-load the edit distance matrices when transcoding.
(3-pixel) sequences that may be modified when storing bytes to the
DHGR display.
This relies on producing an efficient linear representation of the
DHGR framebuffer in terms of a packed 28-bit representation of (Aux,
Main, Aux, Main) screen bytes.
