Hacking Emulation RetroArch/Libretro Thread: PS Vita Edition! Nightlies Included

[Aliminator]

Look for the Final Burn Alpha v0.2.97.30 romsets, though I had to check on a computer for errors, some roms just don't work.

I just chose the specific FBA rom sets, and Asterix as well as Nitro Ball work just well on FB Alpha on my PC with the same version used as on the vita, so Im curious why its not working. Am I doing anything wrong?

 

[hiroakihsu]

Also as an aside, if you exit RA properly (As many SHOULD be doing by now to maintain working configurations), when you return it'll use the last selected core (Out of the box, it runs 2048 for some reason).

You mean by going into retroarch menu and selecting "quit retroarch" instead of using PS button? I always do that but the config still doesn't autosave, and it still defaults to desmume core when I relaunch (using 10/13 nightly).

 

[deathblade200]

I'm using the retroarch.vpk and have noticed the controls go unresponsive until I freeze-resume with the home button. 10/12 build

the controls have gotten pretty weird and its not just the all in one having the issue the controls for whatever reason seem to take about a minute to start working for me and longer if I hit any of the buttons instead of waiting the lock up only happens when I load the retorarch menu or when first loading a game

 

[SeongGino]

Wait...So are you saying the libretro devs are dropping support for individual core vpks from here on?

If I was a betting man (Which I'm not... usually), I'd say that is the case now.
Considering the massive space savings, and some of the minor bugs now having been fixed in the AiO (All ROM selection-based crashes are now exclusive to MAME/FBA for clear reasons), I don't see any reason to use the individual cores.
Besides, installation takes 1-2 minutes vs. 1 hour for all the cores; a far easier method for keeping test builds up-to-date.

Not sure if you're a point of contact for the RA team, but is there a forum where we could post issues we find with the nightly builds?

Huge digression and aside here...
Aside from "You have been blocked from viewing Libretro's Tweets" unless I use an alias, I can't officially consider myself a true Libretro member. I've never even signed up for it or asked for consent.
This whole thread, really, was a labor of love of sorts; not only to make up for my... er... personal wrongdoings with the team in the past, but to give something that I felt was sufficient for recording the active progress of what is, no doubt, one of the biggest PS Vita homebrew projects to exist. Of course, it's the others here that helped to bug test and report issues with the port; whether they intended to or not. (^^'

I doubt Libretro here actually cares... but I wouldn't mind being more a proper tester for their project. However, the chances of this are slim; I'll take it if it's offered, but I refuse to force anything down anyone's mouth.

So, yeah, that's why this merely remains the Unofficial Official Thread.

TL;DR - This is the thread to post issues for the nightly builds.
Libretro has gone on record however on accepting unofficial GBATemp threads as endorsed locations for bug reports, so...

e.g. ALL the SNES cores have unresponsive controls. To get some level of response back, I need to press home and re-enter the emulator where the controls sometimes work.

Confirmed, this is a global issue.
It has to do with the quick menu toggle it seems; ~50% of the time it is triggered, the controls may become unresponsive which requires suspending RetroArch and resuming it, but this isn't a perfect solution.
Mainly with ISO-powered emulators (PCE with Turbo CD titles, Genesis+GX/PicoDrive with Sega CD titles, and PCSX-ReARMed), this causes the virtual CD to lose its read position upon suspension/resuming, causing an inevitable lockup when it has to read from the disc image again (Which it basically lost upon suspension).

So yeah, at the present this is an issue with the AiO executable.

You mean by going into retroarch menu and selecting "quit retroarch" instead of using PS button? I always do that but the config still doesn't autosave, and it still defaults to desmume core when I relaunch (using 10/13 nightly).

Assuming you have a re-generated (new) retroarch.cfg or retroarch folder structure, it SHOULDN'T be an issue.
But as always with this, YMMV. For some reason it's only ever me that gets good results.

 

[Deleted User]

Confirmed, this is a global issue.
It has to do with the quick menu toggle it seems; ~50% of the time it is triggered, the controls may become unresponsive which requires suspending RetroArch and resuming it

Got the same problem here until I figure that it happen when I put my finger on the retrotouch. It is disabled in menu BUT if you touch it while starting a game, you have to pause then resume to make it work. So again, if controls don't work remove your big finger from the touchpad then pause the game by going to the quick menu then resume.

 

[Lord M]

If I was a betting man (Which I'm not... usually), I'd say that is the case now.
Considering the massive space savings, and some of the minor bugs now having been fixed in the AiO (All ROM selection-based crashes are now exclusive to MAME/FBA for clear reasons), I don't see any reason to use the individual cores.
Besides, installation takes 1-2 minutes vs. 1 hour for all the cores; a far easier method for keeping test builds up-to-date.

So this mean that now i must choose to have olny old separate cores or new AiO that will get updates? Bad, most bad news now...
Because in separate cores i can have different build for each cores, for example i used old FBA because back touchpad is very annoying during gameplay, and savestates is faster because game freeze during saves (the new cores continue the game and lag as a shit, and savestate need double time to save when game continue. Even if i open quick menu to stop game during saves, the new savestates function is slow...)

 

[Deleted User]

I don't know if you can still use the various standalone vpk but for sure the eboot.bin in each standalone vpk are same core that the *.self found in the standalone retroarch.vpk

They just rename all eboot.bin to "emuname_libretro.self". The trick is that the eboot.bin inside the retroarch.vpk is a kind of launcher that allow core to be loaded dynamically. Rename fceumm_libretro.self to eboot.bin and it will work. But you'll lose the ability to change core at runtime by doing this.

 

[Lord M]

I don't know if you can still use the various standalone vpk but for sure the eboot.bin in each standalone vpk are same core that the *.self found in the standalone retroarch.vpk

They just rename all eboot.bin to "emuname_libretro.self". The trick is that the eboot.bin inside the retroarch.vpk is a kind of launcher that allow core to be loaded dynamically. Rename fceumm_libretro.self to eboot.bin and it will work. But you'll lose the ability to change core at runtime by doing this.

And you'll lose the ability to change core even if i take a old core, rename to .self and put inside/ overwrite the existing one in retroarch.vpk?

 

[Deleted User]

And you'll lose the ability to change core even if i take a old core, rename to .self and put inside/ overwrite the existing one in retroarch.vpk?

I think if you just change a self file it will work (as long as the version is not too old, to match the configuration). Just DO NOT REMOVE/REPLACE the eboot.bin by mistake.

I was trying to compile my own version of the standalone retroarch (to have front touch instead of back), and I figured that the *.self files are just standalone core eboot.bin renamed to .self. That mean the binary retroarch.vpk/vba_next_libretro.self == vba_next.vpk/eboot.bin)

 

[Lord M]

I think if you just change a self file it will work (as long as the version is not too old, to match the configuration). Just DO NOT REMOVE/REPLACE the eboot.bin by mistake.

I was trying to compile my own version of the standalone retroarch (to have front touch instead of back), and I figured that the *.self files are just standalone core eboot.bin renamed to .self. That mean the binary retroarch.vpk/vba_next_libretro.self == vba_next.vpk/eboot.bin)

