OOVPA sorting - Cxbx-Reloaded/Cxbx-Reloaded GitHub Wiki

In the PatrickvL OOVPA_Sorting branch, I'm planning to merge together all versions of each library specific OOVPA database (like D3D, DSOUND, XG, etc) into one library specific OOVPA database.

Each library specific OOVPA database will contain OOVPA registrations for all OOVPA's we have for that library.

Each OOVPA registration is done using a macro called REGISTER_OOVPA. It's arguments are:

  • (symbol, version, type).

When all these occurrences are sorted, all symbols end up together, in incremental order of version.

This makes it very easy to manually spot and prevent duplicates.

The symbol argument is used for 3 purposes:

  1. It indicates the OOVPA to register (excluding the "OOVPA_" prefix)
  2. It indicates the patch to register (excluding the "EmuPatch_" prefix)
  3. When debugging, this string is written to the output. Since their prefixes are the only difference between an OOVPA name and a patch name that are to be combined, all patches and OOVPA must use this strict naming convention. (OOVPA names must also have a version suffix.)

The version argument must indicate the exact XDK version the OOVPA is based upon.

Some symbols stay the same across all XDK versions, so require only one OOVPA version registration.

Other symbols differ between XDK versions and thus require multiple registrations.

If a symbol returns to a prior form, use an aliased OOVPA.

The type argument forwards the declaration to type-specific macros, currently the possible types are:

  • PATCH, for registering an OOVPA with a patch.
  • LTCG, for registering a patch that originates from a (D3D) LTCG database.
  • XREF, for registering an OOVPA without a patch.
  • DISABLED, used for experimentally disabling OOVPA xrefs or patches.
  • ALIAS, for using an alternative OOVPA definition, while keeping the same patch for the mentioned symbol.

(Registrations of type ALIAS require a fourth argument, being the name of the alternative OOVPA which must have an appendage to the base function name, like FunctionB)

An alias OOVPA registration type is not the same as an OOVPA alias declaration.

An OOVPA alias declaration is simply one line, formed like this:

#define name_3 name_1

  • Where name is the OOVPA name, like D3D_CreateDevice.
  • Where 3 represents the new version for which the OOVPA must be used.
  • Where 1 represents the old OOVPA version to reuse.

An example:

#define OOVPA_D3D_CreateDevice_5788 OOVPA_D3D_CreateDevice_4344

This introduces a new version 5788 OOVPA for D3D_CreateDevice, based on the 4344 version OOVPA for that same function.

Summarizing:

  • All symbols must use consistent names.
  • Registrations must be kept sorted.
  • Never duplicate OOVPAs. Use aliases instead.