lr-armsnes and Retropie 4.4

Used2BeRX

@mitu Installation scripts, as far as I know. I know that zerojay's expirimental installer was completely borked, and the mame plus port that gamez_fan had started still will not install on 4.4 to this day.

EDITED TO ADD: The atari800 installer that future_child had made needed to be fixed to work. Even after this, the game "Beamrider" will not work on 4.4. He's looking into the issue to find out why but hasn't posted anything about it yet. This used to work with the same emu no problem in older versions of RP.

mitu

@used2berx Which installation scripts ? The rest of things you mentioned are not part of RetroPie.

Used2BeRX

@mitu said in lr-armsnes and Retropie 4.4:

@used2berx Which installation scripts ? The rest of things you mentioned are not part of RetroPie.

I added more info after you posted.

PS... Not really appreciating whoever is downvoting my posts here. I'm trying to help the community about a valid concern I have regarding the Pi Zero. Thanks.

Used2BeRX

@mitu @dankcushions
Fresh install of RP 4.3 and there is zero lag while running the hack "Super Mario All-Stars" in lr-nestopia. This is the same result that I got while running it during original testing on a 4.2 build. It is completely unplayable on the 4.4 build with massive slowdown and audio stutter. All 3 are tested with the exact same Pi Zero, with 3 separate SD cards.

I will begin testing according to dank's specifications.

mitu

@used2berx Make sure to note which RetroArch and Nestopia versions are ok in 4.2.

Used2BeRX

@mitu said in lr-armsnes and Retropie 4.4:

@used2berx Make sure to note which RetroArch and Nestopia versions are ok in 4.2.

Sure thing. How do I do this again? :)

mitu

@used2berx Just use the RGUI (Select + X) and make note of the versions shown at the bottom of the screen. RA should be either 1.7.1 or 1.6.9.

Used2BeRX

@mitu said in lr-armsnes and Retropie 4.4:

@used2berx Just use the RGUI (Select + X) and make note of the versions shown at the bottom of the screen. RA should be either 1.7.1 or 1.6.9.

Will do. This is going to take a while. I need to test Super Mario All Stars on all 3 units for 5 minutes according to dank. I'm also going to try to see if I can duplicate the much quicker and higher performing experience in a libretro emulator for "The 7th Saga" on 4.3 and run the 5 minute tests on each of them. Once I have the logs copied for each test, I will go back in and get these numbers as well. I'm going to keep copies of the entire logfiles in each case just so I don't miss something you guys need and have to re-test them again.

Used2BeRX

@mitu @dankcushions

This is interesting... This is regarding the 4.3 install.

I just looked in the runcommand.log file after running All-Stars for 5 minutes in lr-nestopia and I saw this:

[ERROR] Couldn't find any audio driver named "alsa_thread"
[INFO] Available audio drivers are:
[INFO] alsa
[INFO] alsathread
[INFO] tinyalsa
[INFO] sdl2
[INFO] null
[WARN] Going to default to first audio driver...

I literally just went into the global options in the configuration menus a few minutes before this test and selected "alsathread" for the audio driver for all emulators. Looks like this selects "alsa_thread" when it is expecting "alsathread"?

RetroArch version from the file:
[INFO] RetroArch 1.7.3 (Git b2ceb50)

(Selext+X) information, RA/Emu versions:
1.7.3 - Nestopia 1.49-WIP 5ecea44

As for what @dankcushions was looking for... I believe this is it?

[INFO] Threaded video stats: Frames pushed: 25170, Frames dropped: 1.

Let me know if you wanted something else here or if that is the line you're looking for and I'll get the rest of the info for the other tests to compare this to.

mitu

@used2berx said in lr-armsnes and Retropie 4.4:

RetroArch version from the file:
[INFO] RetroArch 1.7.3 (Git b2ceb50)
(Selext+X) information, RA/Emu versions:
1.7.3 - Nestopia 1.49-WIP 5ecea44

These are the same versions included in 4.4, did you update the image through the RetroPie-Setup script ? You should post the whole runcommand.log file, not just the statistics line, there might be other information there that could give a hint.

Used2BeRX

@mitu said in lr-armsnes and Retropie 4.4:

@used2berx said in lr-armsnes and Retropie 4.4:

RetroArch version from the file:
[INFO] RetroArch 1.7.3 (Git b2ceb50)
(Selext+X) information, RA/Emu versions:
1.7.3 - Nestopia 1.49-WIP 5ecea44

These are the same versions included in 4.4, did you update the image through the RetroPie-Setup script ? You should post the whole runcommand.log file, not just the statistics line, there might be other information there that could give a hint.

Yes, actually. I did. After installing RP 4.3, I updated the install script. Then I ran "update all packages", but I declined when it asked about updating the OS and kernel itself. My thought was that I was just updating all of the emulators to the current versions?

At any rate, the screen I get for the RetroArch options is very different on 4.3 than it is for 4.4. In 4.3 we get the old screen with green bars. On my 4.4 image it has the soft blue RetroArch displayed that looks a lot like the PS3 options screen.

