N64 from 16:9 to 4:3 instead

mitu

I'm not sure which problem are you trying to solve ?
Without any configuration, even with a wide screen resolution (16:9), Mupen64plus should default to keep the original aspect ratio (4:3).

Moreover, the Libretro core should also default to 'core provided aspect ratio', thus keeping the aspect ration requested by the Mupen64plus-next core. There's no need to modify any .cfg and you shouldn't, any configuration done from the RetroArch menu should be saved as overrides (core/game/directory) so you keep the (minimal) defaults for all cores and just adjust settings per-system/core/game.

Can you add some logs (/dev/shm/runcommand.log) on pastebin.com from the emulator not perfoming how you expect and also the configuration used.

Arrafart

@mitu

Thank you for taking a look at this Mitu,
https://pastebin.com/JX0nuU9y

Mupen64plus has only displayed 16:9 fullscreen so far on this device, unless I manually adjusted the resolution.

mitu

Not sure how maintained is the glide64mk2 video plugin, you should either use the RetroArch core or the - more maintained - GlideN64 plugin to run.

In the log it see your resolution is detected as set as 800x600 by the emulator, is this a crash log or what exactly is the behavior associated with this log file ?

Arrafart

In the log it see your resolution is detected as set as 800x600 by the emulator, is this a crash log or what exactly is the behavior associated with this log file ?

@mitu I successfully started the rom, it was booting in 16:9 and I successfully exited.

I'll check how to choose a different core and try that also.

Not sure how maintained is the glide64mk2 video plugin, you should either use the RetroArch core or the - more maintained - GlideN64 plugin to run.

I selected the GlideN64 emulator in the Loading screen but it jumps back into ES. Hope this is what you meant...

https://pastebin.com/NaGsP18r

Also tried the lr-mupen64plus emulator and, same thing, it jumps back into ES.

https://pastebin.com/WUJHqZvM

mitu

The RetroArch log would have more info if you choose verbose logging during startup.

For the standalong log, since the crash seems to be OpenGL related, it may be a mismatch between the OpenGL version required by the emulator (OpenGL 3 most likely) and the version supported by your board. Since you're using an relatively unsupported platform, what are the your platform flags detected by RetroPie-Setup and what capabilities does your device have - does it support GLES2 or GLES3 with hardware acceleration ?

Arrafart

@mitu said in N64 from 16:9 to 4:3 instead:

The RetroArch log would have more info if you choose [verbose logging]

lr-mupen64plus_next
https://pastebin.com/sh3wuA0K

lr-mupen64plus
https://pastebin.com/NEM8nX6U

mitu

The logs show:

[INFO] Requesting **core OpenGL context (3.3).**
[INFO] [Video]: Using HW render, glcore driver forced.
[INFO] [Video]: "**glcore**" saved as cached driver.
[ERROR] [Wayland]: Failed to connect to Wayland server.
[INFO] [GLX]: GLX_EXT_swap_control_tear supported.
[INFO] [GLCore]: Found GL context: **"x".**
[INFO] [GLCore]: Detecting screen resolution: 1280x720.
[INFO] [XINERAMA]: Xinerama version: 1.1.
[INFO] [XINERAMA]: Xinerama screens: 1.
[INFO] [GLX]: Using Xinerama on screen #0.
[INFO] [GLX]: X = 0, Y = 0, W = 1280, H = 720.
[INFO] [GLX]: Using windowed fullscreen.
[INFO] [GLX]: Creating context for requested version 3.3.
[WARN] [GLX]: X error message: **GLXBadFBConfig, request code: 151, minor code: 0**

which means you're running uner Xorg, with OpenGL (core) render driver. The core requests an OpenGL 3.3 context, but Xorg is unable to provide it, most likely because the driver for your GPU doesn't support that version of OpenGL (Core). I suspect the same reason causes the crash of the standalone emulator - unsupported/unavailable OpenGL version.

