PatrickvL

@Scarver40 this compatibility report is not meant to become a forum. We've got a discord channel for that. I'll soon delete both your message and this one, to keep things...

At some point in time we should compare the symbol addresses we write to our HLE cache file of Halo, to the symbol addresses [Xeon ](http://ngemu.com/threads/xeon-v1-0-released.40464/#post-573790) had in it's `halo.ini`...

_From @LukeUsher on June 1, 2017 9:0_ There are quite a few things going on with Halo that make it problematic to emulate. Xeon had game specifics hacks for it...

_From @blueshogun96 on June 5, 2017 0:30_ @LukeUsher, I do recall that day when sir caustik said that Halo likes to modify its textures at odd times. I guess that's...

I'll definitely look into this one, once my work in progress branch is nearing is completion

_From @ergo720 on July 25, 2017 13:45_ Well, with the latest build, it now crashes with a different error. PAL, win10, 3ca1a354 [KrnlDebug.txt](https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/files/1173832/KrnlDebug.txt) 1.01: [Xbe.txt](https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/files/1185568/Xbe.txt) 

Actually, it looks like D3DDevice_GetBackBuffer AND D3DDevice_GetBackBuffer2 aren't assigned, but only the first is verified, not the latter, which is probably the cause for this exception

Hm. Then perhaps it's calling convention or arguments aren't declared right...

Still strange how the cursor indicates the call to D3DDevice_GetBackBuffer2 failed. Which implies the trampoline to D3DDevice_GetBackBuffer isn't assigned, even though the call originates from EmuPatch_D3DDevice_GetBackBuffer...

But regardless, the trampoline to D3DDevice_GetBackBuffer2 isn't assigned checked...