Problem Out of memory

[cristiapi]

After few minutes of flight, the "Virtual size" allocated by Orbiter 2016 (I use Sysinternals Process Explorer) goes beyond 4 GB and Orbiter crashes (I have 16 GB SDRAM and Win7 64 bit).

My installation: Orbiter 2016 + D3D9Client2016-R1 + OrbiterSound40_20121120 (nothing else).
I activated all the checkboxes in Parameters -> Realism and Parameters -> Perturbations and I use Mesh resolution = 128 in "Video -> Advanced".

1) Is there any way to fix the problem?

2) Is there any chance to see "Orbiter 2016 64 bit"?

Thank you

 

[Face]

After few minutes of flight, the "Virtual size" allocated by Orbiter 2016 (I use Sysinternals Process Explorer) goes beyond 4 GB and Orbiter crashes (I have 16 GB SDRAM and Win7 64 bit).

My installation: Orbiter 2016 + D3D9Client2016-R1 + OrbiterSound40_20121120 (nothing else).
I activated all the checkboxes in Parameters -> Realism and Parameters -> Perturbations and I use Mesh resolution = 128 in "Video -> Advanced".

It would be interesting to know if this also happens to you if you:

1. remove the known incompatible OS and
2. use the inline client instead of D3D9Client.

This could help to understand if it is OS, D3D9, or Orbiter itself that runs over the memory.

 

[Ripley]

...remove the known incompatible OS...

For a moment I thought you meant Operating System!!
:rofl:

 

[cristiapi]

[*]use the inline client instead of D3D9Client.

What is "the inline client"?

 

[Face]

[*]use the inline client instead of D3D9Client.

What is "the inline client"?

Orbiter's default graphics system.

 

[Urwumpe]

What is "the inline client"?

It is also called MOGE. martins own graphics engine.

Orbiter.exe instead of Orbiter_ng.

 

[cristiapi]

It would be interesting to know if this also happens to you if you:

1. remove the known incompatible OS and
2. use the inline client instead of D3D9Client.

The virtual size allocation without OS4 and without D3D9Client is negligible (about 700 MB) and Orbiter 2016 doesn't crash.

 

[Face]

The virtual size allocation without OS4 and without D3D9Client is negligible (about 700 MB) and Orbiter 2016 doesn't crash.

And running just without OS4, but still with D3D9? If that gets you memory problems again, I think your best bet is to report this to the D3D9Client team (jarmonik and kuddel) in the appropriate threads. I think this is the dev thread.

 

[cristiapi]

With D3D9 (with or without OS4) the virtual size value is steadily increasing. It seems that D3D9 never frees the allocated textures (or whatever it allocates).
Is that a known problem or it happens just to me?

Addendum:
I did a search for "64*bit" but I found nothing.
Is there any "reference" thread or link for an Orbiter 64 bit plan?
I'm asking because I really don't understand the reasons for a 32 bit version.

 

[Face]

With D3D9 (with or without OS4) the virtual size value is steadily increasing. It seems that D3D9 never frees the allocated textures (or whatever it allocates).
Is that a known problem or it happens just to me?

No clue. I think you really should report this to the D3D9 team.

 

[Linguofreak]

Addendum:
I did a search for "64*bit" but I found nothing.
Is there any "reference" thread or link for an Orbiter 64 bit plan?
I'm asking because I really don't understand the reasons for a 32 bit version.

Orbiter itself (without addons, Orbiter sound, or graphics clients) is a one-man project with a slow release schedule that started before 64-bit CPUs were common on consumer hardware, and long before many people were running 64-bit Windows. Martin's effort on the latest release (which took 6 years because it's a hobby project for him, not a job) was mostly focused on adding terrain support. If he chooses to add 64-bit support, it would probably be a good part of the effort he devoted to the next release, which, judging from prior releases, might take as long as 5 years. DLL addons would then need to release separate versions for 32 and 64-bit, otherwise, 64-bit users would have almost no addons. So the community would probably need to put together a DLL to implement some sort of bytecode to code addons in a platform-neutral manner.

In short, it will probably be a lot of work for a lot of people that have lives outside of Orbiter.

 

[Face]

I did a search for "64*bit" but I found nothing.
Is there any "reference" thread or link for an Orbiter 64 bit plan?
I'm asking because I really don't understand the reasons for a 32 bit version.

Martins certainly thought about it, because he made an effort to do this: http://orbiter-forum.com/showthread.php?t=36770 .

Check the thread there, perhaps you can understand it better then.

 

[cristiapi]

Thank you for the link (I don't know why a search for "64*bit" doesn't show that thread).

The focus of that thread is the /LARGEADDRESSAWARE flag (on 32-bit executable), while I don't see the reason for not to publish a "real" 64-bit release. What I mean, is that when I need to generate a 64-bit program, I just need to change the target platform and I get a 64-bit executable or a 64-bit dll without any problem.
Hence my question is just: why Martin doesn't change the target platform from 32 to 64 bits and compile the source to get a 64-bit executable? What do I'm missing here?

---------- Post added at 22:36 ---------- Previous post was at 22:33 ----------

[...]If he chooses to add 64-bit support, it would probably be a good part of the effort he devoted to the next release,

Could you explain why?
[I'm just asking, I'm not saying that it's not true]

 

[Face]

The focus of that thread is the /LARGEADDRESSAWARE flag (on 32-bit executable), while I don't see the reason for not to publish a "real" 64-bit release. What I mean, is that when I need to generate a 64-bit program, I just need to change the target platform and I get a 64-bit executable or a 64-bit dll without any problem.

Well, from my personal experience it is not "just that". In a legacy software that I had to convert, I ran in almost all of the problems listed e.g. here and there.
It gets even more problematic if you are not working with monolithic systems, but modular ones, like Orbiter. E.g. how to deal with a mixed addon infrastructure, how to introduce necessary interface-changes, etc.

But of course I can't speak for Martin's code.

Hence my question is just: why Martin doesn't change the target platform from 32 to 64 bits and compile the source to get a 64-bit executable? What do I'm missing here?

AFAIK, due to the not-so-easy procedure (as hinted above) he opted for not doing it just now.
But this question is best ask to him personally. Keep in mind that he is not patrolling the forums deeply enough to catch every question starting with "why is Martin (not) doing this and that". Especially not if it turned out to be a premature fix for a problem probably not originating in Orbiter's code at all.

 

[Linguofreak]

What I mean, is that when I need to generate a 64-bit program, I just need to change the target platform and I get a 64-bit executable or a 64-bit dll without any problem.
Hence my question is just: why Martin doesn't change the target platform from 32 to 64 bits and compile the source to get a 64-bit executable?

Ideally, yes, all you need to do to port a program to 64 bit is to recompile. However, in practice, when you have spent a long time writing a large program with a single platform in mind, your code tends to contain a lot of things that are not bugs on that platform, but are on other platforms. As a result, the first attempt at recompilation results in a *ton* of errors, which you need to go through and fix one by one.