requiring callers to keep track of it
- stop trying to cache content_deltas, I think it results in losing
deltas. Instead just recompute the deltas for each page as we need
it. This is fast enough in practice.
- track the average fill rate for the additional offsets we emit.
This should be close to 3 if we're succeeding in finding enough
collateral work
- overhaul how we pass in the target memory maps. The previous way
didn't make sense: we weren't actually encoding for the target video
frame, but were using an inconsistent mix of old and new frames. I
think this was causing image artifacting because we were aiming for
the wrong thing.
- Add some debugging assertions that were used to track this down.
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
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.
Switch from 14340Hz to 14700Hz, which is 44100/3 i.e. a divisor of the
most common audio input sample rate. This gives better quality
(and/or faster to encode) audio quality at the cost of producing <2%
faster playback.
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.
- Every time we process an ACK opcode, toggle page 1/page 2 soft
switches to steer subsequent writes between MAIN and AUX memory
- while I'm here, squeeze out some unnecessary operations from the
buffer management
On the player side, this is implemented by maintaining two screen
memory maps, and alternating between opcode streams for each of them.
This is using entirely the wrong colour model for errors, but
surprisingly it already works pretty well in practise (and the frame
rate is acceptable on test videos)
DHGR/HGR could be made runtime selectable by adding a header byte that
determines whether to set the DHGR soft switches before initiating
the decode loop.
While I'm in here, fix op_terminate to clear keyboard strobe before
waiting.
- can't emit Terminate opcode in the middle of the bytestream
- pad the TCP stream to next 2k boundary when emitting terminate opcode,
since the player will block until receiving this much data.
