Author Topic: dink's FBN Development & Fixes thread  (Read 558303 times)

Offline dink

  • Administrator
  • *****
  • Posts: 4648
  • Karma: +407/-1
  • pie? I nearly bought one!
Re: dink's FBN Development & Fixes thread
« Reply #2415 on: May 08, 2022, 08:48:37 PM »
some happenings since the first cv1000 wip:
A little while ago I checked in an optimization that improves speed/performance (and reduces the cpu load / requirement)
Added support for 16,24bpp gfx modes

best regards,
- dink

Offline dink

  • Administrator
  • *****
  • Posts: 4648
  • Karma: +407/-1
  • pie? I nearly bought one!
Re: dink's FBN Development & Fixes thread
« Reply #2416 on: May 08, 2022, 09:08:44 PM »
thanks guys, I'm glad you're excited about this, I have been wanting to do this since 2015! (or earlier?)

el_rika, it has blitter delay and cpu speed changer.  currently cpu speed changer has issues with odd percentages (anything not 25,50,75,100%), it causes skips in the music.  I understand that it "needs" to be fixed, but it's very difficult to fix.  please understand that I've spent weeks on this without luck so far.  it will be fixed hopefully soon as I explore new ideas. (as the original post said).

best regards,
- dink

Offline el_rika

  • Jr. Member
  • **
  • Posts: 96
  • Karma: +7/-0
Re: dink's FBN Development & Fixes thread
« Reply #2417 on: May 09, 2022, 03:33:45 AM »
Got around to test a couple of games (Ibara BL and Mushihimesama).

Emulation is amazing, fantastic job dink and everyone involved!
My measurements put input lag at 2 frames (mame is 3 in Retroarch for cv1000).
The blitter delay works as it should, absolutely no issues.

Ibara has zero issues, Mushihimesama, at least in Retroarch android, has the clasic layer issues where some layers/elements are not displayed properly (ex. at the ship selection).
This is fixed by deleting the "game.cfg" before each run, though here it doesn't seem to work.

The performance is way way better than latest mame. Amazing job here as well!

Can't wait to test some more 🤜🤛

Edit: With the risk of being punched in the face, i can not stress enough how this driver needs a sync_to_exact content, at least in Retroarch. It needs perfect smoothness..it' s just too good for anything less than that.

« Last Edit: May 09, 2022, 03:38:45 AM by el_rika »

Offline barbudreadmon

  • Administrator
  • *****
  • Posts: 985
  • Karma: +56/-1
  • Helper
Re: dink's FBN Development & Fixes thread
« Reply #2418 on: May 09, 2022, 04:08:00 AM »
Edit: With the risk of being punched in the face, i can not stress enough how this driver needs a sync_to_exact content, at least in Retroarch. It needs perfect smoothness..it' s just too good for anything less than that.

Hmmm, what do you mean, are you talking about the refresh rate ? I see pcb was measured at 60.024Hz, are you asking for it to be set at that value ? There is more or less a policy of not handling refresh rates beyond 60Hz in FBNeo (i believe because compatible screens are considered uncommon ? Or maybe some kind of directx blitter limitation in standalone ?) but maybe we could add some kind of kludge to allow it in the libretro port if retroarch handles this well ? Except if there are other technical reasons i'm not aware of ?

Offline bytestorm

  • Newbies
  • *
  • Posts: 12
  • Karma: +1/-0
Re: dink's FBN Development & Fixes thread
« Reply #2419 on: May 09, 2022, 04:31:20 AM »
holy smokey YES!!! Oh man, thanks for the cv1k news!!! IBARA here we go! Damn what a start on a monday.. reading these news WHOOho!
 :smilie: :biggrin:

Offline Tatsuya79

  • Newbies
  • *
  • Posts: 39
  • Karma: +2/-0
Re: dink's FBN Development & Fixes thread
« Reply #2420 on: May 09, 2022, 05:44:58 AM »
My measurements put input lag at 2 frames (mame is 3 in Retroarch for cv1000).

