[Project] unspaced, 3 by 5 matrix display

inomanoms

Eye of Cthulhu

1_3 by 5 matrix font.PNG 2_block groupings.PNG

3_small 3 by 5 matrix.png
4_large 3 by 5 matrix.png

http://www67.zippyshare.com/v/ZvzixAh4/file.html




After a week's worth of hard work, I am pleased to present what I consider to be an improvement on our segment displays: a 3 by 5 matrix display.

I had initially intended to make a much larger matrix, but after much reasoning came to the conclusion that the largest unspaced matrix possible with three wire colours is a 3 by N matrix. I was forced to choose between beginning to space the matrix to achieve larger dimensions, or force the character set into 3 blocks wide. I chose the latter option, considering it the high road.

The sloped blocks in the corners of the display are a direct consequence of the display's limited dimensions. I had to, somehow, display the widest characters of the alphabet (M and W) which normally in the smallest pixel font take up a width of 5 blocks (3 arms/legs and the 2 spaces inbetween) within 3 blocks.

The sloped blocks in the corners of the display also might suggest to some people that this is a segment display. But it really is a matrix display, capable of all the 2^15 output possibilities you'd expect of it.

It functions differently from the segment displays above in that there is not necessarily a 1 to 1 relationship between a switch attached to a wire and the on/off state of a single block in the display. In order to service the inner "landlocked" blocks, it is necessary to run more than one wire through the peripheral blocks of the display and so the switches begin to service groups of blocks. The colour coded displays at the top of the map are intended to give you an idea of how the wiring of the display groups blocks together.

Another consequence of the wiring is that achieving the inverse of a character is not simply a matter of reversing the state of all the switches to a display. The map showcases "dark" and "light" versions of all characters. These are not there to give an idea of the aesthetics of light blocks on a dark background versus dark blocks on a light background as much as to document the switch states of a character and its inverse.

In addition to the light and dark character versions, there is a small and large version of the display on the map. This is a result of my initial difficulties in wiring the smaller display and deciding to create a display at double the size which was easier to wire. Please not that the wiring of the small and large displays are fundamentally different.

Eventually, I got the smaller display to work, but under the provision that a string of small displays alternate between versions of the display where green and blue in the wiring are switched. It was hard to get the wiring to compact enough that the spacing between the displays was at least equal but not greater than the display width (looks wierd). I'd also like to point out here, that while the displays are spaced out vertically on the map, they are designed to be able to abut top to bottom without merging.

The smaller display at 3 by 5 (15 blocks) without wiring and 6 by 11 (66 blocks) with wiring, is significantly smaller than Richard's 14 and 16 segment displays. The larger 6 by 10 (60 blocks) without wiring and 9 by 14 (96 blocks) with wiring display is comparable in height, but more compact horizontally. With the smaller display and a minecart wiring, the entire message "997, 998, 999... 1000. One thousand subscribers. You are all amazing! Thank you. Zerogravitas" fits onscreen.

However, this is not to boast. Regardless of how compact a display is, if one intends to gather and guide the "feeding" wires of the display to another area on the map, the longer the string of characters, the larger the pillow of feeding wires around the group of displays becomes.

I've been wondering how to counteract this. I'm not smart, but I remember being introduced to the concept of multiplexing in highschool Compsci. Does anyone think something like this would be possible in Terraria? A new project perhaps?

Please respond with comments and criticisms and give a "like" or whatever this site does to stroke it's members' egos.

-inomanoms
 
Last edited:
Have you built any example text displays, using minecart look-up tables, for example?
I hadn't, but have now:


Remind me in the future not to want to again until I have finished completing my reference table by minecart wiring for easy Tedit copy/paste. You counted ~37 times of hammering? I counted more. Terraria seems to have special difficulties with laying down parallel tracks with no spacing between them. In orienting such tracks, the game iterates through all the junction possibilities, even if they make no sense in the context of the surrounding tracks.

Presumably you immediately loose all the compactness benefits, needing at least 15 tiles width for all the pressure plate track spaces. As you say.

