Compact and lag friendly GIF display v2

[Robert3D]

This is v1, scroll down for the updated v2

Ive been building a compact image display for a while now and have been upgrading it multiple times. My goal was to make a display, capable of displaying GIFs with binary colors, while being UPS friendly and compact.

Video:

https://www.youtube.com/watch?v=g9RzkD9eqik

A clock at the top determines which frame the GIF is on. The timing signal is filtered out, so that I can (partially) use that signal for data storage too and because the game wont have to calculate as many things each frame this way.

A bunch of constant combinators hold the data for each frame. Each signal is stored as a 32bit integer so, at best, each signal can control 32 lamps without compression. There's 259 possible signals in the game currently so the maximum amount of pixels you can have with this is 8288. All those signals can fit neatly in 13 constant combinators. The remaining combinators then split these bits apart and feed them into a line of lamps, which turn on, if the bit of their signal was 1. You could theoretically calculate and then put in the signals by hand, but I just used a quick program I wrote to do it automatically.
.

displaytemp.png (395.73 KiB) Viewed 1121 times

.
Some signals may be "0" and storing them in the combinators is useless, but I did so anyways because I would barely safe any space removing them, and it looks cleaner this way.

I'm not using all the available pixels in the video. I designed this display to not require power poles (for the future update), so there's extra data taken up for pixels, that were removed for power poles. Additionally, there's a single signal that's not used outside of managing which frame the GIF is on. Its extra 32 pixels wouldn't have added a full row or column tho, so its simply unused. I didn't want to add image compression to the machine, because I wanted to have a pixel perfect display and it would've been inefficient with dithering. It would've also significantly added to build size and lag.

This display has reached the limit of what can be stored on a single wire. To increase its size further, you would simply add the same components but for a separate wire, which is equivalent to building the same thing twice.

I'm pretty happy with where this is at, but I'm far from done. There's still a couple things I could optimize, and with the update in October, i'll be more then busy updating this display. In the current version, there's still a bunch of combinators I could cut away, if I'm updating my program, even if that wouldn't decrease its footprint that much further anymore. I could also give compression another attempt or see if there's a compact way to interweave wires between combinators, to compactly build the logic for another display in the footprint of the current one.

The new version will add a lot more signals to the game, increasing the possible display size by a lot. Lamps will get RGB support, allowing me to fiddle with full color video, but most importantly, I'm interested in the new selector combinator. It will allow me to index colors and make this truly a color GIF display. I already have used mods to start conceptualizing such a display, but so far, the biggest downsides to color indexing are its insane footprint and lag. Essentially the problem is that the selector combinator can only output a single signal, so I need a seperate selector combinator for every pixel in the future display. The current screenshots of the selector combinator didnt show the ability to change what signal will be output, and I don't want to turn the display into a mess of wires to ensure each signal reaches the correct lamp, so ill have to add one more arithmetic combinator for every pixel, just so the output signal is the same as the input one with a different value.

I've made a suggestion post going into more detail about the selector combinator and what I wish is added to it:
viewtopic.php?f=6&t=115344

The blueprint string is way too big for the character limit of a forum post, so you can find it in this text file:

Display v1 BP string.txt

(313.34 KiB) Downloaded 51 times

[Robert3D]

After a few months of developement, im finally able to release
Version 2 of the GIF display. Its now fully updated to 2.0 and has gone through a complete redesign.

Video:

https://www.youtube.com/watch?v=2r8U2By9xxU

-RGB color indexing
-Vanilla
-Running at 60 UPS
-Supports any length of GIF
-Relatively compact
-Supports MUCH higher resolutions then the original

BIG display.png (3.5 MiB) Viewed 171 times

How it works
A clock controls which frame is suppose to be displayed, it also acts as the ON/OFF switch. The data for the each frame is held in constant combinators. Each signal gets split into 4 8bit numbers, these 4 numbers will each continue on a separated network. For each index from 1 to 255, check which signals' value equal that, then set those values to the color assigned to that index (0 is always pure black). Lastly, these outputs are recombined into the 4 networks and routed into the display. Every 4 lamps in a row are set to the same signal, but are connected to a different network.

https://www.youtube.com/watch?v=XwSte6uPXb4

highly simplified.png (4.98 MiB) Viewed 171 times

Pin display
Size is a important consideration. Higher resolution means a cleaner image, but also means higher UPS/ FPS costs.
For the first video, I used a resolution of 200x113, to completely fill out the maximum zoomed out screen in map view. I consider that to be the largest, practical resolution for projects outside of editor mode.
The second video and screenshot use the biggest possible resolution, for the GIF I used (256x200). This size is only feasible because you can zoom out further in editor-mode.
But there is another way to use displays: With the new pin system introduced in 2.0, its possible to set up a display anywhere in the world, then look at the display through the pin preview. The preview is only 65x65 max, but thats enough for most purposes.

