New Release D3D9Client Development

[JimiJamesMR]

No visual helpers

Hi all.

First of all, a big thank to the developer/s for this DX external client for Orbiter :tiphat:

As the client got already some time being used and tested, I imagine the issue I'm going to mention is already reported. I'm referring to the visual helpers, Force Vectors in vessels in particular. They only work on vanilla orbiter, but they don't on D3D9 or D3D7 clients (didn't try D3D11 as I have a DX10 graphics card myself). I'm very interested in this feature.

Is there any well known fix to this issue I'm not aware of? (apart from running orbiter vanilla and not the orbiter server).

If not, is to reimplementing it back on the TODO list of D3D9 client? Is there any addon that brings back the force vectors?

Thanks very much.

 

[orb]

Orbiter doesn't provide the required interface to the external graphics client to display them. See that post for a possible hack that may be implemented in the client in future.

By the way, the D3D11Client supports DX10 graphics cards.

 

[JimiJamesMR]

Orbiter doesn't provide the required interface to the external graphics client to display them. See that post for a possible hack that may be implemented in the client in future.

By the way, the D3D11Client supports DX10 graphics cards.

Thanks very much.

Do you know if the orbiter latest beta has added the required interface to implement visual helpers on the external client? I saw those Oibiter betas on OVP sourceforge site, I think, but didn't try them myself.

Didn't know I could use D3D11Client; might try it, but I don't know if it is so settled as D3D9. It'd be nice if it supports the Dan's DeltaGlider IV-2 addon that D3D9 currently doesn't support.

 

[jarmonik]

D3D9Client RC45

Sorry about being away for a while and I may be away for an other while or so. But here is a minor project update. There are some changes in an animation code and surface code, so, any new anomalies in surfaces and animations should be reported asap.

- Fileparser bug fixed
- One new fullscreen mode
- Insurface blitting work-a-round
- MFD Specularity bug fixed
- DGIV Antenna animation should work now
- Failed to release warning removed
- Stereo convergence set

ALT-TAB

Is it my old rig too old or RC44 is always loosing connection to the Direct3DDevice when Alt-Tab is pressed or when searching at Help dialog from ALT-F1?

Alt-Tabing won't work in "true" Full Screen mode and it's never going to work. Use windowed fullscreen mode.

Moons Names
I was getting some errors in Orbiter.log:

Planet Not Found 'Kale                    '
hPlanet is NULL in FileParser::ScanBases(Config\Kale\Base)
Planet Not Found 'Ymir                    '
hPlanet is NULL in FileParser::ScanBases(Config\Ymir\Base)
Planet Not Found 'Paaliaq                 '
hPlanet is NULL in  FileParser::ScanBases(Config\Paaliaq\Base)....etc

These moons have only one thing in common: in their cfg there is a comment like this:

; === Configuration file for moon Kale-S/2001_J8(Jupiter) by Rolf Keibel Carl Romanik and Tony Dunn ===
Name = Kale                    ; S2001-J8
EllipticOrbit = TRUE           ; assume unperturbed orbit
HasElements = TRUE             ; orbital elements follow .....etc

If I remove the " ; S2001-J8" comment, the error is gone.

Can the FileParser.cpp be made to check the "Name" string untill the ";" sign (or any other way to support having comments after the Name)?
Edit: If I have one or more " " (spaces) after the Name I get "Planet Not Found 'Ymir ".

This should be fixed now.

I guess you are standing on the equator? I can confirm that one. However this I also happening without D3D9 client.

-------------------------------------------

I noticed this while on approach to KSC:

In the first image, I have the center of the base in sight and see the runway lights.
But when the center of the base is out of sight, the lights disappear.

Runwaylights must be in the same base configuration file as the runway itself.

You can compile it from the sources without the /arch:SSE2 switch.

Athlon XP doesn't support SSE2, only SSE.

As mentioned above, if you have Visual Studio / C++ Express, you can recompile D3D9Client from sources with /arch:SSE instead of /arch:SSE2.

D3D9Client requires XNA Math support, therefore, simple rebuild without SSE2 is unlikely going to work.

We're slowly starting to test IMS on DX9 client, and there seems to be trouble with the panel.

First off, it is impossible to load an older scenario. The log file starts to produce these messages:

!! ERROR !! Target and source is the same surface. If this is a  texture then specify (IMS\IMSmainpanel.dds) in D3D9Client.cfg  InSurfaceBlit
D3D9ClientSurface::CopyRect() Failed

