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.
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?
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?
Cheers
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
For everyone interested this is how it shoud go.
Binaries>UnSetup.Manifests.xml
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.
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.
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 …