No, because as you go on to say, and as the minecart wiring of the displays was intended to be, the displays can be lit up in multiple passes. Perhaps this would have been more obvious had I included a working example in my original post.

My foremost intent with the 3 by 5 matrix display was to reduce the size of your 14/16 segment displays. Your 14/16 segment displays are (almost) the same width as the number of pressure plates needed to service them. Any attempt at making them smaller necessitates either increasing the kerning between the displays or multiple rows of minecart pressure plate tracks.

This leads to two paradigms of how displays can be used: single line write/clear/write or multi-line print. To list the benefits and drawbacks of multiline print over single line write/clear/write:

Benefits:
  • a theoretically improved legibility of text due to more text being displayed on screen at one time (size) and text being displayed longer on screen at one time (no erase)
  • an increase of print speed despite the overhead of the rebound time a minecart requires transversing multiple rows of tracks since multi-line print is no erase and hence half the track length of single line write/clear/write.
  • extendability of text length to a maximum of map height, which with single line write/clear/write ends once the minecart tracks manipulating the displays exceed half screen height

Drawbacks:
  • Map real estate. A significant drawback considering our aspirations to utilize displays with the logic of a computer, which takes up its own space on the map and requires proximity to the display to prevent despawns.
  • the reality of reduced legibility due the fact that at max. speed the minecart travels and the small size of the letters, the text (at least to my old eyes, you can watch the video to form your own opinion) appears blurry. The text is readable only at a slow(er) minecart speed which results in:
  • a decrease in print speed due to slower required minecart speed.
  • Work intensive setup. Even if I completed the reference table with the minecart wiring, I highly doubt that Terraria will cleanly seam the individual character displays copy/pasted in TEdit.

... ultimately, driving the display this way prevents it from being used in a truly dynamic fashion (as with a computer).

Given my lack of expertise in computers and logic, I am apprehensive to make argumentations against this. However, I fail to see how if the 14/16 segment displays are programmable, that the larger of the 3 by 5 matrix displays cannot be in the same way. They are basically the same, only that one line of pressure plates has been split up into two, one above, and one below the display.

Or are you saying, that, in general, we have not yet created a programmable minecart wiring for use with our displays? Because to my eyes, but both the current segment and matrix displays are equally "static" as they are hard-wired to pressure plate tracks. Both the larger 3 by 5 matrix display and the 14/16 segment displays can be used in a single line write/clear/write fashion.

The larger of the two matrix displays uniquely lends itself to being driven in a loop. Assuming we could advanced to a point where the pressure plates in the loop activate mechanisms which relay the logic of character to charater mappings instead of just turning blocks on and off, this display type may come in handy.


There's just no compact way to multiplex; the more complex the functionality, the more space it needs.

I have no idea. I was just throwing out the idea "multiplexing" without knowing what it really is. My Compsci teacher explained to us in highschool, that multiplexing is how multiple phone calls are sent over a single cable. I thought this would be useful for reducing bulk in our wiring without knowing the how. When I talked to Joe, he seemed to think I was talking about animating displays? I really have no idea.


Have you tried also mapping multiple wires to switches, such that activations of inner blocks double activate the outer block that they route over (hence cancelling out). The aim being a 1 to 1 mapping of switch clicks to block states.

In the smaller of the two displays, there already are instances of multiple wires mapping to single switches. But this was born more out of the need to stay compact than to produce the affect you describe. It's also not possible to create 1 to 1 mappings with just three wire colours and unspaced display blocks:

Code:
[   ]   [ G ]  <-- [display blocks]
          |
[ * ]   [RGB]  <-- [display blocks]
          |
(RG ) - (RGB)
  |       |
{RG }   {  B}  <-------- {switches}

  *This adjacent block will
  merge with block right of
  it regardless of the wire
  colour used to service it


So the bottom panel of switches tessellates with the top panel of a character display directly below... Clever design consideration. Must have taken a fair old bit of trial and error.

