Goodbye fbalpha, welcome fbneo

Darksavior

@dodonpachi When troubleshooting always revert to retropie's defaults. That means rewind is off and threaded video is on.

Riverstorm

@barbudreadmon - I don't if this is a good spot to post a DAT question so just let me know.

I combed through the DAT thoroughly and could only find a few games that stood out as potentially incorrect. It's basically the games that prefix vs such as vscastlevania. There are around 31 that I could find that have an aspect ratio of 256:224. Should these be 4:3? There's an example below from the DAT.

<video type="raster" orientation="horizontal" width="256" height="224" aspectx="256" aspecty="224"/>

Also by the way thanks for adding this additional information. It's really quite useful! :)

barbudreadmon

@Riverstorm NES has a PAR (pixel aspect ratio) of 1:1, hence a DAR (display aspect ratio) of width:height (= 256:224 = 8:7). I might be wrong but i believe NES-based arcade boards have the same ratios.

Ashpool

@barbudreadmon Ok, SAR vs./to PAR/DAR Calculations are sometimes frustrating/sometimes even may appear somewhat esoteric [1], e.g.: Correct Geometry - Aspect Ratio for different systems, Display information vs screen dumps .

I would wish that at least the arcade xml/dat files, even the ones for current MAME, would stick to the old-style (or as FBNeo still does) of providing aspectx and aspecty together with the display/screen information. Mame2003, and Mame2003Plus (guess still leftovers from the original Mame2003 info) datfiles are providing aspectx=4, apecty=3 for horizontal VS. titles per screen (e.g. for VS. Baseball that would be 8:3) (and vice versa for Vertical-Games).
If you are sure the information provided in the FBNeo xml is correct, then maybe it is time to update mame2k3+ (if it would be just the datfile, i would offer my help (over in the mame2k3+ threat) in doing it, but as the (driver?)-source(s) must be modified I think that is beyond my ability and maybe that could also mess up other things?).

P.S.: I guess not, but does anyone knows, if there is a way to derive the correct DAR from the Screens modline Information provided in the (mame-)datfile?

1: Even if the basics of how to calculate the third from 2 known is simpel but to get 2 fixed datums for a certain game/system may be complicated (especially to filter out legend/myth from spec. and fact) - sigh.

Riverstorm

@barbudreadmon - I appreciate that information. I was a bit tired last night and missed the 8:7. I like to see it condensed but I think that should work out fine for calculations. I thought it was a simple error but I see it's correct.

I was hoping you'd entertain one more question out of a lack of knowledge and for posterity. Why aren't they displayed as the "prime" condensed ratio as in 8:7 vs 256:224? Is it just the way the raw information is pulled from the source?

@Ashpool - Yes you're correct that m3plus does do that. A quick pull from vshoot.


<video screen="raster" orientation="horizontal" width="288" height="224" aspectx="4" aspecty="3" refresh="60.000000"/>

There is a small group of guys that work on m3plus (arcadez, mahoney, misty, grant, mark plus many many miscellaneous contributors) that are always looking for ways to improve the core. If you open a request on Github they would probably take a look. They auto generate the DAT from source within games so it would probably just be tweaking the code potentially, or you could be right too that it's an era specific issue of the code from way back when.

https://github.com/libretro/mame2003-plus-libretro

I don't want to go down a rabbit hole here as I know it's easy with these types of discussions and it's probably not the thread for a long discussion but wouldn't you need to know something about your target display to calculate a DAR that makes the game look correct on your display or I might not know what you're trying to achieve with your calculations.

Ashpool

@Riverstorm said in Goodbye fbalpha, welcome fbneo:

I don't want to go down a rabbit hole here as I know it's easy with these types of discussions and it's probably not the thread for a long discussion

You're right, it is a rabbit hole (are there any drinks or fungi involved?) :/ And as CRTs had a few screws you could turn to expand/shrink the view, which is a user action/turn, and because of that - it is impossible to say that even on the real machines the Aspect was right/set in stone...

Yeah, that is a bottomless hole to dive into...

barbudreadmon

@Ashpool said in Goodbye fbalpha, welcome fbneo:

If you are sure the information provided in the FBNeo xml is correct

