Question Particle Streams in D3D9 / Check for Graphics Client?

[BrianJ]

Hi all,
I notice there is a slight difference in the way particle streams are handled by D3D9 graphics client as opposed to default Orbiter2016 rendering. My launchpad LOX venting looks "thin" or "sparse" using D3D9, the particles seem to have less air resistance.

Q. Is there an easy way to check whether the user is using D3D9 Graphics Client or native Orbiter2016 rendering? Is there an OrbiterAPI function for that? (I couldn't find one).

If yes, then I could simply make two different particlestreams and choose the apropriate one at sim start.

Many thanks,
Brian

 

[kuddel]

Q. Is there an easy way to check whether the user is using D3D9 Graphics Client or native Orbiter2016 rendering? Is there an OrbiterAPI function for that? (I couldn't find one).

Technically there could be a procedure to check that, but:
I personally do not like this. This smells like it would lead to a scenario where every add-on developer needs to account for all the different renderers like Web-Developers needed to detect what browser their site was running on.

I would therefore prefer this to be consistent in all renderers.
The "standard" is of course the inline renderer (whether it's right or wrong does not matter here).
The D3D9Client should (in my opinion) adopt to behave equal to the inline renderer.

/Kuddel

 

[DaveS]

The D3D9Client should (in my opinion) adopt to behave equal to the inline renderer.

This is where I strongly disagree. D3D9Client due to using a more powerful API and more flexibility, should be striving for accuracy, not mimicking the effects generated by an outdated API. It should not be afraid to breaking the chains imposed on it by that outdated API(D3D7).

 

[BrianJ]

Well, I tried linking the D3D9 sdk gcAPI.lib, gcAPI.h in my build. Functions

gcEnabled(), gcInitialize()

look like they could be what I need, but they don't seem to return anything when used in my vessel.dll (.dll compiles ok though). Just experimenting

 

[kuddel]

This is where I strongly disagree. D3D9Client due to using a more powerful API and more flexibility, should be striving for accuracy, not mimicking the effects generated by an outdated API. It should not be afraid to breaking the chains imposed on it by that outdated API(D3D7).

I see what you are about to say, but what I meant by

...the "standard" is of course the inline renderer...

is that the visual results with equal parameter sets should be comparable / equal.

Extensions however should clearly be implemented in the "most modern and accurate" way.
:tiphat:

---------- Post added at 23:42 ---------- Previous post was at 21:38 ----------

....just to go back to the original question:

/**
 * \brief Get a client id DWORD, if a client is present
 * \return Client id DWORD (e.g. 'D3D9') or zero
 */
DWORD  gcClientID();

Including gcAPI.h (and linking gcAPI.lib) you should be able to detect if the sim is running with D3D9Client...

if (gcClientID()) {
  // "D3D9" => D3D9Client
} else {
  // 0 => inline client
}

---------- Post added at 23:51 ---------- Previous post was at 23:42 ----------

Addendum:

/**
 * \brief Check if GC is initialized and operational.
 * \return true, if the interface is initialized and operational.
 * \note Always returns flase if the gcInitialize() is never called or the gcInitialize() has failed.
 */
bool  gcEnabled();

...should yield equal results (if you prefer Boolean return values )

 

[BrianJ]

Including gcAPI.h (and linking gcAPI.lib) you should be able to detect if the sim is running with D3D9Client...

if (gcClientID()) {
  // "D3D9" => D3D9Client
} else {
  // 0 => inline client
}

---------- Post added at 23:51 ---------- Previous post was at 23:42 ----------

Addendum:

/**
 * \brief Check if GC is initialized and operational.
 * \return true, if the interface is initialized and operational.
 * \note Always returns flase if the gcInitialize() is never called or the gcInitialize() has failed.
 */
bool  gcEnabled();

...should yield equal results (if you prefer Boolean return values )

Thanks, but doesn't seem to work for me in my vessel.dll. - I'm probably not linking it correctly in my build, but can anyone confirm that gcInitialize() and gcEnabled() work in a vessel .dll ? I'll go back and try again if yes. Note: the .dll compiles ok, and my VC++ compiler tells me that these functions should return a DWORD or boolean value.
Many thanks,
Brian

 

[kuddel]

Thanks, but doesn't seem to work for me in my vessel.dll.- I'm probably not linking it correctly in my build, but can anyone confirm that gcInitialize() and gcEnabled() work in a vessel.dll ?

I cannot think of anything that might prevent a vessel.dll from working...

The things you have to check are:
1. gcAPI.lib is added to your link list --I think you did that
2. include gcAPI.h in a (cpp-)source file wherever you need it --I think you did that, too
3. make sure gcInitialize() is called once before any other gcXXX() call (preferably in the constuctor) -- maybe you missed this?
4. after that gcEnabled(), gcClientID() etc. should do what they are supposed to do

Find attached an MFD sample project (not a VESSEL, but close :thumbup: )

/Kuddel

 

[BrianJ]

Hi kuddel, thanks so much. I'll have another try with gcInitialize() in the constructor section.

---------- Post added at 03:41 PM ---------- Previous post was at 02:39 PM ----------

Got it.
Once gcInitialize() is in the constructor, gcEnabled() returns the correct value.
Thank you very much kuddel.