MonoAGS components system and FileSystem.

Started by Monsieur OUXX, Wed 20/03/2019 12:37:54

Previous topic - Next topic

Monsieur OUXX

I'm fiddling with the ResourceSelector branch and I've noticed how FilesView has a private IFileSystem. It's supposed to be populated by FileView's constructor : FilesView(IFileSystem files, ...).
However I can't seem to understand where and how this constructor gets called. Is it with _filesView = rightPanel.AddComponent<FilesView>();?

The reason why I want to know this is because I want to know how the FileSystem is decided. In the master branch, the Resources system has stuff like this :
game.Factory.Resources.ResourcePacks.Add(new ResourcePack(new FileSystemResourcePack(AGSGame.Device.FileSystem, AGSGame.Device.Assemblies.EntryAssembly), 0));
There, the FileSystem is passed explicitly. It's done twice: One for the mobile file system, and one for the Desktop file system.

But then how does it work with FilesView? Why and how is the FileSystem chosen implicitly there?
 

tzachs

When you call AddComponent<> the engine uses the Resolver class to resolve all the dependencies that the component has in its constructor.
The resolver itself it is tied to the device's file system by default. You can, however, override it with your own file system implementation if you want. To do that, you'll create your own implementation of the IFileSystem interface and then tell the resolver to use your implementation instead. Here's an example of how you'd do something like that.

If you want, you can also create the component yourself and pass a file system explicitly, and then call AddComponent with your component:
Code: csharp

var view = new FilesView(AGSGame.Device.FileSystem, ...);
_filesView = rightPanel.AddComponent(view);


p.s The files view is not a complete implementation (I stopped mid-development as I started questioning some design choices I made- so this goes to the back-burner until I figure out what's the next step for the editor).

Quote from: Monsieur OUXX on Wed 20/03/2019 12:37:54
It's done twice: One for the mobile file system, and one for the Desktop file system.
Not sure what you mean here. The file system is passed once afaik.

Monsieur OUXX

Quote from: tzachs on Wed 20/03/2019 13:18:36
Quote from: Monsieur OUXX on Wed 20/03/2019 12:37:54
It's done twice: One for the mobile file system, and one for the Desktop file system.
Not sure what you mean here. The file system is passed once afaik.

game.Factory.Resources.ResourcePacks.Add(new ResourcePack(new FileSystemResourcePack(AGSGame.Device.FileSystem, AGSGame.Device.Assemblies.EntryAssembly), 0));
game.Factory.Resources.ResourcePacks.Add(new ResourcePack(new EmbeddedResourcesPack(AGSGame.Device.Assemblies.EntryAssembly, CustomAssemblyName), 1));
 

tzachs

Ah, well, that's not "one for mobile, one for desktop". That's one for loading from the file system and one for loading resources embedded in the project (which is not necessarily for mobile -> most developers would probably prefer to embed their assets on desktop too, so they won't need to distribute all of their assets in separate files).

Crimson Wizard

#4
Quote from: tzachs on Thu 21/03/2019 18:34:34most developers would probably prefer to embed their assets on desktop too, so they won't need to distribute all of their assets in separate files.

In regards to AGS developers were constantly complaining that they have to distribute it as one big file, because it forces users to redownload gygabytes of data to fix 1 bug.

(On other hand AGS supports reading smaller files from disk, but they ignore this for years, so idk.)

If there were a tool for automated repacking of the embedded main file that could solve the issue partially (not sure if that would work with Steam's auto updates).

eri0o

Steam supports binary patching, so it usually can make the downloads works with one big file, providing it has some logic - my experience with ags is the diff is rarely big, a new room hits 3 MB and not 900 MB when updating... But for other systems, if something needs to be updated, they DON'T support binary patching, so separate files are preferable.

tzachs

Quote from: Crimson Wizard on Mon 25/03/2019 19:58:20
In regards to AGS developers were constantly complaining that they have to distribute it as one big file, because it forces users to redownload gygabytes of data to fix 1 bug.

Fair, though I was actually talking about the difference between having the assets embedded in something (be it the executable, or "asset pack files") and just distributing all of the assets in their unchanged forms (i.e having your bg.png appear as bg.png in the distributed folder) so that users have the ability to change the background image of your game (for example). I imagine most developers would not want that, though it might be appealing to a few (to allow for very simple "modding").

SMF spam blocked by CleanTalk