search

libretro-mirrors / libretro-arb

For proposed improvements to libretro API.
8 stars 2 forks source link

Core-side unique id / checksum calculation #4

Open heuripedes opened 10 years ago

heuripedes commented 10 years ago

It would be nice if the libretro api had a way to allow the frontend to query for a string that could uniquely identify the content.

Example usage:

Alcaro commented 10 years ago

We could read the file ourself even if need_fullpath is set, but reading and hashing a 650MB ISO would take a while, and the base file could refer to a dozen of other files (pretty sure CUE files do something funny, and bsnes BML files could have same content for different ROMs too). Definitely an interesting idea.

ramapcsx2 commented 9 years ago

The ISO reading can be done faster by looking inside the container and hashing just some identifiable object there, like the main executable.

Alcaro commented 9 years ago

So you're proposing that the frontend learns how to read every disc file system in existence? Because that's nowhere near realistic, and even if it was, the point of libretro is that we can create a new core without reworking the front.

A better idea would be to hash a few carefully chosen megabytes from the file. That would make different files show up different (even J/E/U should have a few bytes shifted which will make everything show up differently, alternatively use the RAM differently which will show up once we hash a chunk of code), with the exception of romhacks, and almost all cheats work for hacked ROMs anyways.

ramapcsx2 commented 9 years ago

Yea, that's right. Your suggestion would be better at this approach. Then again, there's still the problem of even trying to compile a list of every content ever created..

heuripedes commented 9 years ago

@Alcaro Hashing a piece of data from the ISO does create unique ids but it disallows the frontend to store a single .srm for multi-file content, if it were to be implemented. @ramapcsx2 In the case of roms, there's http://datomatic.no-intro.org/ which can provide file hashes and internal rom checksums.

ramapcsx2 commented 9 years ago

So it appears this function could be done and could be useful, but it needs to approach content in different ways. Hashing it all is good and preferable for small content. It's fast and there are various known good file hashes available to identify it. For larger content it gets complicated. I would still implement an image reader to identify CD based content. Most console games (if not all) have identifiying files in them that can be looked up in already available databases. (For example: PSX and PS2 via the Sony catalog number). Unique, new content that was made for libretro can have an ID requirement in the API.

heuripedes commented 9 years ago

The proposal here is to free the frontend from the "burden" of having to uniquely identify something it doesn't know anything about. For roms, regardless of the media, the emulator core would just return a string containing the internal checksum, game id or catalog number (perhaps with a prefix/namespace to avoid conflicts.) For cores can't identify the content, the frontend would fallback to the current behavior.

I'm against adding a image reader dependency to the frontend.

edit: I'm against requiring the frontend to have a image reader.