Well then, that sounds like a pretty big thing! Being able to port a game to become actual Wii Software and take all the advantages of the hardware reads like homebrew dream.
I'll keep an eye on this, and thanks for explaining it!
That's not my primary goal. First, that would be hard work at all and take lots of time. The second point is that even if one manages to port over everything to the Wii RVL-SDK, you would most likely violate Nintendo's terms of use when releasing compiled binaries coming from the official development environment. Anyway, it's almost hard to get there. The development tools they used for the Wii, are really "bitchy" what means, you are facing several problems like the following:
- ASM inline assembly most likely impossible (very bitchy)
- true (real) ASM suffering several directives / commands (.hidden, FUNC_START, .zero... etc.)
- ASM branch forward / backward commands work in a different way compared with GCC (bne 1f for GCC == bne+ @1 in MetroWerks' ASM compiler / so is 1: in GCC == @1: in MW.)
- compiled ASM object files contain code in reversed order compared to GCC-ASM compiled object files (upside down - figured out using IDA Pro) ...WTF?!...
- no ASM types like "@PROGBITS" / "@NOBITS" etc. usable in the GCC standard form (instead, you have to use it like this: ".section .init,2,1,3" (alignment, type, flags))
- defining sections like this causes problems in libraries like libOGC (while this mode works for the binary and the library separately, it doesn't for the library itself upon linking the binary and library in the end - error "section 'init' is unknown to the linker")
- standard compiler settings producing dozens of errors and/or warnings upon compiling GNU-code
- IDE crashing upon debugging in some cases when browsing through debugged source code files
- several standard variables and functions (eg. "basename" / "va_list" / "attributes" etc.) not usable or even available
- Linker causing error ("'__destroy_global_chain' not found") when using ".skip" command instead of ".zero" in ASM for "C-Runtime" files like "ecrti", "crtbegin", "crtend", "ecrtn"
- compiling C++ code is even trickier... X-(
- incompatibility of RVL-SDK libraries when using GNU-Tools (compiling code works, but the ELF's won't even run) so compiled GCC code != compiled MW code
- resetting hardware is annoying upon bugs in the code (sometimes requires pulling USB EXI cable)
- ODEM not detecting NDEV correctly after resetting (Hardware Revision Number then is "0" or way above "100")
- no sample code files on how to start the debugger / Metro Target Resident Kernel ("MetroTRK") on custom projects which is needed for the debugger
- only standard linker files - no special explanation on sections or examples for several demos inside the RVL-SDK
...and so on... the list of problems is long.
My primary goal is using the RVL-SDK for debugging stuff only. There are no planned releases to RVL-SDK compiled binaries.
By the way: looks like I managed to start a MW compiled libOGC partially - the debugger popped up and stopped inside the library source code, which is a good sign at this moment.
Gesendet von meinem BLA-L29 mit Tapatalk