Yeah, i think that in many games front touch pad would be much better than backpad. No way to add a touchscreen support for hotkeys? I think will be very useful by using the 4 touchscreen zone for savestate slot +/- and save/load states

 

[LibretroRetroArc]

> Aside from "You have been blocked from viewing Libretro's Tweets" unless I use an alias, I can't officially consider myself a true Libretro member. I've never even signed up for it or asked for consent.

Umm, I am not certain I ever blocked somebody. Can you tell me which Twitter follower this is?

> I doubt Libretro here actually cares... but I wouldn't mind being more a proper tester for their project. However, the chances of this are slim; I'll take it if it's offered, but I refuse to force anything down anyone's mouth.

Regarding testers, it's a nice offer but honestly, we need more developers, not testers.

--------------------- MERGED ---------------------------

What are you guys talking about regarding unresponsive controls? When did this start happening?

When you're working with an experimental toolchain/SDK and you keep adding features that people request I guess there is bound to be situations where it will backfire. It sucks that I can't even test both targets (Vita and PS TV) since I only have a PS TV at my disposal and that doesn't have the touchscreen facilities or anything.

 

[laharl22]

When desmume will work mister libretro?

 

[frangarcj]

When desmume will work mister libretro?

It works now.

 

[subcon959]

It sucks that I can't even test both targets (Vita and PS TV) since I only have a PS TV at my disposal and that doesn't have the touchscreen facilities or anything.

Perhaps it might be a good idea afterall then to accept a few more testers with actual Vitas who would likely pickup on things like this?

 

[LibretroRetroArc]

Yeah, Desmume will work now. Keep in mind that even though the dynarec works, it will still be far below fullspeed. We will need to make Desmume much, much faster (and its dynarec far more efficient) before we will see better results there unfortunately.

 

[laharl22]

Yeah, Desmume will work now. Keep in mind that even though the dynarec works, it will still be far below fullspeed. We will need to make Desmume much, much faster (and its dynarec far more efficient) before we will see better results there unfortunately.

Im impatient for the dynarec

 

[yeeeeeeee]

If you are concerned about the vpk size like me you can open it up and delete the cores .self you don't need, just tried it and it works. I deleted a bunch of stuff that seemed related to cores I'm not using from database\rdb\ too, I wonder if that stuff is needed at all? And probably could have deleted stuff from /info too but the files were so small that I didn't bother...

 

[laharl22]

Gpsp bug are fixed or not?

 

[pralima87]

If you are concerned about the vpk size like me you can open it up and delete the cores .self you don't need, just tried it and it works. I deleted a bunch of stuff that seemed related to cores I'm not using from database\rdb\ too, I wonder if that stuff is needed at all? And probably could have deleted stuff from /info too but the files were so small that I didn't bother...

Can you explain how to do that?

 

[yeeeeeeee]

Can you explain how to do that?

Just rename the retroarch.vpk to retroarch.zip on your pc, then open it up and you will see all the .self files for each core, delete the ones you don't need. Don't delete the eboot.bin!!!