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

Piorjade

Members
  • Content Count

    13
  • Joined

  • Last visited

  • Days Won

    3

Piorjade last won the day on September 7 2018

Piorjade had the most liked content!

About Piorjade

  • Rank
    Junior Member

Recent Profile Visitors

1955 profile views
  1. The most efficient way that I know of would probably be double buffering. (The reason for that being the fact that direct GPU calls like set or setForeground take a certain amount of time depending on the tier and a good double buffering API has an algorithm that minimizes the amount of GPU calls) On the other hand I don't know if that's actually necessary for a text editor.
  2. Looks nice dude! This might get useful to me when I try to make my own OS. P.S. It's nice to see users from CC on here
  3. I'm not interested in reading up posts which consist of passive-aggressive comments from the person that created the thread as you seemed not to appreciate the help of others and just cry and complain constantly. Yes I know but the way I understood your tears that I skimmed over I thought you didn't like the fact that the library he gave you only has one buffer and you thought it was a "bug" at first that you had to reboot or something like that. What? The comment you quoted doesn't really clear up or negate what I've said. My comment you've quoted is basically th
  4. OC's way of limiting GPU calls, making pixel-by-pixel drawing incredibly slow, is actually kind-of realistic. (it's only more extreme to compensate for good server performance) One way, which was already suggested, is to buffer every pixel and only draw the changes. Additionally to that you'd have to create some sort of algorithm, which groups pixels together to reduce GPU calls. Soo that is the general idea of some sort of double buffered graphics library for OC. I know how you're feeling and I didn't read every comment here but it seems like you've overreact
  5. 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!
  6. 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.
  7. 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,
  8. 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
  9. Thanks! Is there any wiki page that shows what metadata processes exactly have?
  10. 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?
  11. net API - The most basic DNS system How this works: The DNS server constantly broadcasts out its information every 2 seconds on the specified port The client APIs have a function to search for the next DNS server (they wait for the above information) which then sets the table containing the information to net.foundServer Now the client APIs have the ability to call net.setDNS(net.foundServer.address) to lock to that DNS With that the client APIs can now register and delete their URLs on this DNS server Every other client who has that DNS server locked on too
  12. Soo I was kinda bored doing basically nothing when I thought about making an OS for OC, which I wanted to do for a long time now. I got pretty far, considering that I'm pretty new to OC, up to the point where it is supposed to start up background "services" at the same time. I didn't know that computer.pullSignal / event.pull doesn't let a coroutine yield (I copied the event and keyboard api over to my OS because I thought I didn't need to rewrite these things on my own) so I quickly had to think of a solution and came up with this. Functions Currently I made it usable for normal Ope
  13. I tried to translate it into german, but fucked the script up. I think i translated the wrong values/strings.
×
×
  • Create New...

Important Information

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