I'm not sure but I believe that Moviestorm might have to be re-written to support 64 bit OSes. I would love to see a 64 bit Moviestorm and others might to because it wouldn't have the memory restriction that 32 bit has.
IIRC, 32 Bit OS's are limited to 4 GB of ram, 64 bit's don't have this problem.
A 32-bit application would be limited to 4GB of Virtual Address Space (VAS) both on a 32-bit and a 64-bit Windows system. Always. The problem is that those 4GB are split between user address space (available for the application process itself) and the kernel address space (reserved for system structures and data used in the process context).
By default, both on 32 and 64-bit Windows systems, of those 4GB, only 2GB are available for the application itself. My proposition was to take advantage of a well-known feature that allows us to stretch this address space: on a 32-bit system that would render at most 3GB of the VAS (in practice, a lot less); but on a 64-bit OS, running on WoW64, the full 4GB of VAS would be available for the user address space. See: https://support2.mic...spx?scid=889654 and https://msdn.microso...y/aa366778.aspx
Virtual address space per 32-bit process:
- 32-bit OS: 2 GB, 3 GB if the system is booted with the /3GB switch (*)
- 64-bit OS: 2 GB, 4 GB if the application is compiled with the /LARGEADDRESSAWARE switch
(*) Please note that the /LARGEADDRESSAWARE switch is required for the application taking advantage of this feature.
So on a 64-bit Windows OS we'd have 4GB available for the Moviestorm process, provided it's running on a JVM with the LARGEADDRESSAWARE feature enabled, instead of the current 2GB cap. Of course, this doesn't imply that those full 2GB extra would be available for the application itself: the JVM takes its share. In fact, of the 2GB currently available, only 512MB (or at most 800MB) are available for the data heap. Provided we've got MS running happily on such a JVM, the next logical step is to take advantage of the extra address space and to increase the heap size. Now, this means that the JVM has more memory to track, manage and take care of, so it will need extra memory for its own data structures. Further, this also means that the garbage collector will have extra work to do, so a performance hit is to be expected, though its magnitude needs to be empirically assessed.
Indeed, a full and real 64-bit implementation of MS would be the real and ultimate cure for all our predicaments related to memory shortage: with a user address space of 8 TB, no more out of memory exceptions are to be expected. Too bad it seems quite improbable that we'll see it in the future/ever.
IIRC the problem to get this accomplished has to do mostly with third-party libraries that are used and invoked from Moviestorm's own code. My knowledge about Java is shallow, so maybe I'm wrong, but porting MS itself to run on a 64-bit JVM shouldn't be very hard. Theoretically. There may be some class members and pieces of code that require further consideration to make it work reliably on a 64-bit platform.
Nevertheless, Ben is making his best and some performance and memory usage optimizations are to be expected soon: eg, not mapping meshes data files into the application address space unless an asset in the addon is actually used (http://www.moviestor...445#entry106539). For sure, that can make a difference.