Input lag is the same now, it has been fixed for a couple of MAME versions.
Try updating your core (main MAME without date).

Offline el_rika

  • Jr. Member
  • **
  • Posts: 96
  • Karma: +7/-0
Re: dink's FBN Development & Fixes thread
« Reply #2421 on: May 09, 2022, 06:20:20 AM »
Hmmm, what do you mean, are you talking about the refresh rate ? I see pcb was measured at 60.024Hz, are you asking for it to be set at that value ? There is more or less a policy of not handling refresh rates beyond 60Hz in FBNeo (i believe because compatible screens are considered uncommon ? Or maybe some kind of directx blitter limitation in standalone ?) but maybe we could add some kind of kludge to allow it in the libretro port if retroarch handles this well ? Except if there are other technical reasons i'm not aware of ?

Retroarch seems to not be friends with high refresh rate screens (ex.160 hz). It always tends to produce the strangest results (wildly uneven frame pacing and stutters, which should actually happen to some extent, as 160 is not a multiple of any conventional arcade framerate).
However as strange as it sounds, the moment the game is locked/throttled to its original intended framerate (ex. 59.6 cps driver or 57.5 cave 1st gen or 60 for cv1000) at the core/driver level (the frontend seems to not be able to do such a good job), the smoothness is top notch. I don't know honestly why it works the way it does, but it works as long as the sync to original framerate is overriding the rest.

@Tatsuya
Yes, i know the recent mame cores have the extra frame eliminated, but in terms of using latest mame for cv1000, it's out of the question, as it became ~ 3 times slower than the older cores. All the recent work i know that's been done to the actual mame cv1000 driver has been to speed it up, so the massive regeession in performance it's a bit of a mistery to me, but it is what it is.


Offline Joaquim2020

  • Sr. Member
  • ****
  • Posts: 263
  • Karma: +4/-11
Re: dink's FBN Development & Fixes thread
« Reply #2422 on: May 09, 2022, 06:21:58 AM »
Hi dink please check hbmame for more additions.

Death Smiles with hidden elements and charather unlocked.

Dodonpachi & Knuckles.

Dodonpachi Saya Texture Type B. - No one made Saya texture appear in the beggining of the game yet, because it's to dificult to combine the texture to import it. If you check the original game you will find the textures are missing. If eventually someone made it. It will be great.

There is a nother 3 hacks, but i believe is not necessary.
« Last Edit: May 09, 2022, 06:23:37 AM by Joaquim2020 »

Offline barbudreadmon

  • Administrator
  • *****
  • Posts: 985
  • Karma: +56/-1
  • Helper
Re: dink's FBN Development & Fixes thread
« Reply #2423 on: May 09, 2022, 06:58:16 AM »
Retroarch seems to not be friends with high refresh rate screens (ex.160 hz). It always tends to produce the strangest results (wildly uneven frame pacing and stutters, which should actually happen to some extent, as 160 is not a multiple of any conventional arcade framerate).
However as strange as it sounds, the moment the game is locked/throttled to its original intended framerate (ex. 59.6 cps driver or 57.5 cave 1st gen or 60 for cv1000) at the core/driver level (the frontend seems to not be able to do such a good job), the smoothness is top notch. I don't know honestly why it works the way it does, but it works as long as the sync to original framerate is overriding the rest.

Hmmm so i'm still not sure what you are asking exactly here. Are you asking that those games stay throttled at 60Hz like they currently are ? Or are you asking for them to be throttled at 60.024Hz ?

Offline el_rika

  • Jr. Member
  • **
  • Posts: 96
  • Karma: +7/-0
Re: dink's FBN Development & Fixes thread
« Reply #2424 on: May 09, 2022, 08:34:21 AM »
Hmmm so i'm still not sure what you are asking exactly here. Are you asking that those games stay throttled at 60Hz like they currently are ? Or are you asking for them to be throttled at 60.024Hz ?

