TAS movie files are made up of a bunch of button presses so I am guessing that it depends on the number of buttons the controller has. Since each controller button has 2 states (pressed, not pressed) that means each button should be able to be stored in a single bit since a bit has 2 states as well (0,1). The SNES controller has 12 buttons (d-pad counts as 4) so that means each frame should take up 12 bits right?
TAS movie files are made up of a bunch of button presses so I am guessing that it depends on the number of buttons the controller has. Since each controller button has 2 states (pressed, not pressed) that means each button should be able to be stored in a single bit since a bit has 2 states as well (0,1). The SNES controller has 12 buttons (d-pad counts as 4) so that means each frame should take up 12 bits right?
While the premise (button states occupying a bit each) is right, the information is stored in bytes, not bits. As such, any number of bits will get rounded up to the closest multiple of 8. One SNES controller should theoretically occupy at least two bytes per frame. The rest (the 31 KBs mrz got) is movie header and all that kind of technical data not having direct relation to the actual buttonpress content.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Each frame consists of 2 bytes per controller. So if there are 3 controllers, a frame is 6 bytes and if there is only 1 controller, a frame is 2 bytes.
This does not include the header or other information.
snes9x (SMV) uses 2 bytes per controller. 4 bits per controller per frame are wasted to make it nice to process.
VBA is also 2 bytes per controller
Gens uses 3 bytes per frame, and doesn't really make any distinction between 1p and 2p modes.
Mupen64 uses 4 bytes per controller -- 1 byte per analog axis, and 2 bytes for the buttons.
Here's the kicker: FCEU uses a run-length encoding scheme. This means it records CHANGES to the buttons being pressed. If you hold the controller is a certain way, you can record (almost) any length of time and the file size won't change. Almost. It also makes hex editting a real pain, which is why everyone just converts to FMV, edits that, and then converts back.
While the premise (button states occupying a bit each) is right, the information is stored in bytes, not bits. As such, any number of bits will get rounded up to the closest multiple of 8.
Actually there's no technical reason why the button states could not be stored in the file with as few bits as possible. It just makes the writing and reading routines slightly more complicated than when reading entire bytes, but it's not very difficult and definitely possible.
Of course in practice the people who created the file formats probably took the lazy path and used whole bytes for each frame.
Well when it's easier, more people can work with it. Even if you go the lazy way, is there really a point to save a couple of kb if that means harder to code ?
There is also the advantage of being easier to hex-edit movie files if the format is more structured, at the expense of space. Usual rant about FCM goes here.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
AKA, the D-Pad buttons only take up one half byte.
4th byte:
0x000000FF Analog Y
3rd byte:
0x0000FF00 Analog X
2nd byte:
0x00010000 C-Right
0x00020000 C-Left
0x00040000 C-Down
0x00080000 C-Up
0x00100000 R
0x00200000 L
1st byte:
0x01000000 Digital Pad Right
0x02000000 Digital Pad Left
0x04000000 Digital Pad Down
0x08000000 Digital Pad Up
0x10000000 Start
0x20000000 Z
0x40000000 B
0x80000000 A
Warp wrote:
Actually there's no technical reason why the button states could not be stored in the file with as few bits as possible.
There is. Reserved bits are safeguards in case you need to put some other function in there (for example, reset).
Actually there's no technical reason why the button states could not be stored in the file with as few bits as possible.
There is. Reserved bits are safeguards in case you need to put some other function in there (for example, reset).
That's not a technical reason. Technical reason means "there's something inherent in computers which makes it impossible to do it".
Besides, the extra space is simply a side-effect of the chance that there just happens to be less buttons than a multiple of 8. It's not a question of "I will reserve n bits for future use" but a question of "there are n non-used bits left in this last byte, something which I cannot control, but which may be convenient for future use".
