Need some help with the Raspberry Pi edition of mupen64plus

[Alessandro Porcelli]

Hello everyone, I am trying to get mupen64plus to run correctly on the Raspberry Pi 3. The version is the one found at the following address.

https://github.com/ricrpi/mupen64plus

I successfully managed to compile the binaries after some struggle, though I still experience some issues with the configuration files and (seemingly) the core events. I am running the latest Jessie Raspbian.

First issue: configuration folder not being saved.
 It appears that unless I (root) run the emulator with --configdir /home/pi/.config/mupen64plus every time it will load other configurations. Is this normal? Where are these other configurations found?

Second issue: fullscreen resolution not configurable
 The fullscreen resolution is taken to be the same as the Raspbian environment. In my case, that would be 900p to 1080p depending on the screen I am running on. This of course limits the performance of mupen64plus, as a resolution of 480p would already be sufficient. At the moment, I am changing the output resolution alltogether from raspbian's boot configuration, but I'd much rather it staying at the native value. Is it something possible?

Third issue: Core event commands do not respond
 I cannot quit the emulator by pressing esc, nor can I access any other command using my keyboard, though they are correctly bound in the configuration file. What could this be? The controllers I configured work fine, could this still be an SDL configuration issue, and if it is, which options should I enable in SDL2-2.0.3 before compiling? Could the core events be disabled by default in the compilation? If yes, how do I change these options when compiling mupen64plus?

Thanks to everyone for your patience, I hope to hear from you.

A.P.

[Richard Goedeken]

Hi Alessandro,

I haven't used the raspberry pi fork of our emulator so I'm not 100% sure about what could be causing your problems, but at least I can give a few ideas.

1. configuration folder.  If you're running as root, it may be looking in /root/.config/mupen64plus for the mupen64plus.cfg file.  From the terminal where you run the emulator, try "echo $XDG_CONFIG_HOME" if that gives a non-blank path, then the emulator will use that plus "mupen64plus" for the config folder.  Otherwise, try "echo $HOME".  The emulator will use that plus "./config/mupen64plus".

One special note is that you cannot "save" the location of the configuration folder in the configuration file, because it has to know from where it is to read the configuration file in the first place. :)  It's a chicken and egg problem.

2. Fullscreen resolution not configurable. Which video plugin are you using?  I think all of the video plugins should support a user-specified fullscreen resolution.  On the PC you can use the command-line arguments "--fullscreen --resolution 640x480" or whatever.

3. Core key events don't work.  Is it only key events or do joystick-based events also not work?  There is no option or switch to disable core events; they should always work, assuming they are configured correctly.  If I remember correctly, we are using the SDL1.2 keycodes in the configuration file, so that the same defaults would work regardless of which version of SDL we build against.

Regards,
Richard

--
You received this message because you are subscribed to the Google Groups "mupen64plus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mupen64plus...@googlegroups.com.
To post to this group, send email to mupen...@googlegroups.com.
Visit this group at https://groups.google.com/group/mupen64plus.
For more options, visit https://groups.google.com/d/optout.

[Alessandro Porcelli]

Hello Richard, thanks a lot for responding. I figured out the configuration issue....it was just me being clueless. The core events also seem to work fine now, after messing around with SDL2 and compiling the emulator from scratch, that was rather odd. The only thing which I still can't really figure out yet is the resolution issue. I used every plugin available, with specified resolution. I only get "setting video mode: 1440x900" (900p monitor) which, as you can imagine, is a tad bit too much for the RPi to handle. I believe the issue could still be with my SDL2, which I installed using the following configuration

 sudo ./configure --disable-video-x11 --disable-pulseaudio --disable-esd --enable-video-opengles --enable-libudev --disable-video-opengl

Using --enable-video-opengles2 instead of opengles just resulted in a "could not get EGL display" error, though it does try to initialize at the "correct" resolution.

I hope this gives some insight.

Kind regards,

A.P.

[Richard Goedeken]

