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

Read a color and letter at a point.

Started by XMan3, 28 June 2016 - 07:26 PM
XMan3 #1
Posted 28 June 2016 - 09:26 PM
So, I am trying to make a thing (I'd prefer to keep it a secret for a while. :)/> ), and I came accross one thing holding me from doing it, can you read a color and letter from a point?

For example:

color = term.getColor(16,16)

would output the color which is at 16,16

and basically the same thing with the text.

So, is this possible?
Selim #2
Posted 28 June 2016 - 10:15 PM
If you wish to do this, you need to write a framebuffer that tracks what is on the screen in the RAM. The function to get color at a point then gets the value from the buffer. This is not a feature in ComputerCraft normally.
XMan3 #3
Posted 28 June 2016 - 10:19 PM
If you wish to do this, you need to write a framebuffer that tracks what is on the screen in the RAM. The function to get color at a point then gets the value from the buffer. This is not a feature in ComputerCraft normally.

Thanks! I will start writing that, then!
Lupus590 #4
Posted 28 June 2016 - 11:29 PM
To save you time you may want to look into adapting an existing framebuffer api.
XMan3 #5
Posted 29 June 2016 - 01:21 PM
To save you time you may want to look into adapting an existing framebuffer api.

Hmm. That probably would be a wise choice.
Any ideas where I could get one?
Lupus590 #6
Posted 29 June 2016 - 02:47 PM
Any ideas where I could get one?

I've never used one as an API myself, but there is the default window API. Although a lot of people recommend against using it due to it being slow.
Making windows API faster
It's also worth noting that you can potentially improve your performance just by drawing to a window set to invisible, then make that window visible for just a moment before you continue rendering. Every time you make the window visible it draws its whole content (taking about the same amount of time as term.clear(), regardless as to the complexity of what's in it), so by "queuing" a bunch of draw operations into an invisible window (which stores what you write into it, but doesn't actually pass it on to the main terminal display), you can take a simple shortcut past optimising your own code.
I'm quite a fan of Lyqyd's stuff, so I would try out his framebuffer first (also available on pastebin).
There are other's on the forums though: quickbuffer (which has a pastebin not in it's forum post), I'm sure that there was more framebuffers on the forums…

If you really get into this then you may want to test your choice: http://www.computerc...ormance-tested/
Edited on 30 June 2016 - 09:21 AM
Bomb Bloke #7
Posted 30 June 2016 - 03:00 AM
Sure it's slow relative to using no buffer at all, but if you have to use one then the window API is about as fast as it can reasonably be. The addition of term.blit() with CC 1.74 made it much, much faster.

You're using it pretty much all the time anyway, due to multishell.
Lyqyd #8
Posted 30 June 2016 - 03:42 PM
Yeah, the window API has gotten much faster since term.blit appeared, though for situations like a windowing OS, my framebuffer API has features that make it easier to copy the data from one buffer to another. It's also probably a bit faster than the built-in window API, though perhaps not by much any more. It minimizes writing to the screen when able, and uses term.blit to write a row at a time when it draws.
XMan3 #9
Posted 30 June 2016 - 03:59 PM
I want to make one note, I am using 1.73 since I didn't really like how the new update felt. If it is better now I could update but I haven't been looking at it since this works fine.
If it is required to update, I can do that too.