Fixes p3io and extio lighting output being swapped with one another (the header, mm and smx modules had it right)
Fixes IDS_DDR_P1_BOTTOM_LIGHT schema being incorrectly mapped (on SD)
Adds 64 bit ddr build and related dependencies
Merging this before or after !37 doesn't really matter, although I think this kinda does what anyone would want to expose their own p3io r232 port (COM4) for anyways (using their own lights for the HDXS device).
Tested with:
DDR 32bit SD
DDR 32bit HD
DDR 64bit HD
Verified that all (EXTIO, p3io HDXS, and p3io IOCTL based ones) lights work, and are mapped as expected.
Still missing are the DDRS ones on COM2, but those ones would be hard to map / not really be of use to anyone emulating anyways as they're strips and not individual lights.
In GitLab by @xyen on Jun 29, 2020, 19:14
_Merges ddr_hd -> master_
- Adds HDXS acio device + emu
- Fixes p3io and extio lighting output being swapped with one another (the header, mm and smx modules had it right)
- Fixes IDS_DDR_P1_BOTTOM_LIGHT schema being incorrectly mapped (on SD)
- Adds 64 bit ddr build and related dependencies
Merging this before or after !37 doesn't really matter, although I think this kinda does what anyone would want to expose their own p3io r232 port (COM4) for anyways (using their own lights for the HDXS device).
Tested with:
- DDR 32bit SD
- DDR 32bit HD
- DDR 64bit HD
Verified that all (EXTIO, p3io HDXS, and p3io IOCTL based ones) lights work, and are mapped as expected.
Still missing are the DDRS ones on COM2, but those ones would be hard to map / not really be of use to anyone emulating anyways as they're strips and not individual lights.
The API gets kinda messy with the different types of lights here. Any idea how we can avoid exposing the interfaces of different types of hardware here?
The API gets kinda messy with the different types of lights here. Any idea how we can avoid exposing the interfaces of different types of hardware here?
The following code is save to handle the NULL value. Therefore, I don't understand why you emit a warning log message that is also not very informative, imo. Are there valid use-cases for lights_dispatcher to be NULL?
The following code is save to handle the NULL value. Therefore, I don't understand why you emit a warning log message that is also not very informative, imo. Are there valid use-cases for `lights_dispatcher` to be NULL?
It's not, ddrio-mm uses it (and correspondingly has a copy of it).
This file is completely unused.
In GitLab by @xyen on Jun 29, 2020, 19:28
Commented on [src/main/mm/ddrio.def line 1](https://github.com/djhackersdev/bemanitools/compare/768a7a74f2cab5501d428fb0791cd4ef2e2acacd..347851c52cb549740e839ead126e977e18a79f59#diff-2d5958dc3db4204f40555c55db6cbdc1L1)
It's not, ddrio-mm uses it (and correspondingly has a copy of it).
This file is completely unused.
Not easily, since we can't double up on the previous functions, as they're all called at different locations.
Originally I tried stuffing the new stuff into ddr_io_set_lights_p3io, but the existing call would clobber the light values that I set.
The main issue is that the lighting used between cab types isn't really translatable either (unlike SDVX and IIDX, where I re-used the existing functions when writing support for the new IO), so we can't just re-map existing bit usages.
Will leave this open for more discussion, but if you think this is acceptable, feel free to resolve this thread.
In GitLab by @xyen on Jun 29, 2020, 19:31
Commented on [src/main/bemanitools/ddrio.h line 122](https://github.com/djhackersdev/bemanitools/compare/768a7a74f2cab5501d428fb0791cd4ef2e2acacd..347851c52cb549740e839ead126e977e18a79f59#diff-44e32b1c1ddc2c361e7a7ed54eac58dbR122)
Not easily, since we can't double up on the previous functions, as they're all called at different locations.
Originally I tried stuffing the new stuff into `ddr_io_set_lights_p3io`, but the existing call would clobber the light values that I set.
The main issue is that the lighting used between cab types isn't really translatable either (unlike SDVX and IIDX, where I re-used the existing functions when writing support for the new IO), so we can't just re-map existing bit usages.
Will leave this open for more discussion, but if you think this is acceptable, feel free to resolve this thread.
In GitLab by @xyen on Jun 29, 2020, 19:33
Commented on [src/main/acio/hdxs.h line 23](https://github.com/djhackersdev/bemanitools/compare/768a7a74f2cab5501d428fb0791cd4ef2e2acacd..347851c52cb549740e839ead126e977e18a79f59#diff-85870e6e4d34e789ec309b83715c7846R23)
The lights are controlled in pairs, this bit controls up/down together, as well as left/right.
See the IO test screen: https://xyen.s-ul.eu/wcdHwAw3.png, notice `P1 Select LR` and `P1 Select UD`
Well, that is ok. I suggest we should add some documentation to the functions to clarify the cabinet types they are used for and that you don't have to implement all of them if you don't want/can support specific ones. It's clear to us right now, but API users might be uncertain how/when each one is called.
Well, that is ok. I suggest we should add some documentation to the functions to clarify the cabinet types they are used for and that you don't have to implement all of them if you don't want/can support specific ones. It's clear to us right now, but API users might be uncertain how/when each one is called.
I'm not sure if any other games use HDXS, but in theory if someone were to implement one, I'd assume that they want lights to work, and so the warning would remind them to implement a light dispatcher.
In GitLab by @xyen on Jun 29, 2020, 19:34
Commented on [src/main/acioemu/hdxs.c line 31](https://github.com/djhackersdev/bemanitools/compare/768a7a74f2cab5501d428fb0791cd4ef2e2acacd..0606f7d3ea7cefee2cd451b66ae9fd5fa32caa56#diff-f250b21cf0d07aec368160e08fde6b7cR31)
I'm not sure if any other games use HDXS, but in theory if someone were to implement one, I'd assume that they want lights to work, and so the warning would remind them to implement a light dispatcher.
In GitLab by @xyen on Jun 29, 2020, 19:34
Commented on [src/main/bemanitools/ddrio.h line 122](https://github.com/djhackersdev/bemanitools/compare/768a7a74f2cab5501d428fb0791cd4ef2e2acacd..347851c52cb549740e839ead126e977e18a79f59#diff-44e32b1c1ddc2c361e7a7ed54eac58dbR122)
Agreed, will add some documentation to ddrio.h
In GitLab by @xyen on Jun 29, 2020, 20:23
Commented on [src/main/acioemu/hdxs.c line 31](https://github.com/djhackersdev/bemanitools/compare/768a7a74f2cab5501d428fb0791cd4ef2e2acacd..0606f7d3ea7cefee2cd451b66ae9fd5fa32caa56#diff-f250b21cf0d07aec368160e08fde6b7cR31)
changed this line in [version 2 of the diff](/djhackers/bemanitools/-/merge_requests/39/diffs?diff_id=1250&start_sha=0606f7d3ea7cefee2cd451b66ae9fd5fa32caa56#c9b16d703af187e058e1ad5066d315d55e0013ff_31_31)
In GitLab by @xyen on Jun 29, 2020, 20:23
Commented on [src/main/ddrio-mm/ddrio.c line 218](https://github.com/djhackersdev/bemanitools/compare/768a7a74f2cab5501d428fb0791cd4ef2e2acacd..0606f7d3ea7cefee2cd451b66ae9fd5fa32caa56#diff-e6f3d9731e2b8969c06c02ec33b90068R218)
changed this line in [version 2 of the diff](/djhackers/bemanitools/-/merge_requests/39/diffs?diff_id=1250&start_sha=0606f7d3ea7cefee2cd451b66ae9fd5fa32caa56#97e7bf54e551179937021f956e999412348c6281_218_218)
In GitLab by @xyen on Jun 29, 2020, 20:23
added 1 commit
<ul><li>347851c5 - ddrio: add some more comments</li></ul>
[Compare with previous version](/djhackers/bemanitools/-/merge_requests/39/diffs?diff_id=1250&start_sha=0606f7d3ea7cefee2cd451b66ae9fd5fa32caa56)
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 Jun 29, 2020, 19:14
Merges ddr_hd -> master
Merging this before or after !37 doesn't really matter, although I think this kinda does what anyone would want to expose their own p3io r232 port (COM4) for anyways (using their own lights for the HDXS device).
Tested with:
Verified that all (EXTIO, p3io HDXS, and p3io IOCTL based ones) lights work, and are mapped as expected.
Still missing are the DDRS ones on COM2, but those ones would be hard to map / not really be of use to anyone emulating anyways as they're strips and not individual lights.
Why did you delete this file? Looks like this is used for minimaid support.
The API gets kinda messy with the different types of lights here. Any idea how we can avoid exposing the interfaces of different types of hardware here?
Nit: Remove empty line
Up and down for the same index? Can you explain how this works?
The following code is save to handle the NULL value. Therefore, I don't understand why you emit a warning log message that is also not very informative, imo. Are there valid use-cases for
lights_dispatcherto be NULL?In GitLab by @xyen on Jun 29, 2020, 19:28
Commented on src/main/mm/ddrio.def line 1
It's not, ddrio-mm uses it (and correspondingly has a copy of it).
This file is completely unused.
In GitLab by @xyen on Jun 29, 2020, 19:31
Commented on src/main/bemanitools/ddrio.h line 122
Not easily, since we can't double up on the previous functions, as they're all called at different locations.
Originally I tried stuffing the new stuff into
ddr_io_set_lights_p3io, but the existing call would clobber the light values that I set.The main issue is that the lighting used between cab types isn't really translatable either (unlike SDVX and IIDX, where I re-used the existing functions when writing support for the new IO), so we can't just re-map existing bit usages.
Will leave this open for more discussion, but if you think this is acceptable, feel free to resolve this thread.
In GitLab by @xyen on Jun 29, 2020, 19:33
Commented on src/main/acio/hdxs.h line 23
The lights are controlled in pairs, this bit controls up/down together, as well as left/right.
See the IO test screen: https://xyen.s-ul.eu/wcdHwAw3.png, notice
P1 Select LRandP1 Select UDWell, that is ok. I suggest we should add some documentation to the functions to clarify the cabinet types they are used for and that you don't have to implement all of them if you don't want/can support specific ones. It's clear to us right now, but API users might be uncertain how/when each one is called.
In GitLab by @xyen on Jun 29, 2020, 19:34
Commented on src/main/acioemu/hdxs.c line 31
I'm not sure if any other games use HDXS, but in theory if someone were to implement one, I'd assume that they want lights to work, and so the warning would remind them to implement a light dispatcher.
In GitLab by @xyen on Jun 29, 2020, 19:34
Commented on src/main/bemanitools/ddrio.h line 122
Agreed, will add some documentation to ddrio.h
Then I suggest change this message to something like "NULL lights_dispatcher, lights output won't work" to tell the user what to expect.
In GitLab by @xyen on Jun 29, 2020, 20:23
Commented on src/main/acioemu/hdxs.c line 31
changed this line in version 2 of the diff
In GitLab by @xyen on Jun 29, 2020, 20:23
Commented on src/main/ddrio-mm/ddrio.c line 218
changed this line in version 2 of the diff
In GitLab by @xyen on Jun 29, 2020, 20:23
added 1 commit
347851c5- ddrio: add some more commentsCompare with previous version
In GitLab by @xyen on Jun 29, 2020, 20:23
resolved all threads
LGTM
In GitLab by @xyen on Jun 29, 2020, 21:05
merged