New Release D3D9Client Development

"ENBseries_D3D9_v100"? Can you elaborate what that is / was?
 
You can set the Panel scale setting via the Parameters page of the Orbiter Launchpad to scale any ship's 2D panels to fit a given screen resolution. For example, setting Panel scale to 1.25 would make 2D panels 25% larger (the 1920 panel becomes 2400 pixels wide), and setting it to 2.0 is good for a 4k monitor (the 1920 panel becomes 3840 pixels wide).

Oh, very cool! Thank you very much! That's exactly what I needed.

The "irony" now though is that I've discovered that orbiter crashes on me after a few minutes when I'm in 4K while in 10km above the surface moon orbit; so I can only fly around the moon in HD resolution or at 60km above the surface in 4K--though I haven't test the exacted cut-off point yet. So far everywhere else (rather limited to earth and mars at the moment) works fine in 4K.

(I just figured out how to turn notifications on so I know when someone's responded to this thread--so sorry for the long delay).
 
So, trying to compile the sources for the latest changes I've made to the SSU meshes, the build keeps failing with these kind of error messages:

Code:
9>c:\shuttleultra\orbitersdk\include\gcconst.h(389): error C3646: 'normal': unknown override specifier (compiling source file vc\PanelR11.cpp)
9>c:\shuttleultra\orbitersdk\include\gcconst.h(389): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int (compiling source file vc\PanelR11.cpp)
9>c:\shuttleultra\orbitersdk\include\gcconst.h(390): error C3646: 'pos': unknown override specifier (compiling source file vc\PanelR11.cpp)
9>c:\shuttleultra\orbitersdk\include\gcconst.h(390): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int (compiling source file vc\PanelR11.cpp)
The only thing that has changed code wise since the last time is my VS 2017 version which is now 15.9.7. I'm certainly no C++ expert but to me it seems like MSFT has changed the way some of the base code works and that's why it keeps failing. I'm reporting this here as gcconst.h is part of D3D9Client.
 
Side-Note: Are you sure you have also updated Orbiter (to r85) when you use the current D3D9Client code (r1085)? r1085 is for that Orbiter revision.
Although gcconst.h wasn't changed for that step, it changed at r1082.

Ahh I see: from the line numbers it must be gcconst.h r1062.

You are still on Orbiter r84, you might be better off to not change that too early ;) Focus on one step/error at the time.

For the errors you get (gcconst.h r1062) it looks like D3DXVECTOR3 isn't defined...maybe you did change the include order a bit?!
 
Last edited:
Side-Note: Are you sure you have also updated Orbiter (to r85) when you use the current D3D9Client code (r1085)? r1085 is for that Orbiter revision.
Although gcconst.h wasn't changed for that step, it changed at r1082.

Ahh I see: from the line numbers it must be gcconst.h r1062.

You are still on Orbiter r84, you might be better off to not change that too early ;) Focus on one step/error at the time.

For the errors you get (gcconst.h r1062) it looks like D3DXVECTOR3 isn't defined...maybe you did change the include order a bit?!
Updated Orbiter r85 and everything compiled fine. No changes to anything as I wrote, other than updating VS. In fact, I hadn't done any code work in a few weeks as I have concentrated on the meshes/textures which is why these errors appearing out of the blue was such a surprise.
 
So, another mystery solved! :thumbup:

--- Addendum 2019-02-24 16:55 ---
...solved by Jarmo :)
 
Last edited:
For the errors you get (gcconst.h r1062) it looks like D3DXVECTOR3 isn't defined...maybe you did change the include order a bit?!


I have changed the D3DXVECTOR3 into FVECTOR3 as it should be.

---------- Post added at 18:53 ---------- Previous post was at 08:14 ----------

New build for Orbiter Beta r85 is out. There are some minor bug fixes and the LensFlare now blocks the sun if behind a mesh.
 
I have changed the D3DXVECTOR3 into FVECTOR3 as it should be.

---------- Post added at 18:53 ---------- Previous post was at 08:14 ----------

New build for Orbiter Beta r85 is out. There are some minor bug fixes and the LensFlare now blocks the sun if behind a mesh.

Will this lens flare fix be available also for the O2016 version?
 
