State: 26.03.2025 // DD.MM.YYYY


Rain Meadow does not contain anything that makes it inherently incompatible with a x64 build of the game.




IL does not change depending on the release target (x86/x86_64).
Additionally, the main game assembly remains untouched (Assembly-CSharp.dll + firstpass)


It is theoretically possible though, that slight variations may exist in the
Unity, UnityEngine, BepInEx function bodies, due to miniscule patch-level
differences from the UnityPlayer build first used for the specific game update, and the
one currently available on Unity Hub.


So as long as the we are not talking about Post-JIT Inline-hooks, conventional IL hooks should remain in working condition.
Do not take this as a guarantee, there is always the possibility of unlucky circumstances, causing something to break even when it shouldn't.




If the mod author decides to, they can support X64 World by using "X64 World: Library Loader" and providing a x86_64 counterpart library with their usual x86 one.
This also requires the user to have the Library Loader companion mod enabled aswell.




The circumstances mentioned would be your machine having more than 4GB of memory available.
In which case, it will help you out until the process maxes out its memory consumption.




Linux systems should never get to such a point by default due to the kernel protecting you from such a scenario.


Windows is similiar, although older versions may or may not have sufficient protection built-in.
But in general: Windows will not freeze completely, it may come to a point where it lags obviously, but it wont flat out freeze your computer. Ever.
Windows' Virtual Memory Management and the windows kernel won't allow things to come to such a point, and the latter will still process stuff obviously.
WinUI lag != Kernel lag.


What I can say in terms of modern windows (7+) though, is that you should never have to worry about this.




The process is simple enough already if you follow the instructions on the Library Loader page.
And the alternative would be expecting me to provide x86_64 native libraries for all mods in existence that do native interop.


1. Get the X64 World: Compatibility Patch: Dreams mod!
2. Profit.

Same goes for Iterator TTS.



The mod does a pre-emptive check (rough, although) if your current game can made x86_64.
If this check succeeds, you will be prompted if you want to continue or not.


After which (if consent has been given) the mod will exit the game and start a external patcher
that will then try to patch the game to a x86_64 instance.


In essence, we are switching the game from a x86-Release UnityPlayer to a x86_64-Release one.




At the time of writing this, im not quite familiar of the way steam approaches game updates.
If steam is smart enough to find any different files from their expected state and replace them accordingly, a game update will simply
revert your game to x86 towards the latest game version.


If steam does this in a rather simple manner and only provides the changed files, then the results will become unpredictable.
In a worst case scenario, you still have the backup the mod created before going x86_x64 in any case.


As for when this mod gets updated to fit in with the new game version: I don't know, probably sooner rather than later.
Don't worry about the mod accidentally patching the game if its not compatible.
The mod and the underlying patcher have extensive checksum verification, it will not attempt a patch unless its confident it can pull it off.






The game suddenly going x86_64 makes things quite hard to predict, therefore, there is also a zero-support policy
on game-breaking bugs or even issues in general at runtime when playing the game with the mod enabled.


Support does exist on problems when installing the mod in the first place though, however.
Its just the part after successfully installing where you are on your own.




Windows (legacy):
H:\SteamLibrary\steamapps\workshop\content\312520\3326331909\plugins\data\backup

Windows (new):
%APPDATA%\x64world\data\backups

H:\ = Same drive letter where you have installed Rain World onto.


Windows:
%APPDATA%\x64world

Linux:
~/.config/x64world


NOTE: Modern x64 world versions do NOT require .NET anymore as they rely on NativeAOT builds!

Restart your machine after .NET 8 Installation!

If that does not work, you might have been on the receiving end of this issue:
The thing you are likely experiencing is due to the fact that when both (x86, x86_64 versions of any version of a dotnet runtime/sdk/whatever) are installed on your machine, the "dotnet" command (the thing I use to determine if your machine has the required runtime in the first place), will only use the x86 dotnet host to list all installed runtime, which in turn will only list all x86 runtimes.

Meaning you could theoretically download the correct version of the net runtime x64, but have some legacy .net 5 (x86) just chilling from a couple of years back and it will mess up the runtime query check.

I just became aware of this issue and a fix is being worked on, in the meantime, if you do encounter this issue while reading this: just uninstall any x86 net runtimes if you don't truly need them in that specific architecture.

^NOTE: The 1.0.4 update should have fixed this issue.


It will most likely always be a hard no. But if you're curious nonetheless you can check the recent update notes if something got changed that warrants such a re-install.

Most updates this mod receives are only small fixes and or precautionary additions/checks to the mod component itself, rather than changes to the end-result that is the patched x86->x86_64 rain world instance.


As mentioned previously, the main game assembly remains untouched, only the unity backend has been switched to x64 bit. There -should- be no empirical measurable difference between both of these versions.

The avg FPS have a chance to be different for both archs of the game just due to x86_64 asm code just flat out being better than the jitted x86 code in some circumstances and or vice versa, this is highly compiler specific and even then, would not affect speedrun timings, as I think they use IGT anyways, which would not be affected on a semi modern game, as it should be.

When the game will switch officialy to 64 bit, the game developers will have pretty much done the same thing, this mod also does, and I doubt old speedrun times will become invalid due to that.

Its not my call to make though in terms of speedrun legality, but regardless: this is my take on this.


Library Loader and x64world's compat mods will remain though, as they still have value then.


Warning: Only do this if you're desperate and out of options.



There are 2 ways of checking this:

First way: Check via task manager, if the main rain world process does NOT have a (32 Bit) suffix then it works as intended.

Second way: Check the LogOutput.txt file and see if you can find this line: "The game process is not a X86 one, indicating it already is a x86_64 one." - If you are able to find it, the mod also works as intended.

If not: it likely also says what went/is wrong.