Mupen64plus fails to launch - 0.9.5b - Ubuntu beta

[mdeguzis]

Games will fail to launch, seg fault.

Status Updates

• Glide64* plugins don't seem to work anymore
• Rice Video plugin works windowed, but not full screen (possible fix for that) (patch)
• Tried sven-eckelmann's PPA, but no luck

@beaumanvienna , if we apply this patch after download and repacking the Ubuntu debian package, this may work and we can use the much more capable Rice Video plugin.

Source build status

Failed: missing files

wget https://mupen64plus.googlecode.com/files/mupen64plus-bundle-src-2.0.tar.gz
mkdir temp-build-mupen64plus
mv mupen64plus-bundle-src-2.0.tar.gz temp-build-mupen64plus/
wget https://launchpadlibrarian.net/48486260/rice-crash-vendorstring.patch
mv rice-crash-vendorstring.patch mupen64plus-video-rice/src/
patch GraphicsContext.h < rice-crash-vendorstring.patch ***DOES NOT WORK, MANUAL DIFF NEEDED***
sudo apt-get install libfreetype6-dev libboost-filesystem-dev
./m64p_buid.sh

[beaumanvienna]

Ok, I'm on it. The diff is simple, can be done manually as well.

This seg fault is confirmed, this is how it looks on my system: http://slexy.org/view/s2XEGEoL3Q

I will also change SDL_FULLSCREEN to SDL_FULLSCREEN_DESKTOP, this works better together with xbmc in fullscreen mode.

[mdeguzis]

I'm sure others have this, maybe report we should report this bug too, as that original link I attached is for Lucid and not Trusty. Not sure how it cropped back up again. My compile stalled, but I didn't try it more than 2 or 3 times. Are you going to repack or compile from source? In any case, this will likely fix Rice Video from not working too, which allows a much nicer plugin extension set in mupen64plus.

I'm wondering if we should freeze / repack all our packages to avoid such regressions. Sure, we'd have to test new versions, but that kind of testins shouldn't be hard. What do you think?

[mdeguzis]

I am submitting a bug report to Launchpad now and will link it. Please see this wiki page about how we should properly handle apport on/off vs just removing it. I think it is safer than not having it. I remove it to avoid it inteferring with gameplay, but we can discuss this or turn it back on very easily.

Bug report I submitted:

https://bugs.launchpad.net/ubuntu/+source/mupen64plus-ui-console/+bug/1355747

If you wish to add anything to the bug report, let me know. It may not open to public access until confirmed, so I may be able to add it for you.

[beaumanvienna]

Are you going to repack or compile from source?

I'll do both. I'll repackage it so it won't be superseded by other providers, then fix the too short vendor string bug. All this is going to be compiled on the PPAs server farm.

I'm wondering if we should freeze / repack all our packages to avoid such regressions.

In my opinion we should do this for all our packends. Mupen won't work anyway w/o the patch, plus fullscreening will be an issue w/o SDL_FULLSCREEN_DESKTOP.

As long as we don't have any issues or missing features with a backend, we can keep our custom made versions for a longer time. This would apply to mednafen, which is running pretty flawless I think. For other backends like PCSX2 we will have to merge our fork more often with the upstream branch. When I tested it, I encountered some graphic artifacts. If the version in our PPA is superseding the official version that we want to test, we can still install it with dpkg -i...

I can't open the bug report you submitted, sorry!! :-(

[mdeguzis]

In my opinion we should do this for all our packends. Mupen won't work anyway w/o the patch, plus fullscreening will be an issue w/o SDL_FULLSCREEN_DESKTOP.

Agreed, let's work towards this. Like I said before, once built, I really do wish to spend time getting to leran the build process, but I like your methods so far, and wish to learn from you after we get to a stable 1.0. I've been watching your code and you're great to learn from.

I can't open the bug report you submitted, sorry!! :-(

It must be until it's acknowledged. I'll see if there is any settings on the page to change this.

[mdeguzis]

There, bug should be public now.