More planning than luck. Of course, I tried luck first, but that quickly lead to dead ends and confusion. Once I realized that the top and bottom halves were vertical mirrors of the same wiring, it was simply a matter of switching the exit positions of the red versus green/blue wires out of the display and botching the wiring of display's middle row into the rest.

Hardest was maintaining that minimum 3 block wide gap in the smaller display. I felt like a genius after coming up with a solution for that after a full day of struggling with the problem.


inomanoms said: ↑
there is not necessarily a 1 to 1 relationship between a switch attached to a wire and the on/off state of a single block [...] it is necessary to run more than one wire through the [peripheral] blocks

That's a brave design choice, and a great literal solution that I wish I'd thought of.

If I'm not mistaken, it's with this principle (outputting to a display block with multiple wires) that the symbols in Joe's slot machine are created.

But great effort in the character design, adding in punctuation and mathematical operators too!

Thank you. :happy:


I guess you could reverse the corner slope angles if you limited the display use to just numbers, no letters, right? Which might make some of the digits slightly more readable.

Such a thing already exists and is affectionately named "The Diceman Font", as it was inspired by and intended for Joe's calculator.

1_dicemanX font.png


The activations for the numbers 2 and 5 are slightly different from those of the inward sloping versions of the 3 by 5 matrix display, and there is an extra block of spacing to accomodate the comma and decimal separators in the smaller display version of the font. But aside from that, the display is basically the same as its alpha-nemeric version. The mathematical operators are taken one for one from the font for the 3 by 5 matrix displays.

I had not bothered to include the DicemanX Font in my last post because if you are only dealing with numbers, a 7 segment display is much more efficient than a 3 by 5 matrix display. Besides, I'm also rather fond of Joe's torch displays. They are uniquely his, and remind me, for some reason, of drag-racing.


Before dealing with the wiring of matrix displays, I had developed three other fonts which I might aswell add in here as "goodies".

2_4x4 unspaced.png

The first is a 4 by 5 matrix font. Like the 3 by 5 matrix, it too employs sloped blocks (for "M" and "W" and "N"), but is a bit less broken-up and, therefore, more legible. The display suffers from not having a vertical centre, so letters like "T" and "I" seem unbalanced. Attempting mathematical operators proved difficult because of the inconvenient placement of the sloped blocks in the display. Until we get more wiring colours (crossing my fingers for Terraria 1.3), this display (and font) cannot be wired.

3_5x5 spaced.png

The next one is a vertically spaced 5 by 5 matrix font. It has an aesthetic that moves in the direction of the matrix displays seen in buses, etc. It is the first font of mine that doesn't need sloped blocks because it is 5 blocks wide. I have not yet attempted to wire this display, but am optimistic about it working. Unfortunately, the display matrix will require spacing between the letters and so will not be able to maintain the continuous horizontal stripes seen in the screenshot, nor will it have the ability to scroll in increments smaller than the width of a character.

No mathematical operators for this font. The vertical spacing of the display blocks really work against this display.

4_poor mans 2x3.PNG

This last font is a 2 by 3 block font. (You may have seen it somewhere before ;)) Basically, I wanted to determine what the smallest font size that you can make in Terraria with blocks is, and the answer is the same size as that of the letter statues only with the added benefit of punctuation. I call it "The Poor Man's (Statue) Font". This font can't be used as a display since sloped blocks of different orientations appear in the same location of the 2 by 3 matrix. Activations do not reorient blocks, but simply move them between the fore and background (though it would be interesting if activations did!).


Also, did you try using actuators in addition to the gemspark blocks?

Yes, I did, but opted not to use them. An offline gemstone block is the same colour as an offline gemstone wall, while an unactuated gemstone block is darker than an offline gemstone wall. I wanted to avoid a 3 colour palette if I had the option of simply using a foreground and background colour.

