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.
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.
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.
DHGR playback modes. Actually the only difference is whether to
initialize (D)HGR display since everything else is steered by the video
stream. 6 of these bytes are currently unused, but it is convenient
to pad to the same length as the TICK opcode so that it does not
complicate the ACK stream framing.
Move towards the convention of using upper-case labels for system use
(soft switches etc) and lower-case for program use.