SCUMMVM for Windows 64 bit

carlo_bramini · Post by **carlo_bramini** » Sun Sep 04, 2016 5:08 pm

Hello friends,
I'm wondering if there is a reason for not making available a Windows build for 64 bit platforms.
I tried to search through the forums, but I have found nothing, or it escaped to my attention.

Actually I have been able to build both i686 and x86_64 executables, by compiling from cygwin bash and feeding "--host=i686-w64-mingw32" or "--host=x86_64-w64-mingw32", depending on the version I wanted to make.

Besides an initial error in detection of freetype2 in both versions that needs to be inspected, I have found no problems.

Sincerely.

dreammaster · Post by **dreammaster** » Mon Sep 05, 2016 3:15 am

The short answer is that there's no real advantage to doing so. Even Windows 10 still runs 32-bit applications quite happily, and none of the game engines would see any performance benefit from 64 bits vs 32 bits. So there's little point to providing both 32 and 64 bit executables.

Post by **sev** » Tue Sep 06, 2016 8:14 am

We used to release it once, but as dreammaster mentioned, there is no real point of doing so.

Perhaps you have some specific reason why do you think it is a good idea?

Eugene

carlo_bramini · Post by **carlo_bramini** » Sat Sep 10, 2016 12:12 pm

Hello,

thank you very much for the replies.

No, there is not a specific reason that would force the release of a 64 bit version... but since its creation is absolutely inexpensive because both Windows API and 64 bit exist for other platforms, then it would be a new application to be added to the library of native 64 bit applications for Windows, near 7zip, MPC-HC and many others.

Sincerely.

EDIT: if I can say my opinion, perhaps you may let the users to expose their thoughts with a poll, if they would like to have also a build for Window 64 bit or not... it won't be a final decision, but it could help to direct to the best choices to be taken.

NLS · Post by **NLS** » Mon Sep 12, 2016 10:03 am

Well, x64 is a "moving forward" idea.
Many apps don't get a real benefit from moving to native x64, but as you can't run 8bit code and since (relatively) recently you can't run 16bit code on x64 environments (without emulation), why not explore that area? Just to be fully ready.
Also, I suspect native x64 code runs more comfortably on x64 environment, even if you don't actually make use of the extra register lengths etc.
Also for an emulator and similarly for an interpreter, looking to the future is the "must", as new engines get added, which in the future may require x64. I don't see engines emulated as dead fossils. I expect that new engines will be added that are not considered yet. After all, development in general has moved to high-level programming (all games run over a more generic "engine", either created by the developer or buying the rights to use it). "Future" scummVM will need x64 eventually.

That said, there is no rush for any real reason. True.
But if it's just a "make" parameter...

Reckless · Post by **Reckless** » Mon Sep 12, 2016 6:24 pm

There's simply no reason to do so. It would just be effort for the sake of it and I'm sure we'd prefer contributors to concentrate on stuff that matters.

albadross · Post by **albadross** » Tue Sep 13, 2016 9:56 am