[beaumanvienna]

Confirmed, I can access it now.

[beaumanvienna]

I have tested to set the resolution to fullscreen by replacing this code here:

https://github.com/mupen64plus/mupen64plus-core/blob/master/src/api/vidext_sdl2_compat.h#L417

with

http://slexy.org/view/s21e6oCdJS

That works. If you have a closer look at the slexy paste, it is even using the external display. I'm already testing this together with xbmc, no problems here. We would have to replace libmupen64plus2_2.0-4_amd64.deb. Mupen64Plus is linked against SDL2, I love that!

[mdeguzis]

Wow, awesome find JC. I was compiling, or trying to, with the old patch information, thank you for finding that key area of code to change, can't thank you enough. SDL2 is used, yep! I like that. If this then means we can use the Rice Video plugin, that is one up on the Ubuntu base version, and a huge plus for the project, as the Rice Video plugin is vastly superior in quality and capability. If you want to include this in the PPA, it's an easy enough change. Like I said before, once we hit a stable 1.0, I want to start getting used to the PPA process, even with source compiling. Thank you JC

Off topic question: To what button corresponds 'Z' on the PS3 controller in Mupen64Plus? I don't get how to dive in DK64 :-D

See the layouts wiki section for anything, but it should be R2 that I have set.

[beaumanvienna]

I've copied a temporary solution to our dropbox.

There's just one little annoyance left, it doesn't center in the middle of the screen.

You can revise the code changes here: http://slexy.org/view/s2MLaV3C1V

Let me know how this works for you! I take for the centering issue tomorrow, then I'm going to move libmupen64plus2_2.0-4_amd64.deb to our PPA and have it updated.

[mdeguzis]

Some comments were posted to the now linked bug report (linked to google code). Do you mind reviewing this and responding to the maintainer? He may have the fix for us, which we can then save as a static package in our PPA if you want. Otherwise, you can make your changes regardless to fix this. I linked our issue ticket to him, but he may have some things you may find useful:

https://bugs.launchpad.net/ubuntu/+source/mupen64plus-core/+bug/1355747

I've copied a temporary solution to our dropbox.

My Dropbox is full, so I can't open it lol. I really need to setup owncloud or something.

