New Orbiter SVN commit (r.71, Oct 14 2017)

Thanks for the response. In fact, I do not have a choice of graphics, just Nvidia. I have tried with the default Nvidia settings in Control Panel, and the Nvidia Graphics Card works fine with other applications.

Thanks anyway for your help.
Best wishes

Upkeep.

Right-click on the NVIDIA icon near the clock, and there should be an option to show a contxt menu, or something simillar. That enables the menu entry I'm talking about.
Or you can set the default GPU for a program in the NVIDIA control panel.
 
Tried Control Panel again. Unfortunately I have no option to change from Nvidia. I do not have an Intel driver installed, just Nvidia GTX 770. Looking at the back of the PC there are no other graphic card ports.

Thanks for trying.

All the best
Upkeep
 
Tried Control Panel again. Unfortunately I have no option to change from Nvidia. I do not have an Intel driver installed, just Nvidia GTX 770. Looking at the back of the PC there are no other graphic card ports.

Thanks for trying.

All the best
Upkeep
The "dual-GPU" option that GLS is talking about is only available on laptops. It works by switching between the integrated GPU ("IGPU") which is built into your CPU and the dedicated external GPU ("EGPU"). It uses the IGPU during low graphics load situations to conserve battery lifetime. When it senses a high graphics load it should automatically switch over to the more powerful but more battery-demanding EGPU. As soon as this load disappears again, it switches back to the IGPU.


Desktop PCs don't have this function as they don't rely on battery power so they're free to stick to the EGPU at all times.


Where does your the cable from monitor plug in currently? Is it into the graphics card itself or into the motherboard?
 
It plugs into the graphics card itself using DVI plug

Best wishes
Upkeep
 
Just to be absolutely sure the DirectX 9.0c is really installed (I do believe you know what you're doing, so sorry if it sounds ridiculous...
but I know for example that some people still try the web-installer and that one does not do it right for 9.0c)

Can you check these files versions, please: DirectX 9.0 (June 2010 release)
search for the following files:

%WinDir%\System32\D3DX9_43.dll with version 9.29.952.3111
%WinDir%\System32\d3dx10_43.dll with version 9.29.952.3111
%WinDir%\System32\d3dx11_43.dll with version 9.29.952.3111

(BTW, the list is from here)
 
Last edited:
I could be wrong, but something from the back of my head suggested me: could you try to rename the file Device.dat in your Orbiter root folder, and see if it gets recreated upon next start?
 
Yes it does get recreated. But still no luck.
Thanks again for trying.
All the best
Upkeep
 
A very nasty little problem you present here...
Maybe this is not an option for you, but since you're having these problems after you've updated your NVIDIA driver to 411.70, would a downgrade to a former version be an option to try?
Or does the 411.70 version need a BIOS update, too? But I doubt, 'cause you can run other applications (DX10, 11 or 12 I presume) without issues.
 
Thanks for your response.

Yes, going back to a much earlier driver is an option I could try in principle. I expect there is not any particular problem doing so (except for establishing how far to go back as this issue has been around for me for a while now).

I am now currently running Nvidia driver 416.34 which produced the same problem with Orbiter, not surprisingly. Nividia seem to update their drivers very frequently...

I am nevertheless reluctant to go back to an earlier driver for a number of reasons:

1. All my other applications are working well with the new driver and I even appear to be getting better fps on some.

2. I am concerned about damaging my system in the process of going back to an older driver. I realise the risks are probably low here of course.

3. On principle I am not keen on using old drivers for anything. They are usually updated for a reason and Windows may well be updated in tandem with new releases from vendors. I like to keep the pc update to date as best I can.

The strange thing is that usually, when a driver is updated, other people suffer the same problem and some expert is able to find a solution. I am not an expert at all and tend to be risk averse as far as fiddling with software is concerned. So I seem to have a uniqiue set-up here

I think I am back to square 1 on this one, sadly.

Anyway, thanks everyone for your efforts to help.

I do appreciate them.

Best wishes

Upkeep
 
Yes. That is correct. Applications was no doubt the wrong terminology. Sorry about that.

Best wishes

Upkeep
 
Is there any new information on this problem with the new Titan textures in the D3D9 client? In particular, is the problem with the textures themselves (i.e. something I need to fix) or with the D3D9 code that somebody else is going to look into? ;)

