packed representation (diff, apply etc). This allows the (D)HGRBitmap
classes to focus on the bitmap packing and share common logic.
Numpy has unfortunate long-standing bugs to do with type coercion of
np.uint64, which leads to spurious "incompatible type" warnings when
e.g. operating on a np.uint64 and some other integer type. To work
around this we cast explicitly to np.uint64 everywhere.
Get tests working again - for now HGR tests in screen_test.py are
disabled until I finish implementing new packing.
HGRBitmap is still incomplete although closer.
- 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.
