you know how to keep different devkitppc version for different homebrew needs?
create (extract) each devkitppc to different folders inside devkitpro.
example :
devkitPPC/ <-- I keep this one updated (also, autoupdate would replace it, if you ever launch the devkitpro installer again)
devkitPPC_r27/
devkitPPC_r29-1/
and before compiling, or in your makefile, set the path to the devkitppc you want. it will affect the environment variable only temporarily, for the current session (current MSdos window only):
build.bat
the second line is just a way to check it worked, it displays the temporary environment variable path.Code:set DEVKITPPC=/f/devkitPro/devkitPPC_r29-1 set devkitPPC make clean make -j4
or
makefile
Code:export DEVKITPPC := $(DEVKITPRO)/devkitPPC_r27 ...
You still need to edit the libogc version manually to match the version used by your project.
There's a more complicated (automated) way if you want to also use different portlib/libogc path, which involve editing the "wii_rules" file in devkitppc folder, and then just "set" the devkitPPC variable to the folder with the wii_rules you want.
devkitppc_usbgx/ with wii_rules set to usbgx libogc and portlib path
devkitppc_oldhomebrewname/ with wii_rules set to specific libogc and portlib path
etc.
or edit the path to wii_rules in your makefile :
Code:include $(DEVKITPPC)/wii_rules
or, overwrite the path in your makefile after wii_rules include:
add this to edit the path in your makefile (or if not using wii_rules) :
Code:export LIBOGC_LIB := $(DEVKITPRO)/libogc/lib/wii export PORTLIBS := $(DEVKITPRO)/portlibs/ppc
they will be loaded here:
Code:export LIBPATHS := $(foreach dir,$(LIBDIRS),-L$(dir)/lib) \ -L$(LIBOGC_LIB) -L$(PORTLIBS)/lib
@ECHO off
TITLE Compilation d'USBLoader GX
CD..\..\..
SET PATH=%cd%\msys\bin;%cd%\devkitPPC\bin;C:\Program Files\TortoiseSVN\bin
SET DEVKITPRO=/%CD::=%
SET DEVKITPRO=%DEVKITPRO:\=/%
SET DEVKITPPC=%devkitpro%/devkitPPC
SET DEVKITARM=%devkitpro%/devkitARM
CD %~dp0
make -j5
wiixz boot.dol HBC\boot.dol
pause
I'm working on it, and I started adding it to the sources, but haven't tested yet.@Cyan is the wiiu gamepad support currently on the to-do list one which will use it regardless of whether usbloader is injected into VC? Would love to be able to not bring a wiimote around for that if it didn't require injection!
Ultimately holding out for HID support but this could be great in the mean-time
I'm working on it, and I started adding it to the sources, but haven't tested yet.
I'll need to create a forwarder WiiVC, but I don't understand the different patching options (wiimote passtrhough?)
Also, you should note that the gamepad will NOT work if it's not launched from a WiiVC.
the gamepad support is full integrated part of IOS255 (fw.img injected into wiiVC) and that cIOS can't be changed while in vWii mode.
if launched from vWii, the WiiU hardware is completely deactivated.
Greywolf : the only advantage is to launch nintendont on SD card without wiimote.
a lot of users are now using nintendont injected wiiVC to play games, but only one nincfg.bin file is shared among all launched games.
Using a loader allows users to set different game settings, but some users don't have a wiimote or a procontroller, so they can't use USBGX interface to launch a gamecube game.
That's only used for a short period (pick the game, launch!) but will help a lot of users.
that's also why I would like to fix the AHB and sysmenu resources access. If it's not possible, I'll limit the banner layout access when using WiiVC, but also the "start/option" button below the animated banners. that's the less problematic of both resources access issue.
I'll need to create a forwarder WiiVC, but I don't understand the different patching options (wiimote passtrhough?)
ok so the first piece to the puzzle is done, updating nfs2iso2nfs to allow for a better flexibility.
-separated wiimote passthrough patches from homebrew patches (as some homebrew may want to keep that emu around)
-improved wiimote vertical patch, now also swaps around the A/B/1/2 buttons
-improved homebrew AHBPROT patch, should now work correctly
https://mega.nz/#!EkoTWDaT!L6jfHa-rK97wecprnfpmuofrzGkNDaJZcWdKmAH0FSY
Basically for homebrew that wants to use the gamepad, add -passthrough into its command line together with -homebrew, for homebrew that doesnt want it (like my upcoming wiiware launcher) just use -homebrew and also maybe -wiimote or -vertical depending on whatever is best for that particular title.
also another thing, from nfs2iso2nfs 0.5.4 onwards for things like nintendont the "-homebrew" flag isnt enough, it'll also need "-passthrough" to work with the gamepad, I dont see that option implemented at all either. only things like the vwii channel booter dont need "-passthrough" as that actually makes use of the official gamepad wiimote/classic controller emu.
that and you'll have to edit the script to include -passthrough into the script nfs2iso2nfs cmd since you'll be using it with nintendont.
sure.
https://github.com/FIX94/nfs2iso2nfs/releases/tag/v0.5.5
please make sure to add -passthrough to the -homebrew flag though for nintendont/homebrew files, and maybe for homebrew files add an option to also not have -passthrough so homebrew that doesnt use it (like the channel booter) will work properly.
its not just about seeing wii remotes but in code, its basically either execute the old wiimote code to allow them being used or fully emulate the entire interface and ignore any and all real hardware bluetooth input. -passthrough basically will keep the old wiimote code active as if you chose to not use the gamepad, so wii homebrew can keep using real hardware bluetooth data. The magic of it is that the actual gamepad connection still is active though and the IOS keeps updating the gamepad input buffer, thats where libwiidrc hooks in and basically processes that IOS buffer and makes it available to be used as another input option when the library is used. The actual gamepad input in IOS is being read by a separate thread, thats why it still gets updated even when processing the real hardware bluetooth input.If I recall correctly, the unaltered fw.img from Nintendo could not see Wii remotes if WiiVC was set to gamepad mode. I THINK the passthrough patch is needed because homebrew doesn't use the official SDK and has varying implementations of classic controller support thus requiring individual gamepad patches. I also think this patch was developed so that homebrew that has not yet been updated could still be used to some extent.
its not just about seeing wii remotes but in code, its basically either execute the old wiimote code to allow them being used or fully emulate the entire interface and ignore any and all real hardware bluetooth input. -passthrough basically will keep the old wiimote code active as if you chose to not use the gamepad, so wii homebrew can keep using real hardware bluetooth data. The magic of it is that the actual gamepad connection still is active though and the IOS keeps updating the gamepad input buffer, thats where libwiidrc hooks in and basically processes that IOS buffer and makes it available to be used as another input option when the library is used. The actual gamepad input in IOS is being read by a separate thread, thats why it still gets updated even when processing the real hardware bluetooth input.
also the whole emu does not work with the libogc bluetooth implementation so thats why -passthrough is required in the first place. -passthrough does not only allow the wiimote data to stick around but also makes that gamepad input buffer available to easily read out from the PPC processor in the first place by adding some memory cache flush code of that buffer from ARM side.
it can read/write save files into vWii nand.I wonder if fw.img (IOS255) even has vWii NAND access at all. I suppose it does to read/save the savegame. I don't think the savegame is stored on wiiu, is it?
I recreated the banner repository since gxarena is down, and I had all the banners.
To use it set the banner path to http://banners.rc24.xyz/ (is it still possible to grab the banners via usb loader gx?)
The GitHub repository is at https://github.com/larsenv/Custom-Banners
Thanks! Yes, the banner URL is actually a setting so it can be changed without a recompile.
Hopefully I can get SSL working soon and we can just the repository instead.
Could you test it out please? I set it to not enforce SSL because I know how the Wii is with it. If it doesn't work I can host it with Apache.
I looked through all the options, there wasn't one I saw for downloading custom banners...
if the pad keeps the linked console in memory, you should also need to resync it everytime you go into vWii mode (after syncing it in Wiiu mode).
But the wiimote is sync to both WiiU and vWii at the same time, so I guess the CCpro should work the same way.
I'll have to test on my console, but I had to resync the vWii after playing Zelda wiiU with the Classic Pro, so I guess it lost vWii sync.
Maybe CCpro can only be sync to WiiU or vWii, not both?
I had the same problem, what base and d2x are you using?actually, it's the wii u pro controller. the wii remote seems to stay synced. the wii u pro controller only seems to lose sync if I load usb loader gx.
I didn't hear about the WiiU Pro losing sync without the wiimote losing it too.