Open intvsteve opened 5 years ago
There is currently work underway that has added ROM format identification via System.IO.Stream.
In all practical purposes, actual usage of ROMs themselves requires them to be distinct on-disk entities:
Perhaps tweaking the memo system to accept a 'name' and a stream would be another way to approach things. FileStreams would pass the file path (perhaps normalized in some way), while resource-based approaches could pass the resource name and the stream.
That could possibly remove the complexity of all of the quasi-storage-access scheme work in the test code, which is essentially doing what I just described. :P
The
Rom
base class presently only exposes a file-oriented API for creating ROM instances. There is a great deal of infrastructure built around this, including the Memo-based caches.When unit tests were created, a great deal of effort was required to work around the limitations of using a Portable Class Library, which requires an
IStorageAccess
interface, as direct access to file system APIs is not available.As work on archive support progresses, it's become clear that exposing a Stream-based API would be immensely useful - and perhaps would be a substantial simplification, if it's not going to be an insane amount of work.
To undertake this requires assessing how much work is required to curb the reliance on
IStorageAccess
, or at least allow the Memo system some greater flexibility in terms of decoupling it fromIStorageAccess
.An alternative would be to extend the existing
IStorageAccess
implementation to instead have awareness of archives and render them essentially invisible to INTV.Core.Perhaps both can be done, in that basic ROM format identification can be achieved purely via a Stream API and sidestep the memo system.