Goodbye fbalpha, welcome fbneo

roslof

@barbudreadmon said in Goodbye fbalpha, welcome fbneo:

Seibu SPI is now supported :

Senkyu / Battle Balls
E Jong High School
Viper Phase 1
Raiden Fighters
Raiden Fighters 2 - Operation Hell Dive
Raiden Fighters Jet
E-Jan Sakurasou

Note : no, we can't remove that 999 countdown, and you'll have to restart the game at the end of it, the good news is that you have to go through it only the first time you launch the game, sometimes there are also clones (single board PCB version) that don't have that countdown

Another big win. Performance is great after countdown hell.

roslof

@barbudreadmon said in Goodbye fbalpha, welcome fbneo:

Namco NA-1 is now supported :

Bakuretsu Quiz Ma-Q Dai Bouken
Cosmo Gang the Puzzle
Emeraldia
Exvania
Fighter & Attacker
Super World Court
Tinkle Pit
Knuckle Heads
Numan Athletics
Nettou! Gekitou! Quiztou!!
X-Day 2

@barbudreadmon for this earlier released set, there are some issues you should be aware of. FWIW, My test device is a Pi4B. Updated lr-fbneo to commit 578e85f. Let me know if you'd like me to file any of these issues in the fbneo git repo:

Bakuretsu Quiz Ma-Q Dai Bouken (bkrtmaq) controls do not appear to work/respond (eg. cannot add credits).
Cosmo Gang: The Puzzle (cgangpzl) SegFaults after rom is validated line 1285: 12660 Segmentation fault
Numan Athletics (numanath) SegFaults after rom is validated line 1285: 26458 Segmentation fault
Nettou! Gekitou! Quiztou!! (quiztou) boot screen displays Key Custom ERROR can't seem to advance

The rest of the games seem to be working as expected. Hope this is useful.

It's great to remove the lr-mame2015 emulator from these games. Thank you!

barbudreadmon

@roslof were those tests done with latest code ? i can't reproduce that issue on cgangpzl and numanath (i don't have a pi4 though, only a pi3 but that shouldn't make any difference). what do you mean exactly by "after rom is validated" ? could you maybe provide full log ?

I confirmed the issue with the 2 others, thanks for the report.

Riverstorm

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

DTEAM

@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

WeirdH

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

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

DTEAM

@weirdh said in Goodbye fbalpha, welcome fbneo:

Does this setting reside in retroarch-core-options.cfg?

Yes It is.

barbudreadmon

@weirdh it should be, but maybe you got some override somewhere ?

@roslof the 2 quiz games are fixed, i'm still waiting for more informations about your crash on the 2 others.

Anyone else can reproduce this crash with cgangpzl and numanath ?

roslof

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

Verbose Pastebin for cgangpzl

Verbose Pastebin for numanath

barbudreadmon

@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

roslof

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

barbudreadmon

@roslof that's interesting, i'll see if i can reproduce and debug this issue with merged romsets

roslof

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

WeirdH

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

dankcushions

@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

barbudreadmon

@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

roslof

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

barbudreadmon

@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

@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/dats

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

barbudreadmon

@dteam oops, it seems i missed your original msg, sorry about that, yeah those romsets require new bioses