Optimization

RRPs have many benefits, but they also have flaws. The biggest issue with RRPs is that you are generating the assets as they are requested, which means to load a resource, you need to run some code, instead of reading a pre-made asset from the jar itself. However, RRP uses this to its advantage.

By default, the game takes quite a bit to start up, and it takes quite a bit to even get to the stage where it will start loading textures, we can use this valuable time to generate any assets that don't rely on other mods.

RRP adds an entry point that allows mods to pre-generate their assets before the assets are even asked for. This entry point is the RRPPreGenEntrypoint, this is called off thread and at preLaunch. To take advantage of this system, implement the RRPPreGenEntrypoint class, add the your entry point to your fabric.mod.json

"entrypoints": {
   // your other entrypoints
   "rrp:pregen": [
      "the.fully.qualified.name.of.your.Class"
   ]
}

In YourClass#register, you can pre-generate any assets you can here. This is where RRP shines, turning it's greatest weakness into a powerful advantage, this may be faster than normal assets, because it saves on I/O! This way, your assets are already in memory by the time Minecraft asks for it. Technically it could be even faster by making RRP the highest priority resource pack, and I am considering allowing RRPs to override mod assets but not normal resource pack assets.

However, one of the advantages RRPs in that they allow you to generate assets dynamically so you can create items and blocks when certain mods are loaded, and when certain items are registered. But these can't always be pre-generated (nor premade like normal assets). In this case, we can still improve our load times by creating assets asynchronously, and so there are async methods in RRP, like addAsyncTexture or addAsyncResource.