Stitch - Massive Monitors

Started by KingofGamesYami, Aug 13, 2018, 02:16 AM

Previous topic - Next topic

KingofGamesYami

Reposted from here

Stitch isn't a new idea, but it's certainly a useful one.
The basic idea is to create a larger monitor out of multiple smaller ones. The implementation is anything but basic.
Installation and Setup
For the lengthy, human-readable API, download from rKU6E2K4 (~9,774 bytes)
Since I was overly-verbose in variable naming, a minified version is available from CTrVdFK9 (~3,812 bytes)
You can load the API through either os.loadAPI or dofile; it will detect which one automatically. If you are in need of multiple instances, you will want to use dofile

os.loadAPI( "stitch" ) --#loads stitch as a global API
local stitch = dofile( "stitch" ) --#loads stitch as a local "API"
local stitch_2 = dofile( "stitch" ) --#as shown here, you can have multiple objects this way

There is one very important function that separates this from a normal terminal object.
stitch.setMonitors( table t )
The table provided is to be a table of strings, which refer to monitors (eg "monitor_0"). It is a two-dimensional table, in the order t[ y ][ x ]. This means the table is visually similar to the layout of the monitors when viewed from the front.

stitch.setMonitors( {
{"monitor_0", "monitor_1"},
{"monitor_2", "monitor_3"},
} )

Before you do ANYTHING with the virtual monitor object, be sure to set the monitors. It sets up several internal variables, meaning the results of calling functions before it ranges from overwriting those changes to outright errors.
After the monitors have been set, you may easily use term.redirect to run practically anything on this giant monitor.
term.redirect( stitch )
stitch.setTextScale( 5 )
print( "Hello, world!" )
A rather useful feature of my API is the overriding I do on the peripheral API functions and event system. "stitch" is a valid monitor for all intents and purposes. Please note that having multiple instances will not be individualized, and may have unintended consequences when used this way.
For testing, I used this clever program to run any program on the monitor:

os.loadAPI( "stitch" )
stitch.setMonitors( {
{"monitor_7", "monitor_1", "monitor_6"},
{"monitor_3", "monitor_4", "monitor_5"},
} )
stitch.setTextScale( 0.5 )
stitch.clear()
shell.run( "monitor stitch", ... )

Finally, we have the two functions which, if misused, will screw things up. For efficiency purposes, the monitor object acts as a buffer, and is updated every 0.05 seconds (20 times per second). I have included the ability to disable this functionality and manually control the buffer updates.

stitch.disableAutoBuffer() --#disables the automatic buffer.
stitch.buffer() --#forces the API to render the buffer to the screen (note: does not 'redraw' parts that haven't been changed)

Known Bugs:
Any text drawn at an x value of 0 or less will not show up. Fixed!
term.scroll incorrectly determines length of background colors string Fixed!






Thanks to Shazz, for the original API. I didn't use any of his code, but it was an inspiration.
Huge thanks to BombBloke (and everyone else in AAP), for putting up with all the things I did wrong, and helping me get this thing up to spec.
And finally, thanks to GravityScore for his sublime text plugin

Update!
+Fixed known bugs
+Added redraw() and setVisible( boolean visible )
Update!
+Changed behavior of redraw and setVisible
+Fixed a crash bug
I'm a ComputerCraft veteran with over 3k posts on the old ComputerCraft Forum.  I'm mostly inactive in CC having moved on to bigger, more interesting projects but still contribute to the community.

pjals

Is .blit going to work anytime soon?
hi i am T79, bye

SquidDev

Quote from: pjals on Jun 23, 2020, 12:08 PMIs .blit going to work anytime soon?
I'm fairly sure it works already. I don't recall having any issues using it for any of the monitor arrays I've set up.
GitHub | CC:Tweaked: A ComputerCraft fork | Plethora: A peripheral mod