ii-vision/transcoder/make_data_tables_test.py

import unittest

from colours import HGRColours
import make_data_tables


class TestMakeDataTables(unittest.TestCase):
    def test_pixel_string(self):
        pixels = (HGRColours.BLACK, HGRColours.WHITE, HGRColours.ORANGE)
        self.assertEqual("0FC", make_data_tables.pixel_string(pixels))


if __name__ == '__main__':
    unittest.main()
Precompute the edit distance between the 8-bit (2-pixel) and 12-bit (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. 2019-06-13 21:58:10 +00:00			`import unittest`

Checkpoint WIP for easier comparison to dhgr branch: - 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 2019-07-02 21:40:50 +00:00			`from colours import HGRColours`
Precompute the edit distance between the 8-bit (2-pixel) and 12-bit (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. 2019-06-13 21:58:10 +00:00			`import make_data_tables`


			`class TestMakeDataTables(unittest.TestCase):`
			`def test_pixel_string(self):`
Checkpoint WIP for easier comparison to dhgr branch: - 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 2019-07-02 21:40:50 +00:00			`pixels = (HGRColours.BLACK, HGRColours.WHITE, HGRColours.ORANGE)`
Precompute the edit distance between the 8-bit (2-pixel) and 12-bit (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. 2019-06-13 21:58:10 +00:00			`self.assertEqual("0FC", make_data_tables.pixel_string(pixels))`


			`if __name__ == '__main__':`
			`unittest.main()`