resource-system-that-does-not-suck.md

• Global manifest that is always in memory.
  • Stores indices and metadata.
  • Read in at start.
    • Or embedded into executable as R/W.
      • Further trickery can be used to embedded resources as well.
        • Maps well to Windows + Mac + iOS + Android.
  • Mutated at runtime.
    • There are no dynamic allocations for management.
  • Resources have sequential identifiers.
    • Assigned through an "append only" database.
      • Stable across builds unless you lose the database.
      • Built on top of SQLite3.
    • Reserved ranges can be used for patches.
    • Placeholders can be used for handy aliases.
      • Localization of content.
  • Resources are typed, versioned, and named.
    • Names are stripped when shipping.
      • Prevent leaks caused by data mining.
      • Also, reduces memory usage.
    • Look up by type and name goes through lookaside hash table.
      • Code references are hashed at compile-time if possible.
  • Resources have three streams.
    • First is BF_RESOURCE_STREAM_MEMORY, which is copied into memory.
      • This is fixed up in a type specific manner after which the resource is online.
      • Basically read and cast. About as fast as you can get.
    • Second is BF_RESOURCE_STREAM_DEMAND, which is streamed on demand.
      • Notably used for textures, geometry, and shaders.
    • Third is BF_RESOURCE_STREAM_OUT_OF_BAND, which is additional information that's only available during development.
      • Mostly used for debugging.
  • Resources loading is straight forward.
    • Starts by reading BF_RESOURCE_STREAM_MEMORY into memory.
      • If versions are incompatible then the data is hotfixed.
        • Some additional space is reserved.
    • Then a pointer to the memory is passed to a type-specific callback.
      • This does any processing to bring it online.
        • Thus any necessary space for the runtime is built into the structures.
          • For example, space for GLuint.
    • Some additional callbacks are fired, mostly for systems to stream.
      • Just tracks lifecycle of resources.
  • Resources can be pinned.
    • Will always be ready to use.
  • Resources can be overridden.
    • Pointer to another resource.
    • Hot-reloading piggy backs off of this.
  • Patches are overlayed onto the two indices/tables.
    • Automatically applied if BF_PATCH_AUTO flag is set.
    • Replaces most fields.
    • Can be gated however you want.
      • Driven at a higher level.
      • Usually gated by entitlement, i.e. for downloadable content.