[Another series of incomprehensible ramblings until codified in the spec]
Context
Planned target min spec for Reloaded-III is somewhere along the lines of:
I can hypothetically mod an OG XBOX game with this.
The XBOX notably has 64M of total RAM, with the next console (GCN) clocking in at 43MiB of total memory between all components. Therefore, it is assumed that for multi-platform titles, the XBOX probably has some RAM to spare.
With that in mind I consider said target spec to be 'it can run some basic mods with less than 2MB of RAM used'.
Stretch goal is 'it can run with <0.5MB RAM', to make it embeddable in 6th gen game titles. That is very ambitious, it may be possible, but I won't count on it.
Note:
This does not explicitly mean 'Sewer will port Reloaded to 6th gen consoles'.
In fact have no plans of doing so. It simply means, the target spec is to make a port to something as low spec as a 6th gen console possible. (It seems cooler than saying 'make it work on microcontroller')
In practice, the Reloaded model of small mods with dependencies isn't super suited for platforms without an OS, as lack of access to a shared libc means a lot of code duplication.
Requirements
Lightweight dependencies (no text formats).
Optional features. (Certain loader features should be able to be compiled out if unnecessary on given platform)
Mod Settings Serialization
The server, which configures the mods should be able to serialize to a binary format (opt in supported by mods) which has minimal code size and maximal parsing speed.
Here is an arbitrary example of such format:
numitems: u16
item[numItems]
Where Item is:
key: u16
value: u8/u16/u32/u64
Type of values for each key is declared inside separate metadata file which contains all known settings. The purpose of the key is to allow for versioning. For example, if a field is removed, it will be ignored, as the mod will no longer read a field with that 'key'.
Minimal Hooks Backend
reloaded-hooks-rs is expected to weigh around 300kB in code!! This is more than the loader itself is expected to weigh (~100kB tops).
For X86 targets like Xbox, it will be necessary to create a more minimal version of Iced_x86 for reloaded-hooks-rs. This can be achieved by making various instruction sets optional (toggleable).
Alternatively, we do a self rolled minimal backend with very limited code rewriting support, like detours. We could self-roll our own JitX86 (which I plan to do at some point anyway) and for code rewriting, use detours as a backend.
Binary format for Loader Config
Runtime information for loader such as:
Which mods to load
Mod locations
Mod metadata
Will need to use a binary file to save on code size.
This is planned to reduce startup times, as a merged file is needed to reduce I/O overhead. So no special accomodations needed here.
[Another series of incomprehensible ramblings until codified in the spec]
Context
Planned target min spec for Reloaded-III is somewhere along the lines of:
The XBOX notably has 64M of total RAM, with the next console (GCN) clocking in at 43MiB of total memory between all components. Therefore, it is assumed that for multi-platform titles, the XBOX probably has some RAM to spare.
With that in mind I consider said target spec to be 'it can run some basic mods with less than 2MB of RAM used'.
Stretch goal is 'it can run with <0.5MB RAM', to make it embeddable in 6th gen game titles. That is very ambitious, it may be possible, but I won't count on it.
Note:
This does not explicitly mean 'Sewer will port Reloaded to 6th gen consoles'.
In fact have no plans of doing so. It simply means, the target spec is to make a port to something as low spec as a 6th gen console possible. (It seems cooler than saying 'make it work on microcontroller')
In practice, the Reloaded model of small mods with dependencies isn't super suited for platforms without an OS, as lack of access to a shared libc means a lot of code duplication.
Requirements
Mod Settings Serialization
The server, which configures the mods should be able to serialize to a binary format (opt in supported by mods) which has minimal code size and maximal parsing speed.
Here is an arbitrary example of such format:
Where
Item
is:Type of values for each key is declared inside separate metadata file which contains all known settings. The purpose of the
key
is to allow for versioning. For example, if a field is removed, it will be ignored, as the mod will no longer read a field with that 'key'.Minimal Hooks Backend
reloaded-hooks-rs is expected to weigh around 300kB in code!! This is more than the loader itself is expected to weigh (~100kB tops).
For X86 targets like Xbox, it will be necessary to create a more minimal version of Iced_x86 for reloaded-hooks-rs. This can be achieved by making various instruction sets optional (toggleable).
Alternatively, we do a self rolled minimal backend with very limited code rewriting support, like detours. We could self-roll our own JitX86 (which I plan to do at some point anyway) and for code rewriting, use detours as a backend.
Binary format for Loader Config
Runtime information for loader such as:
Will need to use a binary file to save on code size. This is planned to reduce startup times, as a merged file is needed to reduce I/O overhead. So no special accomodations needed here.