, computers.
Because who doesn't need giant pictures in their factory?
Image processing
Each item on the belt is representing one pixel of the final image.
First step is figuring out what colors are different items. I put a short strip of compressed belt for each item in the game, took a screenshot zoomed out and then averaged the RGB values by computing square root of mean squares (link).
- palette.png (1013.13 KiB) Viewed 3191 times
Next step is converting the input image to an array of factorio items. Since there is a limited number of available colors the image will look slightly off, so to deal with that I used the Floyd-Steinberg dithering algorithm. The brightest and darkest items (lamps and coal) are not completely white and black, so to make it work properly some images need contrast and brightness adjustment.
As you can see, most items are grayish and not very saturated, with few standing out. Most notably coal is by far the darkest one. There's also very few yellow items. This causes artifacts on final images, especially with a lot of bright colors. Pictures in grayscale tend to look more detailed compared to colored ones.
Printing
Splitter
To make one inserter handle both sides of the belt and save some space I made this tileable design. Each inserter is responsible for one whole straight belt section. The picture is for two sections. There's also room for power poles and roboports below.
- splitter.png (427.76 KiB) Viewed 3191 times
The basic idea is to use a filter inserter and send it signals. To make things simpler the stack size is set to one. Current item signal is travelling via green wire up. Also, the items are requested to the chest only when needed. This way you will only need one chest. To make things work faster current item signal is multiplied by 5 before sending to requester chest. There is now also a second row of filter inserters, but in blacklist mode. These are supposed to take unwanted items and put them back into logistic network. This way the printer is a bit faster overall and doesn't jam when the requester has too many items in it. This was added later and is not shown on images.
- inserter.png (535.53 KiB) Viewed 3191 times
Using clocks would be unreliable, so instead a counter is used. Each time the inserter picks up an item a pulse is sent via the red wire down. It's not important what the item was, just how many were put already, so it is then converted to I signal. The actual counting is done by an arithmetic combinator with a feedback loop to itself. The operation is identity function ("*1" in this case), so it only adds inputs and remembers them. It outputs the number of already placed items.
- counter.png (335.43 KiB) Viewed 3191 times
Each pixel is stored on a single bit of a constant combinator signal. All signals from the memory are passed to the bit shifter and then all but the least significant bit are zeroed, so only one output signal is non-zero. Memory is organised into groups. The values in constant combinators are 32-bit integers, so one group can only handle 32 pixels. To get around that each group is connected to a decider combinator, that only passes the signals if that group is selected. This is done by signal G, which is incremented every after 32 pulses.
- memory.png (791.25 KiB) Viewed 3191 times
The code is written in JavaScript and is available on github.