Your system should have the gles gles3 flags instead of x11 (which I assume it's now set by RetroPie-Setup), so that the GLES3 specific build options are applied to emulators/libretro cores. What are the system's flags, detected by RetroPie-Setup, right now ?

Arrafart

@mitu

Your system should have the gles gles3 flags instead of x11 (which I assume it's now set by RetroPie-Setup), so that the GLES3 specific build options are applied to emulators/libretro cores. What are the system's flags, detected by RetroPie-Setup, right now ?

I'm too new to this, may I have a tip on where to spot this? I'll ask Chatgpt and Google also a bit, maybe it can help before you find this post

mitu

@Arrafart said in N64 from 16:9 to 4:3 instead:

I'm too new to this, may I have a tip on where to spot this?

Go to an 'unsupported' package and open it up (i.e. fs-uae in experimental is not available for ARM targets), RetroPie should print the flags and explain why the package is not available for installation.

Arrafart

your flags: 64bit gl vulkan x11

mitu

@Arrafart said in N64 from 16:9 to 4:3 instead:

your flags: 64bit gl vulkan x11

OK, that only looks partially right. Your device/platform should include les gles3 gles31 and no vulkan nor gl.

EDIT: you can see how platform flags are added in https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/system.sh. You can customize your platform - how the platform is detected and how is named, then add a platform_<name> function where you can further customize the flags.

Arrafart

@mitu

I need a moment to process this. Give me a moment :D
I might have questions, but later....

Thanks!

mitu

@Arrafart said in N64 from 16:9 to 4:3 instead:

I need a moment to process this. Give me a moment :D

Sure. If you're not familiar with Bash scripts or don't understand how the system detection/flags system works, it's ok, the script is not meant to be directly manipulated by end users, but by someone familiar with Linux and Bash script.

Arrafart

@mitu

Something like this?
I opened your link, analyzed it, and figured that the opi02w is not in there at all.
I asked chatgpt, sorry, to give me the same kind of info like the rpi4 but then for the orange pi zero 2w.

How bad did it do? XD

I want to try and add the correct info to the script if possible, I would be proud

But...., it would not have solved my initial issue thought 🤔

PS: I recognized the armv8 from the img, and the cortex-a53 from the opi zero forums

function platform_orangepizero2w() {
cpu_armv8 "cortex-a53"
__platform_flags+=(orangepi gles gles3 gles32)
}

mitu

I asked chatgpt,...

Yeah, I see a pattern here.

I want to try and add the correct info to the script if possible, I would be proud

One more platform added and a correct detection/categorization for the platform would be good.

PS: I recognized the armv8 from the img, and the cortex-a53 from the opi zero forums
__platform_flags+=(orangepi gles gles3 gles32)

They're not entirely correct:

orangepi what's the use of this flag ?
gles32 is of no use, since it's not used anywhere (gles31 is used by the RetroArch build script) and it's also not correct. The Panfrost driver for your GPU (ARM Mali G31) doesn't implement GLES3.2, only OpenGLES 3.1 , see [1]
platform name should be named after the SOC model (something with h618 ?). What's the output of /proc/device-tree/compatible ?

You're also missing the detection part, but see the previous question.
[1] https://docs.mesa3d.org/drivers/panfrost.html

Arrafart

@mitu

Scratched the back of my head when i opened the link to the Panfrost info, haha!
It is not correct with many things, but it did help me to identify that i had to use cat (aka the very basics) :)

dietpi@DietPi:~$ cat /proc/device-tree/compatible
xunlong,orangepi-zero2wallwinner,sun50i-h618

Would it be more like this?

function platform_sun50i-h618() {
cpu_armv8 "cortex-a53"
__platform_flags+=(gles gles3 gles31)
}

Maybe unrelated: Would it help if I'd say the bootEnv.txt contains an overlay_prefix=sun50i-h616? (No idea what it does, I understood it is connected to the .dtb(o), and if I amend this to h618, the gpu acc stops working)

mitu

@Arrafart said in N64 from 16:9 to 4:3 instead:

Would it be more like this?

Yes, I think it's better; sun50i-h618 sounds like a good name. You can try adding x11 also to the flags.

Maybe unrelated: Would it help if I'd say the bootEnv.txt contains an overlay_prefix=sun50i-h616? (No idea what it does, I understood it is connected to the .dtb(o), and if I amend this to h618, the gpu acc stops working)

That's just instructs the bootloader (U-Boot) to look for any .dtb files under the sun50i-h616 folder. Since the H616 is the previous SOC version in the H series, it might have inherited part of that version's device tree.

dietpi@DietPi:~$ cat /proc/device-tree/compatible

xunlong,orangepi-zero2wallwinner,sun50i-h618

You can use either rangepi-zero2wallwinner or sun50i-h618 as a device identification string, and set platform to sun50i-h618.

Arrafart

@mitu

function platform_sun50i-h618() {
cpu_armv8 "cortex-a53"
__platform_flags+=(x11 gles gles3 gles31)
}

The Orange Pi zero 3 has the same chipset, if I'm right, so they would carry the same name like that.

Not sure what to do with it, but...

I had a good day, thanks!

Arrafart

@mitu

Your system should have the gles gles3 flags instead of x11 (which I assume it's now set by RetroPie-Setup), so that the GLES3 specific build options are applied to emulators/libretro cores.

Found it: Can I apply it to the system.sh script and reinstall emulators or should update Retropie script?

mitu

@Arrafart You should re-install with the new flags. Don't update, since RetroPie-Setup doesn't have your modifications and it won't work anyway.