Goodbye fbalpha, welcome fbneo

GreenHawk84

@dankcushions noted, I did not set those settings myself. I am not sure why they are set the way they are. The only override files I truly want in place are the game overrides for the overlays.

SFIII is running smoothly except for the audio issues which I have noticed ever since FBNeo was the new FBA. It gets pretty scratchy at times.

Riverstorm

@barbudreadmon - I agree "simulating" VRR is better than nothing. I can't seem to find those options in any RA(?) documentation. Would you happen to know a link to read up on them? I don't quite understand what those options do in relation to frame duping, using a static or VRR monitor.

I guess I can see frame duping as what is making it work correctly for FPS but I don't understand how that works on a "normal" monitor of say a static refresh rate like 60Hz. I am guessing when you say a normal monitor you're referring to a static refresh rate monitor.

It seems like if you're duping frames you would have lag somewhere basically trying to slow the frames on a static refresh rate. It seems a normal monitor of 60Hz is always going to refresh at 60Hz regardless of what RA is doing. Which you would think would have to create issues somewhere from the graphics to the audio to possible input lag.

I know @grant2258 has explained it a few times and I think he's done it well but sometimes it's a challenge to wrap my head around the concept as whole and how the devs "trick" the hardware into appearing to run correctly but I'm getting closer. :)

On a side note it just seems that gsync/freensync are not really part of Pi world in any capacity. For freesync you need a Freesync capable monitor, an AMD graphics card, display port 1.2a and the drivers. It's basically the same for gsync but they tote they are taking it to the next level by refining adaptive sync which requires special hardware in the monitor that raises the price by several hundred dollars.

If using HDMI vs Displayport I don't know the exact HDMI version that supports gsync/freesync but I believe it's newer than the 1.3a this SoC supports. Anyway the thought being it seems like gsync/freesync wouldn't really do anything unless you're running RetroPie on a PC with the minimum requirements for gsync/freesync.

Also should we turn those option on when running on a Pi with a normal monitor vs. a VRR monitor? If one way is better than the other I would like to tweak my settings for the core and possible other cores.

barbudreadmon

@Riverstorm

turning those options on doesn't seem to affect performance either (apart from the games now running at the right & slower speed), so i'm not sure there is any good reason to keep them off
to render a 57 fps content on a 60Hz screen VRRless, i guess they are evenly duping 3 frames each second, actually some people might be sensible to that so i guess it would be one reason to keep it off
afaik nvidia gpus work with both gsync & freesync (there was a nvidia update about this, might have been last year)
HDMI VRR requires 2.0

dankcushions

personally i would always want smooth gameplay with slightly different game speed/audio pitch (via the default audio skew tolerance of 0.05), than judders with correct game speed/audio pitch.

also, i kinda think that it sounds like this vrr option just has a side effect on non-vrr devices of ignoring retroarch's default 60fps speed compensation. i wouldn't expect that to be guaranteed across retroarch versions. it almost sounds like a bug, really. if you want to favour correct game speed over smooth 60hz, then i would do it via adjusting the audio skew tolerance.

Riverstorm

@barbudreadmon said in Goodbye fbalpha, welcome fbneo:

turning those options on doesn't seem to affect performance either (apart from the games now running at the right & slower speed), so i'm not sure there is any good reason to keep them off

I appreciate the help in understanding some of these things. It's good to have options but they can get confusing at times!

afaik nvidia gpus work with both gsync & freesync (there was a nvidia update about this, might have been last year)

Nice, I haven't looked in a while but that's a huge green check in Nvidia's corner to be able to use either monitor type with an Nvidia graphics cards vs. locked into one vendor for the life of the card and monitor!

@dankcushions - Yeah I suppose that's subjective. I don't mind the change in audio pitch but I'm not as keen on the speedup part. For example a 57Hz game re-sampled up to 60Hz would be a 5% increase in speed if doing the math correctly.

If I'm understanding what you're saying. Turning on vrr_runloop_enable or video_adaptive_vysnc or both shouldn't be making games run at the right & slower speed on a VRRless monitor? You're thinking it's a bug?

I guess somehow those options seem to be overriding/ignoring audio skew on VRRless monitors. The default of .05 gives you +/- 3Hz to work with and should re-sample up to 60Hz it seems vs. maintaining the slower correct speed with those options.

If audio skew is off does it automatically start using "frame duping" to fake it or you just get screen tearing due to the shortage of frames?

You prefer to leave those options alone due to a potential bug and just change the audio skew to 0.01 or something below the range that would re-sample it up to 60Hz? The closer the game to 60Hz the lower you need to adjust the skew.

grant2258

just to clarify its no bug at all when you select vrr your telling RA you have a variable refresh rate monitor. These options can be selected within RA instead of editing files as well.

