This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
Zecradox's profile picture

New feature idea:Curved monitors

Started by Zecradox, 20 November 2017 - 06:29 PM
Zecradox #1
Posted 20 November 2017 - 07:29 PM
Allow a monitor to have a curve but still act as a single monitor
Example: This should act as a single monitor.
KingofGamesYami #2
Posted 20 November 2017 - 08:25 PM
This creates some… interesting issues.
For example, consider a cube with monitors on all sides. What are the coordinates on the top and bottom going to be? Or, to put it another way, how would you know what is "out of bounds"?

X
XXX
X
X
This is one possible representation of a monitor cube. What would term.getSize() return? If it returns (3X, 4X), some content would be cut for any program not aware that they are running on this monitor. Furthermore, (1, 1) would be in a non-existent space…
If you treat them as separate monitors, what happens if you try to wrap a corner monitor block? Would it simply fail? Or return multiple monitor objects?
Edited on 20 November 2017 - 07:25 PM
Bomb Bloke #3
Posted 20 November 2017 - 11:57 PM
I reckon flat monitors, that act like picture frames, would be a better way to do this. The likes of Stitch could then be used to treat any configuration as a single display, if so desired.
Dave-ee Jones #4
Posted 01 December 2017 - 04:05 AM
I must say, I was not thinking of a triangular shape when he said curved monitor. A right-angled monitor?

I was thinking maybe a flat monitor that's curved, still inside a length of 1 block (so 1:1, 2:1, 3:1 being max I think) and that should work okay. The shell itself would act as it always has except the monitors display text over the curve, like IRL curved monitors. Nothing really changes, they're just..curved.
EveryOS #5
Posted 01 December 2017 - 04:45 PM
What if we had it so that a line the color of the monitor appeared, which would indicate (1, y)

Also, other than little announcements going in circles, what would this be useful for? Because this would be a lot of work.
KidBrine #6
Posted 08 December 2017 - 02:59 PM
I think this would be interesting, and I know I would end up using a feature like this. of course there is the problem of how this would actually work. one question I have is would you need to identify the side you would like to print to? which would require another variable for printing to monitors. or would it be like going past a certain point on the x or y coordinates would move the next monitor? either way, I think it would work and someone would make an API to make to add the option for either.
EveryOS #7
Posted 08 December 2017 - 03:21 PM
one question I have is would you need to identify the side you would like to print to?
What if we had it so that a line the color of the monitor appeared, which would indicate (1, y)
Purple #8
Posted 10 December 2017 - 10:17 PM
Why not just have it act as 2 different monitors for up to 4 monitors on a 4 sided block?
KingofGamesYami #9
Posted 10 December 2017 - 10:27 PM
Why not just have it act as 2 different monitors for up to 4 monitors on a 4 sided block?

1. Which one is returned by peripheral.wrap(side)?
2. How do you determine which sides of the block do have monitors on them?
3. ..and remain backwards-compatible with both of these issues?
Purple #10
Posted 11 December 2017 - 10:43 AM
1. Which one is returned by peripheral.wrap(side)?
A table looking like this:


{
		  "left" = monitor that's on the left side of the monitor cluster
		  "right"= monitor that's on the right side of the monitor cluster
		  "front"= monitor that's on the front side of the monitor cluster
		  "bottom" = monitor that's on the bottom side of the monitor cluster
}
In fact, I would argue that you should also do top and bottom just for kicks.

2. How do you determine which sides of the block do have monitors on them?
3. ..and remain backwards-compatible with both of these issues?
Codevise the omnidirectional monitorshould behave just like a set of regular monitors. So your code would be:
My personal solution would be to use a new type of block altogether rather than regular monitors. You could call it "omnidirectional monitor" or something like that. And that thing would be a box that looks just like a monitor except by default it comes with monitor screens on all sides. And they'd combine just like regular monitors but keeping omnidirectional.

That to me would be preferable from both a backward comparability standpoint and esthetics as I don't want these things everywhere, just where I want to put up big omnidirectional text pillars.

Now the down side of this approach is that you would not get true curved monitors with text spanning across multiple sides. At least not by default. But this could easily be implemented with an internal API function that goes through the array of monitors (shown above) in order clockwise or counterclockwise and divides the text up by the monitors width printing them where appropriate. Something like this:


-- Prints the text across a curved monitor
-- Parameters:
--	   direction = direction in which to loop,
--						 clockwise or counterclockwise
--						 relevant for supporting different regions
--
--	   text		 = the text to print
--
-- Returns: nothing
--
function monitor.printCurved(direction, text)
--	 The length of each substring equal to the maximum amount of characters that can fit on the screen.
	 length = monitor resolution

--	 The array of substrings to print individually
	 texts[] = text.split into length sized chunks

--	 Our iterator which should in reality go through "left", "front", "right", "bottom" in which ever order was chosen.
--	 Used integer here instead for brevity.
	 i = 1

--	 Print the substrings.
	 foreach t in texts do
			monitors[i].print(t)
			i++
	 end
Edited on 11 December 2017 - 09:44 AM