What bugs me most about how the display looks, is also what I think impedes the legibility of the displays the most, namely, the horrible double outlining of the gemstone blocks which bites into the white of the online blocks. This problem can be circumvented by using glass blocks and an online diamond gemstone wall painted the same colour. The texturing of the glass (the cracks or reflections) melds into the background (see the 4 by 4 matrix font for an example)


Someone whould totally some up with a 32768 character alphabet to fully utilise this display space...

My next project will be developing a braille input device using either a 2 by 3 spaced matrix for 6 dot braille ASCII, or a 2 by 4 spaced matrix for Unicode. All 64 glyphs of braille ASCII already have defined meanings. Unicode braille is not tied to a definite character set, so we could create an alphabet with characters reserved for command flags like in XML!


-inomanoms
 
Last edited by a moderator:
I have no idea. I was just throwing out the idea "multiplexing" without knowing what it really is. My Compsci teacher explained to us in highschool, that multiplexing is how multiple phone calls are sent over a single cable. I thought this would be useful for reducing bulk in our wiring without knowing the how. When I talked to Joe, he seemed to think I was talking about animating displays? I really have no idea.

Since multiplexing essentially involves combining multiple signals into one stream, I thought the Terraria analog of this was combining wires of three different colors so that that pass over the same space. This means that a block can be lit up or turned off using multiple sources, which means that your design uses Terraria multiplexing already :). The previous segmented displays that ZeroGravitas and I created/used (and a few other engineers before us) only had 1 source = 1 output whereas your approach uses multiple sources = 1 output which gives much richer possibilities!

Drawbacks:
  • Map real estate. A significant drawback considering our aspirations to utilize displays with the logic of a computer, which takes up its own space on the map and requires proximity to the display to prevent despawns.

There are two good ways of dealing with this. The first is that character NPCs don't teleport at all during the daytime, and even during night so long as the NPC house is somewhere on screen then the NPC will not teleport. This means you can use gigantic computing mechanisms distant from the displays themselves.

The other approach, as I recently began investigating, is that minecart logic is perfectly analogous to hoiktronics logic, and with minecarts there are no issues at all with size or distance between machines. The downside of minecarts is that they are slower and seizure-inducing if one uses teleporters (which will likely be a must).
 
Last edited:
The downside of minecarts is that they are slower and seizure-inducing if one uses teleporters (which will likely be a must).

Another downside is that there is only one player driven minecart, and using hoiking, multiple processes can be executed at once.
 
Another downside is that there is only one player driven minecart, and using hoiking, multiple processes can be executed at once.

Yes, this is potentially a big one. I haven't put too much thought into multiple simultaneous processes just yet (outside of very basic set-ups such as a second NPC transferring contents of a back-up memory as main memory info is getting transferred), but this will be the key to speeding up processes considerably once we move on to bigger machines.
 
Yes, this is potentially a big one. I haven't put too much thought into multiple simultaneous processes just yet (outside of very basic set-ups such as a second NPC transferring contents of a back-up memory as main memory info is getting transferred), but this will be the key to speeding up processes considerably once we move on to bigger machines.

I suppose once mechanisms get big - I mean really big, like much larger than the area around the player required to prevent mob despawns and all NPCs are already in use - you can use a combination of tracktronics and hoiktronics such that hoiked skeletons are executing subroutines in the vicinity of the player who is slowly moving geographically around the map in a minecart... Do you understand what I mean?
 
I suppose once mechanisms get big - I mean really big, like much larger than the area around the player required to prevent mob despawns and all NPCs are already in use - you can use a combination of tracktronics and hoiktronics such that hoiked skeletons are executing subroutines in the vicinity of the player who is slowly moving geographically around the map in a minecart... Do you understand what I mean?

Having skeletons perform routines in the vicinity, absolutely. But I have some really big contraptions in mind...;). Well, I'm not too concerned just yet. We have 22 NPCs to work with currently, and given some good work recently on how to massively compress NPC homes, it might be possible to run up to 22 routines simultaneously so long as those homes are on screen at night. During the day that won't even be necessary, assuming the entire process doesn't spill into the night.
 
Back
Top Bottom