Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal
  • 0
Piorjade

Undocumented "window" parameter in the term API wiki

Question

So I am coming from ComputerCraft and the term API there is pretty straight forward and allows us to create windows to write / redirect to.

Anyway, in the term API wikipage of OpenComputers there is for example the method term.bind with an optional parameter "window", the problem is I can't find any information about this parameter and I assumed that this would be the same kind of "window" as in CC and I won't have to write my own API for it.

Do you guys know something about it?

Link to post
Share on other sites

12 answers to this question

Recommended Posts

  • 0

Here's a little demo to get you started.. But, the warning I received using this method is that it's an 'internal' method and so subject to possible change in the future. Just FYI.

local process = require "process"
local term = require "term"

local function window(program, dx, dy, width, height)
  local _window = term.internal.open(dx, dy, width, height) -- # Create a new window
  term.bind(term.gpu(), _window)                            -- # derp
  process.info().data.window = _window                      -- # Get current process, tack _window unto ...data.window
  os.execute(program)                                       -- # exec program as child process. It inherits our term window via process magic*
  term.clear()                                              -- # clean your fuckin' room
end

window('/bin/dmesg.lua', 10, 5, 65, 20)	-- # Do the dew

Let me know if this need clarification. I'll try to help :) 

Link to post
Share on other sites
  • 0

Okay, thanks for the tip.

 

Another question (it isn't directly related to the topic, so if that's not good tell me and I'll create a new topic for it)

If I wanted to make such a system myself (a self-made term API that allows creating multiple windows), how would I have to handle redrawing the content of them? I already tried having pixels saved in a table (with information like background- and foregroundcolor and which character they contain) but that made it really slow as it iterated through the whole table and made a gpu call for every pixel.

I need redrawing if I for example have 2 windows overlap each other and I saw something in the OpenOS code about a stream for the ttys.

Link to post
Share on other sites
  • 0

That's a great idea!

The reason I wanted to make it is that I wanted to try to make an OS myself, idk really why lol.

Anyway, I'll take a look at that buffer library that OpenOS apparently uses for I/O.

EDIT:

I experimented with process metadata and your answer regarding term.internal.open and I don't get why the process doesn't have a "window" entry in the data table and after you set that as the newly created window it only THEN prints to the new window, which is why I also don't get why you used term.bind in the beginning as that apparently doesn't redirect input/output, it binds these components to the current window/terminal (which is still the original one at in that moment) (I attached some screenshots)

output.PNG

code.PNG

Edited by Piorjade
update on the situation
Link to post
Share on other sites
  • 0

I would definitely keep looking into how OpenOS gets things done, some of it is pretty clever. The buffer API is mostly for byte streams like files and such, maybe socket streams.

An idea I had was creating a double buffer API and a virtual gpu component proxy interface that could then be bound to the term library with term.bind(gpuProxy, windowInstance)

I think this would be workable and easily injected. Just my thoughts.. happy coding

Link to post
Share on other sites
  • 0

From what I understand term.bind just binds the window instance to a given gpu proxy. The window instance is just size info, cursor state and some other metadata. If you keep digging in the OS you might notice term.internal.open isn't used anywhere other than in the term library and windows aren't exposed anywhere to the user. That's because it's not an explicit OS feature. This is why we have to manually bind a window instance to a process' metadata ourself. As for why it's not present in the process info already has to do with that metatable trickery I warned about earlier. There is one term window, it is on the init it shell process.... I forget. Child processes inherit this window or 'term'. Hope that's not too muddy to understand.

Link to post
Share on other sites
  • 0
On 14.4.2018 at 12:11 PM, CptMercury said:

@Piorjade

What also helps to speed up screen redrawing is to update your screen dynamically, so that you are only reprinting the areas that actually changed. Also if you are moving large areas on your screen, like scrolling or dragging, make sure to use the gpu.copy method.

Yeah, that's true, but as I said, if I wanted to have "virtual terminals" (-> "windows") and they overlap and I wanted to redraw the one in the background, I somehow need the data that was on it before, which means I have to have its pixels stored somehow.

 

Again, my methods involving having these pixels in a table lead to the whole redrawing process being really slow, as it would call a gpu method for every pixel.

Link to post
Share on other sites
  • 0
20 minutes ago, Piorjade said:

Again, my methods involving having these pixels in a table lead to the whole redrawing process being really slow, as it would call a gpu method for every pixel.

I think this is why I think a 'grouping' algorithm(if thats what it's called..) would be useful. Yes, you have to iterate every 'pixel' for its data, but you dont have to draw every pixel one by one independently. If you've heard of MineOS, it has  a pretty beefy double buffering library. If you inspect the draw method you can get an idea of how it does grouping for gpu draw calls from its internal buffer. Just a suggestion in case i haven't been clear.. 

Link to post
Share on other sites
  • 0
On 16.4.2018 at 10:51 PM, Molinko said:

I think this is why I think a 'grouping' algorithm(if thats what it's called..) would be useful. Yes, you have to iterate every 'pixel' for its data, but you dont have to draw every pixel one by one independently. If you've heard of MineOS, it has  a pretty beefy double buffering library. If you inspect the draw method you can get an idea of how it does grouping for gpu draw calls from its internal buffer. Just a suggestion in case i haven't been clear.. 

I think I'll first try to set up a basic Operating System (I'm trying to make something like "miniOS", so basically imitate DOS a bit) and when the basic system is working, I'll try implementing your idea, if that's okay. :)

 

Anyway, thanks for your help!

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.