ShuriZma
/
Cxbx-Reloaded
mirror of https://github.com/Cxbx-Reloaded/Cxbx-Reloaded.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Formatting, remove whitespace

Margen67 2021-06-11 13:23:28 -10:00
parent 355cd30beb
commit 629ee417a6
1 changed files with 6 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
OOVPA-sorting.md

@ -2,9 +2,7 @@ In the PatrickvL OOVPA_Sorting branch, I'm planning to merge together all versio
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:
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.
@ -20,22 +18,17 @@ Since their prefixes are the only difference between an OOVPA name and a patch n
The version argument must indicate the exact XDK version the OOVPA is based upon.
Some symbols stay the same across all XDK version, so require only one OOVPA version registration.
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)
@ -44,28 +37,19 @@ 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
`
`#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
`
`#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. Instead, use aliases.
* Never duplicate OOVPAs. Use aliases instead.