I've seen a lot of questions about how to detect player inputs with script - specifically, multi-press inputs. The common example scenario is pressing two or more buttons at once (ex. Attack + Jump) to do an animation, but during gameplay the detection seems very unreliable. The creator then assumes OpenBOR can't detect multiple inputs, the script system can't handle multiple inputs, or that their code is wrong.
The reality is a bit more nuanced than that. Before going into code, it's important to understand just how control inputs work. Take a look at the following videos. They focus on the NES, but most game hardware and software (including OpenBOR) work the same way.
Although control hardware can differ from one platform to another, the actual control interpretation is pretty much identical across the board. Inputs are placed into a memory address for reading by the software, and this is where it gets interesting.
To keep things as memory efficient and fast as possible, control inputs are handled at the Bit level, NOT the Byte. If you recall the basic computation classes most of us had in high school, 1 byte is 1 character, and is comprised of 8 bits, each bit being an on or off signal. In other words, you can encode 8 simultaneous on/off signals (i.e 8 digital controller inputs) into a single byte. Since the NES's native integer size is 8 bits, this works out perfectly. 1 integer (1 byte of memory) can carry the entire controller status for 1 player, and its 8 bit CPU could evaluate 1 player's inputs in a single cycle.
In OpenBOR, things are very similar, just scaled up a little. Most contemporary CPUs are 32 or 64 bit, and extremely optimal at working with 32 bit integers. Because of this, contemporary integers are almost always 32 bit, and so they can carry up to 32 simultaneous input signals - far more than most games need. In OpenBOR's case, there are only 13 possible input signals total (4 directions, 6 Action Buttons, Start, Escape, and Screenshot). You could theoretically encode all the inputs from 2 players into a single integer (for simplicity we don't do that, there's 1 integer per player)!
So why can't you reliably detect more than one press with a script? Actually you can, and we're getting there... But first let's talk about timing. Watch the next video, and pay attention to how the famous Konmai code is interpreted. Notice that only memory address stores all the controller inputs. As above, it's an 8 bit integer, with each bit corresponding to one of the eight controller inputs. Also note how series input sequences are validated - this is also how move commands like a Haoduken work.
IN PROGRESS - I had to leave while typing and didn't want to lose my place. Finish soon.
The reality is a bit more nuanced than that. Before going into code, it's important to understand just how control inputs work. Take a look at the following videos. They focus on the NES, but most game hardware and software (including OpenBOR) work the same way.
Although control hardware can differ from one platform to another, the actual control interpretation is pretty much identical across the board. Inputs are placed into a memory address for reading by the software, and this is where it gets interesting.
To keep things as memory efficient and fast as possible, control inputs are handled at the Bit level, NOT the Byte. If you recall the basic computation classes most of us had in high school, 1 byte is 1 character, and is comprised of 8 bits, each bit being an on or off signal. In other words, you can encode 8 simultaneous on/off signals (i.e 8 digital controller inputs) into a single byte. Since the NES's native integer size is 8 bits, this works out perfectly. 1 integer (1 byte of memory) can carry the entire controller status for 1 player, and its 8 bit CPU could evaluate 1 player's inputs in a single cycle.
In OpenBOR, things are very similar, just scaled up a little. Most contemporary CPUs are 32 or 64 bit, and extremely optimal at working with 32 bit integers. Because of this, contemporary integers are almost always 32 bit, and so they can carry up to 32 simultaneous input signals - far more than most games need. In OpenBOR's case, there are only 13 possible input signals total (4 directions, 6 Action Buttons, Start, Escape, and Screenshot). You could theoretically encode all the inputs from 2 players into a single integer (for simplicity we don't do that, there's 1 integer per player)!
So why can't you reliably detect more than one press with a script? Actually you can, and we're getting there... But first let's talk about timing. Watch the next video, and pay attention to how the famous Konmai code is interpreted. Notice that only memory address stores all the controller inputs. As above, it's an 8 bit integer, with each bit corresponding to one of the eight controller inputs. Also note how series input sequences are validated - this is also how move commands like a Haoduken work.
IN PROGRESS - I had to leave while typing and didn't want to lose my place. Finish soon.