Read a color and letter at a point.
XMan3 28 Jun 2016
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?
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 28 Jun 2016
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 28 Jun 2016
Selim, on 28 June 2016 - 09:15 PM, said:
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 28 Jun 2016
To save you time you may want to look into adapting an existing framebuffer api.
XMan3 29 Jun 2016
Lupus590 29 Jun 2016
XMan3, on 29 June 2016 - 12:21 PM, said:
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
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 by Lupus590, 30 June 2016 - 10:21 AM.
Bomb Bloke 30 Jun 2016
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.
You're using it pretty much all the time anyway, due to multishell.
Lyqyd 30 Jun 2016
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 30 Jun 2016
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.
If it is required to update, I can do that too.