What i'm saying is that the core (or just this driver), would benefit from a throttle to native framerate as an on/off option (in this case lets round to 60) that would have absolute priority over the frontend Vsync settings (ex. if i'm playing SfZero3 and i have the throttled option checked in core settings, but i have the Retroarch refresh set at 60, the game will ignore Retroarch and go to native 59.6. Without the throttle option, it will automatically be run at 60 and the trouble of inconsistent frames, would start when playing in 160hz mode).
 Mame core has this exact same setting and it just works wonders.




Offline barbudreadmon

  • Administrator
  • *****
  • Posts: 985
  • Karma: +56/-1
  • Helper
Re: dink's FBN Development & Fixes thread
« Reply #2425 on: May 09, 2022, 09:05:33 AM »
What i'm saying is that the core (or just this driver), would benefit from a throttle to native framerate as an on/off option (in this case lets round to 60) that would have absolute priority over the frontend Vsync settings

Not gonna happen, if you want to fix a retroarch issue, fill the issue to the retroarch team. That kind of features goes against the libretro concept, would prevent libretro features from working properly, and the only reason it exists for the mame core is because this core wasn't properly libretroized.
« Last Edit: May 09, 2022, 09:18:46 AM by barbudreadmon »

Offline dink

  • Administrator
  • *****
  • Posts: 4648
  • Karma: +407/-1
  • pie? I nearly bought one!
Re: dink's FBN Development & Fixes thread
« Reply #2426 on: May 09, 2022, 09:13:02 AM »
Mushihimesama, at least in Retroarch android, has the clasic layer issues where some layers/elements are not displayed properly (ex. at the ship selection).
This is fixed by deleting the "game.cfg" before each run, though here it doesn't seem to work.

Can you explain this a little more, and give some good/bad pictures so I can see what to look for? Does it affect anything other than the ship selection screen?

I've tried current mame and mame 0.155, tried deleting the game file as you mentioned before, but, the ship selection screen always looks exactly the same for me across mame and fbneo (windows version) - I even checked pcb videos, and they all look alike.

A few hours ago I fixed a race condition with the threading, maybe this has something to do with it?  Can you make sure your core has this fix: eda8ae4
(9h ago from when I posted this)

best regards,
- dink
« Last Edit: May 09, 2022, 09:31:58 AM by dink »

Offline neokyo

  • New Member
  • *
  • Posts: 5
  • Karma: +0/-0
Re: dink's FBN Development & Fixes thread
« Reply #2427 on: May 09, 2022, 09:35:08 AM »
Thanks!!!! Incredible work!!!!

Offline el_rika

  • Jr. Member
  • **
  • Posts: 96
  • Karma: +7/-0
Re: dink's FBN Development & Fixes thread
« Reply #2428 on: May 09, 2022, 09:35:34 AM »
Ship selection:

https://ibb.co/LCFDrNQ
https://ibb.co/8B8Ffbn


Missing bullets and a couple of gui elements:

https://ibb.co/0mz3Y1D
https://ibb.co/pdf1mpk

Seems that somtimes there are other layers/elements missing.
Deleting mushisam.fs partially fixes stuff, but haven't tested more than a few times.

So the code is based on 0.155? That's the one i've been using.

Offline dink

  • Administrator
  • *****
  • Posts: 4648
  • Karma: +407/-1
  • pie? I nearly bought one!
Re: dink's FBN Development & Fixes thread
« Reply #2429 on: May 09, 2022, 09:45:18 AM »
el_rika, the pcb video looks similar to the "broken" version, at least on the ship selection - your thoughts?
https://www.youtube.com/watch?v=dVvKqJrU7N0
some parts are from 0.155 (blitter, cpu), some from latest (devices)

best regards,
- dink
« Last Edit: May 09, 2022, 09:46:26 AM by dink »