Closed GoogleCodeExporter closed 8 years ago
None of us use Xfire, so there is no one on the team who actively investigates
the crap Xfire does, or how to get it to work with the d3d9_proxy.dll
workaround. Steam's overlay doesn't crash the game when OS is running, so the
issue with Xfire is with how Xfire hooks into the game/D3D9. We presently check
to see if Xfire is running when the game is started, and if it is, we stop OS
from loading (should prompt with a message saying such).
Original comment by kornma...@gmail.com
on 18 Jan 2012 at 10:00
After looking a bit in to what XFire does, I believe it searches for the first
instance of d3d9.dll in the games running processes and modifies it using
addresses that *may* be hard coded to redirect it's functions to it's own code.
This doesn't work with OS as OS's wrapped Direct3D functions are in different
locations to what XFire expects which results in unexpected behavior.
I might be wrong in that, but either way it's methods seem less compatible than
the wrapping method OS uses and it's out of our control to change.
Original comment by TheFieryScythe@gmail.com
on 19 Jan 2012 at 12:06
Xfire's input system has been updated. It hasn't been detailed as to how this
new system works, but it may be worth it to temporarily move the start up
warning message in order to test xfire again. ;)
Original comment by jazpub...@gmail.com
on 19 Jan 2012 at 6:54
remove the start up warning message*
Sorry, I noticed that mistake after I'd posted.
Original comment by jazpub...@gmail.com
on 19 Jan 2012 at 6:55
There's probably no reason at all to test OS with Xfire's new input system now.
I just tested it with enbseries which uses d3d9 in a similar way to OS, and it
doesn't work.
I'll report the issue on the XBTT forums and see if Xfire's team can fix the
issue.
Original comment by jazpub...@gmail.com
on 21 Jan 2012 at 11:07
Original issue reported on code.google.com by
jazpub...@gmail.com
on 18 Jan 2012 at 9:03