Lots of them, of course. It is standard practice for orbiter vessels to have their panel bitmaps and the actual panel area in the same texture (all tutorials do it that way), and it's no problem in orbiter itself, so I'd consider this a bug. I take it from the message that I have to specify the texture somewhere in a config file, but surely there must be ways around forcing the user to edit a config when he wants to load an older scenario?

If the vessel is not loaded from scenario but created by scenario editor, there is no crash, however the panel doesn't show up at all. I can't say wheather this is because of the same problem or because the client can't read DXT5 compression (32 bit), but since creation of texture surfaces from a dds file is a default feature of DirectX I would expect the former.

This problem should be fixed.

In the D3D9 client when in external view, the mouse behave erratically.
When I press the right mouse button and rotate my view around an object, it moved in a erratic way.
In the vanilla orbiter installation the rotation is smooth, so it is not my mouse.

I can't reproduce this. It could happed due to loading of surface bases. Try pre-load option. Also surface tiles could cause it in a single core CPUs. Try pre-load option.

Hi.
I am running RC41 with 111105 Beta in full screen mode (actually stereoscopic 5760x1080 x 120 Hz on 3 monitors / Nvidia glasses). Everything is fine until I press any key that pops up a window, like change ship (F3), or display info. The dialogue window does not appear, and the screen mode somehow changes, loosing all stereoscopic effects in display (with glasses it then looks like a double picture as seen in functional stereoscopic mode without glasses). This loss of 3D is also happening with other screen resolutions like 1980x1080x120Hz single monitor. Monitor info says it is still running with 120 Hz refresh needed for stereo.
The 3D stereoscopic display is not lost when using keys not creating a pop-up window, like F1, F8, F9, or F4, or when popping up an MFD.

When running windowed mode (non-stereoscopic), the pop-up windows work fine - thus I assume it is not a problem with the installation.

I am aware that this may be an exotic problem to many not running stereoscopic mode, but then D3D9 is giving anyone the experience of a livetime in 3D - hence I do appreciate a check of the probable cause (and would offer a donation for that great D3D9 client work).

Regards - Robert S.

It is known that dialog windows won't work with antialiasing (multisampling) so make sure it's disabled. Also the stereo effect may conflict with the GDI based dialog windows in a multi display configuration. What I have tested I couldn't detect any problems in a single display configuration with Red-Cyan glasses. In my computer the stereo mode seems to work in a windowed mode as well. If you have something called SLI, you could try to disable it and see if it helps.

(edit: Green-Mangenta glasses may work if used backwards)

 

[N_Molson]

AAAhhhrg !! *full hystery*

:hail: :hail: :hail:

:thumbup:

 

[blixel]

Use windowed fullscreen mode.

A bit off topic perhaps ... but regarding fullscreen windowed mode, would it be possible to have an option to have windowed full screen mode set so there are no window borders/decorations? (e.g. No title bar.) Several games I play have this option. It creates the illusion of playing normal full screen mode. This is desirable if you want to record your screen for the sake of making videos. As it is now, I record my screen and trim 30 pixels off the top to hide the title bar, and 3 pixels off the left, right, and bottom edge to hide the window border. So technically my Orbiter resolution is 1914x1047 instead of 1920x1080

Not a big deal by any means. But it would be nice to have a genuine full screen windowed mode.

 

[N_Molson]

Not a big deal by any means. But it would be nice to have a genuine full screen windowed mode.

It's exactly what the option does on my computer. I have full screen and Alt-Tab working when I select the new option.

 

[Enjo]

It'd be nice if it supports the Dan's DeltaGlider IV-2 addon that D3D9 currently doesn't support.

That's the other way around.

 

[STS]

Orbiter closes when I try RC45 with a DeltaGlider IV Scenario. Are you sure it´s working?

Finished setting up render state
Orbiter Version 100830
D3D9Client Build [Aug 11 2012]
Exception Code=0xC0000005, Address=0x00412958
EAX=0x044F3D90 EBX=0x0A3D0024 ECX=0x00000000 EDX=0x00000400 ESI=0x00000000 EDI=0x00000000 EBP=0x0A5BF468 ESP=0x009FF410 EIP=0x00412958
C:\Users\TurryBoeing\Documents\Orbiter2010P1\modules\server\orbiter.exe EntryPoint=0x004ACFAC, Base=0x00400000, Size=2097152
Critical exception in gc->RegisterVisObject(0x929D578, 0xE878918) (GL-01).
VesselClass Name = DeltaGliderIV
!!! Abnormal Program Termination !!!

 

