Goodbye fbalpha, welcome fbneo

barbudreadmon

@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.

janderclander14

@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?

barbudreadmon

@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.

janderclander14

@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 : )

dodonpachi

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.

barbudreadmon

@dodonpachi said in Goodbye fbalpha, welcome fbneo:

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?

I just compared with early june version, and they ran at exactly the same speed. The only 2 commits from the past 3 months were to reduce memory footprint, notably for runahead's sake (you can now run cv1k with no input lag at all on a powerful enough computer), and i can't see how they would introduce any performance regression.

@dodonpachi said in Goodbye fbalpha, welcome fbneo:

DIT: 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.

MAME was always faster on pc, because they use a x86 dynarec. FBNeo should still run fine on any decent computer though, dink can run this on his 12 years old computer without downclocking.

Sorry but i can't reproduce this, so i'm not gonna be much help. It doesn't look like a core regression.

dodonpachi

@barbudreadmon I would write it off as an anomaly with retropie, if not for the fact that my Windows PC has an i5-2500 CPU. Final Burn Neo shouldn't be a problem whatsoever.

I tried disabling runahead to see if that would help, and it didn't. I'm at a loss here.

barbudreadmon

@dodonpachi said in Goodbye fbalpha, welcome fbneo:

i5-2500 CPU

Dink is using an i7-2600, which doesn't really make any difference since we are talking about emulation (no heavy multi-threading), so i can guarantee it run fullspeed on that without having to downclock the cpu, with ressources to spare.

Maybe your screen is not running at the proper refresh rate or something ? If you are using some kind of ultra-hd screen, make sure it's not stuck at 30hz for some reason, i see that a lot. Otherwise maybe check everything is ok with the usual performance tips.

dodonpachi

@barbudreadmon Both mine and Dink's CPUs seem equivalent here, and leagues above the CPU in a Pi 4B.

In retroarch, I did see a setting along the lines of "force 60hz" turned off. I'll try it when I get home later, but I don't know if that will be it. The way cv1k games run on the rig is now as if it were on a Pi 3 or something--not only is it visually slow, the sound is incredibly choppy. Maybe this is a video driver issue? I'll have to poke around more.

barbudreadmon

@dodonpachi said in Goodbye fbalpha, welcome fbneo:

I did see a setting along the lines of "force 60hz" turned off

That's just a setting to replace original refresh rate by 60hz, it's not gonna change anything about slowdowns, especially since i think refresh rate is already set to 60hz for our cv1k emulation.

roslof

@dodonpachi also turn off the RetroArch Rewind feature. Your symptoms are similar to it being toggled on. Hope that's the issue...

dodonpachi

@roslof That was it!!!! Thank you, I would have almost never guessed that!

barbudreadmon

@dodonpachi said in Goodbye fbalpha, welcome fbneo:

@roslof That was it!!!! Thank you, I would have almost never guessed that!

That's one of the first things mentioned in the performance tips i previously linked to you though, you didn't read them ?

dodonpachi

@barbudreadmon I did, but I must have missed it. I remember reading regarding speed hacks and threaded video.

Darksavior

@dodonpachi When troubleshooting always revert to retropie's defaults. That means rewind is off and threaded video is on.

Riverstorm

@barbudreadmon - I don't if this is a good spot to post a DAT question so just let me know.

I combed through the DAT thoroughly and could only find a few games that stood out as potentially incorrect. It's basically the games that prefix vs such as vscastlevania. There are around 31 that I could find that have an aspect ratio of 256:224. Should these be 4:3? There's an example below from the DAT.

<video type="raster" orientation="horizontal" width="256" height="224" aspectx="256" aspecty="224"/>

Also by the way thanks for adding this additional information. It's really quite useful! :)

barbudreadmon

@Riverstorm NES has a PAR (pixel aspect ratio) of 1:1, hence a DAR (display aspect ratio) of width:height (= 256:224 = 8:7). I might be wrong but i believe NES-based arcade boards have the same ratios.

Ashpool

@barbudreadmon Ok, SAR vs./to PAR/DAR Calculations are sometimes frustrating/sometimes even may appear somewhat esoteric [1], e.g.: Correct Geometry - Aspect Ratio for different systems, Display information vs screen dumps .

I would wish that at least the arcade xml/dat files, even the ones for current MAME, would stick to the old-style (or as FBNeo still does) of providing aspectx and aspecty together with the display/screen information. Mame2003, and Mame2003Plus (guess still leftovers from the original Mame2003 info) datfiles are providing aspectx=4, apecty=3 for horizontal VS. titles per screen (e.g. for VS. Baseball that would be 8:3) (and vice versa for Vertical-Games).
If you are sure the information provided in the FBNeo xml is correct, then maybe it is time to update mame2k3+ (if it would be just the datfile, i would offer my help (over in the mame2k3+ threat) in doing it, but as the (driver?)-source(s) must be modified I think that is beyond my ability and maybe that could also mess up other things?).

P.S.: I guess not, but does anyone knows, if there is a way to derive the correct DAR from the Screens modline Information provided in the (mame-)datfile?

1: Even if the basics of how to calculate the third from 2 known is simpel but to get 2 fixed datums for a certain game/system may be complicated (especially to filter out legend/myth from spec. and fact) - sigh.

Riverstorm

@barbudreadmon - I appreciate that information. I was a bit tired last night and missed the 8:7. I like to see it condensed but I think that should work out fine for calculations. I thought it was a simple error but I see it's correct.

I was hoping you'd entertain one more question out of a lack of knowledge and for posterity. Why aren't they displayed as the "prime" condensed ratio as in 8:7 vs 256:224? Is it just the way the raw information is pulled from the source?

@Ashpool - Yes you're correct that m3plus does do that. A quick pull from vshoot.


<video screen="raster" orientation="horizontal" width="288" height="224" aspectx="4" aspecty="3" refresh="60.000000"/>

There is a small group of guys that work on m3plus (arcadez, mahoney, misty, grant, mark plus many many miscellaneous contributors) that are always looking for ways to improve the core. If you open a request on Github they would probably take a look. They auto generate the DAT from source within games so it would probably just be tweaking the code potentially, or you could be right too that it's an era specific issue of the code from way back when.

https://github.com/libretro/mame2003-plus-libretro

I don't want to go down a rabbit hole here as I know it's easy with these types of discussions and it's probably not the thread for a long discussion but wouldn't you need to know something about your target display to calculate a DAR that makes the game look correct on your display or I might not know what you're trying to achieve with your calculations.

Ashpool

@Riverstorm said in Goodbye fbalpha, welcome fbneo:

I don't want to go down a rabbit hole here as I know it's easy with these types of discussions and it's probably not the thread for a long discussion

You're right, it is a rabbit hole (are there any drinks or fungi involved?) :/ And as CRTs had a few screws you could turn to expand/shrink the view, which is a user action/turn, and because of that - it is impossible to say that even on the real machines the Aspect was right/set in stone...

Yeah, that is a bottomless hole to dive into...