Difference between revisions of "Auto detection"

Jump to navigation Jump to search
1,808 bytes added ,  17:34, 3 March 2006
Some ramblings on how to improve the SubstResFileNames system
(→‎Building blocks: Explain how 'detect' would be implemented)
(Some ramblings on how to improve the SubstResFileNames system)
Line 68: Line 68:
# If the size of <code>gameList</code> does not equal (i.e. no unique match was found), abort with an error
# If the size of <code>gameList</code> does not equal (i.e. no unique match was found), abort with an error
# Finally, create a suitable Engine instance
# Finally, create a suitable Engine instance
Note: I am not yet sure how to handle target_md5 here. Maybe we don't need it anymore, maybe it could be passed as a hint to <code>detectGames</code>.
Note: I am not yet sure how to handle target_md5 here. Maybe we don't need it anymore, maybe it could be passed as a hint to <code> detectGames </code>.




The 'detect' part should be pretty obvious now:  
=== File name handling (revising the SubstResFileNames system) ===
# Invoke <code>detectGames</code> to obtain <code>gameList</code>
The current file name substitution system, built around SubstResFileNames, tries to solve multiple goals at once: (TODO: Give a list here). This makes some things more complicated than necessary. Also, it can't do all that one would like to be able to do... for example, when used during detection, it should be possible to deduce language/platform information from those filenames (useful for the detector).
# Compute a new list from that, keeping only the gameid, platform, language values
 
# Remove any duplicates from that new list (since we drop some information, some entries may suddently become identical)
Also, there are some efficency issues: If we search through the full list of file name subsitutions for each game, we essentially arrive at a quadratical run time.
# Return this list to the caller
 
Taking a closer look at <code>substResFileNameTable</code>, one quickly notices that almost all entries in there really map a gameid to either a full fixed file name (usually for mac versions), or to a "pattern" filename (think of  GAME.LA0, GAME.LA1, GAME.LA2 etc.). The exception to this is the code to detect MM/Zak variants for NES and C64. If we add dedicated code for the latter, the table finally is reduced to what I just described: A map from gameids to file name "patterns".
 
Now, take a look at <code>ScummEngine::openRoom</code>. It actually also encodes a lot of knowledge about SCUMM filenames. This is duplicated knowledge. Instead of first putting effort into generating a "good" filename, and then putting more effort into trying to substitute that file name, and doing that over and over again -- wouldn't it be much better to check once which kinds of filenames are needed, and then always generate the right names immediately? In particular, the 'create' function already has to determine the file substitution required for that game... why throw that away?


=== File name handling (revising the SubstResFileNames system) ===
Hence the idea is born to unify the knowledge / data found in <code>ScummEngine::openRoom</code> and <code>substResFileNameTable</code> into a single mechanism. This is why I wrote above that <code>detectGames</code> should return a SubstResFileNames (or equivalent recorde). We already pass that to the ScummEngine object. We simply extend this to allow to be used directly by <code>ScummEngine::openRoom</code> (and of course other methods) to generate suitable filenames from given data.
TODO
 
TODO: Finish this


== Standardized descriptions ==
== Standardized descriptions ==
1,079

edits

Navigation menu