The audio skew is whats causing this behaviour in fixed rate monitors its a design choice for a default not the must have value.

Its all subjective to a user needs. Proper speed vs running the wrong speed. The jerkyness is very overly stated in the 57.x to 59.x range again its all subjective audio skew does the job. It certainly a steep learning curve to new users that dont know about it.

Riverstorm

@grant2258 - That makes sense! Thanks for clarifying the options and how to use them! :)

barbudreadmon

For those of you who play on x86 (and maybe pi4 and/or odroids xu4/n2), FBNeo now has highly accurate nes/fds emulation, see original announcement on our forum : https://neo-source.com/index.php?topic=2487.msg28700#msg28700

sirhenrythe5th

Not to forget the latest addition of one of the very few arcade-games made by Eletronic Arts: "Rabbit".
Very nice 2D fighting-game, worth a look!!!

mitu

@barbudreadmon I added a few notes in the Wiki for the NES/FDS systems about using lr-fbneo. I guess it isn't possible to load .nes / .fds files directly - without them being packed into properly named archives - is that correct ?

barbudreadmon

@mitu yes

mitu

@barbudreadmon I noticed that after running NES game with lr-fbneo, a fbneo sub-folder appears in the ROMs folder - empty right now. For the arcade system, I see it's storing the hiscore data (the .hi files), but for NES I don't know if this is used - maybe it can be disabled for this subsystem if it's not used ?

barbudreadmon

@mitu It's the save folder for fbneo, some fds/nes games will use it. Imho, the real issue is that savefile_directory is never set in fbneo's config, so the creation of this subfolder fallbacks in each folders hosting fbneo roms, instead of being centralized in retroarch's savefile_directory.

mitu

@barbudreadmon said in Goodbye fbalpha, welcome fbneo:

the real issue is that savefile_directory is never set in fbneo's config

I thought the frontent/libretro should know/set where the savefile_directory is set ?
I see Nestopia queries RETRO_ENVIRONMENT_GET_SAVE_DIRECTORY and so does FCEumm.

grant2258

@mitu said in Goodbye fbalpha, welcome fbneo:

I thought the frontent/libretro should know/set where the savefile_directory is set ?
I see Nestopia queries RETRO_ENVIRONMENT_GET_SAVE_DIRECTORY and so does FCEumm.

The save path is set I checked the code.

https://github.com/libretro/FBNeo/blob/71cf627f2cb5f4c003cbfa535e8cf5950b561f10/src/burner/libretro/libretro.cpp#L1133-L1170

if it saving to contentdir/fbneo its working properly i dont have any nes games for the pie to test

barbudreadmon

@mitu What i mean is that, in retropie, savefile_directory appears to be set to the rom folder by default, which doesn't seem a good practice imho. In a standard retroarch setup, savefile_directory would be defined to the same path for every cores, so i create a fbneo subfolder inside it to avoid having the savefiles at the root of this folder (where other cores might store files under the same name, causing potential issues).

grant2258

There some issues with the input system. Lets show you an example you start fbneo and want to set a lightgun up so you goto quick menu->controllers=>port 2 controls->device type and choose lightgun close the core load it up again you'll see its set right so you think great that cores set up lets play some nes games.

load any nes game with FCEUMM go to quick menu->controllers=>port 2 controls-> look at the device type it says unknown so after scratching your head as to why you set it too zapper close the core load it again all is well. So you thinking no biggie i just had to set it.

nope load fbneo again and look at port2 whats it say now? unknown why oh why are cores saving this in the global config when ever you set one you knock another one out.

Ive been working on my personal 2003+ build and am making some good progress. I will be changing the controller options to be set in the core options until this issue is resolved.

It wont be any issue to anyone that only uses retropads. Just to let the guys using arcade panels or genesis type controllers that that set custom ports on other cores youll probably have to do a core override because this is saved in retroarch.cfg.

barbudreadmon

@grant2258 said in Goodbye fbalpha, welcome fbneo:

I will be changing the controller options to be set in the core options until this issue is resolved.

Afaik, having input settings in core option is not recommended for netplay support, but maybe that's not an issue for the mame cores anyway.

grant2258

@barbudreadmon said in Goodbye fbalpha, welcome fbneo:

Afaik, having input settings in core option is not recommended for netplay support, but maybe that's not an issue for the mame cores anyway.

Well to be honest I hear what your saying but considering anything that uses this option will knock another ones settings off id say thats a bigger issue than netplay not working. It all about perspective of usability

barbudreadmon

@grant2258 said in Goodbye fbalpha, welcome fbneo:

thats a bigger issue than netplay not working. It all about perspective of usability

I wouldn't call it a bigger issue, since it can be fixed through overrides, i would even say it's working as intended, but yeah i guess it's really annoying if you have an habit of not using the default device type, especially if you don't care about netplay in the first place.