WPAD and PAD coincide?

I have an input system going, and basically what it does is this:

WPAD_Init();
PAD_Init();

while (1) {
    WPAD_ScanPads();
    // Check down events and do stuff

    PAD_ScanPads();
    // Check down events and do stuff
}

Doing this effectively renders the Wiimote code useless (it doesn't seem to pick up anything). Switching the order (init PAD first; scan PAD first) causes the Wiimote to work and GCN controller does nothing. Why? :/

Do you know what the two initilize functions actually do to the hardware, and specifically the wiimote.

Um, what... Are you just asking or indicating that you know something? No, I don't know what they specifically do, but I assume they do some housekeeping that'll set up the PAD and WPAD subsystems for you.

I don't see any reason why they would conflict; they should be seperate and I've seen homebrew that makes use of both input methods at the same time.

The mentioned code in the first post should work. Perhaps show us some more of the actual handling code? I've used both WPAD/PAD in one application too, which worked just fine. Does WPAD_Init() actually work? (Check if the player1 LED comes up on the wiimote if you press a button)

Quote
blasty
The mentioned code in the first post should work. Perhaps show us some more of the actual handling code? I've used both WPAD/PAD in one application too, which worked just fine. Does WPAD_Init() actually work? (Check if the player1 LED comes up on the wiimote if you press a button)

Yes, the player 1 LED does come up once you press a button, so WPAD_Init() is working. My code just doesn't seem to catch any events...

Here, take a look at it yourself (if you can get past my IFDEFs :P)... Check out Game::MainLoop() in Game.cpp. Notice how Init and Update is called on each Input. See WiimoteInput.cpp and GamecubeInput.cpp; it's effectively doing what I posted. I guess it's possible I'm doing something stupid and missing it, but everything seems in-check to me.



Edited 1 time(s). Last edit at 08/07/2008 08:53PM by AerialX.

Quote
AerialX

Quote
blasty
The mentioned code in the first post should work. Perhaps show us some more of the actual handling code? I've used both WPAD/PAD in one application too, which worked just fine. Does WPAD_Init() actually work? (Check if the player1 LED comes up on the wiimote if you press a button)

Yes, the player 1 LED does come up once you press a button, so WPAD_Init() is working. My code just doesn't seem to catch any events...

Here, take a look at it yourself (if you can get past my IFDEFs :P)... Check out Game::MainLoop() in Game.cpp. Notice how Init and Update is called on each Input. See WiimoteInput.cpp and GamecubeInput.cpp; it's effectively doing what I posted. I guess it's possible I'm doing something stupid and missing it, but everything seems in-check to me.

You are only calling WPAD_INIT(); and PAD_INIT(); once right?

Quote
vader347
You are only calling WPAD_INIT(); and PAD_INIT(); once right?

Unless boost's foreach is seriously flawed, of course (and actually I tried it with a normal for loop anyway to ensure that wasn't the problem). I just don't see what could be wrong, since commenting out one of the two makes the other work, just as switching their order does.

Could you post the entire program?

Quote

Could you post the entire program?

He did.

Try using (WPAD_CHAN_0) as in:

if(WPAD_ButtonsDown(WPAD_CHAN_0)&WPAD_BUTTON_UP)
//do something

if(WPAD_ButtonsDown(WPAD_CHAN_0)&WPAD_BUTTON_DOWN)
//do something

WPADData* data = WPAD_Data(WPAD_CHAN_0);

I am using WPAD_CHAN_0, although admittedly it's messy and checks things differently than the PAD checking code (because the WPAD stuff was written first and mainly just ported from my PC wiiuse checking code). I'll change it for consistency's sake, make it use WPAD_ButtonsDown() and friends, but I really doubt that'll fix anything since the PAD stuff fails in the same way the WPAD fails depending on their order.



Edited 1 time(s). Last edit at 08/08/2008 08:46PM by AerialX.

I've had no problems when I've used, as you put it, "WPAD_ButtonsDown() and friends".

Well, as expected... That changed nothing D:

Oh. Sorry.

Um, ignore this; I'm an idiot :/

For the curious: Whichever input was ->Update()'d last would write its button states over the previous input's. My project finally has proper multi-input support and GX now works (that took me all night): Picture

It works! =D
great job getting GX working.

Everything besides sound works now right?

That depends on your definition of "everything" ;)

I'm going away on vacation for the next two weeks. When I get back I'll finish up the texturing in GX that I've been working on tonight and it'll be more or less on par with the OpenGL demo (minus sound; that'll be a hell of an adventure on its own >.>).