I'm not sure of anything, we used this value because the nintendo VS is a NES so it makes sense to think it used the same aspect ratio.

@Riverstorm said in Goodbye fbalpha, welcome fbneo:

Is it just the way the raw information is pulled from the source?

Yes, the driver was hardcoded with width:height for aspect ratio instead of 8:7

Ashpool

@barbudreadmon said in Goodbye fbalpha, welcome fbneo:

I'm not sure of anything, we used this value because the nintendo VS is a NES so it makes sense to think it used the same aspect ratio.

Me neither, but FYI the first link I cited in the Mame2k3+-threat as well as lrfceum are refering to 8:7 as PAR for the NES, not DAR ... so who knows, sigh...

Riverstorm

@barbudreadmon - I was pulling info from the DAT with some python scripts and just happened upon those game ratios looking a tad odd and thought I would run it by you. I appreciate you taking the time to look at it, it is very much appreciated it!

barbudreadmon

And mesen which is supposed to be the best nes emulator as far as accuracy is concerned is using neither 4:3 nor 8:7, and i don't even understand where this one is coming from.
It definitely looks like a rabbit hole to me, so we'll stay with the current default aspect ratio. Anyway the user can change it to match his taste, either through retroarch settings or through core options (in dipswitches)

sleve_mcdichael

In Space Invaders (invaders.zip) there's a dipswitch setting (enabled by default?) that simulates the colored overlay of the original cabs, turning the bottom portion green where the player's ship and shields are.

Battle Zone (bzone.zip) used a similar colored overlay over a monochrome display, with the top 20% tinted red and the remainder tinted green. In lr-mame2003 it's colored this way already by default but in lr-fbneo it's just displayed in monochrome (white) and I didn't see any way to enable this color overlay in bzone as there is in invaders; is something there, that I've missed or, if not, is this a place I could make such a request?

barbudreadmon

@sleve_mcdichael sure, i'll try to do that soon

barbudreadmon

@sleve_mcdichael the method i used to implement colors in space invaders is not gonna work here, we probably need a real color overlay system in our framework for this one, implementing this will probably take some time and i'm first gonna need advice from our main devs.

barbudreadmon

@sleve_mcdichael bzone has colors now

sleve_mcdichael

@barbudreadmon cheers, thanks!

WeirdH

@barbudreadmon I just found something that might be a bug. Don't know if this is the right place to report, as MAME2003-Plus seems to show the same behavior:

In mpang, when I use the service menu to set coin options to '2 chuters multi', the game plays fine at first, but upon a game over, it shows a glitched (incomplete) screen and softlocks.

The MAME emulation appears to be marked as 'status good' on arcadeitalia, but I don't know if that status takes into account any other settings than default.

barbudreadmon

@WeirdH Did you check if MAME (current) has the same issue ? Tbh, it's a bit weird that mame2003 has the same issue, since mame's and finalburn's cp2 emulation code aren't based on each other, it might be an issue happening on real cabinet (?).

Ashpool

@barbudreadmon Do you have any idea why it is that clrmamepro is building a (neogeo) romset with zero roms reported as missing whence building a non-merged set, but is, when using the option of separate bios files, removing a few roms from the set and then reports them as missing?

miss list for the non-merged build:

 You are missing 0 of 524 known FinalBurn Neo v1.0.0.03 Neogeo Games sets (+ BIOS sets)

and then for the non-merged + separate bios build/scann

 You are missing 14 of 524 known FinalBurn Neo v1.0.0.03 Neogeo Games sets (+ BIOS sets)

19yy
cabalng
cnbe2018
hypernoid
kof97ip
looptris
mslug3x
mslug4lw
mslug5f
mslug5w
ngmontst
santaball
teot
xenocrisis

barbudreadmon

@Ashpool It looks like a clrmamepro bug to me, as far as i can tell there is nothing wrong with our dat file.

The only thing that comes to mind when looking at this list of games is that none of them would be available if you are rebuilding from a MAME set (homebrews and hacks). Aside from that, there is nothing making those games "stand-offish", there are dozens of romsets with similar circumstances that aren't listed here.

Ashpool

@barbudreadmon said in Goodbye fbalpha, welcome fbneo:

It looks like a clrmamepro bug to me

feared so :| Nevertheless, thank you for looking into it!