How to deal with monitor pixels

I've written a simple program that creates a checkerboard pattern on a 3x4 computer screen. I did that just so I could figure out the pixels and such.

One thing I noticed is that the border monitors (8 types in total) have fewer pixels than the borderless monitors. Also, you can see that the pixels on the borders are bigger than the rest of the pixels in the screen.

So if a normal monitor has 11Wx7H pixels, a top left corner monitor has only 9Wx6H pixels.

That usually throws me off when I'm setting up buttons on the screen, because there isn't a common ground or function that I can find that tells me the top left coordinate of every monitor in the screen.

So how do you guys get around with it? Or you don't? Do you think it's a bug and should be fixed?

The edges of the monitors and the terminals have extra pixels by design, actually.

Cranium, on 16 April 2014 - 12:49 AM said:

The edges of the monitors and the terminals have extra pixels by design, actually.

I know, but they work weirdly. For example, if you set the cursor position to (0,0) and write something, it'll come out as blank. It is counter-intuitive, because you'd think that the first pixel is (0,0), and not (1,1). Besides, the extra hidden pixels only counts as one pixel, so the actual resolution of the top left corner monitor is 10Wx7H, which is one pixel less than a borderless monitor.

well, considering that number lists in Lua generally start at one, it makes sense to me.
Also, in almost every system ever made, monitors start at 1,1 in pixels.

Hmm… Alright, I guess.

But how can I get around with having the top left monitor only being 9 pixels wide? Do I have to add "border monitor detection" in my code?

Why exactly would you need to detect that? I mean why treat is as separate monitors and not as one big multiblock monitor?

Hrmmm…

You shouldn't HAVE to track borders. ComputerCraft shouldn't care which "pixel" you click on, but rather should be tracking which "character" you click on. It SHOULD be able to do that accurately whether you're using a monitor or an in-built display.

What I suspect is that you're been thrown off by this bug, where ComputerCraft gets inaccurate data about where players click on monitors in a multiplayer environment.

This was reported as "fixed" while 1.6 was in the pre-release phase, however, the users stating so didn't come off as experienced coders. I'm inclined to suspect they misunderstood how to replicate the bug and so didn't test it correctly.

If it still exists in 1.63pre4, it'd ideally go into the bug report thread in the beta section.

wojbie, on 16 April 2014 - 12:47 PM said:

Why exactly would you need to detect that? I mean why treat is as separate monitors and not as one big multiblock monitor?

I do treat the screen as one big multiblock monitor. It's just that I don't like having buttons that are in multiple monitors, so I usually tend to have only one button per monitor to avoid having the block hitbox in the middle of my buttons :P/>

For example, let's try finding the top left positions of all monitors in the screen.
The first one would be (1,1). Because monitors are 11Wx7H, you'd think that the next monitor is at (12, 1). It's actually (10,1). Even if I set the first pixel as (0,0), the next one would be (10, 1) instead of (11, 1)

Cranium, on 16 April 2014 - 03:43 AM said:

well, considering that number lists in Lua generally start at one, it makes sense to me.
Also, in almost every system ever made, monitors start at 1,1 in pixels.

Oh, and I figured out that there is a (0,0) pixel. It's just hidden by the texture of the monitor. So, in fact, the top left monitor is 10 wide in total. It just has 2 fat pixels that occupy the space of 3 pixels. This is odd behavior for me, because even if there are hidden pixels, you'd want all monitors having the same resolution, right?

Well, monitors do change their overall resolution per block when they are connected to each other. But the fact still remains that the first visible pixel is 1,1. That's the same for monitors in real life. It is not that the texture covers the first pixel up at 0,0 but instead, it cannot draw anything at 0,0. That coordinate simply does not exist within monitors.

Just throwing it out there, but no image-handling systems (other then that used in ComputerCraft) come immediately to mind when considering a 1x1 origin. Heck, even MS Paint uses 0x0, and I know Java certainly does. I'm inclined to consider ComputerCraft one of the exceptions, rather then proof of the rule. Not that that matters - ComputerCraft is highly unlikely to change in that regard.

caramba, characters aren't always evenly divided at the borders of monitors. That is to say, the row length of a given monitor block - be it an edge block or otherwise - is not neccaserily an integer.

So, to do what you're wanting, it sounds like you'd want to start off by placing two monitor blocks side by side, and use term.getSize() on it. Divide the result by two, and you've got a value that's at least roughly equal to the row width of an edge block.

You can then start adding blocks, pulling in the row length each time you do so until you've got a somewhat accurate picture as to the row length addition provided by each mid-block.

Of course, you should expect entirely different results if you start altering the text scale.

Bomb Bloke, on 16 April 2014 - 04:18 PM said:

Just throwing it out there, but no image-handling systems (other then that used in ComputerCraft) come immediately to mind when considering a 1x1 origin. Heck, even MS Paint uses 0x0, and I know Java certainly does. I'm inclined to consider ComputerCraft one of the exceptions, rather then proof of the rule. Not that that matters - ComputerCraft is highly unlikely to change in that regard.

caramba, characters aren't always evenly divided at the borders of monitors. That is to say, the row length of a given monitor block - be it an edge block or otherwise - is not neccaserily an integer.

So, to do what you're wanting, it sounds like you'd want to start off by placing two monitor blocks side by side, and use term.getSize() on it. Divide the result by two, and you've got a value that's at least roughly equal to the row width of an edge block.

You can then start adding blocks, pulling in the row length each time you do so until you've got a somewhat accurate picture as to the row length addition provided by each mid-block.

Of course, you should expect entirely different results if you start altering the text scale.

Thanks for all the info! I guess I was just finding it weird that the border characters weren't the same size as others, and that was throwing me off. I mean, how can a monitor even have 10,5 characters of width? Well, it's a nuisance, for sure. :P/>


Also, after all the test programs I made, I'm beginning to wonder if I could setup some nice floor decorations using monitors…