I must confess that I have not understood this thread at all so please may I ask a question. Some time ago I decided I had had enough of Microsoft operating systems on my 64-bit machines and changed all my machines to Linux. However, my experience with ScummVM Linux is that it does not do as good a job as ScummVM for Windows using Wine (e.g. I can't replay some games I have completed in the past under Windows). So I have been downloading and running under Wine a version from the official daily builds page generated by the buildbot called Windows (64-bit) latest development build. If there is apparently no need for a 64-bit version, what am I running? Or should I be downloading the 32-bit development version?

Post by **criezy** » Tue Sep 13, 2016 10:46 am

@albadross: The 32 bits version of ScummVM for Windows should work just as well both on 32 bits and 64 bits computers. Some applications do benefit from being 64 bits (for example if they require a lot of memory) but that is not the case of ScummVM.

Also I am somewhat interested in your claim that the Linux version does not do as good a job as the Windows version. Are some features missing, some bugs present, or is it just general performances (e.g. cursor lag, some games being slow)? This might not be the thread where to discuss this, but I think we would welcome bug reports and features request on our new shiny bug tracker. Or you could start a new thread on the forum if there is something to discuss.

Dark-Star · Post by **Dark-Star** » Tue Sep 13, 2016 11:03 am

At least in Visual Studio, building the 64bit version out of the box fails with the provided (generated) solution file.

There are some missing defines that are required for 64bit (FPM_64BIT for libMAD and SCUMM_64BITS for the director engine, although from reading the source code it looks like the latter might actually get added if you use the 64-bit version of the create_project tool, but it should get added for x64 builds in any case)

Also, there seems to be a compiler problem with MSVC running out of memory and/or crashing with a segfault if you turn on Optimization and Whole-Program Optimization in the project settings (which is the default).

Turning off the optimizations and adding the missing #DEFINEs makes it build just fine in MSVC (provided you have the corresponding libraries)

GUN · Post by **GUN** » Wed Sep 28, 2016 9:00 pm

I'm curious,

carlo_bramini wrote:[...]Actually I have been able to build both i686 and x86_64 executables, by compiling from cygwin bash and feeding "--host=i686-w64-mingw32" or "--host=x86_64-w64-mingw32", depending on the version I wanted to make.

carlo_bramini wrote:[...] then it would be a new application to be added to the library of native 64 bit applications for Windows [...]

creates MinGW at the actually point native Windows executables? That would be awesome or works it like before over an MinWG Layer? Then it would be better to check if you can run it over Visual Studios.

carlo_bramini wrote: [...] let the users to expose their thoughts with a poll, if they would like to have also a build for Window 64 bit or not... it won't be a final decision, but it could help to direct to the best choices to be taken.

I don't get it, everybody tells, there will no benefit of doing this. Plus new versiuons will drop support of older machines. Wheres the point of need that?

Post by **rootfather** » Thu Sep 29, 2016 6:41 am

ScummVM in general is 64bit ready - I always use the latest source code revisions and compile the builds myself using mingw-w64. Works like a charm! For the "general user", there is currently no point in using a 64bit version of ScummVM, but if you *want* it, you can still compile it yourself.

Applications built with MinGW are native Windows applications, you don't need a compatiblity layer like the Cygwin DLL. However, when compiling ScummVM with MinGW, you need a bunch of additional .dll files for the additional libraries, because most of the libraries used in ScummVM (and the GNU C++ library) are linked dynamically and not statically. See http://wiki.scummvm.org/index.php/Compi ... 22_machine for further reference.

With kind regards
rootfather

carlo_bramini · Post by **carlo_bramini** » Sun Oct 23, 2016 12:06 pm

Hello friends,
I hope that one day we will see a 64 bit build of SCUMMVM.
After all, as someone noticed, it is just a parameter for the configure script to be added when you decide to compile and as written also in another reply, SCUMMVM is already 64 bit ready, no changes to the code are required, actually.

However:

The short answer is that there's no real advantage to doing so.

that's not true. Or at least, it depends.
Windows 64 allows you to run 32 bit code, but it does not come for free. The SysWoW64 includes almost everything, so you are actually running 2 operating systems, one at 32 bit and one at 64 bit and this is also an explanation because it consumes much more memory than the past.
In addition, for those parts not available in native 32 bit code, with my experience I can tell you that the translation layer for stack, memory and calls is not so cheap as you may think.

In few words, if you have no choice because your software really needs to be 32 bit (like using third party libraries) then ok. Otherwise, always go for 64 bit when you are going to use Windows 64. You won't regret. The 32 bit support on Windows 64 must be considered as a facilitation, nothing else.

I hope you will find this useful.

Sincerely.

TMM · Post by **TMM** » Fri Nov 04, 2016 6:29 pm

Hi! I'm the current ScummVM Windows maintainer/releaser (as of 1.9.0, fairly new)

that's not true. Or at least, it depends.
Windows 64 allows you to run 32 bit code, but it does not come for free. The SysWoW64 includes almost everything, so you are actually running 2 operating systems, one at 32 bit and one at 64 bit and this is also an explanation because it consumes much more memory than the past.
In addition, for those parts not available in native 32 bit code, with my experience I can tell you that the translation layer for stack, memory and calls is not so cheap as you may think.

I did some research into this and while this is true it is only true when comparing 32bit software running on a 32bit system. The overhead you are describing is identical for running a 64bit scummvm on a 64bit system.

Basically, a 32bit binary running on a 32bit Windows will use less memory than that same program compiled for 64bit windows on 64bit windows. However, the 32bit program running on a 64bit windows will use the same, or slightly less ram than the 64bit version.

Having said that, once I get the whole release process for 1.9.1 and onwards sorted out I'm willing to also create 64bit builds for Windows. There is however a non-trivial amount of work involved in making 'upgrades' from a 32bit to a 64bit installation work smoothly for all users.

I don't expect this to happen in the 1.9.x series.

KuroShiro · Post by **KuroShiro** » Fri Nov 04, 2016 9:59 pm

TMM wrote: Having said that, once I get the whole release process for 1.9.1 and onwards sorted out I'm willing to also create 64bit builds for Windows. There is however a non-trivial amount of work involved in making 'upgrades' from a 32bit to a 64bit installation work smoothly for all users.

I don't expect this to happen in the 1.9.x series.

Forgive me if I'm being obtuse, but wouldn't getting it to work for all users simply mean making the installer install the required .dll files for all the libraries used in compilation in addition to what it already does? The actual compilation process for a 64-bit .exe in MSYS2 is fairly simple.

TMM · Post by **TMM** » Fri Nov 04, 2016 10:02 pm

Forgive me if I'm being obtuse, but wouldn't getting it to work for all users simply mean making the installer install the required .dll files for all the libraries used in compilation in addition to what it already does? The actual compilation process for a 64-bit .exe in MSYS2 is fairly simple.

The old installer places stuff in c:/Program Files (x86)/ScummVM, a native 64bit installer would place them in c:/Program Files/ScummVM. People upgrading from pre 1.5.0 would lose their savegames if we just clean out that old directory post install.

I have to do a lot of tests is what I'm saying.

EDIT: Also; scummvm-tools installs in the same directory, I just haven't figured out what a migration path should look like.