TODO: HLE Database v2 Progress

[RadWolfie]

The following list of OOVPA database we need work on to finish moving into HLE database v2 table.

• XAPILIB
  • Copy all OOVPA list into v2 table.
  • Fix all OOVPAs to match with same address found in v1 table.
  • Fix OOVPA's XDK revision to lowest known match.
  • Add missing OOVPAs if any has occured.
• D3D8
  • Copy all OOVPA list into v2 table.
  • Fix all OOVPAs to match with same address found in v1 table.
  • Fix OOVPA's XDK revision to lowest known match.
  • Add missing OOVPAs if any has occured.
• DSOUND
  • Copy all OOVPA list into v2 table.
  • Fix all OOVPAs to match with same address found in v1 table.
  • Fix OOVPA's XDK revision to lowest known match.
  • Add missing OOVPAs if any has occured.
• XGRAPHC
  • Copy all OOVPA list into v2 table.
  • Fix all OOVPAs to match with same address found in v1 table.
  • Fix OOVPA's XDK revision to lowest known match.
  • Add missing OOVPAs if any has occured.
• XNET (Is found with XNET, XNETS, and XONLINES library header)
  • Copy all OOVPA list into v2 table.
  • Fix all OOVPAs to match with same address found in v1 table.
  • Fix OOVPA's XDK revision to lowest known match.
  • Add missing OOVPAs if any has occured.
• XONLINE (Is found with XONLINE and XONLINES library header)
  • Copy all OOVPA list into v2 table.
  • Fix all OOVPAs to match with same address found in v1 table.
  • Fix OOVPA's XDK revision to lowest known match.
  • Add missing OOVPAs if any has occured.
• XACTENG
  • Copy all OOVPA list into v2 table.
  • Fix all OOVPAs to match with same address found in v1 table.
  • Fix OOVPA's XDK revision to lowest known match. (Last known revision found is 4928)
  • Add missing OOVPAs if any has occured.

[LukeUsher]

I would not merge XNET and XONLINE, simply because they are unrelated APIs.

XNET implements network functionality, communication, sockets, that kind of thing.
XONLINE implements Xbox Live specific functionality, authentication, matchmaking, etc.

XONLINE Depends on XNET, but XNET is a completely separate library

[RadWolfie]

Strange, my research doesn't show XNET library headers if title is using XONLINES library header. Titles with XONLINES library do contain XNET and XONLINE section headers together excluding XNET library header.

How would you purpose to separate the two in v2 database method?

Actually I do have another idea which will help to keep both separately. And everyone should be happy with it.

//{ Lib_XONLINES,{ Sec_XONLINE }, XONLINE_OOVPAV2, XONLINE_OOVPA_SIZEV2 },

//{ Lib_XONLINES,{ Sec_XNET }, XNET_OOVPAV2, XNET_OOVPA_SIZEV2 },

[RadWolfie]

Or...

//{ { Lib_XONLINES , LIB_XONLINE }, Sec_XONLINE, XONLINE_OOVPAV2, XONLINE_OOVPA_SIZEV2 },

//{ { Lib_XONLINES, LIB_XNETS, LIB_XNET }, Sec_XNET, XNET_OOVPAV2, XNET_OOVPA_SIZEV2 },

Edit: I think this option is better.

[jarupxx]

As far as I know, XACTENG completed by PR #733 that fix OOVPA's XDK revision to lowest known match.
Please note. I was not tested less than version 4928. Because not found a test case.

[RadWolfie]

Updated OP to state title with lowest XACTENG we have available is 4928.

[RadWolfie]

Side note: Fix OOVPA's XDK revision to lowest known match. is somewhat low priority. Though, Add missing OOVPAs if any has occured. is a must if something is missing. (Just a reminder for myself and others plan to work on it.)

For now, DSound has the highest priority for the paragraph above which I am still working on for 3911 and 4039 revisions. Hopefully D3D's OOVPAs doesn't need to go down this path.

[jarupxx]

D3D8 OOVPA database has progressed to step 2. For now, D3D8 4039 revision is missing some OOVPAs.

[RadWolfie]

I notice LukeUsher and PatrickvL are mixing of HLE and LLE support. If we have partial LLE support, we should not use UNPATCHED. To knowledge for ourselves what's not necessary to patch when partial LLE is supported, we need to use something like LLE_ENABLE? UNPATCHED should be used only for we can allow native function to process since the callers are either patched, included support by kernel function, or not a requirement to patch.

Does it make sense to you guys? We can change it once WIP_HLEDB_v2 branch is rebased from master branch. Then merge into master.

P.S. I am currently working on DSound's 4134 revision to be fully support. Once this is done, regression should reduce from 40% to 10% chance. Then WIP_HLEDB_v2 should be ready to finalize for merge into master branch. It does not mean HLE DB v2 are 100% done, btw.

[PatrickvL]

Hi I really don't have a preference, just as long as you guys can do your thing best, then choose whatever helps to achieve it. Previously, I have stated that purely the scanning itself doesn't really need a distinction. Symbols can be searched for, regardless whether they will be patched or not. Even the /distinction/ between XREF and not-XREF doesn't matter for the scanning phase itself (except for the quick lookup using the XREF ID as an index into an array, of course). Neither does a distinction between an unpatched versus to-be-patched symbol make any difference to the scanning code itself. But, what I'm not so sure about, is what would be the best way to decide which detected symbols need to be patched, when the three LLE flags are taken into account. Surely, if all LLE flags are disabled, all available patches that we found the symbol address of in the current Xbe, must be patched (otherwise, why else did we mark an EMUPATCH with FUNC_EXPORT?) On the other hand, if all LLE flags are enabled, no patch must be applied at all, because the run was configured to do everything using LLE. But what if only a subset of the LLE flags are selected? For example only the GPU LLE flag; Then how do we discern which available EMUPATCH'es (those marked with FUNC_EXPORT) need to be patched? Or in other words : how could we discern a GPU patch from a sound or input patch? I have no concrete answers for that yet, except that we might need to export functions using specific prefix or suffix(es), so we can recognize their functional domain, so we could skip patching those that need to be LLE'ed... What are you're thoughts on this matter?

[RadWolfie]

HLE v2 XACT library is having a problem with [5233] Red Faction II. See issue Cxbx-Reloaded/game-compatibility/issues/410

This is for record purpose, currently not sure if the fault is from HLE v2 XACT library is incomplete or process to implement all HLE functions are incomplete.

[jarupxx]

Currently, HLE v2 XACT library does not to work well...
How about temporarily use UNPATCHED, until we work on XACTENG?

[LukeUsher]

@jarupxx I have no problem with this, it's causing more regressions than it's solving so unpatching is a viable option

[jarupxx]

Hi, Report current status

XAPILIB, D3D8, DSOUND, XGRAPHC, XONLINE library was Fix OOVPA's XDK revision to lowest known match task completed by PR #797

Although XNET library is theoretically completed, However, it has not been tested with real titles.
It may have been replaced by XONLINE since XDK 4361.

[PatrickvL]

Thank you very much. I've updated the checkboxes in this issue description above.

What's left to do now, according to you?

[RadWolfie]

Since there are only very minor few detection missing. We can safely close this issue as we are moving HLE Database v2 into separate project. Any remaining tasks will be created in separate repo.