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


  • Content Count

  • Joined

  • Last visited

  • Days Won


Fingercomp last won the day on November 22 2018

Fingercomp had the most liked content!


About Fingercomp

  • Rank
    Leading Member

Profile Information

  • Gender

Contact Methods

  • GitHub
  • IRC

Recent Profile Visitors

1909 profile views
  1. TL;DR: set the resolution to 159×28. Displays automatically scale the content to fit the screen's inner area. If you decrease the resolution height, the display area will occupy more horizontal space. I'll assume that your screen is 8×3. The aspect ratio of the screen's inner area is (2 × (8×16 - 4.5)) : (3×16 - 4.5) = 494×87. The "- 4.5" terms are the screen borders, and the width is doubled because the cell width is half its height. If you set the resolution proportional to this ratio, it will fill the whole screen. Of course, you can't do this, as the maximum resolution is 160×50. So we have to compromise and choose the resolution that fits the screen the best. local function round(num) local integer, frac = math.modf(num) if frac >= 0.5 then integer = integer + 1 end return integer end local data = {} for w = 1, 160, 1 do local h = math.max(math.min(round(w * 87 / 494), 160 * 50 / w, 160), 1) local area = w * h local delta = (w / h) - 494 / 87 table.insert(data, {delta, area, ("%d×%d"):format(w, h)}) end table.sort(data, function(lhs, rhs) return lhs[1] < rhs[1] end) local f = io.open("./data", "w") for k, v in ipairs(data) do f:write(("%.6f %d %s\n"):format(v[1], v[2], v[3])) end f:close() The above code creates an array and fills it with 160 possible resolutions by choosing a width and calculating the height such that the aspect ratio is the closest to what we're trying to achieve (494:87). Then it writes the data to a file so that we can plot it. Here's what we get: Now it's clear that the best resolution is 159×28. Its aspect ratio differs from 494/87 by ~0.000411, which is really small. Let's go ahead and calculate the thickness of the black area. Let dw, dh be the dimensions of the display area, and iw, ih the dimensions of the inner area. dw/dh = 159/28; iw/ih = 494/87. 159/28 > 494/87, so the display area height is less than the screen's inner area height. Therefore, the width of the black area is dw = iw. The height equals 0.5 × (ih - dh) = 0.5 × (87/494 × iw - 28/159 × dw) = 0.5 × iw × (87/494 - 28/159) = 0.5 × 494/87 × ih × (87/494 - 28/159) = 1/27666 × ih. In other words, the height of the black area is 1/27666th of the whole inner area height, which is negligible.
  2. Pressing the button that is placed on the screen turns the screen on/off. Make sure the button is not adjacent to the screen. Also, you should use rs.getInput in yor problem. rs.getOutput returns the strength of the redstone signal emitted by the computer's redstone card.
  3. Fingercomp

    Drone usage?

    Of course there is. Assembling a drone with a leash upgrade produces a drone that can transport cows, horses, sheeps, and pigs. Like this: Or... like this: Besides, drones are entities. They move in straight lines; they don't get stuck in the fence and can actually enter a house through a door. They move pretty fast — about 6 blocks a second (robots are at least 2 times slower). Drone's movement is asynchronous, so the machine can execute some other code in the middle of the flight. Drones can fly above the block height limit. The screenshot above was made while enjoying the flight at a height of 260 blocks, for example. Oh, they can fly below the bedrock, too. Also, drones look cool. Jobs at which drones clearly outperform robots include player transportation (thanks to the leash upgrade) and item transportation (due to their mobility). And, if used with robots, drones can be useful for crop farming, autocrafting, and construction, for example.
  4. The last chapter mentions briefly the biggest problems that make sound reconstructed from the audio data sound bad, and I'm going to try to explain them. 1. The program is quite simple. It's merely a proof of concept. It doesn't use modulation or non-sine waveforms. 2. Most sounds are complex. Most sounds I hear are far from being purely sinusoidal. Perhaps it's different for you, or for someone else who happens to read this post. :) White noise is vastly different from a flute, and the flute isn't the same as a guitar. Each instrument has a unique timbre, and even a single instrument can have different timbres depending how performers play it. Sound can be decomposed into an infinite number of sinusoids that, when summed together, produce the original sound. This is what Fourier transform does, basically. So if you use it to decompose a sound of a violin playing, and filter the output, you'll see, indeed, multiple sine waves that construct the signal, which are called partials. When you reconstruct the sound back, to get better approximation, you need to sum more partials. 3. Unfortunately, the sound card only has 8 channels (by default). This means that from the set of sinusoids that represent the encoded signal we have to choose eight of them. It's enough for a piano, but for some sounds (such as human speech) it's clearly too few of them, and what you get doesn't even seem to be similar to what was originally encoded. It's worth noting that if the program also analyzed the spectrum to use different waveforms, it could probably achieve a better resemblance. 4. Furthermore, we discard phase. The Fourier transform produces two values for each sinusoid: the amplitude, and the phase. The phase is important. For example, if you have two sine waves that differ in phase by π, and have the same frequency and amplitude, you won't hear any sound. These sinusoids are opposite of each other: if, at some point, one has a value of 0.5, the other has the value of -0.5, so, when you sum them, you get zero everywhere. The sound card has no way of setting phase. It's possible to get the situation as described above: if the first channel accumulates phase of π, and then you initialize the second channel, you may hear no sound at all! Though, given the limited channel count, the fact that we discard the phase doesn't really make much difference. But the channel count can be changed in the configuration file. When I was testing the program, I had tried running it with 64 channels. It was quite noisy, because the program does not filter the output of Fourier transform, and doesn't set phase. It was also glitchy, caused by my computer, which was unable to process everything fast enough. But it was still better than 8 channels.
  5. The sound card is added by Computronics, a wonderful addon for OpenComputers. There are a few who actually know what it does. Even less people are able to use it. No one dares to understand how it works, or so I hope. Anyway, it appeared a few years (?) ago, and is still mostly undocumented. There is a page in the in-game manual, which fails to explain how great the card is. Of course it does! It has a heap of different methods, which you can use to cast many crazy magics to make the sound card sound, and it's impossible to teach someone to do magic by reading a single page. OK, I'm serious now. Last year I managed to understand how to use it, and even wrote a few posts about that. In Russian. Half a year later, I translated them to English. And now I thought of posting a topic here so that you could read them, too. Here's the link. The first two parts are all about basic things, like getting simple sounds, ADSR, and modulation. The third part features a little bit more complex things, like complex numbers and Fourier transforms. I tried to keep it simple, so I could get something wrong. If so, please leave a comment there pointing out the mistake. Grammar fixes are also highly appeciated.
  6. When I was writing that response, I didn't really know, well, how experienced you are at Lua programming. OOP in general, not in Lua, isn't really advanced. Many languages allow to write in object-oriented style. To name a few: Java, Python, C++. If you don't know what OOP is, writing a few programs in these languages can help to understand the subject. OOP in Lua is really complicated. It requires using of metatables -- and that is advanced. In library, the code may quickly become complicated and hard to maintain. Instead of messing with metatables, I prefer to use libraries that nicely hide all the mess. It's just me searching for the greatest library possible, and someone would need quite a lot of Lua experience to create a library I would be satisfied with. So if you don't want to rewrite the whole GUI library once again and want to keep it as it is, I am not going to stop you. If you can't do OOP, do what you can, or you can easily lose the motivation. Create the library you want, not I. Your current way is very beginner-friendly, so Lua beginners might use it, while I would stick to using some other library.
  7. This mod adds a new architecture. Use the same items and blocks you use to build a regular Lua computer. Before you insert the processor, shift-click while holding it, until something like "65C02 Thistle" is printed to the chat. Then you can insert it into the computer. I also think the mod adds an EEPROM, so don't forget to insert it.
  8. As an author of a few programs that heavily used different GUI libraries, I have found problems in your current library. The approach it going to work for really simple programs, but when someone uses it for bigger projects, it becomes really hard to use. Below are some of problems I've found. You wanted feedback, after all. Why not use OOP? So that GUI elements could be modified in some way by calling its method, like menu:addSeparator(). OOP is a really great choice when making GUI libraries. It's incredibly hard to add a custom element that would use your GUI system. Every program with GUI I've written needed some elements that were not provided by a GUI library I used. With proper OOP, it becomes a really easy thing. Without OOP or support for adding custom objects, it's often a pain. Your code exports some functions to the global environment. A user can accidentally override such functions and break the library. Use local whenever possible. Only export functions via the return statement. (Note, adding local when defining function in a table is a syntax error: local function tbl.func() end will not work.) GUIs quickly become more complex as more features are added. Using your library, it's hardly possible to change a button callback to another function. Ideally, it'd be something like button.callback = function() print("Now it does something else") end. You also can't switch a button to the pressed state, you can't add child objects (like a label on a frame in a container).
  9. It's better to use block symbols: ▁▂▃▄▅▆▇█ ▏ ▎ ▍ ▌ ▋ ▊ ▉ █ http://www.unicode.org/charts/PDF/U2580.pdf
  • Create New...

Important Information

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