Topic: dink's FBN Development & Fixes thread

[JohhnnyB]

@dink

Thank you for the ongoing support for FBA, even after the recent drama.
You guys are making a lot of people happy with this piece of software (which I have been using myself for the last 10+ years and prefer it over any version of MAME).

A quick question - is synching romsets with the current version of mame (0.209) on your todo list? I'm building an arcade cabinet for my old-school needs and it would seem FBA is synched to 0.208 currently. No biggie, just a question.

Unless anyone knows a way of doing it on the source level without programming knowledge then I could try.

[dink]

JohhnnyB, glad you dig it!  I found FBAlpha in 2014 and haven't looked back. 

I don't think there are much changes between .209 and .208 regarding romsets, I'd be surprized if one doesn't work in fbalpha.
When mr.Barry synched the romsets from .207 to .208 even, there were only a couple of internal rom-filename changes - but fbalpha loads the roms via the crc and not the filename, so even those wouldn't have made much of a difference - the new set would load fine.
I guess what I'm saying is, that in the longrun we'll need to come up with something to synch the romsets like Barry did.  Maybe JacKc will come back?   But for the short-term, I think we'll be alright.  If there is a breaking/serious change, like a parent changes to a clone, and a new romset-version is made a parent, me or iq_132 usually takes care of this.

best regards,
- dink

[el_rika]

I remember this being a sensitive subject some years back..but, is it possible to reduce Battle Gregga's input lag to PCB levels?

We now have most Cave shmups (except the SH3 bunch) to almost PCB level input lag. However Battle Garegga is still on the laggy side, with, by my estimation, around 5 frames compared to the original 2 (even 1 on Saturn but that's another story).

[barbudreadmon]

is synching romsets with the current version of mame (0.209) on your todo list?

I'll add it on mine, i just need to come up with a good way to detect those romset changes (i'm thinking about parsing and comparing mame/fba dat files to generate a listing).

[dink]

That would be great!!:)

I'll add it on mine, i just need to come up with a good way to detect those romset changes (i'm thinking about parsing and comparing mame/fba dat files to generate a listing).

[JohhnnyB]

That would be great!!:)

Good news! Thanks for a quick reply. 

Another topic worth mentioning - autobuilds. I remember seeing that question somewhere on the forum.

Currently the only way to get a working Windows binary (until the team decides to release an official rls) is to compile the source from GitHub.
BUT

you can get already compiled Windows builds from

http://ashura.mameworld.info/nightlybuilds/fba_builds.html
or
http://www.emucr.com/search/label/FBA?&max-results=16

Both point to Barry's Git.

[dink]

Thanks for posting those links, JohhnnyB

[dink]

On buffered soundchips.

Recently I buffered the AY8910, SN76496/89[a], and now the Namco WSG chips.
What's this mean?  Simply put, less cpu usage and better sound.  For the developer, it makes working with the sound chips a lot nicer as well, due to dealing with less code in the drivers.  Take a look at the pacman driver's sound update routines in the attachment below.

The first block of code (- prefixed) was called every time the cpus ran, the second block was called at the end of a frame, to make sure the sound buffer was completely filled.  In some games, this would have to be called up to 262 times per frame (and there are usually 60 frames in a second!)  Each call is basically a call to emulate the soundchip.

The buffered approach does things a bit smarter, it only updates the sound buffers when the game writes to the soundchip.  On average, it updates 1-5x per frame, but if a certain game were to use the chips as a rudimentary dac, it could be called hundreds of times per frame.

Out of the FM chips, they're all buffered except for the YM2151 and YM2413.  Going to have to tackle those next..

For those that don't know -
The code removed has a - in front of it, the code added/replaced has a +.
(the green block at the bottom of the image replaces all that code above it!)

best regards,
- dink

[barbudreadmon]

@dink great !

@JohhnnyB i synced the romsets with MAME 0.209, we might be missing some new working clones though

[JohhnnyB]

@barbudreadmon

Great, thanks!

@dink

Thanks for posting those links, JohhnnyB

Every little bit helps I think.
On another note I found out that Ashura-X's builds are kinda based on Barry's Git if I'm not wrong.

Since we don't have any Windows builds for the NEW FBA currently I could step up and start compiling them from the GIT let's say every week/two weeks and posting them to a public place for people to download.

I'm thinking x86 and x64 builds only, unless someone is really desperate for the WinXP or Debug ones.

Let me know if that's okay with you and which compiler would be best (I'm thinking Mingw-w64 or MS Visual Studio).

[vbt]

On buffered soundchips.

Recently I buffered the AY8910, SN76496/89[a], and now the Namco WSG chips.
What's this mean?  Simply put, less cpu usage and better sound.  For the developer, it makes working with the sound chips a lot nicer as well, due to dealing with less code in the drivers.  Take a look at the pacman driver's sound update routines in the attachment below.

well done dink ! it deserves a study

[dink]

JohhnnyB, thanks for the offer regarding exe's, but Ashura-X had updated his build stuff to pull from our new git instead of Barry's.  I think his build script is stuck though, I'll let him know.
Personally, I post a exe whenever I feel that the exe is worthwhile for people to try.  Over the past several days a lot of writing/rewriting has been going on, and its probably best that I finish everything & remove debug code before using an exe from the current code.  Of course, anybody is free to make an exe and try if they want - though

best regards,
- dink

[Stifu]

Great work on the buffered sound chips, dink! I wonder how much this will improve performances on the Raspberry Pi, and which arcade systems / drivers are concerned by those improvements. Like, will the Taito F3 benefit from this? It apparently uses ES5505 and ES5510 sound chips, but you didn't mention those.

[dink]

Stifu, thanks

The 550x chips are already buffered, I'm afraid!  There isn't much that can be improved for f3, the bottleneck really is the vdp - it's very complex.

Best regards,
- dink

[DarkShadowMD]

Hey Dink, Sorry for the late answer, seems the latest debug build of FB Alpha fixed the bug I described. Sorry about that ^^

Cheers!