MISCHIEF MAKERS doesn't accept key input anymore

[richard42]

Originally reported on Google Code with ID 564

Describe your system:
 - Operating System (be specific): Debian sid amd64
 - Machine type (32-bit or 64-bit): 64 bit
 - Mupen64Plus version: 2.0-rc*
- Plugins used:
UI-console: using Video plugin: 'Mupen64Plus OpenGL Video Plugin by Rice' v1.99.5
UI-console: using Audio plugin: 'Mupen64Plus SDL Audio Plugin' v1.99.5
UI-console: using Input plugin: 'Mupen64Plus SDL Input Plugin' v1.99.5
UI-console: using RSP plugin: 'Hacktarux/Azimer High-Level Emulation RSP Plugin' v1.99.5

Mischief Maker doesn't accept controller input anymore. This worked fine in 1.99.5
but broke somewhere after. I didn't bisect the versions yet. But it most likely broke
during casualjames core refactoring.

Reported by sven@narfation.org on 2013-07-01 09:24:22

[richard42]

This regression was introduced before 2013-02-17

Reported by sven@narfation.org on 2013-07-01 09:26:44

[richard42]

Yes, it is in the big mess started after "Enable experimental support for link-time
optimization" and ended before "Don't free random memory on config option type change".
So it is in the range which cannot be bisected very well because it either doesn't
compile or it crashes. I will still try to do my best

Reported by sven@narfation.org on 2013-07-01 10:13:43

[richard42]

This part of the history is so messy (68 untestable or uncompilable commits) that bisecting
makes nearly no sense. But here slightly reduced range.

* last known good commit: 560ea0cc70aa2d181811834de4887a90f8ec9d2e ("Compilation fix.")
* earliest known good commit (because it doesn't crash and doesn't crash immediatelly):
19dbd07fb342f4d56493ce3cd9e9514284da3779 ("Don't free random memory on config option
type change")

here just my help script for detecting possible candidates for testing (used with my
git conversion because hg seems to have bugs in its bisecter):

autoskip=139
while [ "${autoskip}" = 139 ]; do
    git clean -dfx
    rm -rf ~/.config/mupen64plus/
    make -C projects/unix V=1 UNAME='linux' HOST_CPU='x86_64' APIDIR=/usr/include/mupen64plus/
DEBUG=1 DEBUGGER=0 PREFIX=/usr/ LIBDIR="/usr/lib/x86_64-linux-gnu" PIC=1 OPTFLAGS="-DNDEBUG"
SHAREDIR="/usr/share/games/mupen64plus/" all NO_ASM=1 -j9
    if [ "$?" != 0 ]; then
        git bisect skip
        continue
    fi

    mupen64plus --emumode 0 --corelib projects/unix/libmupen64plus.so.2 ~/tmp/mischief
    autoskip=$?
    if [ "${autoskip}" = 139 ]; then
        git bisect skip
    fi
done

Reported by sven@narfation.org on 2013-07-01 10:35:29

[richard42]

This regression was introduced in commit 734b67b8ff647cc355b5f6b781799c42e75e81ea ("Implement
SI register DMA busy bit. Fixes some message spamming (multiple SI DMA interrupts in
queue") on diddy kong racing.") of mupen64plus-core

I've used a modified version of the script to fix the most annoying bug in casualjames
config refactoring:

autoskip=139
while [ "${autoskip}" = 139 ]; do
    git clean -dfx
    rm -rf ~/.config/mupen64plus/
    git show d2f23bae6b5075dd0cda40888601c0f4ba40c87f:src/api/config.c > src/api/config.c
    make -C projects/unix V=1 UNAME='linux' HOST_CPU='x86_64' APIDIR=/usr/include/mupen64plus/
DEBUG=1 DEBUGGER=0 PREFIX=/usr/ LIBDIR="/usr/lib/x86_64-linux-gnu" PIC=1 OPTFLAGS="-DNDEBUG"
SHAREDIR="/usr/share/games/mupen64plus/" all NO_ASM=1 -j9
    if [ "$?" != 0 ]; then
        git bisect skip
        continue
    fi
    git checkout -f src/api/config.c

    mupen64plus --emumode 0 --corelib projects/unix/libmupen64plus.so.2 ~/tmp/mischief
    autoskip=$?
    if [ "${autoskip}" = 139 ]; then
        git bisect skip
    fi
done

Reported by sven@narfation.org on 2013-07-01 10:57:30

[richard42]

A commit 4788b92175c50714fcbf91c899c248aedb9d022b ("Revert: Implement SI register DMA
busy bit") was proposed as quick workaround for the release 2.0. The actual cause of
this problem has still to be analyzed

Reported by sven@narfation.org on 2013-07-01 16:26:04

[Papermanzero]

Played the game recently with the newest build. Used a Xbox360 controller with Windows 7 and had no issues. Could be that the workaround is still active.