So you have a lua file, and you want to be able to run it from the command line like
./your_script.lua. In languages like python or ruby you would accomplish this by adding
#!/usr/bin/env ruby or
#!/usr/bin/env python as the first line of the file. The
#! magic pattern, known as a shebang (sheh-bang) or hashbang, tells linux to use a specific command to execute the file. However, the python and ruby examples only work because
# starts a comment in those languages, so the interpreter ignores it. In lua, our comments start with
#, so we need to get clever.
TL;DR: Input sequencing and automation tools such as autohotkey scripts, hardware macros, auto-clickers, and turbo buttons are important accessibility tools that allow people with disabilities to play games they’d otherwise be unable to play. These tools are often banned in multiplayer titles, particularly MMORPGs, in the name of fairness and bot prevention. I argue that these tools should be allowed, or even implemented within the game itself. With the recognition that a line has to be drawn somewhere, I suggest that a tool should be classified as a bot only if it automatically makes meaningful decisions in response to stimuli provided directly by the game, creating a feedback loop that does not involve the player. Further, I suggest that in the games that can’t allow external tools fairly, first-party accessibility features can still make the game playable for more people.
In this post I am going to talk about programming with speech recognition software, also known as voice coding. Voice coding as a concept is nothing new, though you may not have heard of it. Here are some talks you can check out if you want to see what this actually looks like in practice:
Recently I wanted to set up a periodic job to mirror some of my personal youtube playlists. There’s plenty of reasons one might want to do this. For me it’s simple: one copy is none copy, and two copies is one copy, so I want a second copy of youtube videos I care about stored locally. This protects against videos getting removed, copyright stuck, youtube shutting down, or anything else that might make the youtube video otherwise unavailable.
It turns out that transmitting and receiving SSTV signals is pretty easy, using just a raspberry pi as a transmitter and an RTL-SDR as a receiver. There are a few programs which you’ll need to install before you begin:
TI-BASIC is the unofficial name for the programming language included on the stock operating systems of the TI-83 and TI-84 Plus series of calculators. This includes a large set of calculators, the most popular these days being the 96x64 monochrome TI-84+SE, the 320x240 16 bit color TI-84+ Color SE (referred to as the “CSE”), and the newly released TI-84+CE which features a LCD which is significantly faster to access than the CSE and a processor upgrade from a z80 to an ez80.
I was watching Notch write what was essentially a re-implementation of Doom in Dart recently, and it inspired me to port Prelude of the Chambered (PotC) to Dart.
One method for displaying numbers larger than 16 bits is to convert it to Binary Coded Decimal (BCD) first, and display the result. BCD works by using four bits to store each decimal (base 10) digit of a number. The following code can convert a number to BCD, and display it. It’s currently written to convert a 24 bit number to a 10 digit BCD number, but can be modified to support anything really. It is memory ineffecient, because it uses one byte for each digit rather than storing two digits per byte. This is useful though because it makes the display routine simpler.
One of the fastest practical ways to write arbitrary pixels (no 1-color rectangles) to the LCD is with an OTIR loop copying pixel data directly from memory. That being said, I was wondering how many pixels you could theoretically update per frame. As mentioned, this is theoretical. This does not take into account the overhead of adjusting the LCD window, or any of the other logic you may have. It also assumes that interrupts are disabled.
Half res mode is an LCD mode which results in a halved horizontal resolution. This can also be used for double buffering, because one can write to the left side of the screen while displaying the right side or vice versa.