I have the 4.3 and 4.4 runcommand.log for All-Stars. Give me a minute to figure out how to post them here so you can see the differences.

BTW... the alsa_thread isn't even mentioned in the 4.4 log at all?

Used2BeRX

@mitu @dankcushions

Results on Super Mario All-Stars / lr-nestopia. Full runcommand.log files:

RetroPie 4.2: https://pastebin.com/Em3wPdUR
1.6.0 - Nestopia 1.48-WIP af3bd1a
NOTES: Absolutely zero audio stutter / slowdown. (With or without verbose logging taking place).

RetroPie 4.3: https://pastebin.com/eJf5Gb4h
1.7.3 - Nestopia 1.49-WIP 5ecea44 (Updated stuff right after installing 4.3)
NOTES: Minor audio stutter when game starts up, but then it is fine. (Only with verbose logging. No stutter otherwise).

RetroPie 4.4: https://pastebin.com/DR9BNzbP
1.7.1 - Nestopia 1.49-WIP 5ecea44 (Must have never updated this. Could this be the problem???)
NOTES: Audio stutter / slowdown plagues the game from start to finish and the games are virtually unplayable (With or without verbose logging taking place).

mitu

@used2berx said in lr-armsnes and Retropie 4.4:

At any rate, the screen I get for the RetroArch options is very different on 4.3 than it is for 4.4. In 4.3 we get the old screen with green bars. On my 4.4 image it has the soft blue RetroArch displayed that looks a lot like the PS3 options screen.
[...]

That should not happen with a stock image, the menu should show the RGUI and not the XMB menu (the blue one). Have you applied any configurations to the 4.4 image ?

Regarding the 4.4 image versions - it seems you did not update the image, you should update it - including the OS - then re-test. I'm not expecting it will be different, but you'll have the same base for testing - identical version on both systems - so we could easily pinpoint where the issue might occur.

Right now, it looks similar to this, which has been reported a few times with the 4.4 version, but I don't think you're using the 3.5' audio jack on your Pi Zero.

Used2BeRX

@mitu said in lr-armsnes and Retropie 4.4:

@used2berx said in lr-armsnes and Retropie 4.4:

At any rate, the screen I get for the RetroArch options is very different on 4.3 than it is for 4.4. In 4.3 we get the old screen with green bars. On my 4.4 image it has the soft blue RetroArch displayed that looks a lot like the PS3 options screen.
[...]

That should not happen with a stock image, the menu should show the RGUI and not the XMB menu (the blue one). Have you applied any configurations to the 4.4 image ?

I'm going to say no because I don't even understand what you're asking me here. How would I go about doing this? If I know what you're talking about then I should be able to tell you if I did or not. (At first I thought this was part of the SNES Mini skin, actually, so I switched to the NES Mini skin and it was still blue and there was no change in the speed/quality of the game).

Regarding the 4.4 image versions - it seems you did not update the image, you should update it - including the OS - then re-test. I'm not expecting it will be different, but you'll have the same base for testing - identical version on both systems - so we could easily pinpoint where the issue might occur.

I never ran the update for 4.4 I guess. I'll update it in a minute and let you know if there is any change. I'll re-run the test on All-Stars when I do. (Should I update just like I did before????? Update all, but then decline to do the OS/Kernel updates? I see you said to update the OS, but then you say "to have the same base to test". If I choose yes to OS/Kernel updates here than it will not be the same as my 4.3 image, will it?).

Right now, it looks similar to this, which has been reported a few times with the 4.4 version, but I don't think you're using the 3.5' audio jack on your Pi Zero.

No. That's not at all the issue I'm having. It's hard-core audio sputtering/stuttering that happens when you're running a game/emulator that isn't going at full speed (either because of hardware and/or software limitations). The game is also notably slower, and even when playing the 1st Super Mario Bros in this hacked rom the game runs extremely slow and has the audio stutter.

mitu

@used2berx said in lr-armsnes and Retropie 4.4:

I'm going to say no because I don't even understand what you're asking me here. How would I go about doing this? If I know what you're talking about then I should be able to tell you if I did or not. (At first I thought this was part of the SNES Mini skin, actually, so I switched to the NES Mini skin and it was still blue and there was no change in the speed/quality of the game).

I mean if you copied over any of the files in the configs folder. The stock image, as distributed by the RetroPie project, specifically disables the XMB menu driver and enables the RGUI (the green checkered menu). You should copy the /opt/retropie/configs/all/retroarch.cfg.rp-dist over /opt/retropie/configs/all/retroarch.cfg. Check that the file has the line

menu_driver = rgui

and NOT

menu_driver = xmb

As for the update, you could first update the packages only (no OS update) and re-test, but first you should disable the XMB menu driver for RetroArch.

I see you said to update the OS, but then you say "to have the same base to test". If I choose yes to OS/Kernel updates here than it will not be the same as my 4.3 image, will it?).

The 4.3 and 4.4 images are based on different Raspbian releases, so the OS will always be different. When I say "same base tot test" I mean you'll have the same RetroArch and Nestopia versions in both systems - so this helps to narrow down which update (OS/package/emulator/config ?) triggers the slowdown you're experiencing.