For now, I have setup a Box.net account and invited you via email. Could you please copy over the current contents of your RetroRig dropbox folder? The only caveat is 10-100 GB, 25- MB max file size (https://www.box.com/pricing/). I think this should work for now.

[mdeguzis]

JC, I asked the team via IRC to consider our bug,

https://wiki.ubuntu.com/StableReleaseUpdates#Procedure

"Upload the fixed package to release-proposed with the patch in the bug report, a detailed and user-readable changelog, and no other unrelated changes. If you can't upload to the archive yourself, get a sponsor, attach a debdiff to the bug and subscribe ubuntu-sponsors, as usual. There is no need to wait before uploading. After upload, the bug status should be changed to In Progress, once accepted into release-proposed, the status will be automatically changed to Fix Committed. Also, make sure that: "

Some of this I think is what one would encounter during packaging. I feel a bit over my head but i'll sit down tomorrow and see how else this can be submitted. In the end, this doesn't prevent our changes, but would help others, so it can be submitted at any time?

[mdeguzis]

Let me know how this works for you! I take for the centering issue tomorrow, then I'm going to move libmupen64plus2_2.0-4_amd64.deb to our PPA and have it updated.

This seemed to work ok here JC, let's commit the deb pkg to your PPA and test it for a bit.

[beaumanvienna]

Alright, I can do that tonight!

I'm going to repack libmupen directly from the github code. The only thing I'm going to change is the fullscreen behavior. I'll change it from SDL_WINDOW_FULLSCREEN to SDL_WINDOW_FULLSCREEN_DESKTOP.

This change has no effect, if the resolution settings in mupens configuration file match the actual display setting. Only if the settings state a different resolution, this change will take effect. It won't change the actual monitor resolution anymore, which led to the issues we had in combination with xbmc, that then also gets a resize command. Instead, mupen keeps the actual display resolution, allocates a field the size of the monitor and draws its canvas on a subarea of this field with the size of its resolution settings.

see https://github.com/beaumanvienna/mupen64plus-core/commit/191e607f65743340917883b687b5f873581ded6a

When it comes to the resolution settings, I would like to suggest a new feature. I'd like to suggest a new field in RetroRigs resolution dialog called "Auto" or "XBMX settings", what ever you prefer. You are totally right, implementing a auto-resolution feature into each of our emulators is a bad idea. So forget what I suggested before when I asked to set the resolution to zero in the config files. OK, this is my new suggestion:

First, in the installation run of retrorig_setup.sh, or later when called to change RetroRigs settings, a new item in the resolution dialog appears named "Auto". Retrorig_setup.sh will only save this mode to an internal configuration file. It doesn't have to change any resolution configuration at this point in time.

Second, when xbmc sets up its display settings, it will additionally call retrorig_setup.sh with a parameter "--setResolution INTxINT" (for example retrorig_setup.sh --setResolution 1920x1080). This will run in the background, and not be noticed by the user. If called with this argument, and if "Auto" is enabled, it will configure the emulator resolutions accordingly.

This way, the resolution settings from RetroRig and the resolution dialog in xbmc always stay synchronized.

[mdeguzis]

I like the auto feature in the resolution settings menu. I only apply resolutions to emulators that support it of course. I can call xrander or, xdpyinfo. The latter seems easier to wrangle and is included by default, but we can use either:

Try this:

#!/bin/bash

FULL_RES=$(xdpyinfo | grep dimensions | awk '{print $2}' | awk -Fx '{print $1, $2}')
echo "The full resolution set is $FULL_RES"

read RES_X RES_Y <<<$(xdpyinfo | grep dimensions | awk '{print $2}' | awk -Fx '{print $1, $2}')
echo "The X resolution is $RES_X"
echo "The Y resolution is $RES_Y"

I will build this into an auto feature and set the variables appropriately when I get home. Not sure how we would actively set this everytime XBMC is called, but you're the expert on that haha. To make this worthwhile, XBMC would need to call the auto function each time to grab the current resolution. Not sure how we'd do that. Setting it during install is fine by me, but if we wish to make this dynamic, let's go for it!

[beaumanvienna]

OK! :-) Sounds great!

We currently have two different dialogs for resolution. One in RetroRig and one in XBMC: http://imgur.com/M3mCkmY (don't ask me why it says "file browser" ;-)

If people actually use this dialog in XBMC they might state different resolutions. This could break the gaming experience. If an emulator is just using SDL_WINDOW_FULLSCREEN, it will change display resolution back to what originally was configured. In this case it might happen, that the newly started emulator can't get on top of XBMC. Or that it get's placed under the Unity top bar.

Also, like in my equipment's case, you can choose between several displays with different resolutions.

I can call Retrorig's setup in the appropriate moment, and I can pass it even the right resolution. Can you have RetroRig set up this resultion in turn? This call from xbmc to RetroRig will actually be made everytime the resolution is changed. This is why we need to save an "Auto" flag in RetroRig's settings. Only if this flag is, RetroRig will actually except the request from XBMC. This way we introduce the auto resolution feature as an alternative path that needs explicitly activated.

OK. Shall we agree on an interface? I need to know which script I should call and which parameter I should use. I can not recommend to use xdpyinfo, this is how it looks on my rig: http://slexy.org/view/s20JkZ1gbH

You could use xrandr, again, here this is how it looks on a dual-monitor setup: http://slexy.org/view/s20DcuuPXG, but only when XBMC is passing down the display name. So, it could equally pass down the target resolution directly.

[mdeguzis]

OK. Shall we agree on an interface? I need to know which script I should call and which parameter I should use. I can not recommend to use xdpyinfo, this is how it looks on my rig: http://slexy.org/view/s20JkZ1gbH