[jarmonik]

Orbiter closes when I try RC45 with a DeltaGlider IV Scenario. Are you sure it´s working?

Finished setting up render state
Orbiter Version 100830
D3D9Client Build [Aug 11 2012]
Exception Code=0xC0000005, Address=0x00412958
EAX=0x044F3D90 EBX=0x0A3D0024 ECX=0x00000000 EDX=0x00000400 ESI=0x00000000 EDI=0x00000000 EBP=0x0A5BF468 ESP=0x009FF410 EIP=0x00412958
C:\Users\TurryBoeing\Documents\Orbiter2010P1\modules\server\orbiter.exe EntryPoint=0x004ACFAC, Base=0x00400000, Size=2097152
Critical exception in gc->RegisterVisObject(0x929D578, 0xE878918) (GL-01).
VesselClass Name = DeltaGliderIV
!!! Abnormal Program Termination !!!

Well, that version isn't working. There was a new version of DGIV under a beta test about half a year ago. Obviously, it isn't released yet. I haven't paid much attention lately. Looks like it's no-go at a moment.

Also, it looks like a thread name can no longer be changed in this forum. It still reads RC44 even if I tried to change it to RC45. If that's the case then maybe the version number could be removed from the name.

 

[DaveS]

Nice to have you back jarmonik. Just one that needs fixing: PAPI lights should be along the runway centerline. Currently D3D9Client places them off to one side like the VASI lights.

 

[Poscik]

How to enable this stereo view? I just can't figure it out :< I have GeForce GTS450, so it's supported.

 

[jarmonik]

How to enable this stereo view? I just can't figure it out :< I have GeForce GTS450, so it's supported.

As far as I can tell it's only available for nVidia hardware. Go to the nVidia control panel and select Stereoscopic 3D and run Setup Wizard.

After that you can enable/disable the feature from
Start->All Programs->NVIDIA Corporation->3D Vision->

The ability to run it in a windowed mode will depend about the hardware. SLI/Multi GPU cards aren't supported in windowed mode only in a "true" full screen mode which unfortunalely may conflict with GDI based pop-up dialogs.

 

[Ripley]

Welcome back Jarmo, even if for a little while.
I do hope Dan releases his new DGIV-3 soon now

 

[Phoenix]

I want to thank the developer/s of the D3D9 client - it greatly improves frame rate - but I would like to report the same problem with hires base tiles and night lights as detailed in an earlier post:

Some more unstructured testing: I get night light textures appearing on the KSC surface tile, day or night. This is on a laptop with Intel GMA 965 Express graphics, vanilla Orbiter 100830 and RC42. The actual texture displayed changes with camera angle, see pictures two and three - suggests to me a possible link with the runway lights? I've tried the Earth L14 textures which has the same behaviour. In addition, the nightlights toggle in Visual Effects tab seems to have no effect.

Note - this seems to be specific to one laptop - I cannot reproduce this on a I3/Intel HD3000 laptop.



Another vote for this feature, not necessarily for debugging but for general use.

(Edit)

and just got this when adding a celestial sphere image (the sphere flashes green and magenta):

I am using client version RC45 with Orbiter 2010 P1, but the client did the same with RC44. The graphics chip is: Mobile Intel(R) 4 Series Express Chipset Family. Part of the Orbiter log is as follows:

**** Creating simulation session
D3D9Client: Sytem has XNA math support
D3D9Client:WARNING: [Hardware has only a limited non-power of 2 texture support]
D3D9Client: [3DDevice Initialized]
D3D9Client: [Compiling Effects for Shader Model 3.0]
D3D9Client: [Loading Stars]
D3D9Client: [Loading Constellations]
D3D9Client: [D3D9Client Initialized]

Thanks.

Edit:

The problem seems to be related to specular highlighting, as it can be fixed by disabling this visual effect.

 

[jarmonik]

The problem seems to be related to specular highlighting, as it can be fixed by disabling this visual effect.

Which one of the problems and which specular setting exactly ? (There are three of them)

Specular map and the night lights are stored in the same texture so they could be connected somehow. I could take a quick look into it.

