For some reason playback speed is only about 1.6x (probably due to
slowing down accesses to the I/O page to 1MHz, so as not to mess up
hardware timings), but happily this comes within 3% of being 44100/2.
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
It doesn't functionally matter since I'm not using any conditional
opcodes in the fast path anyway, but STA removes these side-effects.
Earlier I had mistakenly thought that STA absolute did a
read-before-write on 6502, but this is not the case
(verified with visual6502.org)
- 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.
- For HGRBitmap introduce a packed representation in the form
hhHaaaaaaaABbbbbbbbFff where capitals indicate the location of the
palette bit. i.e. for header and footer we include the neighbouring
2 data bits as in DHGR but also the palette bit from that byte, which
is necessary to understand how these data bits unpack into dots.
The nonstandard ordering of the palette bit for the odd data byte (B)
is so that the masking by byte offset produces a contiguous sequence
of bits, i.e. the 14-bit masked representation is still dense.
- Introduce a to_dots() classmethod that converts from the masked bit
representation of dots influenced by a screen byte to the actual
sequence of screen dots. For DHGR this is the identity map since
there are no shenanigans with palette bits causing dots to shift
around.
- Add a bunch more unit tests, and add back the Sather tests for HGR
artifact colours from palette bit interference, which now all pass!
- Reduce the size of the precomputed edit distance matrix by half by
exploiting the fact that it is symmetrical under
i << N + j <-> j << N + i where N is the size of the masked bit
representation (i.e. transposing the original (i, j) -> dist
metric matrix).
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.
Add a test case that the bmp2dhr output of input filenames containing
'.' are handled correctly.
Break out video.Mode into video_mode.VideoMode to resolve circular
dependency.
- Extract out a (File)FrameSequencer class from Video to encapsulate
the generation of still frames. This also makes Video easier to test.
- Fix FileFrameSequencer.frames() to correctly handle filenames
containing '.'
- Temporarily switch to the BMP2DHR NTSC palette (#5) for evaluation.
Video:
- Temporarily hardcode DHGR decoding
- Optimize _heapify_priorities() by using numpy to vectorize the
construction of the list of tuples. This requires changing the
random nonce to an int so the intermediate array has a uniform type.
- Use the efficient 28-bit representation of DHGR (aux, main, aux,
main) tuples introduced in DHGRBitmap to evaluate diffs
- Switch to np.int type for accumulating diffs, and random.randint(0,
10000) instead of float for nonce values.
- Fix/improve some of the error evaluation in _index_changes:
- skip offsets whose diffs have already been cleared
- hoist some stuff out of _compute_error into the parent
- Add some validation that when we run out of work to do with a frame,
the source and target memory maps should be equal. This isn't
happening sometimes, i.e. there is a bug.
Add a new DHGRBitmap class that efficiently represents the
DHGR interleaving of the (aux, main) MemoryMap as a sequence of
28-bit integers.
This allows for easily extracting the 8-bit and 12-bit subsequences
representing the DHGR pixels that are influenced when storing a byte
at offsets 0..3 within the interleaved (aux, main, aux, main)
sequence.
Since we have precomputed all of the pairwise differences between
these 8- and 12-bit values, this allows us to efficiently compute the
edit distances between pairs of screen bytes (and/or arrays)
(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.
