Closed q---- closed 2 years ago
For the L, R, start, select can’t you just define buttons in your skin with the same location and size as x, y, z? You can also define discrete button pushes from the analog stick:
This says that if x goes negative by at least .01 the button defined as “x-“ is shown.
You shouldn’t need a code change to do any of this. If I could get a copy of your skin I might be able to help more.
From: q---- @.> Sent: Friday, April 30, 2021 13:10 To: retrospy/RetroSpy @.> Cc: Subscribed @.***> Subject: [retrospy/RetroSpy] Better input display for Game Boy Player (#183)
When using a GBP with a regular Game Cube controller, I find it to be somewhat overkill to display all inputs on the gc controller, especially since the analog stick gets mapped to d-pad, plus buttons are sometimes mapped to the same thing.
I made a simple addition just above the return statement to RetroSpy/Readers/GameCube.cs to address this:
state.SetButton("gbp_up", ReadStick(SignalTool.ReadByte(packet, BUTTONS.Length + 8)) > 0.5f || packet[12] != 0x00);
state.SetButton("gbp_down", ReadStick(SignalTool.ReadByte(packet, BUTTONS.Length + 8)) < -0.5f || packet[13] != 0x00);
state.SetButton("gbp_right", ReadStick(SignalTool.ReadByte(packet, BUTTONS.Length)) < -0.5f || packet[14] != 0x00);
state.SetButton("gbp_left", ReadStick(SignalTool.ReadByte(packet, BUTTONS.Length)) > 0.5f || packet[15] != 0x00);
state.SetButton("gbi_start", packet[3] != 0x00 || packet[5] != 0x00);
state.SetButton("gbi_select", packet[4] != 0x00 || packet[11] != 0x00);
state.SetButton("gbp_l", ReadTrigger(SignalTool.ReadByte(packet, BUTTONS.Length + 32)) > 0.5f);
state.SetButton("gbp_r", ReadTrigger(SignalTool.ReadByte(packet, BUTTONS.Length + 40)) > 0.5f);
I'm using GBI software to interface with my GBP, which maps both start and x to gameboy start and y and z to gameboy select, which is different than the default. Thus, to cover more use cases, it may be necessary to add more buttons, if this is the best method to add this functionality.
Things I'm unsure of:
As mentioned, I have a working build with the changes I listed above, so this isn't high priority for me, but it took a bit of looking to figure out, so it may be good to add for future users depending on whether you feel it's a good fit.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/retrospy/RetroSpy/issues/183, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE2CEVXXZJ73XOZWZN5QSJLTLME7ZANCNFSM435L7PEQ.
Thanks for the quick reply!
I didn't realize that x-
would work as a name in the skin file; I had assumed that would've had to have been defined in the reader file, since I only saw lstick_x
in both the example skin.xml's I looked at and in the reader file, but that, along with the note on precision sounds good to me.
And yeah, I would be able to handle many-to-one buttons with the skin.xml, which would obviously be cleanest with the potentially different mappings, good point.
The triggers are more similar to the stick in that around half way through the analog trigger is when it triggers a l/r press for the gbp (at least for gbi), but this can surely be handled the same way as the stick, so no worries there.
I don't currently have a skin yet; just was working on understanding the program first, but I should be able to take it from here. Thanks for the help!
No worries, let me know if there is anything I can help with.
From: q---- @.> Sent: Friday, April 30, 2021 13:59 To: retrospy/RetroSpy @.> Cc: Christopher Mallery @.>; Comment @.> Subject: Re: [retrospy/RetroSpy] Better input display for Game Boy Player (#183)
Thanks for the quick reply!
I didn't realize that x- would work as a name in the skin file; I had assumed that would've had to have been defined in the reader file, since I only saw lstick_x in both the example skin.xml's I looked at and in the reader file, but that, along with the note on precision sounds good to me.
And yeah, I would be able to handle many-to-one buttons with the skin.xml, which would obviously be cleanest with the potentially different mappings, good point.
The triggers are more similar to the stick in that around half way through the analog trigger is when it triggers a l/r press for the gbp (at least for gbi), but this can surely be handled the same way as the stick, so no worries there.
I don't currently have a skin yet; just was working on understanding the program first, but I should be able to take it from here. Thanks for the help!
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/retrospy/RetroSpy/issues/183#issuecomment-830386504, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE2CEVVDYBKCYYVAAJO674DTLMKYJANCNFSM435L7PEQ.
Just following up here, everything has worked out just fine for me, thanks again for the help!
I've attached something that should work for the included gamecube-gbasp skin that might make sense to include instead of the current skin.xml since it accounts for lstick being usable for inputting directions, the triggers activating for l/r before they're fully pressed, and x/y being select instead of "select" (which I don't think will actually get set by the reader(?)): skin.txt
Either way, I'm content with this issue as is, and am comfortable with it being closed pending thoughts on updating the gbasp skin.
all fixed.
When using a GBP with a regular Game Cube controller, I find it to be somewhat overkill to display all inputs on the gc controller, especially since the analog stick gets mapped to d-pad, plus buttons are sometimes mapped to the same thing.
I made a simple addition just above the return statement to RetroSpy/Readers/GameCube.cs to address this:
I'm using GBI software to interface with my GBP, which maps both start and x to gameboy start and y and z to gameboy select, which is different than the default. Thus, to cover more use cases, it may be necessary to add more buttons, if this is the best method to add this functionality.
Things I'm unsure of:
0.5f
As mentioned, I have a working build with the changes I listed above, so this isn't high priority for me, but it took a bit of looking to figure out, so it may be good to add for future users depending on whether you feel it's a good fit.