Is it linked to the cloud layer and/or cloud shadows? What happens if clouds are disabled?

About these new Titan textures, I've taken 4 screenshots (scenario is "The Solar System - Titan", starting paused):

Orbiter2016, default textures

onLLML2.png



Orbiter2016, D3D9Client2016-R3b, default textures

cJZUjdx.png



Orbiter2016, HiRes Titan textures + new config

TV1jP0A.png



Orbiter2016, D3D9Client2016-R3b, HiRes Titan textures + new config

SSncq01.png
 
Is there any new information on this problem with the new Titan textures in the D3D9 client?


The problem with Titan textures is caused by a missing configuration file for Titan's atmosphere. The file was uploaded to D3D9 SVN right after the discovery of the problem. I'll have to double check if the file is actually present in the latest release.

The file appears to be there in Orbiter BETA build of the Client but is missing from 2016 build.
 
Last edited:
:thumbup:
I can confirm, that
a) the 2016 Version (of D3D9Client) is lacking those configuration files[1]
b) with them, Titan looks nice in Orbiter 2016.
...I'll wait for Jarmo to commit those files into the branch.

[1] Titan.atmo.cfg and Titan.atms.cfg
 
I've updated to the latest D3D9 (R3.1), but the result is no changes to the 4 screenshots I already posted, which are still exactly the same.
BTW, it might be obvious, but those screenshots were all taken with cloud layer ON.


I've taken 4 new screens, all with cloud layer OFF, and here they are:

O2016 - HiRes tex - D3D9 R3.1 - Cloud layer OFF
M46cxBj.png



O2016 - HiRes tex - Cloud layer OFF
qIG3PUC.png



O2016 - Def tex - D3D9 R3.1 - Cloud layer OFF
WcCUGjf.png



O2016 - Def tex - Cloud layer OFF
H66pHtf.png
 
There is a small problem on the roof panel in stock DeltaGlider. Some of the scematics are invisible in D3D9. The reason is that the alpha channel is set to be fully transparent in (blittgt1.dds). For some reason the DX7 Inline engine seems to ignore the transparency. I don't know what steps leads to this result. One way to fix this is to convert the file in DXT1 format without alpha. That seems to be working in both DX7 and DX9.
 

Attachments

  • Problem.jpg
    Problem.jpg
    36.1 KB · Views: 25
Callisto & Ganymede in Orbiter BETA (r84)

I was clicking through the "The Solar System\Grand tour.scn" scenaio and found that Callisto and Ganymede were just black rsp. white spheres[1].

I could circumnavigate the problem by
1. getting Textures\Callisto.tex and Textures\Ganymede.tex from Orbiter 2016
2. remove/comment-out the "TileFormat = 2" line(s) in Config\Callisto.cfg and Config\Ganymede.cfg so that the "old .tex" files are used.

My question is: Did I miss some Hi-Res package that contain those two moons? (Minor bodies doesn't)
or are we lacking Hi-Res textures for them and the (Orbiter BEAT) repository should be "modified" as I did locally?

[1] black when using D3D9Client, white when using the inline client
 
I was clicking through the "The Solar System\Grand tour.scn" scenaio and found that Callisto and Ganymede were just black rsp. white spheres[1].

I could circumnavigate the problem by
1. getting Textures\Callisto.tex and Textures\Ganymede.tex from Orbiter 2016
2. remove/comment-out the "TileFormat = 2" line(s) in Config\Callisto.cfg and Config\Ganymede.cfg so that the "old .tex" files are used.

My question is: Did I miss some Hi-Res package that contain those two moons? (Minor bodies doesn't)
or are we lacking Hi-Res textures for them and the (Orbiter BEAT) repository should be "modified" as I did locally?

[1] black when using D3D9Client, white when using the inline client

I'm running r84 and have both a Callisto\Archive\Surf.tree and a Ganymede\Archive\Surf.tree, and both look normal on MOGE and D3D9.
Did you install r84 over the Orbiter 2016 release? I think that is the way to do it, as some files aren't in the repository.
 
Ganymede and Callisto should already have been included in .tree format in the Orbiter 2016 release version. They are fairly lowres, so there was no reason to include them in the MinorBodies highres package. Are you sure they are missing?
 
Back
Top