Used2BeRX

@mitu said in lr-armsnes and Retropie 4.4:

@used2berx said in lr-armsnes and Retropie 4.4:

I'm going to say no because I don't even understand what you're asking me here. How would I go about doing this? If I know what you're talking about then I should be able to tell you if I did or not. (At first I thought this was part of the SNES Mini skin, actually, so I switched to the NES Mini skin and it was still blue and there was no change in the speed/quality of the game).

I mean if you copied over any of the files in the configs folder. The stock image, as distributed by the RetroPie project, specifically disables the XMB menu driver and enables the RGUI (the green checkered menu). You should copy the /opt/retropie/configs/all/retroarch.cfg.rp-dist over /opt/retropie/configs/all/retroarch.cfg. Check that the file has the line
menu_driver = rgui
and NOT
menu_driver = xmb

I just checked my /opt/retropie/configs/all/retroarch.cfg and it has the line

menu_driver = "rgui"

It doesn't have xmb

But I just loaded up Super Mario All-Stars and I still get the blue screen and not the green one that I used to see in the RetroArch menu. Is there another possible way to make the blue screen happen? Maybe a /system/ based config got messed up or something?

As for intentionally doing this, I can say that I definitely didn't do anything. I've never used any configs other than what came on the pi (other than putting the experimental installer from zerojay... although I did put something called the "RetroPie Toolkit" on there that allows me to do some cool stuff like log into the Pi from my desktop to run commands from Windows. But I didn't do any options that I don't know what they do, and nothing that specifically says it would have changed this).

As for the update, you could first update the packages only (no OS update) and re-test, but first you should disable the XMB menu driver for RetroArch.

I just did. Now I show 1.7.3 - Netopia 1.49-WIP 5ecea44 in RetroArch.

I see you said to update the OS, but then you say "to have the same base to test". If I choose yes to OS/Kernel updates here than it will not be the same as my 4.3 image, will it?).

The 4.3 and 4.4 images are based on different Raspbian releases, so the OS will always be different. When I say "same base tot test" I mean you'll have the same RetroArch and Nestopia versions in both systems - so this helps to narrow down which update (OS/package/emulator/config ?) triggers the slowdown you're experiencing.

Okay. I didn't do the OS/Kernel, but I updated everything else. As I said, the blue screen RetroArch still shows up even after verifying that menu_driver line is as it should be, and there is no change to the bad performance of All-Stars. At this point I'm not going to re-test it for the runcommand.log file until I figure out how to get back to the Green RetroArch GUI.

mitu

Check if your NES system configuration file for RetroArch (in /opt/retropie/configs/nes) has the XMB display driver enabled. The file there should not be more than 4 lines.

Used2BeRX

@mitu said in lr-armsnes and Retropie 4.4:

Check if your NES system configuration file for RetroArch (in /opt/retropie/configs/nes) has the XMB display driver enabled. The file there should not be more than 4 lines.

lol... what the s***? I'd say it's a little more than 4 lines. It's 94kb. I did a search for menu_driver and it is, in fact, xmb.

Here's what my file looks like: https://pastebin.com/s6PjT2Bp

Any idea how this would have happened? I know I didn't write a 94kb CFG file in my sleep.

Incidentally, the SNES RetroArch screen is Green like it should be. (Although 7th Saga plays like crap in lr-snes9x2002 compared to how well it plays on my 4.2 version still, and I'll have to eventually be testing all 3 systems on that game as well).

I'm going to change that line in my NES config and see if things work better for the NES. In the mean time, feel free to give me your thoughts on what might have happened there. :)

EDIT: I changed that line to read rgui instead of xmb. That gives me the Green screen in RetroArch again, but sadly it doesn't improve the performance of the game.

RetroArch now shows 1.7.3 - Nestopia 1.49-WIP 5ecea44 on my RP 4.4 build.

mitu

Replace the contents of the retroarch.cfg (in the nes folder) with

# Settings made here will only override settings in the global retroarch.cfg if placed above the #include line

input_remapping_directory = "/opt/retropie/configs/nes/"
#include "/opt/retropie/configs/all/retroarch.cfg"

This should get you the stock settings.

Used2BeRX

@mitu said in lr-armsnes and Retropie 4.4:

Replace the contents of the retroarch.cfg (in the nes folder) with
# Settings made here will only override settings in the global retroarch.cfg if placed above the #include line

input_remapping_directory = "/opt/retropie/configs/nes/"
#include "/opt/retropie/configs/all/retroarch.cfg"
This should get you the stock settings.

Yeah. I actually did that by renaming retroarch.cfg to retroarchBAK.cfg then copying retroarch.cfg.rp-dist to retroarch.cfg. There actually did seem to be a bit of improvement, but not enough. It's still laggy and has audio stutter.

Now that we're updated to the same RetroArch and emulator, we've got the same RetroArch Green Screen, and we're using the default retroarch.cfg options, if there is nothing more you can think of to try tweaking (or un-tweaking) at this point, maybe I should just run another runcommand.log and show you the new results?