Goodbye fbalpha, welcome fbneo

barbudreadmon

@red_trev said in Goodbye fbalpha, welcome fbneo:

or even a listing of the new games ?

Closest might be the various posts i did above, i probably forgot some though. You might also look at our announcement post, starting from around https://neo-source.com/index.php?topic=980.msg29188#msg29188 (may 2020)

Otherwise there is a compatibility list at https://raw.githubusercontent.com/libretro/FBNeo/master/gamelist.txt

Riverstorm

@barbudreadmon - I was poking through the arcade DAT and saw a good sized section of "vs" prefixed games (i.e. - vsbattlecity, etc.) that are using the .nes extension. I was wondering if you could tell me if these are misplaced or they are correct in the Arcade DAT?

Also I was wondering if there's any way to build a better DAT for lr-fbalpha2012? I know it's an old core but I think Retropie continues support for older hardware I believe. If not I guess it doesn't matter. I was trying to build a set of ROMs with ClrMamePro and noticed a lot of inconsistencies.

I wrote a python script to extract each game name from the DAT. Then I wrote another script to compare that file to the source code (the drv folder).

There are several games in the drivers but not the DAT and a few hundred games in the DAT but not the drivers. Then I spent some time writing another Python script to extract all the game names only from the drv folder source code and ended with around 5,000 games. I think I pulled game names for every system emulated.

Basically I couldn't find a unique value to signify arcade games only in the drivers if that makes sense. I was thinking of using a python script with the game names to strip games from the DAT that aren't in the source code to clean it up a little. I'm not sure how to add games to the DAT that are in the source, but one step at a time.

I think the rest of the Retropie lr core DATs are in pretty good shape except this one so I started spending some time looking at it. It's not a big deal but I thought I would ask if there's any reasonable way that doesn't require a bunch of time to clean it up a little.

Riverstorm

@barbudreadmon - Sorry, to clarify the first part of the post is pertaining to FBNeo containing the .nes extension games.

barbudreadmon

@riverstorm said in Goodbye fbalpha, welcome fbneo:

I was poking through the arcade DAT and saw a good sized section of "vs" prefixed games (i.e. - vsbattlecity, etc.) that are using the .nes extension. I was wondering if you could tell me if these are misplaced or they are correct in the Arcade DAT?

They are technically nes games using a specific vs mapper, some dedicated nes emulators even support them, the single file with a nes extension will make things easier for any user who wants to try them in another emulator.

Riverstorm

Ok, that sounds good. I wasn't 100% sure but they sound like they should be in the Arcade DAT. I will go ahead and build a set knowing they are ok. I'm just used to seeing all these "eccentrically" named ROM lists in regards to DATs and then you see these single file ROMs with a .nes extension, well, it just looked out of place! :) It's a shame to see PD go dark permanently with no explanation, it was a good starting point at 1.0.0.0.

WeirdH

I noticed something weird. Still not sure if it's an emulation thing or if it's my setup: in donpachi, the sound will start fading out with some static in stage 3. It sounds like a radio losing a signal. But after a few seconds or when releasing the autofire, the sound is back to normal. I've never seen this in any game before, so it might be tied to the game, or my setup is just now starting to fail when I'm playing this particular game.

I'm on a Pi 3B+ with audio going through the 3,5mm jack. So if anybody knows: is this hardware or software related?

EDIT: disabling low pass filter seems to make it better. The music in stage 3 appears to have some fading effect that apparently doesn't play well with LPF and my tiny speakers...

barbudreadmon

@WeirdH said in Goodbye fbalpha, welcome fbneo:

EDIT: disabling low pass filter seems to make it better. The music in stage 3 appears to have some fading effect that apparently doesn't play well with LPF and my tiny speakers...

You should probably let know dink at https://neo-source.com/index.php?topic=3647.735 (i hardly had time to meet him on irc lately so i'm not sure when i'll be able to relay the information).

WeirdH

@barbudreadmon Done.

GreenHawk84

@G30FF hello, I tried your tip to edit the mk2p.nv file for Mame2003-plus, but Smoke, Jade, and Noob are still locked:

G30FF

@GreenHawk84 The offset I mentioned is in Decimal, not Hex.

barbudreadmon

cv1k : https://neo-source.com/index.php?topic=2487.msg33938#msg33938

Still kinda a wip (you can only change cpu clock by 25% steps).
I'm not too sure how well it will perform on a pi4, fwiw when clocked at 50% it seems a tad faster than our segas32 emulation on my desktop.

dodonpachi

Testing on Pi 4, CPU 2100 GPU 750... only the first stage or so, single player.