Will this lens flare fix be available also for the O2016 version?
Sure. I'll merge the changes jarmonik did into the 2016 branch.
Once this has been done (and checked) I'll drop a note.
Then you'll just have to wait a bit, so jarmonik can upload a new 2016-binary to the official site and voila: it's done ;)

So, just wait a bit!

In the meantime you can use the attached build (r1091), which I will remove once the "official release" is published. "Official release" is out
 
Last edited:
R3.7 is out for Orbiter2016

D3D9Client R3.7 is out for Orbiter2016.
In a zip package below GenericCameraMFD for client versions 3.7 and 28.7

NOTE: 3.7 is exactly the same as Kuddel's build above

@Kuddel
Could the build script be modified to copy the CameraMFD from /modules/plugin/ or should we include the DLL in the svn repository ?
 

Attachments

@Kuddel
Could the build script be modified to copy the CameraMFD from /modules/plugin/ or should we include the DLL in the svn repository ?
Sure, I'll take a look at it this evening.

---------- Post added at 20:35 ---------- Previous post was at 09:44 ----------

Done!

By the way:
DockingCamera.dll appears as "Generic Camera" in the MFD selection menu...
I would like to either change that to "Docking Camera" or rename the Module to GenericCamera.dll (which is more work, but I am willing to do it ;) )

What do you (jarmonik) think?

As a next step I would include DX9ExtMFD project, too.
Again, what do you think?
 
Sure. I'll merge the changes jarmonik did into the 2016 branch.
Once this has been done (and checked) I'll drop a note.
Then you'll just have to wait a bit, so jarmonik can upload a new 2016-binary to the official site and voila: it's done ;)

So, just wait a bit!

In the meantime you can use the attached build (r1091), which I will remove once the "official release" is published. "Official release" is out

Thank you kuddel, that was fast :thumbup:
 
DockingCamera.dll appears as "Generic Camera" in the MFD selection menu...
I would like to either change that to "Docking Camera" or rename the Module to GenericCamera.dll (which is more work, but I am willing to do it ;) )
DockingCamera could be a little missleading since it's not just for docking purposes. But I'll let you to make the decision.



As a next step I would include DX9ExtMFD project, too.


I am working on (as we speak) a new version of the ExtMFD running under OrbiterGUI framework (i.e. ogMFD). It should address the performance and other problems effecting the current ExtMFD implementations. Right now the "DockingCamera" doesn't run under any of ExtMFD(s). It would be running fast and smooth under the ogMFD. So, I guess the DX9ExtMFD could become obsollete after that.

I'll try to get the ogMFD out within a week or two. There is no point in bundling the ogMFD into the client without the GUI itself. Let's get back to this after both has been officially released.

Jarmo
 
Last edited:
DockingCamera could be a little misleading since it's not just for docking purposes. But I'll let you to make the decision.
Yeah, that was also a point favoring the rename.

I went for the rename...(done for both trunk & 2016-branch with r1100)!


I'll try to get the ogMFD out within a week or two. There is no point in bundling the ogMFD into the client without the GUI itself. Let's get back to this after both has been officially released.
Sure 100% agree. One step after the other.
 
Now that the Lens Flare PP has been fixed, I decided to try out it. Looks great although it doesn't seem to take in account meshes rendered using the EXT_PASS option as shown in the below screenshot where the light should blocked by the gimbal lock structure on the Ku band antenna: https://www.dropbox.com/s/4n8rtq1j6ef4k6r/SSU_onorbit_5.jpg?dl=0
 
Can someone post the link for the newest version?
Here: D3D9Client Project


---------- Post added at 07:46 ---------- Previous post was at 07:42 ----------

Now that the Lens Flare PP has been fixed, I decided to try out it. Looks great although it doesn't seem to take in account meshes rendered using the EXT_PASS option as shown in the below screenshot where the light should blocked by the gimbal lock structure on the Ku band antenna: https://www.dropbox.com/s/4n8rtq1j6ef4k6r/SSU_onorbit_5.jpg?dl=0


Can you pick the problem parts using mouse with "Pick" feature selected from "D3D9 Debug Controls". They should highlight in green when pressing LMB on them ?
 
Back
Top