Goodbye fbalpha, welcome fbneo
-
@barbudreadmon said in Goodbye fbalpha, welcome fbneo:
for a given emulator, hardware rendering (drawn by GPU) is faster than software rendering (drawn by CPU), the only exception to that would be if your device is very unbalanced (very good CPU with very bad GPU)
What you said makes perfect sense. I guess I wasn't thinking so much about the methods or techniques used to render them. When I do my thought always leans more toward software rendering when it comes to arcade machines. I think of a bunch of discrete logic components slapped onto a circuit board and not so much CPU based architecture.
How to render all those chips? To me it seems to make more sense to emulate those types of hardware components on the CPU (software rendering) for portability vs. going the road of GPU (hardware rendering).
If you utilize and adhere to some platform specific graphical standard like DirectX , etc. or even some GPU manufacturer's proprietary technology (NVIDIA or ATI) you run the risk of that company going defunct or abandoning the technology line and you're back at square one.
I know both companies have developed some great technologies in the past only to ultimately abandon them at their discretion for one reason or another. Not to mention it probably leaves devs needing to maintain multiple code bases to cover all the platform technologies.
When I think of MAME I think of emulation vs. simulation. They both can have the same end result but under the hood they may have went about it in two completely different ways. I think some emulators get the job done and utilize those graphical advantages and/or shortcuts to great effect without much thought into code portability and compatibility. MAME is more about preservation hence emulation by definition vs. simulation may run it perfectly but you have no idea how the original actually worked under the hood. Most gamers probably don't care as long as they have a good experience.
I know their are always exceptions, to all games, but when comparing two similar games graphically and hardware wise from the same era hardware, rendered with the same techniques, I would generalize that the 3D games generally take more processing power than the 2D games for the purpose of shooting the breeze and generalized discussion.
I know it's a rabbit hole and these discussions have been going on for decades. I also see mitu up voted the reply. I do trust his discretion, expertise and impartial replies and may be completely off base on how I view emulation. I also know these discussions have been going on for decades but I do appreciate the explanation and the great games FBNeo supports.
-
@barbudreadmon
I'm not able to run namco na-1 and nb-1. The other stuffs run perfectly.- I'm using MAME romset 0.229
- I'm using Up-to-date clrmamepro dat files from https://github.com/libretro/FBNeo/tree/master/dats
Did I miss something ? I run It on a Pi 4
-
@dteam said in Goodbye fbalpha, welcome fbneo:
@barbudreadmon said in Goodbye fbalpha, welcome fbneo:
I recommend using frameskip on low-end devices if you aren't already.
For that, the value must be 1 or auto
fbneo-frameskip = "0"New edit
I put « 1 » and now, everything is fineDoes this setting reside in
retroarch-core-options.cfg? When I change it there, then launch a game and check 'options' through RGUI, it still says 'no skipping' at frameskip, so I think I'm in the wrong file here... -
@weirdh said in Goodbye fbalpha, welcome fbneo:
Does this setting reside in retroarch-core-options.cfg?
Yes It is.
-
-
@barbudreadmon said in Goodbye fbalpha, welcome fbneo:
@roslof the 2 quiz games are fixed, i'm still waiting for more informations about your crash on the 2 others.
-
@roslof i can't reproduce this at all, maybe your romset is corrupt or something ? Over the years i've seen this issue a few times : the romset was detected as "valid" but the file was somehow unreadable when trying to launch the game, could you try unpacking then repacking your 2 romsets ?
If it's not solving your issue, then please join us on discord or write an issue on github (https://github.com/libretro/FBNeo), this topic is not really the best place for bug tracking -
@barbudreadmon said in Goodbye fbalpha, welcome fbneo:
could you try unpacking then repacking your 2 romsets ?
Done. Good call. I expanded the .7z and repackaged the file. This worked.
You should be aware that the same 'broken' .7z was able to be loaded by lr-mame2015 as-is.
Email me (see my profile) if you would like more details on the .7z files that were failing.EDIT: I'm confident I understand the issue. These original two (2) .7z's are merged sets. The base roms within each set are correct, and pass fbneo's CRC check, but each of the offending .7z files also contain a subfolder for the Japanese version -- 2 roms with identical filenames. I would bet you a doughnut that fbneo is grabbing the files from the subfolder, instead of the ROMs that pass CRC.
Will note that Merge ROMs should never be used as this may happen if the filenames are identical, and it's not optimal anyway.
Cheers!
-
@roslof that's interesting, i'll see if i can reproduce and debug this issue with merged romsets
-
@barbudreadmon FWIW, I believe source was from a 0.222 set. I suspect the ordering inside the archives is important, and also suspect that fbneo uses first match in archive, which may not be at root level.
-
@barbudreadmon said in Goodbye fbalpha, welcome fbneo:
@weirdh it should be, but maybe you got some override somewhere ?
Would a game specific options save file act as an override?
-
@weirdh said in Goodbye fbalpha, welcome fbneo:
@barbudreadmon said in Goodbye fbalpha, welcome fbneo:
@weirdh it should be, but maybe you got some override somewhere ?
Would a game specific options save file act as an override?
that's exactly the purpose of game specific options files: https://retropie.org.uk/docs/RetroArch-Core-Options/#setting-core-options-per-rom
-
@roslof not too sure what was going on with your romsets, i'm able to load merged 7z romsets without issues, even after renaming files so that they have matching name in the subfolder (that wasn't the case by default with those 2 romsets for me, names were slightly different), so i don't think that was the problem
-
@barbudreadmon said in Goodbye fbalpha, welcome fbneo:
@roslof not too sure what was going on with your romsets, i'm able to load merged 7z romsets without issues, even after renaming files so that they have matching name in the subfolder (that wasn't the case by default with those 2 romsets for me, names were slightly different), so i don't think that was the problem
Email me if you wish to have the versions that exhibit the problem. I kept them in case you would like to investigate.
-
@roslof that would be nice but i don't have your email (not appearing in your profile for me, it's probably only showing for you), anyway i don't recommend showing emails in public places like a forum so it might be better to join us on discord or to pm me on FBNeo forum ?
-
@dteam said in Goodbye fbalpha, welcome fbneo:
@barbudreadmon
I'm not able to run namco na-1 and nb-1. The other stuffs run perfectly.I'm using MAME romset 0.229
I'm using Up-to-date clrmamepro dat files from https://github.com/libretro/FBNeo/tree/master/datsDid I miss something ? I run It on a Pi 4
That's fine now. I added namcoc75, namcoc70 and 69 BIOSes and now it works. My game Roms was good.
-
@dteam oops, it seems i missed your original msg, sorry about that, yeah those romsets require new bioses
-
@barbudreadmon said in Goodbye fbalpha, welcome fbneo:
I really recommend "The Outfoxies", it's a hidden gem.
I agree 👍🏻.
Thanks for the info. -
Fairchild ChannelF was added to the list of supported subsystems (i guess this one will require an update of the retropie setup script)
-
@theissdev dink added Ms PacMan Twin this week-end :)
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.