Textures that eat memory - Win7 crashes.

[another_commander]

There are no 1.76.1 nightly builds. Only latest trunk (future v1.77) is built on a nightly basis.

Aha! And, might I enquire, as to my original question?

The only 1.76.1 build supporting large address aware is Capt. Murphy's. Note that, as this build is a third-party one, you are completely on your own with it, we do not offer any kind of support for it whatsoever.

[Gimi]

So ... does the 1.76.1 nightly build already include the 64bit flag set to yes so that the exe will use the 4GB instead of the 2, or is this Capt. Murphy's testversion only at the moment?

There are no 1.76.1 nightly builds. Only latest trunk (future v1.77) is built on a nightly basis.

Aha! And, might I enquire, as to my original question?

The 1.76-maintenance branch source does currently contain the Large address aware switch for the Windows port.
It's rev 4826
If it will stay in is up to the developers. Unreleased and yet to be fully tested I suppose.

Edit: Ninja'ed by one of the gurus.

[another_commander]

If it will stay in is up to the developers. Unreleased and yet to be fully tested I suppose.

Anyone using trunk for testing at this time is also testing the large address aware capability. I'm pretty certain it will stay in, so far I have not seen any kind of problem report associated with it.

[Gimi]

If it will stay in is up to the developers. Unreleased and yet to be fully tested I suppose.

Anyone using trunk for testing at this time is also testing the large address aware capability. I'm pretty certain it will stay in, so far I have not seen any kind of problem report associated with it.

To the contrary, Oolite memory behavior and speed seems to be much improved in trunk. But it's not for me to say that something is included without the appropriate caveats. I'm not a developer.

[Capt. Murphy]

There are no 1.76.1 nightly builds. Only latest trunk (future v1.77) is built on a nightly basis.

Aha! And, might I enquire, as to my original question?

The only 1.76.1 build supporting large address aware is Capt. Murphy's. Note that, as this build is a third-party one, you are completely on your own with it, we do not offer any kind of support for it whatsoever.

And as a_c has advertised presence of said build if you need a windows 1.76.1 installer (with minor cosmetic alterations to make it clear it's not an official or supported release), because you have problems with 1.76 and don't want to use trunk (all the bug-fixes including LARGE_ADDRESS_AWARE are in both trunk and 1.76.1) then send me a PM. This is mostly aimed at people with Intel HD / HD2000 / HD3000 GPU's which really really don't get on with 1.76 under Win 7.

Having said that I would encourage any member who has been round for a while to look into setting up a development environment. It's not hard following the instructions from here https://bb.oolite.space/viewtopic.php?f=8&t=5943. Once done it's all of about 20 seconds work to update your local copy of the source (whether that's trunk or the 1.76.1 maintenance branch) and compile Oolite. It's quicker than downloading a nightly on my machine.

[Lestradae]

There are no 1.76.1 nightly builds. Only latest trunk (future v1.77) is built on a nightly basis.

Aha! And, might I enquire, as to my original question?

The only 1.76.1 build supporting large address aware is Capt. Murphy's. Note that, as this build is a third-party one, you are completely on your own with it, we do not offer any kind of support for it whatsoever.

What I am still not getting from the above debate (and, have mercy on me, concerning the most internal workings of Oolite I am not even a noob) is why a flag that can be set to support 4GB memory at least on 64bit Win7 machines isn't being set in the 1.77 trunk version as standard?

Regards

L

[Gimi]

What I am still not getting from the above debate (and, have mercy on me, concerning the most internal workings of Oolite I am not even a noob) is why a flag that can be set to support 4GB memory at least on 64bit Win7 machines isn't being set in the 1.77 trunk version as standard?
Regards
L

It is set in 1.77 trunk as standard, Rev 4841. It was later ported to 1.76 maintenance in Rev4846.
You can learn a lot about what is going on by just reading through the Oolite commit logs at Berlios. Even though I haven't programmed in 15 years, and never was any good at it, it allows my to understand a little bit about what the devs are doing.

[Lestradae]

It is set in 1.77 trunk as standard, Rev 4841. It was later ported to 1.76 maintenance in Rev4846.

Thanks, that clears that up for me. I was confused by A_C's reply that this was only a third party branch of the Oolite exe, but the confusion was indeed mine - I thought trunk was 1.76.1 and not already 1.77.

Thanks for the patience.

[Lone_Wolf]

What I am still not getting from the above debate (and, have mercy on me, concerning the most internal workings of Oolite I am not even a noob) is why a flag that can be set to support 4GB memory at least on 64bit Win7 machines isn't being set in the 1.77 trunk version as standard?

Regards

L

To clarify : the large address aware flag is only needed on windows 32-bit versions.

[Capt. Murphy]

To clarify : the large address aware flag is only needed on windows 32-bit versions.

Err I'm not quite sure if you mean that...

Large Address Aware flag allows 32bit applications to use 4GB of memory (rather than 2GB) on 64bit Windows.

Large Address Aware flag in combination with a Boot.ini tweak allows 32bit applications to use 3GB of memory (rather than 2GB) on 32Bit Windows with 3GB or more installed ram. If no Boot.ini tweak it's ignored.

http://msdn.microsoft.com/en-us/library ... ory_limits

[Lone_Wolf]

Guess i have to rephrase :
Large address aware is only useful for 32 bit Oolite versions running on 32 or 64 bit windows.
See cpt Murhpy's post above for details.

[Lestradae]

Just tried out the new trunk 1.77 on Windows 7 with 409 (!) oxps in - and am massively impressed.

The crashes I used to have reliably after two or at least three jumps seem to be gone. Did ten jumps in a row and not a stutter. Using more than 2GB RAM (with Windoof taking up 1+Gb of those) seems to pay off.

My nice oxp witchjump effect is gone, though, not sure if that is a known issue, and my textured planets are sometimes textured and sometimes white golf balls which suddenly change into the Oolite procedurally generated ones. If that is new information I'll provide more about that.

Nice work by all devs!

[cim]

My nice oxp witchjump effect is gone, though, not sure if that is a known issue, and my textured planets are sometimes textured and sometimes white golf balls which suddenly change into the Oolite procedurally generated ones. If that is new information I'll provide more about that.

The golf ball is due to the new planet texturing not yet setting up the atmosphere properly when the ground texture is externally-provided. They're just really really cloudy... (it's a known issue which should get fixed naturally as work on that bit of the code continues)

OXP witchjump effects disappearing? Ah...is it BGS? BGS generates those effects by placing a dummy ship near the player, and then using some extreme shader effects to make it appear as a full-screen overlay. Very cleverly done. Unfortunately, in trunk, ships which aren't within the camera aren't drawn (as opposed to 1.76, which draws them and then almost always discards the result as being out of view, which is somewhat inefficient). If you switch to one of the external views while doing the jump sequence, then you might be able to see it again. Thanks for pointing this out - I'll go and talk to the BGS developers.