In the highly underrated Steampunk novel The Difference Engine, the equivalent of cinema houses delivered a pixelated moving image displayed by tiles which could be flipped mechanically. The control engine for orchestrating the movement of the these tiles was a large noisy machine controlled by a deck of punched cards.
Your task is to emulate such an engine and display a pixelated animation as specified by an input file. The input consists of lines in a fixed-width format, but you may assume whatever is convenient for a line-ending indication. The format is:
SSSSYYxxXXOA
SSSS: 4 digit sequence no. may be padded by blanks or all blank
YY: the y coordinate affected by this line (descending, top is 0, bottom is m-1)
xx: the starting x coordinate
XX: the ending x coordinate
O: hexadecimal opcode
A: argument (0 or 1)
The input is explicitly sequenced (if you ever drop your deck of cards on the floor, you'll thank me for this part). That means the program must perform a stable sort of the input lines using the sequence field as a sort key. Lines with the same sequence number must maintain their original relative ordering. (It should work with an unstable sort, if you append the actual line number to the key.) A blank sequence field should be interpreted as lower than any number (ascii collation sequence).
A single statement line can only affect a single y coordinate, but may specify a contiguous range of x values. The ending x value may be left blank or may be identical to the initial value in order to affect a single pixel.
The opcode is a hexadecimal digit which specifies the Universal Binary Function Code which is used as a rasterop. The argument is 0 or 1. The raster operation performed is
pixel = pixel OP argument infix expression
--or--
OP(pixel, argument) function call expression
So the original value of the pixel enters as X in the UBF table, and the argument value from the statement enters as Y. The result of this function is the new value of the pixel. And this operation is performed upon each x,y pair from xx,YY to XX,YY specified in the statement. The range specified by xx and XX includes both end-points. So
0000 0 010F1
should set pixels 0,1,2,3,4,5,6,7,8,9,10 on row 0.
Output dimensions (m x n) should be 20 x 20 at a minimum, but may be larger if desired. But the grain should show, you know? It's supposed to be pixelated. Both graphical and ASCII-art output are acceptable.
If for example, we wanted to make an image of a pixelated figure:
# #
###
##
####
#
#### ####
# #
###
# #
# #
If we draw him with a bit-flipping op, like XOR, it can be drawn and erased regardless of whether the screen is black or white.
00020261
0 6 661
1 3 561
2 3 461
3 3 661
4 4 461
5 0 361
5 5 861
6 3 361
6 5 561
8 3 561
9 3 361
9 5 561
10 3 361
10 5 561
Duplicating this sequence will make the figure appear and disappear.
A larger animation can be composed out-of-order, by specifying different "shots" in the sequence field.
100 016F0
101 016F0
102 016F0
103 016F0
104 016F0
105 016F0
106 016F0
107 016F0
108 016F0
109 016F0
110 016F0
111 016F0
112 016F0
113 016F0
114 016F0
115 016F0
200020261
2 0 6 661
2 1 3 561
2 2 3 461
2 3 3 661
2 4 4 461
2 5 0 361
2 5 5 861
2 6 3 361
2 6 5 561
2 8 3 561
2 9 3 361
2 9 5 561
210 3 361
210 5 561
00020261
0 6 661
1 3 561
2 3 461
3 3 661
4 4 461
5 0 361
5 5 861
6 3 361
6 5 561
8 3 561
9 3 361
9 5 561
10 3 361
10 5 561
300020261
3 0 6 661
3 1 3 561
3 2 3 461
3 3 3 661
3 4 4 461
3 5 0 361
3 5 5 861
3 6 3 361
3 6 5 561
3 8 3 561
3 9 3 361
3 9 5 561
310 3 361
310 5 561
00020261
0 6 661
1 3 561
2 3 461
3 3 661
4 4 461
5 0 361
5 5 861
6 3 361
6 5 561
8 3 561
9 3 361
9 5 561
10 3 361
10 5 561
Producing:
This is code-golf so shortest program (by byte-count) wins. Bonus (-50) if the engine makes clickity-clack noises.
x
coord always inclusive? \$\endgroup\$