I first thought, can we use function copyDefaultConfig here when placing the file? Except, when I updated this last time it also added a couple new entries, which I suppose we would not want to miss out on.

You can't use copyDefaultConfig because the file is updated upstream and updates will not copy when a new version is added.

So could we use sed or something, then, to add the fix automatically? Or, why do we even have to do this manually, why is this just not the default already; is the glitch specific to a certain hardware/platform?

The default is the opposite (copyDepthToRDRAM=1), so it's clearly a platform (RaspberryPi / GLES3) glitch

[DONKEY%20KONG%2064] Good_Name=Donkey Kong 64 (E)(J)(U) frameBufferEmulation\copyDepthToRDRAM=1 frameBufferEmulation\N64DepthCompare=0

The launch script has some overrides for games, but copyDepthToRDRAM is not among the settings considered. Maybe it would be useful to have a GLideN64.local.conf and merge the settings from it in GLideN64.custom.conf, during installation/configuration.

@mitu Oh,cool
problem complete
this xpadneo troubles?

@barbudreadmon This is INCREDIBLY helpful. Thank you for sharing that link and giving me a breakdown of how I should be handling my ROMs. I appreciate you taking the time!

@duglor 2.9.0 isn't released yet.

@mitu thanks for such a swift reply. I thought that might be the case...oh well!

Please add some info about your setup, as detailed in https://retropie.org.uk/forum/topic/3/read-this-first.

Mame 2010 hasn't been updated in the last 2 years, so it's unlikely the binary is 'old'. If you look at the package version information option in the package details (RetroPie-Setup), you'll see when it was built and from which upstream commit. Compiling from source will get you the same version as the binary installation.

@Finntendo

You should read the Docs.
Here you can find many answers to your questions.

I will try to answer your question.

RetroPie is a collection of bash scripts running on top of a lite linux OS.
Lite means it has no Desktop (windows) environment it only has the terminal.
You can even install RetroPie separately on your own compatible debian based linux OS, even if it has a Desktop environment, even if it's not a Raspberry Pi.

Just see a binary as an EXE files from windows, it is also a binary, you download it and it runs.
But to create EXE files you need to compile it first from source so the computer can understand it.
Compiling is converting the programming language into understandable code for the CPU this can take a long time depending on what computer you use.

The RetroPie guys made it easier by supporting binary installs for the Raspberry Pi and perhaps for some other arm boards.
They compiled it for you and many people can use them.

Source installs can be more up to date if the source code is maintained regularly and the binary files are behind but it takes much more time to install.
Though the binaries from RetroPie are updated quite regularly so if it's possible to update from binary than that is in most cases a better choice as it is much faster.

You say you have updated everything now from source.
This means that all installs are very up to date.
So when everything works I would wait some time to update from binary.
Because it could mean that you downgrade the emulators.

The OS underlying files are updated in a quite normal way.
This does not depend on the source / binary installs.
So you won't downgrade your OS.

@sleve_mcdichael Yes.

For example ./retropie_packages.sh image all buster would build rpi1, rpi2/3 and rpi4 images based on buster.

@mitu Spot on - I had to manually update the controls too (select the controller type in PCSX2), but now working completely as before - thanks so much for your help :)

Regards,

The Gent

@djavs said in IM STUCK start4.elf:

i got this image Raspberry Pi4 running VIRTUALMAN PLAYBOX v1.4.5.14 512GB RETRO-BLISS-REVOLUTION!

We don't support 3rd party images, as outlined in https://retropie.org.uk/forum/topic/3/read-this-first.
Use the image from https://retropie.org.uk/download and you'll not have this issue.

@llivingst I ran into a similar issue when I updated a year old build on my pi 4. It would get to emulation station, but went to a blank screen when going into a game. It think it was crashing cause I could not exit back to emulation station or my video feed was gone. I know a lot of kernel changes were made, so maybe you have a custom configuration that interferes with the new kernel. But Step one would be to try switching hdmi ports. I remember that being in the wrong port did that before. If not, you might have to reimage a new build. I changed all my custom configs from overclocks to KMS drivers switched back to and still no go.

@sleve_mcdichael Thank you so much!!! I will definitely give this a go once I returned home from work.

edit: It works and now I am able to update to 4.8. Thank you so much!!!

@mitu That did the trick, thanks for your help!

@windg It sure is! I decided to load up Mizzurna Falls, A game that I knew for sure crashed during the intro now runs fine. I couldn't find any glitches in the Gran Turismo introduction and played driver for about 6 hours without a crash. I know thats not all but those were it for me. The only thing I am unsure of is the end game event is Final Fantasy 8.

@lolonois Thanks, will check it out.

Hi I think I fixed the problem I had to reformat my sd card and re install retro pie so I think my version was outdated to the point it wasn’t supposed anymore

@simpleethat I agree. It's great that it's all config files and easily backed up and replicated. The trick is knowing which files to back up, but it's not that difficult. :)

Press F4 in Emulation Station to go to the command console. Then enter:

sudo apt clean # clears the update cache sudo apt autoremove # removes installed packages that are no longer needed by other packages (so-called dependencies) exit # exits the console back to Emulation Station