I can see where that can differ with more than one display. xrandr is doable too, but based on your output, would I be going after the primary display dimensions?

only when XBMC is passing down the display name. So, it could equally pass down the target resolution directly.

Inserting code or utilizing display code in XBMC could be the best solution JC. If you can get XBMC to pass the X and Y values to the setup script, we could maybe then follow your reccomendation to make XBMC call retrorig's setup script with option flags. What would like be easier is a seperate supplimental utility script that has 1 purpose: to swap out the resolutions dynamically. Maybe it's possible to just call upon the resolution function(s) in the setup script.

[beaumanvienna]

Shall we call this script retrorig_setResolution.sh then? With argument 1 = x resolution and argument 2 = y resolution. For example

retrorig_setResolution.sh 1920 1080

Do you agree with me that we need to store a flag to release automatic resolution setup? This could be a XML or a text file. I would say a normal text file should be sufficient. The syntax could be parameter-name, value for example automatic resolution, true.

Can we use the existing code from the script modules to set the resolution?

[mdeguzis]

Do you agree with me that we need to store a flag to release automatic resolution setup? This could be a XML or a text file. I would say a normal text file should be sufficient. The syntax could be parameter-name, value for example automatic resolution, true .

Yes, I agree. How to pass variables and flags was what I was unsure of. Say I write export auto_res="true"in the main setup script, we could then couple retrorig_setResolution.sh with the startXBMC.sh script. In the resolution script, if it picks up that exported file flag as true, determine the resolution from xrander and set it to the emulator files.

Do you have a more simple solution? Maybe I am thinking about this wrong.

[mdeguzis]

JC,

We can use xdpyinfo just fine:

test@test-pc:~$ xdpyinfo | grep screen
default screen number:    0
number of screens:    1
screen #0:

Notice screen #0. In your case, two or more will show. I can take input from either, xdpyinfo is easier to parse, but whatever output looks cleaner to you (xrandr or xdpyinfo).

[beaumanvienna]

Nope.

yo@yo:~/xbmc$ xdpyinfo | grep screen
default screen number:    0
number of screens:    1
screen #0:

As far as I can tell from the video, you got the installation right. Only libmupen64plus2 and mupen64plus-data are provided from my PPA. Could you send me a screenshot from synaptic showing everthing that has to do with mupen? This is what works for me http://imgur.com/RsYtoph Only some packages have the version number 2:2.0.1.0, this is from my PPA.

Please check your mupen64plus configuration file, XBMC resolution settings and your OpenGL driver.

[mdeguzis]

Here is everything in synaptic I have that matches mupen: https://cloud.githubusercontent.com/assets/3931917/3939661/51df6f2a-24cb-11e4-966e-21da20b74f99.png

Please check your mupen64plus configuration file, XBMC resolution settings and your OpenGL driver.

This is from a base install, using the nvidia kernel driver. I did not run this in XBMC, unless that is intended and the only way it would work. I did a base install then installed mupen64plus.

Take your time studying, and when you return, we can brainstorm for resolution work as well. I will be gone most of the morning tomorrow, but in the pm local time (UTC -5), I can work on things.

You don't build plugins just yet with your PPA, so /usr/lib/x86_64-linux-gnu/mupen64plus can't have fault plugins just yet.

[beaumanvienna]

Ohh, you have the debug version of libmupen64plus2 installed. This happened after a base install? Strange! The debugging library is provided by the official repositories as well. In this case I should remove libmupen64plus2-dbg from our PPA.

OK, I understood you still have graphic issues. That's understandable with a debugging version. Could you remove it and install libmupen64plus2 manually?

[mdeguzis]

I installed mupen64plus as follows:

    apt-get install -y libmupen64plus2=2:2.0.1.0
    apt-get install -y mupen64plus

Something is wrong though. I will do a reinstall of Ubuntu in my VM to check this to...I still get the flashy seizure window look, but Alt+Enter jumps me down to a windowed 1280x1024 that looks just fine. BUT, what I noticed is the video plugin being used was Arachnoid, not* the one specified in /home/test/.config/mupen64plus/mupen64plus.cfg. Maybe mixing pkgs is tough, I am going to also try sven's PPA and his instructions

