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

dgelessus

Members
  • Content Count

    158
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by dgelessus

  1. It turns out that gpu.bind requires a full address and doesn't automatically expand partial addresses. Instead you need to use component.get to expand the address: local SCREEN_ONE = component.get("d53") local SCREEN_TWO = component.get("c5d") This will store the full addresses of the two screens in SCREEN_ONE and SCREEN_TWO, which you can now use directly with gpu.bind.
  2. I'm quite certain that isn't the case. At some point I had two screens attached to one computer, and when changing the primary screen from one to the other, the old one kept its text even after the computer was shut down. O_O
  3. Nice, that reference image will probably come in handy at some point. I like what you did there with the heading sizes/layout, looks really fancy yet so simple. Would those palette changes actually be useful for anything? Color themes are a nice idea, but that's basically it. Most other things that I was thinking of, e. g. highlighting the currently selected text field in a GUI, would require assigning "objects" to the palette slots, and there could only be 16 of them.
  4. ^ this. The exact size of normal characters is 8*16 points, and double-width ones (East Asian glyphs, certain other symbols and control character replacements) are 16*16. The font used by OC computers is the GNU Unifont, see its Wikipedia article for more technical details that you'll probably never need
  5. Does that mean that palette changes are retrocative? e. g. if you write text in palette color 1 and later reassign that palette slot, will the previously displayed text change color? I never understood that part of the color palette mechanics.
  6. Try checking that the GPU/screen binding actually succeeds. Print some text before rebinding, then print the return value of gpu.bind (once, no need to put it in an infinite loop) and print some text again: local component = require("component") local gpu = component.gpu local SCREEN_ONE = "d53" local SCREEN_TWO = "c5d" print("Rebinding... " .. tostring(gpu.bind(SCREEN_ONE))) print("This should appear on the first screen.") print("Rebinding... " .. tostring(gpu.bind(SCREEN_TWO))) print("This should appear on the second screen.") If that succeeds, continue from there. Also no
  7. 1. Unlike with CC, not all APIs are loaded by default. Instead you need to explicitly load them with require: local component = require("component") local fs = require("filesystem") For a full list of all APIs and components, see the wiki at http://ocdoc.cil.li/. 2. Practically none - CC and OC have similar components and APIs, though of course they are used differently. And if you absolutely need to use a CC peripheral that has no OC counterpart, you can use the Adapter block to control it. 3. OC monitors are character-based, so there is no way to directly control pixels as such. Sc
  8. This is a short boot/rc script that automatically mounts all new file systems under a mount point named after their label, in addition to the normal name assigned by the OS. Special characters in the label are replaced by an underscore and a conflicting name gets the start of its address appended, so the obvious tricky situations should not cause any problems. I wouldn't be surprised if someone else had already written this kind of thing or if it was integrated in some of the non-default operating systems, but I couldn't find anything on the forums or OpenPrograms, so here it is. (Yes, ha
×
×
  • Create New...

Important Information

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