Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some issues in Raspbian (RPi 3) #27

Open
AlessandroPorcelli91 opened this issue Aug 7, 2016 · 8 comments
Open

Some issues in Raspbian (RPi 3) #27

AlessandroPorcelli91 opened this issue Aug 7, 2016 · 8 comments

Comments

@AlessandroPorcelli91
Copy link

Hello, I am having some issues with the latest compiled version of this emulator and I hope to fix at least a couple of them with your kind support:

1st: Configuration folder not being saved
I have to explicitly put the option --configdir /home/pi/.config/mupen6plus every time, or the emulator would load different configurations. Where are such configurations to be found?

2nd: Core event commands not working
Pressing esc to quit the emulator, as well as all of the other commands do not work, though they are correctly bound inside of mupen64plus.cfg. Could these by disabled by default in compilation time? How do I check this?

3rd: Unchangeable fullscreen resolution
The fullscreen resolution is automatically taken to be the one that Raspbian is running in. This is a problem because such resolution is too high for most games to run smoothly. I can change the default resolution to be lower, but I'd much rather keep it native and change it only within mupen64plus. Is it possible?

Thanks for your time and work.

@ricrpi
Copy link
Owner

ricrpi commented Aug 8, 2016

1: Are you running as root/sudo as the /root.config/mupen64plus folder will be used.

2: I'm not sure what the current implementation is but I think I changed it from my hack to SDL2 and last time I modified the code in that area I checked that keyboard inputs where working (especially ESC).

3: The resolution used is Raspbians resolution however the frame buffer/emulator uses the configured resolution from mupen64plus.cfg. The video-core scales this up to fit the screen.

@AlessandroPorcelli91
Copy link
Author

Thanks for responding. I was not aware of the other configuration file, thanks. However I'm completely lost with the other two problems, could my SDL2 compilation be bad? Using the very same emulator through retropie does not generate any problem, it seems. I can correctly exit the emulator through the esc key. This is the same binary I am using in the xserver environment.

For the resolution, I really don't know. the emulator reports

Core: Setting 32-bit video mode: 1440x900

No matter what I have in the configuration file. The resolution is actually 900p 16:10, not any upscaled 480p as I wanted. This is my mupen64plus.cfg video config

[Video-General]

Fullscreen = True
ScreenWidth = 640
ScreenHeight = 480

If true, use correct aspect ratio, if false, stretch to fullscreen

AspectRatio = True

If true, activate the SDL_GL_SWAP_CONTROL attribute

VerticalSync = False

This is what I have in gles2n64.conf

#Window Settings:
window width=320
window height=240
multisampling=0
auto resolution=1

#Framebuffer Settings:
framebuffer bilinear=0
framebuffer width=320
framebuffer height=240

#VI Settings:
video force=0
video width=320
video height=240
video stretch=0

Putting auto resolution to 0 gives me the correct resolution, though it does not upscale to full screen.

@ricrpi
Copy link
Owner

ricrpi commented Aug 10, 2016

In gles2n64.conf set 'auto resolution' to 0 so that the screen uses the frame buffer resolution not the host screen resolution (mupen64plus-video-gles2n64/src/OpenGL.cpp:399).

@AlessandroPorcelli91
Copy link
Author

Yep, it does use the frame buffer resolution but it stays in the corner of the screen without upscaling. That was the last sentence in my previous comment :)

@gizmo98
Copy link
Collaborator

gizmo98 commented Aug 10, 2016

I believe you must set video width/height (or window width/height) to your actual screen resolution. Framebuffer resolution should be upscaled to video /width/height then.

@gizmo98
Copy link
Collaborator

gizmo98 commented Aug 10, 2016

You can also play around with special SDL2 version which support dispmanx upscaling https://github.com/RetroPie/SDL-mirror/commits/retropie-2.0.4

SDL_VIDEO_RPI_SCALE_MODE=1 mupen64plus --windowed --resolution 320x240 --gfx ${VIDEO_PLUGIN}.so --audio ${AUDIO_PLUGIN}.so "$ROM"

@AlessandroPorcelli91
Copy link
Author

I'll look into the special SDL2 version, thanks. In the meanwhile, I have tried to play around with the options in gles2n64.conf and I realized that the actual resolution is given by whatever is in the #Window Setting section, whereas the FrameBuffer Setting gets ignored. This did not allow me to upscale the actual window to full screen, though I realized that if I put VI Setting's video force to 1 and I change around those numbers, I can stretch the video around. Though it also moves in overscan somehow. Also, the smaller the numbers are, the larger the picture (WTF?!) For example: here are my settings atm

#Window Settings:
window width=640
window height=480
multisampling=0
auto resolution=0

#Framebuffer Settings:
framebuffer bilinear=0
framebuffer width=320
framebuffer height=240

#VI Settings:
video force=1
video width=80
video height=60
video stretch=0

The size is about right, but it's almost completely moved downwards (I can only see Mario's cap in the press start screen)

@AlessandroPorcelli91
Copy link
Author

AlessandroPorcelli91 commented Aug 26, 2016

UPDATE: The key core events now seem to work after a fresh installation of SDL2 and mupen64plus. The only thing which is holding me back is the fullscreen resolution. I still have to try the special version of SDL2, I just hoped I could make it work with the regular one. I also noticed that pressing Ctrl+z while the emulator is running causes my raspberry to freeze, apparently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants