This is a new trend. Not so new as an idea, but console verification of it in front of thousands of people makes it a trend automatically. I want to add it in the next release. Any implementation suggestions?
My current idea is to add another bit to fm2 |commands|, append desired pollcount that input should happen at at the end of input line (that'd only work if the corresponding bit is set), have pollcount that resets every frame, and a poll advance hotkey. This allows frames we don't need subframe input at to remain entirely normal, and not to spam empty entries for subframes we don't record input at.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bizhawk made a conscious decision not to deal with subframe input until 2.0 or 3.0. And it's crusty in its own way. If all you want to do is hack it so you can send a subframe FM2 to a game, then that's easy. Your approach sounds fine. It's recording and tasediting it that's not easy.
Last edit: zeromus 2016-07-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
adding poll advance to an emulator will generally brutalize it. however since fceux already supports debugging relatively well, this shouldn't be such a huge problem. I hope you can see why it's a bigger problem in bizhawk.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I've found another use case for sub-frame input.
I have been handed the source code of an NES game that is failing to see Zapper trigger presses, and I am expected to fix it. I have been told that it detects all presses in emulators but misses about 20 percent of them on an NES. So I sat and thought of possible differences between the emulation environment and the hardware environment.
One cause of failure to read input happens when a particular control is read multiple times during the frame. An NES input device can change the input at any cycle, while an emulator usually changes once per vblank. A dependency on when in the frame a button is pressed can be tested in an emulator by varying the scanline number on which the input is changed. It doesn't often happen with games that use a controller because a controller is often read only once per frame, compared to a Zapper that has to be read every 10 lines or so to detect light.
The "Display on scanline:" field in PPU Viewer allows changing the scanline on which the pattern table viewer reads video memory. I hereby request the same feature for when presses on the standard controller and the Zapper take effect.
Last edit: Damian Yerrick 2016-09-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You're literally insane. FCEUX is way too crusty for that.
Why is it not in a not-so-crusty-supposedly bizhawk yet then?
My current idea is to add another bit to fm2 |commands|, append desired pollcount that input should happen at at the end of input line (that'd only work if the corresponding bit is set), have pollcount that resets every frame, and a poll advance hotkey. This allows frames we don't need subframe input at to remain entirely normal, and not to spam empty entries for subframes we don't record input at.
Bizhawk made a conscious decision not to deal with subframe input until 2.0 or 3.0. And it's crusty in its own way. If all you want to do is hack it so you can send a subframe FM2 to a game, then that's easy. Your approach sounds fine. It's recording and tasediting it that's not easy.
Last edit: zeromus 2016-07-23
Recording is easy as long as you poll advance. Adding this to taseditor might indeed be a challenge.
adding poll advance to an emulator will generally brutalize it. however since fceux already supports debugging relatively well, this shouldn't be such a huge problem. I hope you can see why it's a bigger problem in bizhawk.
I think I've found another use case for sub-frame input.
I have been handed the source code of an NES game that is failing to see Zapper trigger presses, and I am expected to fix it. I have been told that it detects all presses in emulators but misses about 20 percent of them on an NES. So I sat and thought of possible differences between the emulation environment and the hardware environment.
One cause of failure to read input happens when a particular control is read multiple times during the frame. An NES input device can change the input at any cycle, while an emulator usually changes once per vblank. A dependency on when in the frame a button is pressed can be tested in an emulator by varying the scanline number on which the input is changed. It doesn't often happen with games that use a controller because a controller is often read only once per frame, compared to a Zapper that has to be read every 10 lines or so to detect light.
The "Display on scanline:" field in PPU Viewer allows changing the scanline on which the pattern table viewer reads video memory. I hereby request the same feature for when presses on the standard controller and the Zapper take effect.
Last edit: Damian Yerrick 2016-09-05
Awesome news, I'll show this to the pros!
Last edit: feos 2016-09-05