intvsteve
commented
5 years ago Looks like doing this the least disruptive way will involve creating a better ROM file location system than a simple file path. Going to see about an implicitly convertible struct that has the "name" (formerly, path) and IStorageAccess bundled together.
The idea is to be able to have, say, a 'resource' storage access, a 'compressed archive' storage access, and a typical 'file system' storage access. In theory then you create one of these for specific use cases and pass it along to the ROM API layer and it Just Works (TM). The FileMemo<T> type could drop its cached StorageAccess, hopefully. The new system, via implicit conversion operators, could then hopefully be introduced piecemeal rather than making a hugely disruptive change to the API layers.
Doing this has some different facets, which may need to split into separate projects.
The danger of discovery is that drilling into arbitrarily large .zip / et. al. files could place a heavy performance burden on the system w.r.t. memory and speed. Some considerations to mitigate: a) Gather list of potential archives and prompt to select which ones to search b) User-defined option to restrict size (default to something reasonable, e.g. 128MB)
Browsing for things like "browse and play" may involve different work on different platforms. Perhaps the native file dialog in Windows integrates browsing into known archive types already (or maybe only .zip). If so, yay! If not, then it's a slog to write a multi-platform archive browsing dialog.