Looking in files for Arachnoid doesn't show much than the heading tags that are normally present:

test@test-pc:~$ grep -r "Arachnoid"
.config/mupen64plus/mupen64plus (copy).cfg:[Video-Arachnoid]
.config/mupen64plus/mupen64plus.cfg:[Video-Arachnoid]
RetroRig/emu-cfgs/x360_wireless_controller/mupen64plus/mupen64plus.cfg:[Video-Arachnoid]
RetroRig/emu-cfgs/ps3_blu_controller/mupen64plus/mupen64plus.cfg:[Video-Arachnoid]
RetroRig/emu-cfgs/x360_usb_controller/mupen64plus/mupen64plus.cfg:[Video-Arachnoid]
RetroRig/emu-cfgs/ps3_usb_controller/mupen64plus/mupen64plus.cfg:[Video-Arachnoid]

Another thing I found out, is when specifying specific packages I will have to adjust the uninstall parameters too (example of me remove the set I currently had):

apt-get --purge remove libmupen64plus-dev libretro-mupen64plus mupen64plus-data
apt-get remove mupen64plus

Otherwise,they stick behind if you check the dpkg get selections listing as deinstall. See this article no biggie, now that I know.

[beaumanvienna]

It was always using Arachnoid on my installation, I just forgot to mention it. This shouldn't be a problem. This has nothing to do with libmupen and mupen itself originating from different sources.

The version number of libmupen64plus2 supersedes the versions delivered by the Ubuntu repros or Ecklemanns PPA. No need to state the version explicitly. Could you paste [Video-General] from mupen64plus.cfg? And please paste again all your mupen packages installed.

[mdeguzis]

Installed with

apt-get install mupen64plus

Packages

https://cloud.githubusercontent.com/assets/3931917/3942118/e3e89e52-2555-11e4-81e3-60640c8b5063.png

[UI-Console]

# Mupen64Plus UI-Console config parameter set version number.  Please don't change this version number.
Version = 1.000000
# Directory in which to search for plugins
PluginDir = "/usr/lib/x86_64-linux-gnu/mupen64plus"
# Filename of video plugin
VideoPlugin = "mupen64plus-video-rice.so"
# Filename of audio plugin
AudioPlugin = "mupen64plus-audio-sdl.so"
# Filename of input plugin
InputPlugin = "mupen64plus-input-sdl.so"
# Filename of RSP plugin
RspPlugin = "mupen64plus-rsp-hle.so"

[Video-General]

# Use fullscreen mode if True, or windowed mode if False 
Fullscreen = True
# Width of output window or fullscreen width
ScreenWidth = 1280
# Height of output window or fullscreen height
ScreenHeight = 1024
# If true, activate the SDL_GL_SWAP_CONTROL attribute
VerticalSync = False

Full scren enabled just segfaults as normal:

https://cloud.githubusercontent.com/assets/3931917/3942116/bb8abd8c-2555-11e4-86db-144f16c970d3.png

[mdeguzis]

Confirmed resolved with latest pull request under commits 87486b8 and 423ff10

The main screen of Mario Kart 64 looks more pixilized, but everything works good! Hopefully at some point we can get the Rice Video plugin working, but this is great, thank you very much JC!

[beaumanvienna]

The main screen of Mario Kart 64 looks more pixilized, but everything works good!

I've been using 'Arachnoid Video Plugin' a lot lately. That's also a pretty good module. We should benchmark different video plugins for mupen64plus. When you say more pixilized, do mean now that you are running Glide64, and compared to which plugin, Arachnoid or Rice?

Tried with Glide64 today, it seems to run a little bit better then Arachnoid.

[mdeguzis]

Glide64 was what I was using, it was only the title screen of Mario Kart 64. Agreed in your email, we can benchmark different video plugins over time.