When you built mupen64plus, did you get the source code from our git repository, or did you build from a forked codebase?  If so, perhaps there's some change in the forked code which is forcing this resolution.  In our codebase there is not even any logic to query the current or desktop resolution, so I don't think there's any possible way that it could override your request with the desktop resolution.  It doesn't know what that resolution is.

Also, are you using the ui-console front-end application and giving it the "--resolution" argument?

Richard

[Alessandro Porcelli]

I have cloned this repo: https://github.com/ricrpi/mupen64plus/ and I built mupen64plus using the script in there, which should get the sources from the official repo. I am running mupen64plus through the terminal like this

sudo mupen64plus --fullscreen  --resolution 320x240  RetroPie/roms/n64/Legend\ of\ Zelda\,\ The\ -\ Ocarina\ of\ Time\ \(USA\).n64

However tho output stays at 900p, as the emulator reports

Core: Setting 32-bit video mode: 1200x900

Alessandro.

[Richard Goedeken]

Okay, I'm willing to continue looking into this.  Can you please send (pastebin) the entire console output when you run a ROM, and also send your entire config file from ~/.config/mupen64plus/mupen64plus.cfg.

Thanks,
Richard

[Alessandro Porcelli]

Sure, here is the complete output from the console http://pastebin.com/qSruNhCR

 The configuration file I uploaded is the one from /root/.config/mupen64plus/ since I am running mupen64plus through sudo. Thank you.

Alessandro.

[Richard Goedeken]

Alessandro,

It looks like you are using older versions of the core, RSP, and video libraries.  Your console output reports:

UI-Console: attached to core library 'Mupen64Plus Core' version 2.0.0

UI-Console: using Video plugin: 'Mupen64Plus OpenGL Video Plugin by Rice' v2.0.0

UI-Console: using Audio plugin: 'Mupen64Plus SDL Audio Plugin' v2.5.0

UI-Console: using Input plugin: 'Mupen64Plus SDL Input Plugin' v2.5.0

UI-Console: using RSP plugin: 'Hacktarux/Azimer High-Level Emulation RSP Plugin' v2.0.0

I'm not 100% sure where it's getting these older versions from, but it could be getting them from a system install..  In the UI-console section of the config file, I see the following:

# Directory in which to search for plugins
PluginDir = "./"
# Filename of video plugin
VideoPlugin = "/usr/local/lib/mupen64plus/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"

That might explain the video plugin but not the RSP.  I would recommend deleting all of the mupen64plus components in /usr/local/lib and deleting your mupen64plus.cfg file, and then trying again with your 2.5.0 build.

Richard

[Alessandro Porcelli]

Hello Richard, I think I see why that might look that way: looking into https://github.com/ricrpi/mupen64plus/blob/master/RaspbianList_Pi2 it does indeed appear that the core library, aswell as the video plugins and the rsp are being compiled from ricrpi's fork rather than the official repo.

 The video plugins are being ported from mupen64plus-ae (port of the port awesomeness). The rsp in particular seems to be 40+ commits behind, whereas for the core that is just 6 commits. The version number is probably unreliable for these libraries...compiling the core from the official repo should work according to the latest version of that document, so I shall try to do that. I have also compiled GLideN64 from the main repo and the issue is still present, so unless there is a conspiracy of video plugins hardcoding the resolution I think that's probably not the cause.

I should have checked where the modules were being compiled from in the first place, I'm sorry if I ended up wasting your time.

Alessandro.

[Richard Goedeken]

The way that the video mode actually gets set is pretty complicated.  It starts in the video plugin, which makes a call into the core (VidExt_SetVideoMode) to set the video mode, and supplies the resolution.  Theoretically the core could ignore this and use whatever resolution it wants, which is probably what's happening with the mupen64plus-ae core that you are building.  But this can also be overridden by the front-end application.  If the front-end has activated the video extension (by calling OverrideVideoFunctions) then the core will not setup the video mode / opengl context at all but pass the callback through to the front-end, and it will set the video mode.  In this case, the front-end could in theory ignore whatever resolution it is given, and choose its own.

