This would allow a singleton instance of it to exist per port, and for multiple devices to be shared between eamio/sdvxio/jbio etc.
In GitLab by @xyen on Sep 12, 2020, 11:08
This would allow a singleton instance of it to exist per port, and for multiple devices to be shared between eamio/sdvxio/jbio etc.
Use-case: Run any SDVX game with BT5 as a backend on real hardware = real ICCA readers and KFCA IO.
mon pointed out, that this is currently not possible:
So I've been thinking a bit more about how to fix the contention between ICCA and jbio's lights, I think I have a solution
jbio-p4io just implements everything in eamio.dll too, using the ICCA driver that already exists, while also opening the h44b on the same acio bus
@xyen already proposed the solution pointed out by this issue, to have a separate shared lib that is running the acio bus "backend" while other (device) libraries can use this to drive single devices on the bus. These emulated devices can be implemented against any kind of API or drive real hardware, e.g. see eamio-icca.
@xyen's main points from our chat regarding his proposed change:
Nothing changes in game hooks
No additional dependencies for any of the base input dll's, only the ACIO using ones
This isn't callback based, each IO dll still calls the polling function and just waits for the entire request/response to occur
We'll need some sort of queueing / lock contention to ensure that no starvation occurs, maybe ticket system?
Some notes from a chat with @xyen about this:
**Use-case**: Run any SDVX game with BT5 as a backend on real hardware = real ICCA readers and KFCA IO.
mon pointed out, that this is currently not possible:
```
So I've been thinking a bit more about how to fix the contention between ICCA and jbio's lights, I think I have a solution
jbio-p4io just implements everything in eamio.dll too, using the ICCA driver that already exists, while also opening the h44b on the same acio bus
```
@xyen already proposed the solution pointed out by this issue, to have a separate shared lib that is running the acio bus "backend" while other (device) libraries can use this to drive single devices on the bus. These emulated devices can be implemented against any kind of API or drive real hardware, e.g. see eamio-icca.
@xyen's main points from our chat regarding his proposed change:
1. Nothing changes in game hooks
2. No additional dependencies for any of the base input dll's, only the ACIO using ones
3. This isn't callback based, each IO dll still calls the polling function and just waits for the entire request/response to occur
4. We'll need some sort of queueing / lock contention to ensure that no starvation occurs, maybe ticket system?
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
In GitLab by @xyen on Sep 12, 2020, 11:08
This would allow a singleton instance of it to exist per port, and for multiple devices to be shared between eamio/sdvxio/jbio etc.
Some notes from a chat with @xyen about this:
Use-case: Run any SDVX game with BT5 as a backend on real hardware = real ICCA readers and KFCA IO.
mon pointed out, that this is currently not possible:
@xyen already proposed the solution pointed out by this issue, to have a separate shared lib that is running the acio bus "backend" while other (device) libraries can use this to drive single devices on the bus. These emulated devices can be implemented against any kind of API or drive real hardware, e.g. see eamio-icca.
@xyen's main points from our chat regarding his proposed change: