The name of the Joystick device is automatically set back to '' when
SDL_JoystickClose(...) is called. The compability wrapper has to store the name
inside a private buffer to provide a similar functionality like pre-SDL2.0
versions of SDL_JoystickName.
The OSX driver seems to name the Controller using the "unique" name
"Controller". Therefore, mapping them to the "Microsoft X-Box 360 pad"
configuration may be a valid workaround for users of compatible gamepads.
The Grab API of SDL now needs the SDL_Window to work. This information is not
provided by Mupen64Plus and therefore such functionality is currently disabled
when building against SDL 2.0. Further adjustments of the Mupen64plus API
should consider moving this functionality do a different part which has access
to all necessary informations.
The Joystick API only changed in such way that it is possible to use a
compatibility wrapper.
SDL 1.3 separated KeyCodes and ScanCodes in its API. The new names for the
scancodes can therefore be easier "backported" than the old name which would be
conflict with the still existing KeyCodes. A simple compatible wrapper is
enough to allow coexistense of SDL 1.2 and SDL 1.3 code.
The POSTFIX make option is useful for distributions to compile different
versions of the plugin in parallel. The object files will be stored in a
directory with the postfix appended and the linker result will also have this
postfix appended.
The CROSS_COMPILE make option can be used to automatically prepend the prefix
to all build relevant tools to seamlessly allow cross compilation without
setting each tool name separately.
Cross compiling for MinGW32 would can be done using
$ make -C projects/unix/ CROSS_COMPILE=i686-pc-mingw32- HOST_CPU=i686 UNAME=MINGW
nogagplz tested mupen64plus on 32-bit ppc and didn't detect any big show
stoppers with interpreter cores and the mupen64plus example rom. This makes the
PowerPC an interesting target for further tests and may reveal other endianness
problems.
nogagplz noticed on ppc32 that PIC is necessary to compile everything as shared
object. Therefore, it seems to be a better idea to have architecture specific
PIC default settings instead of checking only whether it is a 32 or 64 bit
architecture.
