Forum Discussion
Slight concern about the use of hooks, and mem patching
Hey Oculus, can't wait to learn and use the new SDK and get the DK2 :D
I was randomly reading through some of the code in the SDK and noticed that the in OVR_Win32_RenderShim.cpp has things like changing read/write flags of memory pages and patching memory. It seems you have to do this to get the custom display driver to work, but it is probably worth it if latency is reduced.
However, I am concerned about things like anti-cheat programs and anti-viruses. Will there have to be some time these programs whitelist this behavior? Like I don't want to play a Steam game, and have VAC ban my account.
Sorry if I am spreading FUD :?
I was randomly reading through some of the code in the SDK and noticed that the in OVR_Win32_RenderShim.cpp has things like changing read/write flags of memory pages and patching memory. It seems you have to do this to get the custom display driver to work, but it is probably worth it if latency is reduced.
However, I am concerned about things like anti-cheat programs and anti-viruses. Will there have to be some time these programs whitelist this behavior? Like I don't want to play a Steam game, and have VAC ban my account.
Sorry if I am spreading FUD :?
5 Replies
- This sort of patching is done so that native rendering is otherwise unaffected by the display driver. Think about it. How does one go about rendering to the Rift if the operating system can't see it? What we've done is allow developers to target the display by creating back buffers that fit the rift (1280x800 for the DK1, 1920x1080 for the DK2) and leave it at that. To do this we need to patch a handful of functions to ensure our place in the graphics stack.
I don't expect this to raise any red flags on any malware detection software unless their paranoia levels are set to maximum. - I wouldn't worry about antivirus too much, I ran the Oculus World Demo through VirusTotal and nothing sounded alarms.
Its not like using things like VirtualProtect are inherently evil. For instance, JIT compilation requires it in order to function.
As for anti-cheat: For games with native Rift support, I imagine any anti-cheat software would be trained to ignore these calls. For things like stereo injectors...well they all already require stuff like this, so adding this wouldn't make the situation any worse.
Also, Dean: Do you know if there's any plans to open source the display driver bits along with the SDK? I'd be very interested to see the code details behind how it works! "deanbeeler" wrote:
Think about it. How does one go about rendering to the Rift if the operating system can't see it?
What about the normal way of explicitly providing functions to call instead of the default ones?- Microsoft and the Khronos group would have to provide those explicit functions, while Nvidia and AMD would have to provide driver support.
For all intents and purposes, this is a totally new display mode beyond windowed and fullscreen. In order to expose it to the programmer the "normal" way, every layer of the rendering stack would need to be aware of it and treat it differently. I look forward to a future where that is the case, but it won't happen any time soon. "deanbeeler" wrote:
I don't expect this to raise any red flags on any malware detection software unless their paranoia levels are set to maximum.
For the sake of completeness: Looks like I just experienced such a case with Avira (with default security level):
viewtopic.php?f=26&t=11449
