Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CannonBall Complete Set Added #1101

Closed
wants to merge 1 commit into from
Closed

Conversation

LodanZark
Copy link
Contributor

Files list based on the official git: https://github.com/djyt/cannonball/blob/master/roms/roms.txt

PS: epr-10381.132, epr-10381a.132 and epr-10381b.32 has the exact same hash, the explanation why here:
djyt/cannonball@680b524#commitcomment-43242378

Files list based on the official git:  https://github.com/djyt/cannonball/blob/master/roms/roms.txt

PS: epr-10381.132, epr-10381a.132 and epr-10381b.32 has the exact same hash, the explanation why here: 
djyt/cannonball@680b524#commitcomment-43242378
@RobLoach
Copy link
Member

RobLoach commented Oct 14, 2020

Thanks a lot for taking a look at this. Not sure about having multiple files listed. RetroArch and the database take one game -> one rom approach, which lets the menu know which file to display in the playlist. The file in the playlist is what will be run through the core.

Ends up being the same as...

retroarch -L cannonball.so path/to/epr-10187.88

Alternatively, we could index a file that we guarantee will always be there.

The other place where this is indexed is over at https://github.com/parkerlreed/libretro-super/blob/master/dist/info/cannonball_libretro.info . It will cross-reference the .88 file extension.

@LodanZark
Copy link
Contributor Author

Yeah, makes all sense, if cannonball core would accept compressed files, would make things easier :S

@RobLoach
Copy link
Member

if cannonball core would accept compressed files

This has been on my wishlist FOREVER, and here's a related issue for it: libretro/RetroArch#4331

@LodanZark
Copy link
Contributor Author

Adding this filename and hashes to the core info would make the trick, but at the sametime it would lose the ability to curate the roms through rom managers like clrmamepro and other alternatives, I will let you decide what it's the best option ;)

@RobLoach
Copy link
Member

Just having one is optimal for the RetroArch database. Could keep the entire set elsewhere though! If we have multiple in there, I'm unsure how libretro-build-database.sh would respond. It might end up listing a bunch of the same entries in the playlist, which would seem silly.

This could live in a dat in the source repository or something?

@RobLoach RobLoach closed this Oct 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants