The SDL1.2 system cannot cope with Dualshock and similar controllers. After
pressing the config button, an random axis will be configured. This happens
because the state of the device (with 27 or more axis) changes all the time.
This problem can be avoided for these devices under Linux when SDL2 is used
together with its event system. These random movements doesn't anymore with
these joysticks and the hid_sony driver in SDL2+SDL_PollEvent.
This seem to be fixable with SDL1.2 because it just cannot handle newer
devices. Also the SDL_PollEvent doesn't work with the ctypes version of PySDL
for unknown reasons. Thus the implementation cannot be shared between SDL1.2
and SDL2.
To use the new input detection, m64py must be started with the sdl2 option and
a version of mupen64plus compiled against SDL2.
$ m64py --sdl2
mupen64plus supports roms in native (*.z64), byteswapped (*.v64) and
wordswapped (*.n64) rom files. Unfortunately, m64py only supported native rom
files because it didn't swap the also swapped big endian crc values back to the
unswapped host ordered crc values for non-native rom files. This caused crc
checks to fail for these rom files.
The recent_files list has to be an python object serialization. This object
must be an array of strings. Python will save unicode strings and Python3
strings. Not following this rule make m64py crash either while loading the
recent_files information or when adding a new entry when a file is opened.
Don't try to load old style "true"/"false" config entries as integer. This
would cause an value error and crash m64py. Instead try to load the content
only when it is valid and otherwise use the m64py default value.
Neither numarray nor Numeric provide the types uint8, uint16 or uint32. Trying
to use them without having numpy installed will cause an AttributeError.
There is already an mime type for Nintendo64 roms called application/x-n64-rom.
This one has to be extended instead of installing a conflicting type. Otherwise
only one of the desktop entries for mupen64plus-ui-console or m64py works and
not both.
Instead of letting m64py crash with an OSError when the loading of a plugin
fails, it should better create an error message but continue working with the
remaining plugins.
An error can for example look like this:
Frontend: ERROR: failed to load plugin /usr/lib/x86_64-linux-gnu/mupen64plus/mupen64plus-video-glide64mk2.so: libpng15.so.15: cannot open shared object file: No such file or directory
