N64 from 16:9 to 4:3 instead

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.

Arrafart

@mitu I have amended /home/dietpi/RetroPie-Setup/scriptmodules/system.sh but the flags did not change.

I thought, maybe a visual things since i amended myself.
No changes after re-intallation of the 4 emulators.

https://pastebin.com/9Kua2Pt6

mitu

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

@mitu I have amended /home/dietpi/RetroPie-Setup/scriptmodules/system.sh but the flags did not change.

Yes, because you haven't added the detection part. Here's your system.sh, but with detection: https://gist.github.com/cmitu/64d7e993609a3f28b58a0a1a0267d292. Try it and see if the correct platform is detected and the flags are applied.

Arrafart

@mitu

Flags: Sun50i-h618 64bit aarch64 x11 gles gles3 gles31

After reinstalling

Progress on the flags

mupen64plus glide64 16:9
https://pastebin.com/BaRinFXe

lr-mupen64plus
Not supported / flagged

lr-mupen64plus-next (back to ES)
https://pastebin.com/2pptYP5w

mupen64plus glideN64 (back to ES)
https://pastebin.com/n1gqn5ja

mitu

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

lr-mupen64plus-next (back to ES)
https://pastebin.com/2pptYP5w

You need to recompile RetroArch also:

[INFO] [Environ]: SET_HW_RENDER, context type: gl.
[ERROR] Requesting OpenGLES3 context, but RetroArch is compiled against OpenGL. Cannot use HW context.
[ERROR] [Environ]: SET_HW_RENDER - Dynamic request HW context failed.
[libretro ERROR] mupen64plus-next: libretro frontend doesn't have OpenGL support

Arrafart

@mitu

Out of interest I think I found the "get" lines in the system.sh

sun50i-h618)
__platform="sun50i-h618"
;;

Victory! And in 4:3!

lr-mupen64plus-next
https://pastebin.com/ijeRkPF7

I feel like i will be getting picky now, but it runs choppy vs the mupen64plus standalone (that runs smoothly), it has a black bar on top+bottom and graphics took a hit.
Anything polish able? Or is this where we should draw the line for the Orange pi zero 2w?

mitu

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

Anything polish able? Or is this where we should draw the line for the Orange pi zero 2w?

You can look into the core options and make sure you disable any performance demanding options (upscaling, MSAA).

Arrafart

@mitu

I managed to puzzle a bit within the RetroArch menu (hotkey+north within the game), inside the core options, and restarting ES after each change. Might polish a bit more.

It came down to assuring the 1x resolution and some extra texture options for preference. It doesn't beat Mupen64plus graphics yet, but it is damn close right now.

I could also push the 4:3 top and bottom scaling within the glideN64 core options, no more black borders.

I am 95% satisfied! 🥂🙏🏻🎮