Well, I do not have any problem with adding Wii support to the main repository.
However, I do not really know if it is an easy task to do and support afterwards.
The main reason I am sticking to the 1.1 branch is, that some of the new features integrated afterwards are not usable on the Wii (yet).
For example there is no SDL2, OpenGL and LuaJIT for Wii. These are not impossible to use, but it will requiere time/effort to port/use:
- SDL2: A couple of things could be used from wii-sdl for sdl2, but this would only affect the software based renderer.
- OpenGL: The Wii's native GX is similar to GL and a wrapper library like gl2gx, opengx or GRRLib could be used.
- LuaJIT: There is PowerPC support, but I have not been able to compile and use it for Wii yet (which does not mean it is not possible...).
Now for the sound backend: OpenAL is not ported either, I had a short look at it, but not too deep (yet). Generally it should be possible, but I do not know, if it is worth the effort.
The format libraries like ogg, vorbis and modplug would be usable (tremor-lowmem is even available with libogc), but they could be used with a native library (aesnd) as well without much trouble.
I think generally it would be a good idea to implement an easy way to support multiple backends, so ports do not pollute the main sdl2/openal backend with #ifdefs in every function and such (This is the reason I copied the complete lowlevel folder to start the port).
The things I want to do, before I think it is usable (in random order):
- Think of some strategy for memory allocation: Currently everything happens in MEM1(24mb), which means on some point it will just run out of memory and crash. MEM2(64mb) feels lonely.
- Simplify controller logic: Currently the c,d,v,space keys are only useable from an external usb keyboard and the wiimotes/controllers are usable via sdl joysticks (→ only ingame currently). there needs to be some kind of glue code, but I think hardcoding buttons to keycodes is not the-right-thing-to-do™.
- some kind of audio output (see above)
- some kind of video output (see above): sdl is good for what it is used for (it brings the image on the screen), but hacking up a native renderer would also be possible (and has been done for most bigger homebrew).
There are also other things, but I would just consider them nice-to-have (like a menu for choosing the game folder).
You see, there is still a long way to go ...