Richard

[Alessandro Porcelli]

I have compared vidext.c from

https://github.com/ricrpi/mupen64plus-core/blob/master/src/api/vidext.c

and

https://github.com/mupen64plus/mupen64plus-core/blob/master/src/api/vidext.c

And they appear to be the same file, I don't know if this is somewhat meaningful or if that's just me being clueless. Also, I think I recall the resolution of the whole system changing when running mupen64plus fullscreen in Windows, unless of course I kept the native setting. I know this thing is rather meaningless because running the emulator through retropie/emulationstation works flawlessly, it would also be great if somebody else confirmed having experienced this. I just thought it would have been nice to have mupen64plus running from a Xorg environment completely integrated with Raspbian. I have tested several binaries today and here are the results regarding the fullscreen resolution:

1.RETROPIE-NON RETROARCH BUILD: Does not initialize video if Xorg is on,  initializes (at the wrong resolution) without Xorg ( console output for Xorg at http://pastebin.com/YWC1wQzc )

2.RETROARCH LIBRETRO CORES (GLupen64/mupen64plus-lr): Works perfectly in every situation

3.BUILT FROM SOURCE (ricrpi): Initializes video in Xorg and without Xorg, wrong resolution in both cases.

I know this is terribly uninteresting, feel free to drop it if it's too much hassle :D

Alessandro.

[Richard Goedeken]

Okay, I think I've finally traced this down.

In the following file:

https://github.com/ricrpi/mupen64plus-video-gles2rice/blob/master/src/Config.cpp

In ReadConfiguration(), there is a code segment which forces windowSetting.uDisplayWidth and uDisplayHeight to be equal to the display size, if the preprocessor macro "VC" is defined.

From the makefile:

VC=1      == build against Broadcom Videocore GLESv2

So presumably this macro will be defined for a raspberry pi build.

The Initialize() function in OGLGraphicsContext.cpp takes dwWidth and dwHeight parameters, but it ignores these and uses the windowSetting.uDisplayWidth and uDisplayHeight values instead.

To get the behavior you want, just remove the "#ifdef VC" code section in ReadConfiguration() in Config.cpp.

Richard

[Alessandro Porcelli]

Nice job!  So, I can probably find that kind of code in every video plugin out there. It was, indeed, a conspiracy :P. The video mode is now initialized correctly, there's another problem though (you probably saw that coming): the video does not get upscaled to fullscreen, it stays at the bottom left corner of the screen taking just as many pixels as it needs. Do you have any suggestions for that, if I haven't bothered you enough?

Thanks a lot,
Alessandro.

[Richard Goedeken]

It's likely that this behavior is the reason why the rpi developer(s) added this code to always force it to the display resolution. :)  You can try giving the '--fullscreen' option, and using some well-know fullscreen resolutions like 640x480 or 1024x768.  If that doesn't do it, you're probably out of luck.  It would be possible to modify the video plugin to draw everything to an FBO (frame buffer object, instead of drawing to a window) which is bound to a 320x240 texture, and then drawing this texture onto the 1200x900 screen, but it would be a lot of work and probably wouldn't be much faster than just rendering everything on the native display resolution as it's doing now.

Richard

[Alessandro Porcelli]

 That's probably it. I think it is somewhat correlated to the fact that changing resolution on the fly does not really work in a conventional way, if at all, for the RPi. In my experience, in more conventional systems, applications with exclusive fullscreen mode do change the system resolution, perhaps that's where it breaks. I have no way to verify it, but maybe drawing to a FBO at a lower resolution is precisely what retroarch cores are doing. At least I have gained some knowledge from this :) the only practical solution I can see at the moment would be to boot mupen64plus through a script which does the screen mode switching before everything else, since the system is incapable of doing it on its own, while keeping the VideoCore hacks into the plugins.

 Anyway, thanks a lot for entertaining this discussion!
Best wishes,

Alessandro.