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

Fixed spe

PatrickvL 2017-08-02 09:58:28 +02:00
parent b37c38f8d8
commit 887f399568
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
Maintaining-OOVPA's-for-HLE-function-detection.md

@ -1,6 +1,6 @@
#Introduction
Cxbx in it's current form, uses HLE (High Level Emulation). This roughly means, that code in an XBE (XBox Executable) is executed as-is. However, any code that accesses XBox hardware registers will cause problems, since this hardware is not present in the host system running Cxbx.
Cxbx in it's current form, uses HLE (High Level Emulation). This roughly means, that code in an XBE ("XB"ox "E"xecutable) is executed as-is. However, any code that accesses Xbox hardware registers will cause problems, since this hardware is not present in the host system running Cxbx.
So, for HLE to work, Cxbx needs to prevent those hardware accesses. Cxbx does this by scanning for problematic pieces of code, and patches these with replacement code, that emulates the original behavior.
#Scanning
@ -28,7 +28,7 @@ Together with the registration of an OOVPA in an OOVPATable, a replacement funct
If an OOVPA is matched to a location in the XBE, and the OOVPA is registered with a patch, that location is overwritten with a call to the patch, which emulates this function. Thus, the problem of hardware accesses is avoided and emulated instead.
#XRefs
Apart from OOVPA's, Cxbx contains a set of so-called XRef numbers (short for cross-reference numbers), which are unique ID's to indentify a function by. Some OOVPA's are defined including one of these XRef numbers.
Apart from OOVPA's, Cxbx contains a set of so-called XRef numbers (short for cross-reference numbers), which are unique ID's to identify a function by. Some OOVPA's are defined including one of these XRef numbers.
When there's a match found for an OOVPA that has an XRef, the matching location is written to a list, indexed by the XRef number. Once there's a location recorded for an XRef, it's final, meaning that Cxbx will skip a scan with any other OOVPA mentioning that same XRef number.
@ -37,10 +37,10 @@ Some OOVPA's contain an XRef that must be checked for, together with the (Offset
Checking for an XRef means comparing the recorded location to the 4 bytes that are present on the mentioned offset. This is compared as a direct (absolute) reference, and as an indirect (address-relative) reference - either way, if that matches the recorded location, the XRef check holds, and all other (Offset, Value) pairs are checked. If the XRef check fails, the rest of the OOVPA is not checked, it's deemed a miss, scanning continues with the next address.
#Maintaining OOVPA's
Each OOVPA must be unique from all other OOVPA's, otherwise, the same location could be matched to more than one function, which would lead to incorrectly placed patches, which leads to unpredictable behaviour, probably crashes.
Each OOVPA must be unique from all other OOVPA's, otherwise, the same location could be matched to more than one function, which would lead to incorrectly placed patches, which leads to unpredictable behavior, probably crashes.
An OOVPA is formed by choosing a few offsets in the machine code of that function, and writing down their byte values, in such a way that no other function is identifiable with these offsetted bytes.
The function an OOVPA scans for can be different between library versions. To get reliable emulation, Cxbx needs to contain unqiue OOVPA definitions that will match all existing versions of a function.
The function an OOVPA scans for can be different between library versions. To get reliable emulation, Cxbx needs to contain unique OOVPA definitions that will match all existing versions of a function.
Sometimes, after a function changed in one version, it changes once more in another, later version. In some rare cases, a function might even re-appear in a prior form! In this case, the OOVPA for that re-appearance must not be copied over from an earlier version, but instead an alias must be registered. (Aliasses are simply `#define function_new_version function_old_version`)
Sometimes, after a function changed in one version, it changes once more in another, later version. In some rare cases, a function might even re-appear in a prior form! In this case, the OOVPA for that re-appearance must not be copied over from an earlier version, but instead an alias must be registered. (Aliases are simply `#define function_new_version function_old_version`)