Cooking/Packaging with 64-bit

Hey peoples,

All this time I accepted the fact that UDK is 32-bit only but I’m working on optimization at the moment and I noticed that I can get a significant performance boost just by using the 64-bit exe (4-10 FPS depending on the situation)

As I’m not using any dllbind I’m safe in that regard, and whatever claims I’ve read about the 64-bit exe being incomplete haven’t affected me at all (all this time I’ve run the editor and PIE with the 64-bit exe, and I know for a fact that the full-license UE3 has no issues related to the 64-bit exe as we shipped HeroesVII at work with it).
So I went ahead and tried it.

UnrealFrontend only has this Shipping_32 profile but all UnrealFrontend is really doing is launching commandlets in a convenient way.

So here’s what I did:
I modified UnSetup.Manifests.Game.xml and UnSetup.Manifests.xml from the Binaries folder, and I replaced every occurrence of “Win32” with “Win64” (and to be double-safe, replaced “Win64” with “Win32”)
And then I packaged my game.
I then installed the game using the created installer, and launching the game properly launched the 64-bit exe. running it in windowed showed “64-bit” on the window’s title bar.
so yay, it works.

for now I was using the data I had previously cooked with UnrealFrontend. at some point later I’ll try to re-cook everything using the 64-bit exe, by launching the commandlet manually from a bat file, like so:

start Binaries\Win64\UDK.exe CookPackages -platform=PC EG-Entry.udk EG-Menu.udk EG-Training.udk [and the rest of the maps one by one] -full -multilanguagecook=INT

however I dont feel like cooking the data with the 32-bit or the 64-bit exe will make a difference.

anyone tried any of this?

No, but I’m about to!

Sounds do-able.

I could probably full cook the maze game as a test, maybe i can test this “PIE using 32bit issue”]( i posted the other day with your manifest change and get a shortcut to behave like editor without a cook.
I have never done a full cook/ compile before so worth a shot.

Dunno if it helps at all but i did some 32bit upgrades with UT3 (which is literally 32bit only) and they worked fine.


Since UDK is more tailored towards 64bit dll’s etc it shpould be 100?% fine.

Also amazed at your work being in 32bit all this time, amazed at your work anyway but with an added performance increase- cool beans!

Link to where i took my quote from:

Sorry for the necrobump Mate.I just modified the UnSetup.Manifests.Game and UnSetup.Manifests with win64 as you did and did a cooked game.After installing it I hit the ok to start and the game did started in x64bit mode.After I exited the game I went to the installation folder and noticed that in the binaries there was no win64 folder, so I had to manually copy/paste the win64 folder from the udk editor and copy it in to the binaries of the game so that I can launch the game in x64 bit once again.So by default, no win64 directory was cooked in my case.Did this happened to you too?

Didn’t quite understood this part.Were you referring to the UnSetup.Manifests.Game and UnSetup.Manifests again or was it something else?

it was still those 2 files. what I meant is that I simply exchanged “Win64” <–> “Win32” both ways

sorry I missed this reply.
I don’t use UnrealFrontend to cook or package. I cook via a batch file directly and I don’t package at all, since I copy directly to steam. therefore I manually copy the binaries as they are needed (I made a batch file that does the copying into the steam sdk folder, I specified the files manually)

So in that case,in order to launch the game in x64bit we do have to manually copy the win64 folder from the udk editor installation and paste it in to the games installation binary folder so that users can start the game in x64.Did I get it right?

yes that’s how I made it.
the frontend does pretty much the same but with the 32bit exe anyway

Thank you :wink:

A small update on the matter.People most of the time will use custom installers, but reading a few times again what you wrote mate and a lot of testing i managed to cook and package with Frontend in x64 :cool:
For everyone interested this is how it shoud go.


go to line 106 which is <string>Binaries/Win64</string> and change that 64 to 32 and save and recompile the scripts.Now when packaging and after that installing the game we will have the Win64 folder instead of the win32 and everything works perfect.

Also, after installing the game there is a window that will ask to start the game for the first time.If clicked ‘‘ok’’ it will not start the game and the user will have to go to find the exe.In order for this not to happen, before packaging we have to go to the same UnSetup.Manifests.xml and go to line 5 which is <AppToLaunch>Win32\UDK.exe</AppToLaunch> and change the 32 to 64.
That way it will auto launch the game the first time installed.

I do not recommend any other changes in the xml 64>32 and vice versa as i noticed that the win64 folder of the final game was 91.9mb vs the original 93.5mb and we lose some things.Just changing the 2 lines in code from above is enough and the final win64 folder of the game will have all of the files of the original editor win64 folder.

Now, does someone knows where is the option to change dx9 to x11 to cook for? I suspect its in one of the xml scripts but I cant see it and i don’t like much making a shortcut of the game and adding -dx11 to the target line in properties.

Useful info, thanks.

There are some difference in the game runing at 32 and 64 bits?

I haven’t noticed nothing. But compiling the game is a little faster in 32.

Also with a previous UDK version I had problems loading the landscape, game crash randomly when using 32 bits. Never when using 64. But with the last UDK version the problem seems gone.

added this to favorites if bill gates wants to depracate 32 bit we are saved : D

Shame about the dllbind not being supported in 64-bit.

Given that you need dllbind just to be able list files in a folder or use the UDP protocol… yeah… going to be shipping 32-bit for sure.

I suppose stability only as the 64 will use all of the ram.For a game the size of yours, probably 64 will be a safe bet.

Lol, but i doubt 32 will go anywhere in the future.

I think dll bind is possible in 64bit but i have only seen one example that was left a mystery.This game:

The files are long gone for download, but i still have them.And in his editor folder in the binaries>win64 he does have a UserCode folder with two dlls responsible for saving in the game.When playing the game in 32bit or 64bit you can save the game (player position and picked items) and when used the 64bit exe and 32bit, bought can use the same dll to load the game.

But i never managed to understood how he did it.If interested, i can upload the two windows folders and the uscripts for you to try and track it, but i dont have the source for the dlls.I suspect that the dlls in the 64bit folder are 32bit ones and using scaleform and the uscript> he calls for the dll in the 64bit folder that by it self calls the one from the 32 bit folder.But its just a theory.

what was the issue with 64bit dlls again? wasn’t it only that UDKFrontend would simply not include them in the packaged installer? isn’t that irrelevant for Steam anyway?

I think it was that, but i suspect that is difficult to make udk work wih a 64bit dll.Not that i need it anyway.

On the other hand im struggling to find some info on FrontEnd. There is a option called ‘‘Launch Options’’ with a prefixed command ‘’ -seekfreeloading ‘’ and some space next to it for more commands.If im not mistaking, there we need to place things like -dx11 -d3d11 or -sm5 for example to have dx11 as a prefix in the properties of the game exe launcher right?

Than why don’t they work? If i launch the cooked game from FrontEnd>Launch it does start in dx11 with one of the commands, but the final packaged build doesnt want to.
Is it because the defaut udk PackageGame (does not have the ability ??) to create automatically a desktop shortcut icon, which is needed?

Toglling on and off No Vsync doesnt seem to work neither in launch or a cooked game …