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

Video displays at the lower left corner, no full screen #813

Closed
wn2000 opened this issue Dec 19, 2020 · 11 comments
Closed

Video displays at the lower left corner, no full screen #813

wn2000 opened this issue Dec 19, 2020 · 11 comments

Comments

@wn2000
Copy link

wn2000 commented Dec 19, 2020

Running mupen64plus on a RK3328 aarch64 Linux, with SDL2, KMS/DRM, and GLES2.
There's no X11 so windowed mode is not applicable.
When starting with --fullscreen --resolution 320x240 in a 1280x720 screen, I was expecting to see video rendered internally at 320x240 then scaled to 1280x720, but instead video is only rendered in a 320x240 block in the lower left corner of the 1280x720 screen, with the rest part being blank.
Tried three different video plugins, and got the same result.
Is this the normal behavior? Any parameters I missed to make it full screen?

I found some similar reports in the rpi community. And all solutions suggest "update mupen64plus from source". But I'm building from the latest source and the issue still persists.

Appreciate any help on setup or hint regarding where to look in the code.

@richard42
Copy link
Member

you should use "--resolution 1280x720" if that is your screen resolution. nothing in the video plugin is going to automagically scale it for you.

@wn2000
Copy link
Author

wn2000 commented Dec 19, 2020

@richard42 So is there a way to use a different resolution for internal rendering than the displaying resolution? Like scaling a 320x240 texture onto a 1280x720 surface, like what is done by SDL_RenderCopy in SDL2.

@richard42
Copy link
Member

No, none of the video plugins support separate rendering/display resolutions with an intermediate scaling step. When work on most of these video plugins were first started, CRTs were common and you could set your output resolution to 640x480 and have it fill up the entire monitor. This type of functionality could be added to any of the plugins but it wouldn't be trivial. The way to implement it is to render to an FBO which is bound to a texture, and when everything is finished and it's time to do the GL_Swap, unbind the FBO and scale the rendered texture to the final output resolution on the real background surface, then do the swap.

@wn2000
Copy link
Author

wn2000 commented Dec 19, 2020

Thanks for confirming this @richard42 . That saved me much time trying to make it work.
I'm surprised though that this functionality is not there yet.
It's a much needed feature for low-spec boxes, where only 320x240 can run smoothly.
I'm curious how rpi handles this as I see in their launch script --fullscreen --resolution 320x240 were frequently used. Do they first set the monitor resolution to 320x240?

@dankcushions
Copy link
Contributor

@wn2000 retropie uses an SDL fork with bespoke scaling hints to fullscreen 320x240 windows.

btw, this doesn't work on mesa (the rpi4's only video driver) so in that case the resolution is set to current screen res, but some plugins (eg GLideN64) can render at lower resolutions internally (scaling up to mupen64plus's window).

@wn2000
Copy link
Author

wn2000 commented Dec 19, 2020

@dankcushions Thanks for that info! Do you have a link to the customized SDL fork? Is it open source?
I also tried GLideN64 (I think it's called gles2n64 in the log) and did notice it was setting up a 400x240 video whereas other plugins were doing 640x480 by default. But still the video was at a lower left corner, just the size is different. Any hints to get GLideN64 work the way I want (render at low res but scale to current display res)?

@dankcushions
Copy link
Contributor

dankcushions commented Dec 19, 2020

@dankcushions Thanks for that info! Do you have a link to the customized SDL fork? Is it open source?

yes, yes: https://github.com/RetroPie/SDL-mirror/tree/retropie-2.0.10. relevant commit: RetroPie/SDL-mirror@9ae0a81
however given that it uses the dispmanx (rpi-specific compositor) api i don't think it will be much use for non rpi0-3 platforms.

I also tried GLideN64 (I think it's called gles2n64 in the log)

no, that's not the same plugin. GLideN64 is https://github.com/gonetz/GLideN64/ - it's by some margin the best HLE plugin at this point. gles2n64 is a GLES fork of glN64, which has been long abandoned.

and did notice it was setting up a 400x240 video whereas other plugins were doing 640x480 by default. But still the video was at a lower left corner, just the size is different. Any hints to get GLideN64 work the way I want (render at low res but scale to current display res)?

for gles2n64 (which i don't suggest you use anyway), i get the same issue with non rpi0-3 platforms: RetroPie/RetroPie-Setup#3118
given that it's an abandoned, niche plugin, there's little point trying to fix it IMO.

@wn2000
Copy link
Author

wn2000 commented Dec 19, 2020

Awesome thanks for the help. I will try GLideN64 now.
@dankcushions Were you able to resolve issue RetroPie/RetroPie-Setup#3118 with GLideN64?
That's exactly the same issue I'm experiencing.

@dankcushions
Copy link
Contributor

effectively, yes. like i said:

some plugins (eg GLideN64) can render at lower resolutions internally (scaling up to mupen64plus's window).

so you still have to use --resolution (your screen res), but you can use the setting

UseNativeResolutionFactor = 1

so it internally renders at n64 resolution, ending up with the result you want.

@wn2000
Copy link
Author

wn2000 commented Dec 19, 2020

Awesome will try that and report back.

@wn2000
Copy link
Author

wn2000 commented Dec 20, 2020

OK I tried GLideN64. Took some efforts to build for my RK3328 Mali-450 aarch64 platform (had to tweak the code for a little bit otherwise segfault).
First run with mostly default parameters and UseNativeResolutionFactor = 1 resulted in a blank screen, but the music plays and sounds smooth.
After some tweaking I found I have to change the following to True in order for it to display anything:

# Do not use shaders to emulate N64 blending modes. Works faster on slow GPU. Can cause glitches.
EnableLegacyBlending = True

But once this was set it becomes really slow (~10 FPS).
Not sure what I did wrong.

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