Windows Nightly discussion thread

[QUOTE=Awakened;39695]Never had crashing issues with VBA-M, VBA Next or mGBA using zipped ROMs. Not sure what’s causing that for you.

You can open retroarch-core-options.cfg in your RetroArch folder in a text editor and change reicast_boot_to_bios = “enabled” to disabled to revert the config change. Another thing that might help with the memory card problem is deleting the vmu_ files from System/dc (the dc folder should be where you store your Dreamcast games if you don’t have a System folder set in directory settings). The Reicast core is very early in development, so it has lots of issues.[/QUOTE]

I’ll try disabling core config for reicast later this week, and delete the vmu files… Think that DC folder is in the system directory.

As for .zip crashing for GBA… I would like to know the cause, maybe that’s why i can never get MAME ROMs running as it crashes RA instantly.

Maybe opening the ROM contents from the zip then running one file inside may help getting it running… But that’s tedious as there’s so many files within a .zipped MAME ROM.

I think mednafen PSX core are broken somehow. I can’t run any of my PAL Psx games…black screen, only audio is working. USA ntsc and JAP ntsc are working well. MD5 sum for pal bios is ok, also SHA-1. Reverting back core (i kept secure XD) cause PAL games working again.

Does anyone know how to remove a core association to a game in your list of scanned games?

settings > playlists

Open your playlist in a text editor, replace the line pointing to the core with DETECT. Put that playlist in read-only if you don’t want a core association to be written there again.

Thanks alot guys, its working fine now. Much appricated!

The latest Nightly builds have an issue with changing the config options for “savefile_directory =” and “savestate_directory =” to default. I have them set to a certain folder, but with the nightly builds this change doesn’t stay. But everything works fine with the stable build. The bug is probably effecting other custom directories, but I haven’t checked. I had this same issue awhile back with a nightly build and it was fixed the next day, but the bug seems to be back.

Last two Nightly versions crash when i load anything vulkan related.

Same here.

Yes, latest Nightly crashes when trying to run ParaLLEl.

Actually no, it was due to a bad configuration option (Hard GPU Sync"), but now Vulkan works here (on software cores).

Hard GPU sync did always work for me with vulkan before. It’s an important option if you want reduced input lag. Having it ON is not a “bad configuration”.

Edit: Still crashes for me. The only way to not crash is if i have vulkan as default. If my default is “gl” and i use an override for ParaLLEl to use “vulkan” it crashes.

Edit 2: One solution is to keep Vulkan as default and make overrides for ALL other cores to use GL. It’s not the most optimal solution but it works to a few systems i tried.

I’m using a cheaper Toshiba satellite laptop with Windows 10 and as soon as I video threaded to true it segfaults. It’s done this for a while now and I’m not sure if it’s specific to my hardware configuration or if others have had the same issue. I’ll have to check older versions and maybe git bisect to see if it can narrow down when it started as its not been broken in the past. Still persists in nightly as of Sept 12 2016

I am having an issue after updating RetroArch to the latest nightly release.

I have all of my cores configured to have the following directories setup for save files and save states:

C:\Users\Kenny\Dropbox%SYSTEMNAME%

Where %SYSTEMNAME% could be “Super Nintendo Entertainment System” or “Nintendo Entertainment System” etc.

After updating to the latest nightly, they all seem to have changed to the contect directory.

In the .cfg file for whichever core, it shows “default” as both folders.

If I manually change it back to my desired folders, it works as long as I keep RetroArch open, but if I close RetroArch, it seems to default back to the contect directory upon opening.

Sorry if this is the wrong spot to post this, if so, please direct me to the correct location to post!

noob config issue. threaded video doesn’t work on the x86 build if you’re on a x86_64 machine.

[QUOTE=BennyKurns;47190]Thanks for the reply Radius.

I am sure I am using the latest builds, and the latest cores.

I was using configurations-per-core prior to this update.

I use HyperSpin/RocketLauncher as a frontend, not sure if that has any effect on the configuration file, but it does still seem to be using the snes9x config file when loading snes9x.[/QUOTE] I had this issue for months. I figured it out though. Basically, RocketLauncher forces retroarch to save wherever the AKH tells it to.

You have to edit the Retroarch.ahk that Hyperspin/rocketlauncer uses. Once you open it you find this line:

“”" -s “”" . srmPath.FilePath . “” . romName . “.srm”" -S “”" . saveStatePath.FilePath . “” . romName . “.state”""

There are 4 instances of this line. Delete them all carefully without deleting anything else (like an extra space for instance). You may also need to set your save paths in the ahk as well, there are some lines above these where you can set it up.

Once you do that, it should save wherever you want.

As for the “configurations-per-core” it’s not supported anymore by RetroArch itself but other frontends like RocketLauncher and Launchbox can still use those configs.

Oh, I wasn’t aware of this. Weird :confused:

[QUOTE=GemaH;47201]I had this issue for months. I figured it out though. Basically, RocketLauncher forces retroarch to save wherever the AKH tells it to.

You have to edit the Retroarch.ahk that Hyperspin/rocketlauncer uses. Once you open it you find this line:

There are 4 instances of this line. Delete them all carefully without deleting anything else (like an extra space for instance). You may also need to set your save paths in the ahk as well, there are some lines above these where you can set it up.

Once you do that, it should save wherever you want.

As for the “configurations-per-core” it’s not supported anymore by RetroArch itself but other frontends like RocketLauncher and Launchbox can still use those configs.[/QUOTE]

Thank you so much for the reply GemaH.

Everything you said makes complete sense.

I’ll give your recommendations a shot probably sometime this weekend.

Thank you again!

[QUOTE=GemaH;47201]I had this issue for months. I figured it out though. Basically, RocketLauncher forces retroarch to save wherever the AKH tells it to.

You have to edit the Retroarch.ahk that Hyperspin/rocketlauncer uses. Once you open it you find this line:

There are 4 instances of this line. Delete them all carefully without deleting anything else (like an extra space for instance). You may also need to set your save paths in the ahk as well, there are some lines above these where you can set it up.

Once you do that, it should save wherever you want.

As for the “configurations-per-core” it’s not supported anymore by RetroArch itself but other frontends like RocketLauncher and Launchbox can still use those configs.[/QUOTE]

Worked like a charm, thank you GemaH, that would have taken me quite some time to find on my own.

Hey no problem, glad it worked for you.

I know what you mean though, it took me some time to figure it out as well, lol.