Dodonpachi Saidaioujou plays with its original filename (ddpsdoj) instead of borrowing dfkbl, which is a pleasant surprise. Both it and Dodonpachi Daifukkatsu (ddpdfk) seems to perform best with CPU clock set to 25% and blitter delay off, but it practically plays in slow motion. No blitter delay setting seems to improve gameplay speed while maintaining audio consistency.

Mushihimesama (mushisam) runs very well with cpu 25% and blitter delay 57. Same with Futari and Black Label.

Deathsmiles and Black Label seem best with 25% cpu and blitter delay off.

Akai Katana also seems best with 25% cpu and blitter delay off, but like the Dodonpachi games, it's in slow motion and no blitter delay settings seem to improve it.

For a WIP, performance seems promising. I think we could get better results once the CPU overclock system allows for variables not in 25's.

G30FF

@barbudreadmon I decided to go give it a try and see how the performance looked. I tested out Deathsmiles in lr-mame2016 and lr-fbneo as a comparison, and both cores performed about the same if I set the CPU clock down to 25%. I also set a 1/2 fixed frameskip in lr-fbneo. There was some slight movement stuttering, but the framerate was good, the game was fully playable, and there were minimal sound issues. I can test other CV1000 games, but this seems promising.

EDIT: I tested more games, and I found some bugs to report.

Deathsmiles Megablack Label (dsmbl.zip) - The video mode is wrong. This is a horizontal shooter, but it's being cropped into TATE mode like a vertical shooter (original deathsml.zip is fine)
AMI games (ibara.zip, ibarablk.zip, pinkswts.zip) - Inserting coins is slightly problematic. Sometimes you have to mash the select button to have it register a coin. I believe this is happening if you try to insert a coin before the title screen appears; trying to insert a coin after doing this does not register every time.

barbudreadmon

@G30FF said in Goodbye fbalpha, welcome fbneo:

Deathsmiles Megablack Label (dsmbl.zip) - The video mode is wrong. This is a horizontal shooter, but it's being cropped into TATE mode like a vertical shooter (original deathsml.zip is fine)

Yes, we noticed this one, it was fixed yesterday however i only synced the libretro port now.

@G30FF said in Goodbye fbalpha, welcome fbneo:

AMI games (ibara.zip, ibarablk.zip, pinkswts.zip) - Inserting coins is slightly problematic. Sometimes you have to mash the select button to have it register a coin. I believe this is happening if you try to insert a coin before the title screen appears; trying to insert a coin after doing this does not register every time.

Hmmm i can't reproduce this at all. Are you using the same button for coin and retroarch hotkey ? It sounds like the infamous issue where retroarch hold hotkey button logic is conflicting with FBNeo hold coin button logic. Does it still happen if you map coin button elsewhere ?

G30FF

@barbudreadmon I updated from source, and now dsmbl is working correctly!

My controller does not use select as the coin button, it uses the Home button. I'm using an 8bitdo SN30 Pro Wired controller. The issue is a very minor one, and might not even be a bug in FBNeo, honestly. It only occurs if you try to insert a coin before the game's title screen appears (like on the copyright disclaimer screen). Once the title screen appears, adding coins works exactly as expected.

barbudreadmon

@G30FF i think i fixed the issue

Edit : also, the performance should be better with latest commit

G30FF

@barbudreadmon I updated from source, and yes, that did fix the issue! Thanks!

I tested out a couple of games with the performance updates, and they worked well with the CPU clocked to 50%. It wasn't a thorough test, but at 50% CPU it seemed to work better than the last update.

Darksavior

@barbudreadmon I've only tested deathsmiles black label (50% cpu) and it got a huge boost. Even better than mame2016. It's now 59-60fps most of the time with 57-58fps dips. The vertical level will still dip into 53-55fps but it's still a big improvement.

I'm using retropie on bullseye 64bit lite, 2000 cpu/750 gpu, glcore, 1440p crt-pi shader.

barbudreadmon

@Darksavior Yeah, the emulation is almost twice faster on my desktop at 100% cpu, That improvement is about the sh3/sh4 interpreter and will have less of an effect if you downclock that cpu, but it should still be quite noticeable.

G30FF

@barbudreadmon I was playing some NeoGeo games on my Pi, and I tried out the Crossed Swords II MVS/AES conversion (crswd2bl.zip). The game has a number of graphical glitches, with sprites that appear to stutter and flicker. They don't seem to affect gameplay, and the game still works aside from this. I don't think it's an issue with the conversion, as I see the same problem using a Redump version of the Neo Geo CD version. The bug is not present if I run the game in lr-neocd, but it is present in lr-fbneo.