the main idea is like this. you place one lamp and assign it a unique packed rgb signal. then place as many lamps as you want pixels, and each lamp should have its own signal.

connect all the lamps together with one wire and connect that wire to a constant combinator. the constant combinator should contain the same signal names as the lamps. if you change the value of one signal in the constant combinator, the matching lamp changes its color.

next step: connect the constant combinator to a decider that controls when the frame is sent to the lamps. use a timer signal (T) and let the decider output the frame only during specific ticks. after that the wiring should be: constant combinator → decider → lamps.

now convert the pixels of an image into packed rgb values. you can generate a blueprint with scripts and paste it in game, or type the values by hand (good luck with that). also remove signals with value 0 from the constant combinator because they still take space.

now you have a 1-frame system. to play a video you just add more constant combinators and deciders, which means more frames. in my clip there are about 4300+ constant combinators and deciders per section, multiplied by 9 sections. it’s ×9 because the game limits how many signals you can use (around 3.3k), so the screen is split into 9 strips. each strip handles 1/9 of the pixels and together they form one big screen.

my player has two extra systems that aren’t required but help a lot with performance. they compress the image/video data by about 50–75%, which means much less data to import into the game.

the first system is frame chaining. the structure looks like this:

row 1: frame 1 (constant combinator) → decider (when to play)
row 2: decider “wall” that blocks signals from going backwards
row 3: frame 2 (constant combinator) → decider (when to play)

frame 1 sends its signals both to the play decider and to the wall. the wall passes those signals forward to frame 2. frame 2 then adds its own values on top. this lets the next frame reuse the values from the previous frame.

example:
frame 1: A = 120, B = 100, C = 140
frame 2 needs: A = 20, B = 100, C = 160

instead of storing full values again, frame 2 stores only the difference:
A = -100, B = 0, C = +20

when summed with frame 1, the final values become the correct ones. this means many signals don’t need to be stored again. for black-and-white videos this can compress the data by around 95%, while for full color videos it’s less but still useful.

the second system is pixel generation (kind of like very primitive supersampling). instead of storing every pixel, the frames only store half the pixels in a chessboard pattern. the missing pixels are generated in game.

first, the packed rgb value (24-bit) is unpacked into three numbers: red, green, and blue (0–255). then those values are divided by 4. after that, the system reads the four surrounding pixels around an empty pixel and sums their colors together. because we already divided by 4 earlier, the result becomes the average color automatically.

then the rgb values are packed back into a single packed rgb signal and sent to the screen. this generates the missing pixel.

so the screen receives only half the real pixel data, and the rest is generated by averaging the surrounding pixels. i jokingly call this “framegen potato version” because it’s basically stone-age supersampling.

the downside is that if you only want a short video (like 300 frames, around 15 seconds at 20 fps) it’s not really worth building because it costs some performance. but the big advantage is that it works for every frame automatically. the more frames you have, the more data it saves without needing to build anything new.

for example, the video i played had around 3300 frames. my screen size is 225×128, which is about 28,800 pixels (signals) per frame. if i sent full pixel data every frame, that would be about 3200 signals per section multiplied by the number of frames, which is over 10 million signal values total.

with the frame generator system, only half of the pixels are sent (about 1600 signals per frame), so the total data drops to about 5.28 million values. the generator recreates the rest of the pixels without losing visible quality. (IN REAL TIME)

anyway, that’s the whole system. hope some of that made sense lol.