Support 64 bit
Closed this issue · 32 comments
More games are using 64 bit. Its probably worth looking at.
- Some parts of the injector will certainly need to change
- There are some places in the code where I track pointers (e.g. texture pointers) and I'll need to make sure those data structures are 64 bit wide
- Any place where a pointer is passed over interop will need to be checked
- Do I need to use a 64 bit CLR too?
- Does D3D9 even support 64 bit? If not, this may be gated on #8
Hello, any chance this is still being worked on? Guild Wars 2 just announced it is ending the 32-bit client soon.
Thanks for your work!
A 64-bit version exists in this repo but I haven't made a release for it or even documented it. I'm not sure I'll ever make an official release for it, but I'll try to find some time to make a release binary and some instructions for using it with GW2. Maybe you can test it for me? Honestly didn't even think anyone was still using MM at this point, except for me but I don't game much these days.
I still use it, I'm sure others do too but keep quiet about it due to its questionable TOS status. I would be happy to help test a 64-bit version.
I'd be happy to test it as well. I am no programmer but I'm sure I can figure out the UI.
I'll work on the build, but FYI I noticed that the guild wars 2 announcement also mentioned they are adding DX11. If they actually drop DX9 support then even 64 bit modelmod will no longer work. DX11 has to be explicitly coded for (#8). I don't know if I'll be able to fix that.
That's great, thanks!
Yes DX11 is coming, but it probably won't come until the expansion comes out or soon after. Hopefully there will be a way to choose between DX9 and DX11.
Lastly I do believe in supporting the developers so if you have a bitcoin, patreon, etc I'd be happy to support as well.
Yes hopefully they don't drop DX9 entirely. If they do I can probably make DX11 work, but...that's a lot more work and something I have been avoiding. Thanks for the note about Patreon, at this time I don't feel comfortable accepting payment for MM since I don't really work on it much anymore, but maybe I'll reconsider if I end up doing DX11. Anyway I should have the 64 bit build up for test in a few days.
Ok here you go: https://github.com/jmquigs/ModelMod/releases/tag/1.1.0.3
Some extra instructions:
- Unpack the zip somewhere
- Start ModelMod.Exe
- Click New to create a new profile
- Click The browse button next to ExePath in the launcher and browse to and select the Gw2-64.exe file
- Click the Game Profile button in this new profile
- Check "Reverse Normal Components" (I think its needed for gw2?)
- No Command line args
- In "Date Path Name" enter "gw2" (this tells the 64 bit version where to find the mods from the 32 bit version).
- Click Ok, you can exit the launcher now
- Copy "d3d9.dll" from "[ModelModDir]\Bin\modelmod_64 into the "bin64" directory in your gw2-exe installation.
- Start the 64 bit version normally (since it is the default now you can just start GW2 from its shortcut).
- Hopefully your mods load in game, if not, well I'll need to see the log file. The log file should be in [ModelModDir]\Logs.
It seems to work, at least in part. It took a tiny bit longer than usual to load the mods but they did load correctly from the old directory. However snapshotting no longer pulls textures.
I will test more over the weekend and note anything else of interest.
Can you send me a log file? Its probably not finding d3dx. I guess I might have to include that.
Yeah loading takes a bit longer in 64 bit for some reason.
You are correct:
ThreadId(2): Snap started
ThreadId(2): failed to load d3dx: texture snapping not available: LoadLibFailed("C:\Users\Daelin\Documents\ModelMod\64 Beta\TPLib\D3DX9_43_x86_64.dll")
Ok well that should be pretty easy to fix, I'll just need to include it in the package I guess. Let me know if you find anything else, thanks!
Seems to be working on my end fine as well. The only issue is the texture one, it also won't change the textures I have changed in the .yaml file. I'm not sure if it's related.
@arb1911 Yes if it can't find d3dx it will also not be able to load textures. I should have an updated build that fixes that tomorrow.
I’ve noticed it disables mods if the FPS gets too low. I assume this is intentional?
Yes, the default is 28 FPS. Which usually means it will drop out in a boss fight or some intense scene. It should come back after sustaining about 10% above that for a few seconds. There is no UI to set the limit, but it can be customized by editing the profile directly via regedit.
Ok, making that more easy to edit would be nice. Is it there to try and avoid crashes?
Are you getting crashes? It shouldn't be crashing.
No crashes, I'm asking if the FPS disabler is there to try and avoid them.
Oh. Well no, the FPS is dropping because of too much stuff getting rendered. You could lower the overall detail settings. If you want to disable the limiter entirely you could set the MinimumFPS to 0.
BTW there did actually use to be a legit game crash in the old 32 bit version. Like if you played Dragon Stand with MM on, it would probably crash by the time you got to the end islands. I think that doesn't happen in 64 bit anymore, but I haven't checked recently. It can still get really slow in that map though and in other meta events.
I observed the 32-bit version would crash if the RAM usage reached 3.5 GB, but this is innate to the 32-bit client and nothing to do with ModelMod, but probably not helped by it.
I'll disable the limiter and see if anything breaks.
The 32-bit version crashes whenever I went to Path of Fire maps, but this version I can report that it hasn't at all on those maps.
One other thing, since MM now requires you to put the d3d9.dll in the bin folder manually I assume it's no longer possible to use ReShade/GW2Hook or Acdps with it?
Thanks!
@DaelinDwin Ok. Yeah hopefully a RAM-related crash should no longer be an issue. I think the crash is some kind very tiny memory leak but I've never tracked it down. Maybe I'm not clearing stack variables on some function, or using a wrong calling convention somewhere. In any case 64 bit has a huge memory pool so that shouldn't happen if its a leak.
And actually I had a failure of reading comprehension on your previous question. Yes, the limiter is there to try to mitigate very low framerate situations. It does help, though, the effect is not as big as I had hoped. Most of the performance drag of modelmod comes from the fact that it is hooking d3d9, the actually rendering of the models doesn't make it much worse, unless its some kind of insanely complex mod.
@arb1911 I didn't even know it worked at all with ReShade or GW2Hook or arcdps. But yeah there can only be one d3d9.dll at a time unfortunately. I think one of those has the ability to "chain load" another d3d9 but I can't remember which one. I was looking at making MM run as a ReShade plugin, the newer versions of reshade support that, but I never finished that work.
Yeah for the 32-bit version I was able to put the ReShade d3d9.dll in the 32-bit bin folder and it did work with MM. Also, yes, there is a chainload dll for the ability to use Arcdps and GW2Hook together.
But I'm OK with not using ReShade.
If GW2 moves to D3D11, and drops d3d9, then I may resume work on the reshade plugin. Its likely easier for me to implement D3D11 inside of that then to hook all over from scratch.
Ok here is a new build that should fix the texture save/load issue:
https://github.com/jmquigs/ModelMod/releases/download/1.1.0.4/ModelMod-1.1.0.4.zip
Texture snapping and texture mods seem to be working fine now.
Working fine for me as well, I'll report if there's any other problems.
Thanks.
Ok I'm going to head and close this then, thanks both of you for testing!
Thank you!
If you do ever decide to work on dx11 I'd be happy to test that as well.
Thanks for everything.
I'd also be happy to test any future versions or updates you have in mind.