, computers.
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 681 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: