8 replies to this topic

[XMan3]

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]

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]

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]

To save you time you may want to look into adapting an existing framebuffer api.

[XMan3]

Lupus590, on 28 June 2016 - 10:29 PM, said:

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]

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

Bomb Bloke, on 30 January 2016 - 12:48 PM, said:

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 by Lupus590, 30 June 2016 - 10:21 AM.

[Bomb Bloke]

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]

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]

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.