Closed LRFLEW closed 2 years ago
Thanks for the change, sorry for the incredible delay in merging it.
I merged this with a few changes because I worried about breaking existing code, I kept the existing naming of KPADError.
https://github.com/devkitPro/wut/commit/31e97ecc65b813a14f77e4febbbdf9953372cddf https://github.com/devkitPro/wut/commit/cd76f35ab4f491800004052b2df98119dd82a42b
This is a number of changes focused primarily on the KPAD interface, but includes some changes for VPAD when the changes also applied to them. This does result in some amount of API compatibility breaks, but I think the improved consistency is worth it.
The first change is simply adding a function signature for
KPADShutdown()
. I'm not sure why this wasn't present, considering thatKPADInit()
is already there, but adding this is a simple, non-breaking but important addition.The second change is adding more error codes for both KPAD and VPAD, as well as changing the existing error enum for KPAD to be more consistent with how VPAD labels the errors. I took a look at the disassembly of both
KPADReadEx
andVPADRead
to figure out what all the possible error codes are and make educated guesses as to what the errors indicate. It definitely appears that they share the same error codes, as they both result in error codes in similar locations in their respective read functions, and VPAD has a gap in the possible error codes (-3
is never returned). With that in mind, I renamed the existingKPADError
and it's one existing value to match the error enum for VPAD. This, along with using the enum type in the function signature forKPADReadEx
, are API breaks, but I think this is still worth it due to how minimal the existing KPAD error enum was previously.Lastly, I changed the return types for
KPADRead
,KPADReadEx
, andVPADRead
fromint32_t
touint32_t
, as well as updated the comment explainingVPADRead
's return value, since it was incorrect. The return value from these functions is the number of entries actually written to the output buffer. Since the functions have an argument with the length of this buffer, it makes sense to have these types match, but they currently don't. Between making the return type unsigned or the argument type signed, I figured the former made the most sense (as it's a case where I'd usesize_t
, which is equivalent touint32_t
on the Wii U). This is another API break, but may be harder to justify. If you don't think this change is worth it, I can drop the commit from this PR, but I think it's better to make this change now than to just leave it.