New Release D3D9Client Development

[kuddel]

Using "GetModuleFileName (oapiGetOrbiterInstance (), ptrToOutputCharBuffer, charBufferLength);" will get you path to orbiter.exe in Modules/Server and not its root dir (because that's where the loaded orbiter.exe is located), and Spacecraft3 has GetModuleFileName in its import table.

Thanks a lot for the information!
Hopefully I don't memorize it when coding Orbiter modules

While being at this "path issue": I know that the PathRoot enumeration in OrbiterAPI.h is used at several places in the API to set the path origin when loading files for example (e.g. oapiOpenFile ).
Shouldn't we ask Mr. Schweiger (martins) to introduce a function like

OAPIFUNC const char *oapiGetFullPath (PathRoot root = ROOT);

that returns the requested path(s)?

Or is it already available somewhere and I just didn't found it yet?

/Kuddel

 

[orb]

Shouldn't we ask Mr. Schweiger (martins) to introduce a function like

OAPIFUNC const char *oapiGetFullPath (PathRoot root = ROOT);

that returns the requested path(s)?

http://www.orbiter-forum.com/project.php?issueid=936

 

[kuddel]

http://www.orbiter-forum.com/project.php?issueid=936

Votes are up to 4 now :thumbup:

 

[jarmonik]

D3D9Client R12

D3D9Client R12 is now available at CodePlex for Orbiter-2010P1 and Beta.

 

[Cras]

Wasn't there already a R12?

---------- Post added at 11:54 PM ---------- Previous post was at 10:02 PM ----------

Nevermind, I am thinking of R11. Yikes I am confused today.

 

[Kendo]

Just to remind you, after the last few posts, is there any chance to have a slight glow effect such as a Star Trek type glow. Thanks, Ken.

 

[Face]

Spacecraft3.dll seems not to be evolving into a "next version", so do you have any short info on how the follow-up project ("genericvessel" is the name I think) is doin' ?

Genericvessel is open source. The relevant part is here: http://bitbucket.org/face/genericve...ricvessel/GenericVessel.cpp?at=default#cl-142

 

[jedidia]

Say, are there any known issues with D3D9 client and VESSEL::AddMesh()?

It seems like the client is ignoring the ofset vector passed to AddMesh, can anyone confirm that? Do I have to shift the meshes manually every time the visual is created?

 

[BruceJohnJennerLawso]

Say, are there any known issues with D3D9 client and VESSEL::AddMesh()?

It seems like the client is ignoring the ofset vector passed to AddMesh, can anyone confirm that? Do I have to shift the meshes manually every time the visual is created?

I believe you said earlier that the issue was with meshgroup transform or something similar?

 

[jarmonik]

Say, are there any known issues with D3D9 client and VESSEL::AddMesh()?
It seems like the client is ignoring the ofset vector passed to AddMesh, can anyone confirm that?

No such issues has been reported during the past 2 years.

 

[BruceJohnJennerLawso]

No such issues has been reported during the past 2 years.

Is there any idea why Orulex is incompatible with D3D9?

 

[jarmonik]

Is there any idea why Orulex is incompatible with D3D9?

Why do you need to ask that ? If I am not mistaking it's some kind of hack for the Orbiter 2006. You may find the answers by searching the forums.

 

[BruceJohnJennerLawso]

Why do you need to ask that ? If I am not mistaking it's some kind of hack for the Orbiter 2006. You may find the answers by searching the forums.

I asked because I thought it was a similar issue to the one with IMS mesh updating (I think the function that IMS uses to move meshes may be the same one that Orulex used to deform a spherical mesh into terrain). Orulex was designed for 2006, but it still works fine in Orbiter 2010 D3D7, so the question is somewhat valid, isnt it?

 

[jedidia]

No such issues has been reported during the past 2 years.

Thanks. I'm pretty new to all this client compatibility stuff, so I wanted the more obvious possibilities out of the way first. So something must still be wrong in my code somewhere...

I think the function that IMS uses to move meshes may be the same one that Orulex used to deform a spherical mesh into terrain

No, no, no... The functions I am now switching to are the ones (probably) used by ORULEX, not the ones I've been using. You cannot define geometry with Meshgroup_Transform.

 

[jarmonik]

Just to remind you, after the last few posts, is there any chance to have a slight glow effect such as a Star Trek type glow. Thanks, Ken.

The development of D3D9 is suspended until we know what sort of plans Martin has for the Orbiter. I am not investing my time to the client because too many things are uncertain at a moment. Some features may be implemented because the client offers a suitable environment to experiment with them. With the experience gained from that the features can be more efficiently implemented elsewhere.

 

[BruceJohnJennerLawso]

No, no, no... The functions I am now switching to are the ones (probably) used by ORULEX, not the ones I've been using. You cannot define geometry with Meshgroup_Transform.

So where was the incompatibility with graphics clients before, just the issue with old-style blitting 2d panels, as opposed to the new version that Martins created for 2010?

 

[jedidia]

So where was the incompatibility with graphics clients before

They were with Meshgroup_Transform, a function that IMS used, but Orulex most certainly didn't.

---------- Post added 07-14-13 at 10:24 AM ---------- Previous post was 07-13-13 at 07:57 PM ----------

Ok, now I do have a problem that is clearly related to D3D9 client:

It doesn't call "clbkVisualDestroyed" when the camera moves out of distance. I am not sure whether this is a bug, or intended for good reasons.

However it is, IMS needs a method to force clbkVisualDestroyed on module integration, in order to rebuild the visual of the spacecraft, since it gets a mesh added. So far, this method has been to move the camera out of distance, which doesn't work in D3D9 client. So my question is, is there any other way to force a destruction of the visual?

 

[jarmonik]

It doesn't call "clbkVisualDestroyed" when the camera moves out of distance. I am not sure whether this is a bug, or intended for good reasons.

You are correct but this is not a bug. It's not really intended to be this way but unnecessary calls to clbkVisualDestroyed() might cause stability issues with some addons. Since, the client has been working pretty well with this setup I am not going to change this.

However it is, IMS needs a method to force clbkVisualDestroyed on module integration, in order to rebuild the visual of the spacecraft, since it gets a mesh added. So far, this method has been to move the camera out of distance, which doesn't work in D3D9 client.

If you need to trick the Orbiter like that to add meshes into your vessel then something is not right. Maybe an other vessel developer could help you with that. I have never created a vessel for the Orbiter. You should be able to add or replace the meshes you need using AddMesh() or InsertMesn() almost anywhere in the code.

So my question is, is there any other way to force a destruction of the visual?

No. None.

 

[jedidia]

Right... off I go completely rewriting another part of IMS, then. I was afraid something like this could happen :facepalm:

Thanks for the detailed answer!

 

[Disconnect]

the flickering faces when lit by local light source is still there on R12 now i got a radeon hd5770, and the same happens as on hd3850)