4.3 KiB
Resources & Data
This document provides a high-level explanation of how Prosperon handles resource loading, module discovery, and general file I/O. It is intended to give you insight into the concepts and architecture behind these systems, without detailing individual function calls.
1. Module Loading and Discovery
Prosperon uses a set of search paths to locate modules. Each path in this list is consulted in order, and the first matching module file is loaded.
- Paths Array: The engine maintains a list of directories in which it looks for modules. Developers can add or remove entries from this list, controlling where the engine will search.
- Extension Matching: When asked to load a particular module by name, Prosperon tries recognized file extensions until it finds a suitable file. This means you do not have to specify the file’s extension; the engine infers it from a known set of possibilities.
- Shadowing: If your local module happens to have the same name as a built-in module, and is found first in the search path, it overrides the built-in. This can be used to replace or augment default behaviors.
Prosperon caches each loaded module so it is only created once. Subsequent requests for the same module return the same instance.
2. Resource System
Beyond modules, Prosperon categorizes other assets (images, sounds, fonts, etc.) by common file extensions.
- Extension Lists: Internally, there are sets of recognized extensions for each resource type (e.g., for images or sound files). These lists drive how Prosperon locates the actual file you intended to load.
- Canonical Paths: Whenever a resource is identified, its path is transformed into a “real” path on the host filesystem. This ensures the engine is working with unambiguous directory references, even if virtual or mounted paths are involved.
- Consistency: This approach keeps naming consistent across different platforms, so developers don’t need to worry about exact extension casing or platform-specific directory structures.
3. High-Level I/O Flow
Prosperon’s I/O subsystem provides a unified interface for reading and writing files, managing directories, and working with mounted filesystems or archives. While the specific operations vary (creating directories, checking file existence, enumerating directories, etc.), they are all handled through a single engine-provided interface. Key points include:
- Mounting & Write Paths: Prosperon can mount external directories or archives into its virtual filesystem, and can direct all “write” operations to a particular directory.
- Metadata & Enumeration: The engine tracks file metadata and can list contents of directories (including optional recursion into subdirectories).
- Wildcard & Glob Patterns: Certain patterns can be used to include or exclude files from an operation, helping developers filter out files easily.
By keeping resource lookups and filesystem interactions centralized, Prosperon’s I/O system fosters portability across different environments and platforms.
4. Integration in the Engine
From the moment Prosperon starts up, it initializes the module and resource systems. This guarantees that:
- Core Modules (e.g., for rendering or audio) are found in known paths.
- Developer-Defined Modules are discovered if they are placed in the search paths configured by the engine.
- Resource Operations (like finding the correct variant of an image or script) are uniform, relying on known extension lists and standardized directory lookups.
Since everything is cached and resolved through the same system, developers can easily control how their projects load assets, override default modules, or customize file storage locations, without needing to replicate or reinvent these mechanisms.
5. Summary
Overall, Prosperon’s module system and resource loader work together to provide a flexible, extensible approach for organizing a project’s code and data. By adjusting the search paths and extension lists, developers can adapt the engine to a wide variety of use cases—while the I/O subsystem ensures that common file management patterns (mounting, enumerating, reading, and writing) all behave in a consistent manner across platforms and deployment scenarios.