Fix rumble + ifdefs + rumble documentation #594
Conversation
Arceveti
added
the
high priority
Arceveti
changed the title
…into develop/2.1.0-fix-rumble-ifdefs
| @@ -14,7 +14,7 @@ | |||
| * Enables Rumble Pak Support. | |||
| * Currently not recommended, as it may cause random crashes. | |||
| */ | |||
| // #define ENABLE_RUMBLE (1 || VERSION_SH) | |||
| #define ENABLE_RUMBLE | |||
There was a problem hiding this comment.
Either this should be disabled by default, or if it is safe to always leave on, the comment two lines up should be modified/deleted.
There was a problem hiding this comment.
I removed the comment. I think it should be on by default since it's never crashed in any of my testing with these changes. I think that comment was about the old PJ64 crash from around 2 years ago.
There was a problem hiding this comment.
not totally sure about it being left on even if it doesnt cause too much instability just because its extra code being added and most people won't care about it, and we can't be totally certain its not unstable
| @@ -1,7 +1,7 @@ | |||
|
|
|||
| /*---------------------------------------------------------------------* | |||
| Copyright (C) 1998 Nintendo. | |||
|
|
|||
There was a problem hiding this comment.
I personally think we shouldn't be touching any of the include/n64/PR/ files with any formatting changes whatsoever, unless they revolve around code actually written by us.
… into develop/2.1.0-fix-rumble-ifdefs
| #define CHNL_ERR_NORESP (0b1 << 7) /* 0x80: Bit 7 (Rx): No response error */ | ||
| #define CHNL_ERR_OVERRUN (0b1 << 6) /* 0x40: Bit 6 (Rx): Overrun error */ | ||
| #define CHNL_ERR_FRAME (0b1 << 7) /* 0x80: Bit 7 (Tx): Frame error */ | ||
| #define CHNL_ERR_COLLISION (0b1 << 6) /* 0x40: Bit 6 (Tx): Collision error */ |
There was a problem hiding this comment.
Just use 1 instead of 0b1 for these (last one's probably fine though)
| #define CHNL_ERR_NORESP (0b1 << 7) /* 0x80: Bit 7 (Rx): No response error */ | ||
| #define CHNL_ERR_OVERRUN (0b1 << 6) /* 0x40: Bit 6 (Rx): Overrun error */ | ||
| #define CHNL_ERR_FRAME (0b1 << 7) /* 0x80: Bit 7 (Tx): Frame error */ | ||
| #define CHNL_ERR_COLLISION (0b1 << 6) /* 0x40: Bit 6 (Tx): Collision error */ |
| s32 sRumblePakActive = FALSE; | ||
| s32 sRumblePakErrorCount = 0; | ||
| s32 gRumblePakTimer = 0; | ||
| _Bool sRumblePakThreadActive = FALSE; // Set to TRUE when the rumble thread starts. |
There was a problem hiding this comment.
_Bool doesn't exist anywhere else in the repo. Not sure if it comes with any downsides, but I might just stick with u8 for consistency sake. (At minimum, make sure it compiles with GCC 9, or it's definitely a no-go.)
There was a problem hiding this comment.
agreed, this should be a u8
…Arceveti/HackerSM64; branch 'develop/2.1.0' of https://github.com/HackerN64/HackerSM64 into develop/2.1.0-fix-rumble-ifdefs
…into develop/2.1.0-fix-rumble-ifdefs
|
Moving to 2.2/3.0. |
…into develop/2.1.0-fix-rumble-ifdefs
…into develop/2.1.0-fix-rumble-ifdefs
…into develop/2.1.0-fix-rumble-ifdefs
…develop/2.1.0-fix-rumble-ifdefs
…develop/2.1.0-fix-rumble-ifdefs
|
Moving to new PR |
|
Wrong PR lol |
| @@ -14,7 +14,7 @@ | |||
| * Enables Rumble Pak Support. | |||
| * Currently not recommended, as it may cause random crashes. | |||
| */ | |||
| // #define ENABLE_RUMBLE (1 || VERSION_SH) | |||
| #define ENABLE_RUMBLE | |||
There was a problem hiding this comment.
not totally sure about it being left on even if it doesnt cause too much instability just because its extra code being added and most people won't care about it, and we can't be totally certain its not unstable
| #define CHNL_ERR_NORESP (0b1 << 7) /* 0x80: Bit 7 (Rx): No response error */ | ||
| #define CHNL_ERR_OVERRUN (0b1 << 6) /* 0x40: Bit 6 (Rx): Overrun error */ | ||
| #define CHNL_ERR_FRAME (0b1 << 7) /* 0x80: Bit 7 (Tx): Frame error */ | ||
| #define CHNL_ERR_COLLISION (0b1 << 6) /* 0x40: Bit 6 (Tx): Collision error */ |
| s32 sRumblePakActive = FALSE; | ||
| s32 sRumblePakErrorCount = 0; | ||
| s32 gRumblePakTimer = 0; | ||
| _Bool sRumblePakThreadActive = FALSE; // Set to TRUE when the rumble thread starts. |
There was a problem hiding this comment.
agreed, this should be a u8
|
Hi! Is this related to non-functional inputs if the rumble pak is present? (start with it plugged in, or plugged in during play, the controller stops working after that). In my case I built a basically vanilla SM64 with minor bugfixes (like invisible walls) and performance improvements, but with Rumble Pak support. Works perfectly, except for the rumble. |
Fixes rumble and rumble ifdefs, and documents rumble functionality.