My program is too large to post in full here, however here is a slimmed down snippet where the issue is occurring
uint8_t successful_b_presses_just_after = 0;
uint8_t successful_b_presses_active_just_after = 0;
uint8_t successful_b_presses_long_after = 0;
uint8_t successful_b_presses_active_long_after = 0;
uint32_t previous_buttons[4] = {0};
while(1){
MAPLE_FOREACH_BEGIN(MAPLE_FUNC_CONTROLLER, cont_state_t, st)
//other thumbstick code
//Use the buttons previously pressed to control what happens here
button_action = 0;
button_action |= ((previous_buttons[__dev->port] & CONT_A) && !(st->buttons & CONT_A)) << 0; //A released
button_action |= ((previous_buttons[__dev->port] & CONT_X) && !(st->buttons & CONT_X)) << 1; //X released
button_action |= (!(previous_buttons[__dev->port] & CONT_B) && (st->buttons & CONT_B)) << 2; //B pressed
button_action |= (!(previous_buttons[__dev->port] & CONT_Y) && (st->buttons & CONT_Y)) << 3; //Y pressed
if(button_action & (1 << 2)){
successful_b_presses_active_just_after++;
}
if(!(previous_buttons[__dev->port] & CONT_B) && (st->buttons & CONT_B)){
successful_b_presses_just_after++;
}
//stuff that reads button_action, but does not change it
//Every time you perform a successful b press (active), we increment it
if(button_action & (1 << 2)){
successful_b_presses_active_long_after++;
}
//Every time you perform a successful b press, we increment it
if(!(previous_buttons[__dev->port] & CONT_B) && (st->buttons & CONT_B)){
successful_b_presses_long_after++;
}
//Press Y to end
if(st->buttons & (CONT_Y)){
error_freeze("JA, LA (norm/active): %d, %d, %d, %d", successful_b_presses_just_after, successful_b_presses_active_just_after, successful_b_presses_long_after, successful_b_presses_active_long_after);
}
//Other maple stuff
previous_buttons[__dev->port] = st->buttons;
MAPLE_FOREACH_END()
//Graphics stuff
}
I ran this program on real hardware, pressed the B button 5 times (The press "failed" the first 4 times and succeeded the last time) then I pressed Y to end the program and give me the debug message which reads "JA, LA (norm/active): 1, 1, 5, 1". This tells me that somehow it re-polled the controller input between the two "just_after" and "long_after" debug counter sections which explains why my "button_action" variable wasn't what I was expecting.
I don't have a good enough understanding of the DC or the internals of KOS to understand how st->buttons could be updating itself mid loop and if its just some DC limitation/bug, a bug with KOS or something else. I've thought of a ghetto fix where I poll and instantly store the current buttons into a separate variable and use that instead of st->buttons for the rest of the computation, but that would still have some minor issues and it still doesn't fix/explain whats really happening.
Some other things to note: If I have multiple controllers plugged in, the first controller inline gets affected the most with later controllers not being affected much if at all (So if we have Port 1 and 3 active, then port 1 has lots of "dropped" input and port 3 seems to be fine). Also from what I can understand, the bug seems to be more common when there's more stuff to draw (And due to how my program works that also means more of main memory is used to store positions, UVs and such), but I don't really get why and like I said at the beginning, I can get the bug to "completely fix itself with no "dropped" inputs" by drawing a few extra sprites on screen.
)
