Goodbye fbalpha, welcome fbneo
-
@barbudreadmon Don't know if this should go here or in its own thread/report, but I discovered something weird: in
snowbro2, when I change the dipswitches for the coinage settings (through RGUI), then save, exit and relaunch the game, the left direction on my joystick stops working. Changing the dips back and relaunching solves the issue. Is it a bug? -
@WeirdH Thanks for the report, i have one good news and one bad news. The good news is that the issue should be fixed. The bad news is that this game is one of the few using conditional dipswitches (in this case, "Territory" is supposed to control which pair of "Coin A" / "Coin B" is available), and i never found a way to make those work properly due to how the libretro api works.
-
@barbudreadmon Well, as long as things still work without having to endure the god awful US/EU character selection screen, you won't hear me complaining.
Coinage options also aren't really that important to me, but I just stumbled upon this little quirk while fiddling around, so I thought I'd mention it.
EDIT: Confirmed fixed and working for me. Region was set to SE-Asia (gives English text and original character select), changed player 1 coinage setting, smooth sailing.
-
@WeirdH I was thinking about those conditional dips for the past few days and finally managed to get them working. It's still kinda awkward though with that libretro core option list working somehow asynchronously, and the conditional dips sometimes requiring a restart to work properly. But that's the best i can achieve with the tools i have at my disposal.
-
So I updated to the latest binary for the libretro version, and I notice none of my CV1K games save their diagnostic settings. IE, lowered difficulty, 9 credits instead of 1, etc.
I know that a month or so back, the driver was updated to add speed hacks. Did something break in the meantime, or do I need to delete save files somewhere?
-
@dodonpachi due to multiple requests about this, i recently migrated FBNeo nvrams from the older headered/compressed format to a raw format closer to MAME's, it turns out my migration process didn't handle several cv1k games properly due to some unusual nvram behavior.
The fix is on git, thanks for the report. -
@barbudreadmon just downloaded the latest binary from retropie setup, and can confirm the in-game options are saving again! Thank you for the swift fix!
-
Regarding CV1000 games, I'm experiencing a strange behavior.
The first time I run a CV1000 game, it works as expected: near full speed with default 100% cpu in the core options, and almost perfect full speed if I change the core cpu % by the suggested value.
However, the second time I run the same game, fps are halved (around 33 fps) and audio drops are extreme. Also, core cpu settings do not seem to have any visible effect. I have tried saving per game core settings or not, but the problem remains. The only thing that remedies the problem is removing the .fs file for that game in the fbneo directory. Then, the game runs well again, until I run it a second time (after fbneo creates again the .fs file).
I'm using the latest fbneo binary, but I have experienced this problem in previous versions too, since when CV1000 support was added. I'm also running the latest Retropie version on a Pi 4, 4Gb.
Does anyone encountered a similar problem?
-
@janderclander14 said in Goodbye fbalpha, welcome fbneo:
Does anyone encountered a similar problem?
I never heard of it. Does it maybe happen on specific games ?
@janderclander14 said in Goodbye fbalpha, welcome fbneo:
I'm using the latest fbneo binary,
You mean latest from sources, right ? I've no idea how old is the version if you are installing from binary
-
@barbudreadmon Yes, it happens on all CV1000 games and the behavior is deterministic for all of them. And yes, the binary was compiled on Jul 23, 2022 sources.
-
@janderclander14 sorry, i have no idea what's going on with your setup
-
@janderclander14 it seems like there was a similar problem talked about here. Try out the steps el rika did, maybe there's a glitch in the way the .fs file is saving threaded blitter options.
-
@dodonpachi this issue wasn't about performance and was fixed back in may
-
@janderclander14 I don't have any answers, just chiming in to say I can't replicate this either.
d712362159f1c7410fc862638e3cc3b2 ddpdoj.zip fdb4f4321a418b167a440abbb36c8ffb deathsml.zipBoth of these are running 59-60 fps on RPi4 (2 gb) in lr-fbneo latest binary (843db9f, compiled 2022-07-25), both on initial and subsequent launches.
I don't have my sound up so I can't comment on the audio.
I haven't touched the core options.
Maybe comparing verbose logs of before and after might give some insight. Are your global and system
retroarch.cfgfiles default? -
Thank you all for your answers.
Verbose logging for the first and second runs are identical and do not show anything strange. My only settings different from default are threated video = off and one lightweight crt shader. I tried enabling the former and disabling the later but the result is the same: only deleting the .fs file corrects the issue.
This is certainly a strange problem that I haven't encountered with neither other cores nor other games with fbneo.
-
@janderclander14 we did a bit of profiling, emulation is not supposed to be more demanding on subsequent launches
Do you still observe the same behavior (subsequient launch being slower) if you disable the dips "thread blitter" in core options ?
note: i don't expect the games to run at full speed even on 1st launch with this dips disabled, but what i want to know is if it could be some kind of threading issue. -
@barbudreadmon Thanks for looking at it.
I did some tests with the dip options. These are the results with Deathsmiles BL:
- 1st run (no .fs file) default core and dip settings: 57-59 fps
- 1st run disabling thread blitter: 51-54 fps
- 2nd run (with .fs file) with thread blitter disabled (saved from the first run): 27-29 fps
- 2nd run enabling again thread blitter: 30-33 fps
Enabling/disabling the speed hacks option has a similar influence in both runs (3-4 more/less fps respectively).
By the way, is there any option to prevent FBNeo from creating the .fs file?
-
@janderclander14 said in Goodbye fbalpha, welcome fbneo:
57-59 fps
57 seems low though ? It seemed pi4 users were reporting full speed using the right settings. Are you properly overclocking your pi4 and downclocking the emulated cpu ? Are you using some kind of ressource-intensive feature ?
If disabling threading didsn't change that behavior either, then it's clearly something wrong with your hardware/setup and not a core issue. Threading was the only possible cause of randomness on core's side.
-
@barbudreadmon said in Goodbye fbalpha, welcome fbneo:
@janderclander14 said in Goodbye fbalpha, welcome fbneo:
57-59 fps
57 seems low though ? It seemed pi4 users were reporting full speed using the right settings. Are you properly overclocking your pi4 and downclocking the emulated cpu ? Are you using some kind of ressource-intensive feature ?
For this test I used the default core settings, which include 100% core cpu. Downclocking it to around 40-50% gives nearly constant 60 fps across all games. My Pi is also overclocked to 2 Ghz and according to 'top' the emulation uses 99% cpu, with the remaining 1% split among other secondary linux processes.
Anyway, I understand that this looks like some problem on my side, but I'm completely lost at what to look at : )
-
Updated to the latest lr-fbneo, and for some reason Mushihimesama runs significantly slower all of the sudden. I haven't tested any other cv1k game to see if they were effected. Was something changed recently?
EDIT: Strangely enough, this phenomenon also exists in the latest version of lr-fbneo when played on my Windows PC... which can run the same cv1k games at full speed on current mame. Something clearly went wrong here.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.