https://www.youtube.com/watch?v=52lg9wW_tDg

pin display.png (568.88 KiB) Viewed 171 times

RGB color Indexing
I wanted the new display to be able to display full color video. However, lamps in factorio arnt perfect, and bit-precise differences in a colors are not visible under regular conditions. Color indexing allows me to create a color palette of 24bit colors, then use a 8 bit number to select a color for each pixel. This allows me to use any color possible, as long as I got no more then 256 unique colors. This is perfect for this project, since it allows me to select which colors I want to be more detailed, and which colors can remain relatively limited by comparison. Color indexing allows me to store 3 times as much data per signal. It is also how real GIFs work, so this implementation should not reduce the visual quality at all.

Vanilla
You may need the Space age DLC, since the blueprints have been designed with space platforms in mind, but you wont need anything else.

Running at 60UPS
The display is surprisingly lag efficient, for how crazy big it is and how many calculations it needs to do every (GIF) frame. The big version does have some UPS costs, so it should only be used for projects that require its immense size. The regular size performed fine. The pin version is small enough to not cause a noticeable impact on UPS, even if several have been placed and theyre all playing at the same time. You can always turn off the display if you are experiencing lag.
The more entities you look at, the worse your FPS will be affected. The many lamps and the cable connections in between them can cause a severe drop in FPS, if you have too many of them on screen. That shouldnt affect your game/ UPS too much, and FPS recovers as soon as you look away again.
Other then that, the amount of data in the constant combinators can be an issue when blueprinting, depending on the amount. Holding the blueprint that contains a lot of GIF data can cause extremely severe FPS drops and, at extreme sizes, cause the game to freeze for several seconds in between every frame. That is because the game processes the signals inside the combinators, even if they arnt placed yet. After the blueprint has been placed, the game will recover and will process the signals only when it needs to. Extremely oversized GIFs or an excessive amount of GIFs in a save also increase save file size and slow down game saves and loads. Using the pin size display should be fine, but save the game before trying to place down the large scale display. The GIF has been significantly shortened on the big version to make placement easier.

Relatively Compact
Almost every tile is used for combinators and theres no holes in between the lamps. Only additional 3 tiles are required per frame.

Supports MUCH higher resolutions then the original
V1 used binary color lamps and stored data via bit packing in all 259 select-able signals as of factorio version 1.1. The space age update added a lot of things tho: RGB color support for lamps, minor but extremely useful changes to the preexisting combinators and a truly crazy amount of new signals to store data in. I also considered using the new selector combinator, but ended up deciding against it due to scalability.
The problem with selector combinators is that they can only ever output a single value, meaning i would need at least one selector combinator for every single pixel in the GIF. Realistically I would have needed three to per pixel, to actually change the lamps signal to the correct value. The Insane scale and lag this would cause would have easily killed this project. Luckily, I was able to develop a way to index colors without using any selector combinators.
For version 2 of the display, I did some research into signals and blueprint editing. It turns out, that theres a vast amount of signals, that combinators can use, yet are never able to be selected during normal gameplay. By editing the blueprint json, I can insert these signals into a constant combinator to store image data. I can further increase the amount of data I can store (and therefor increase the resolution of the image) by bit packing, which is essentially assigning several pixels to be controlled by the same signal. V1 used binary colors (so just on/off), so I could control 32 lamps per signal, coming out to 8288 pixels in the display max, before needing to build the same components again. V2 uses color indexing with an 8bit index, meaning it can only control 4 lamps per signal, but the increased amount of overall signals more then makes up for that deficit.
The number of possible signals has been raised from 259 to a staggering 12,804! which allows me to use up to 54,216 colored pixels. That is significantly larger then what the maximum zoom-out level of the regular camera can show (the camera can show an area of up to 113x200 pixels, or 22,600 tiles total). If I wanted to, I could still use binary colors and increase my maximum image resolution to 409,728, but that would be a lot larger then what the maximum zoom-out, even in editor-mode, would be able to show (501x282 or 141,282 tiles). I believe this display is now big enough, there should be no need to ever go beyond this resolution.

Blueprints

Since the blueprint strings hold several megabytes of raw data, they are by far too big for the blueprint format of a forum post. Instead you can download the text files containing these blueprint strings from the attachments.
The regular size display has by far the most frames, but that made it exceed the maximum single file upload limit for a forum post. If you want to build it, you will need to download all three text files, and combine its contents in the "Import String" window in factorio.
When the game prompts you to select a signal for a parameter, simply click confirm without selecting anything.