There are some reports about strange anomalies with older Intel Graphics Chips. If the problem is reproducable with ATI/nVidia hardware then we are very likely talking about a real software problem in the client, otherwise I fear, it's a hardware/driver problem.

 

[Phoenix]

Sorry, it's specular water reflections. The night lighting texture changes depending on camera angle. I also occasionally get the huge lights appearing near bases, as described in a previous post, but not always.

---------- Post added at 01:24 PM ---------- Previous post was at 01:08 PM ----------

I may have found a "fix" but it may break something else. In the planet.fx file I added the line "frg.aux.b=0":

float4 PlanetTechPS(TileVS frg) : COLOR
{
 
// Change by Phoenix.  
frg.aux.b=0;
 
    float4 diff  = frg.aux.g*(gMat.diffuse*frg.diffuse) + (gMat.ambient*frg.aux.b); 
    float  micro = 1.0f;
 
    if (gMix>0.0f) micro -= tex2D(Planet3S, frg.tex1).a;
 
    float4 vSpe = frg.aux.r * (gWater.specular*frg.diffuse) * micro;
    float4 vEff = tex2D(Planet1S, frg.tex0);
    if (gSpecMode==2) vSpe *= 1.0f - vEff.a;
    if (gSpecMode==0) vSpe = 0;
 
 float3 color = diff.rgb * tex2D(Planet0S, frg.tex0).rgb + frg.aux.a*vEff.rgb + 
vSpe.rgb;
    return float4(color*frg.atten.rgb+gColor.rgb+frg.insca.rgb, 1.0f);
}

 

[jarmonik]

I may have found a "fix" but it may break something else. In the planet.fx file I added the line "frg.aux.b=0":

That really doesn't make much sense because aux.b is controlling the twilight and global ambient level. It has nothing to do with nightlights. Could it be possible that the effect compiler is getting the code wrong and that might cause the problem from the first place.

Do you get the same results if you replace frg.aux.b=0 with frg.aux.z=0
The nightlights intensity is controlled by aux.a (i.e. aux.w)

aux.r = aux.x
aux.g = aux.y
aux.b = aux.z
aux.a = aux.w

 

[Phoenix]

That really doesn't make much sense because aux.b is controlling the twilight and global ambient level. It has nothing to do with nightlights. Could it be possible that the effect compiler is getting the code wrong and that might cause the problem from the first place.

Do you get the same results if you replace frg.aux.b=0 with frg.aux.z=0
The nightlights intensity is controlled by aux.a (i.e. aux.w)

aux.r = aux.x
aux.g = aux.y
aux.b = aux.z
aux.a = aux.w

Yes, frg.aux.b has the same effect as frg.aux.z and so appears to be controlling night light intensity.

The comments in your effects code has this:

float4 aux     : TEXCOORD5;  // Specular, Diffuse, Twilight, Night Texture Intensity,

which seems to be saying that it is aux.b (or aux.z) which is the controlling variable, and not aux.a (or aux.w), as seems to be borne out in the test - at least on my computer. But then you have another line of code which says:

float4 diff  = frg.aux.g*(gMat.diffuse*frg.diffuse) + (gMat.ambient*frg.aux.b);

I'm confused - I'm not an expert with pixel and vertex shaders. frg.aux.b=0 (or z) seems to switch off nightlights in the hires base tiles. Even if they correctly only rendered at night, they wouldn't be right anyway, so switching them off seems to work for me (as long as it doesn't degrade other rendering). There is an image posted earlier in this thread which shows the repeat tiling effect that changes depending on camera angle.

It must be a problem with my computer. Thanks for your help.

 

[jarmonik]

float3 color = diff.rgb * tex2D(Planet0S, frg.tex0).rgb + frg.aux.a*vEff.rgb + vSpe.rgb;

This is the line that will combine diffuse color, night lights and specular reflection. vEff.rgb is the night light color and the intensity is controlled by aux.a (aux.w). So, it looks like something is mixing up the vector components in your computer. (vEff.a is the specular water/land mask)

A vector component like aux.a (or aux.w) can be also addressed as frg.aux[3]. The index is from range 0 to 3. You could change all frg.aux.* to use the format frg.aux
[*] from the PlanetTechPS section.

I have seen the tiling effect a few times after installing a broken add-on. The texture file is probably corrupt. Does it occur in a clean installation.

Of course, all these anomalies could be caused by the same problem with the effect compiler or with the GPU.