Oolite Bulletins

Shortly after registering on this board the url became inaccessible (maybe the message board was hacked since then) and today I was able to access it. Any new developments on a windows 64 bit executable?

I may have found a workaround for this problem:

Some months ago I've downloaded Large Address Aware, a small utility that can set flags for !64 bit apps to allow them using larger addresses.

When I saw this thread, I thought I should give Oolite a try. I'm using a slightly modded trunk build, compiled as 32bit.

Currently, it does look highly promising. Adding an older working copy of OE which I never was able to use due to memory restrictions, I finally was able to use it. During start-up, Oolite did use more than 2 GiB of memory and everything did work.

Still, tests would have to be done with such a monster...but it might be what's required to allow Oolite the usage of more RAM.

Screet

Welcome back, Screet!

It has been almost a year, I see.

Screet wrote:

I may have found a workaround for this problem: ... it does look highly promising. Adding an older working copy of OE which I never was able to use due to memory restrictions, I finally was able to use it. During start-up, Oolite did use more than 2 GiB of memory and everything did work. ... Still, tests would have to be done with such a monster...

As already said in another thread, welcome back Screet! (doppelt hält besser)

A 64-bit build of Oolite would be really nice for anyone playing with a lot of memory-consuming oxps on Windows. So if you have found a fix that would be much appreciated.

Old OE really does eat memory like crazy - good that the newest test versions aren't that hard any more, not my doing, it's upgrades from merged oxps and nearly no legacy scripts running any more ... if you want to test that, PM me or mail. And for a 64-bit Win build OE would still make a good test-case, it doesn't get more memory-heavy than this.

Hope to hear from you

L

Lestradae wrote:

A 64-bit build of Oolite would be really nice for anyone playing with a lot of memory-consuming oxps on Windows. So if you have found a fix that would be much appreciated.

Well, it's still a 32bit build I'm using, but I've simply used "Large Adress Aware" to set the flag to allow more memory (note: that's really only a flag and can be removed if it does cause problems). I had some problems but those turned out not to be from the flag but from a damaged installation. Seems I did chose the wrong day to compile trunk.

Using the LAA tool it would be both possible to set the flag after compiling before building the package so that anyone using the installer will get the version with more memory or to set the flag manually after installation.

Still, it's pretty much untested here. Using more than 2 GiB RAM was no problem, though. I'm more having trouble with my current trunk compilations - after the latest update, the game now does crash less than a second after launch without any notification of what's going on. Maybe I should try to rebuild it *now* and hope someone found the problem and fixed it

Anyway, I've been thinking about it in the past days and came to the conclusion that for me it might be best to compile a modified version based on the codebase being used for the latest test release in order to have higher compatibility with current OXPs. Sadly, I don't know how to use svn to perform that task and I'm a bit afraid of having to add my little changes to the code again.

Screet

Screet wrote:

Anyway, I've been thinking about it in the past days and came to the conclusion that for me it might be best to compile a modified version based on the codebase being used for the latest test release in order to have higher compatibility with current OXPs. Sadly, I don't know how to use svn to perform that task and I'm a bit afraid of having to add my little changes to the code again.

Screet

I think it is just typing: svn checkout svn://svn.berlios.de/oolite-linux/branches/1.74-maintenance in the terminal window.
That is not the trunk but a branch that was generated when 1.74 was released. It even contains same small bugfixes that were made after the 1.74.2 release but were not important enough to make it a new release.

To the general question, A_C has been helping slowly work toward a 64-bit build of Windows. We have SDL compiled so far and that's all; so we are a VERY LONG way from even starting to build Oolite itself. And with the recent change in Javascript engines, we are now a VERY, VERY LONG way from it as (IIRC) the new engine isn't supported as a Win64 build. Still, there is at least effort on this front.

Cmd. Cheyd wrote:

And with the recent change in Javascript engines, we are now a VERY, VERY LONG way from it as (IIRC) the new engine isn't supported as a Win64 build,

FireFox has 64-bit Windows nightly, but they appear to be a branch. I don’t know how much customization is involved, but I would expect not very much in SpiderMonkey (as it’s been heavily rewritten recently, and works fine on other x86-64 platforms). So basically, this shouldn’t be an insurmountable obstacle, but building it for 64-bit Windows will probably be even more of a pain than it is on other platforms.

It is very much appreciated that you guys are working on this issue - however long it might take ...

As, in the age of a half thousand oxps with more and more RAM hunger, this is still of interest and probably not only for me ...

*bump*

Lestradae wrote:

this is still of interest and probably not only for me

It would be of great interest to me if I could afford to purchase Win7. Ho hum!

Well following some messing around trying to cure memory allocation crashes related to lots of OXP's and/or models with big textures on my Win 7 machine and with a pointer by another_commander I've successfully compiled Oolite with the LARGEADDRESSAWARE flag set by the existing compiler/development environment. The resulting executable seems to work as normal in a 32bit environment, but in theory allows Oolite to use upto 4GB of RAM rather than the normal 2GB in a 64bit environment. In testing I've got to just over 2.3GB 2.8GB memory usage with no ill effects.

See... https://bb.oolite.space/viewtopic.ph ... 15#p168146

*Bump*y ride to a full 64 bit version, it seems ...