New Release D3D9Client Development

[Fabri91]

Thanks for the fix!

kuddel: just to confirm, since I'm a bit confused about this due to your build having "r57" in the name while the previous one had "r58": is your build to be used with the new RC1?

 

[jarmonik]

Here's a VC2008 build version of gcAPI.lib

Kuddel: Could you keep the VC2008 build in the distribution since VC2015 build doesn't work very well.

 

[kuddel]

D3D9Client Beta 24.1.1 for BETA r58 (r733)

Thanks for the fix!

kuddel: just to confirm, since I'm a bit confused about this due to your build having "r57" in the name while the previous one had "r58": is your build to be used with the new RC1?

Oooops, it could be that I've linked against r57 (should still work with Orbiter BETA r58, 'cause no API changes between those revisions)...good catch Fabrizio!

But just because I can :lol: here's the same, this time linked against r58 of Orbiter BETA

 

[kuddel]

Here's a VC2008 build version of gcAPI.lib

Kuddel: Could you keep the VC2008 build in the distribution since VC2015 build doesn't work very well.

Let's see what we can do about this
I am really no fan of putting build-results (binaries) under version control.
Let's see what I will make of it. Either I can tweak the 2015 and 2012 projects, to "behave" or I'll have to swallow that pill :thumbsdown:

Can you provide a simple check / test from which I can see whether the lib(s) are O.K. or not?
One that fails for a LIB build like my last and one that passes with LIBs build like yours.

Besides:
At home I've only Visual Studio 2015.
At work I still have access to Visual Studio 2012 for some time.

But in general I would recommend we build official releases from one Compiler Version only (whatever version we decide).

I would have loved to set up a CI Server, that builds our "releases", but I hesitate to spend around € 10 per month for a Windows Server wich I have no other use for.

---------- Post added at 17:48 ---------- Previous post was at 17:17 ----------

@jarmo: What compiler are you developing on? I thought you switched to Visual Studio 2015...
Or do you have the Visual Studio 2008 Toolset installed (in parallel)?
If martins is still using 2008 only, we might need to restrict ourselves to that toolset.
Using newer IDE is possible though.

---------- Post added at 21:11 ---------- Previous post was at 17:48 ----------

@jarmo: I've decided to resurrect the gcAPI.lib ...since the lib folder was put under source-control anyway it was the quickest choice
Log "History" is preserved (though you might have to make sure "Stop on copy/rename" is unchecked in the Log messages dialog).

The buid_release.bat will now never build gcAPI.lib and just take that (unchanged) file.
...and it's the one you've posted lately.

 

[jarmonik]

But in general I would recommend we build official releases from one Compiler Version only (whatever version we decide).

I have VS2015 and VS2008 in "parallel" so that I can open VS2008 projects in VS2008 and others in VS2015. I prefer VS2015 since it is more productive due to better real-time error checking, intellisense, and debug features.

I would have loved to set up a CI Server, that builds our "releases", but I hesitate to spend around € 10 per month for a Windows Server wich I have no other use for.

That shouldn't be necessary, I am sure there are plenty of other options to distribute D3D9. It's not exactly very large package even with the micro textures. I'd be happy if there's someone willing to maintain a distribution site for the D3D9.

I've decided to resurrect the gcAPI.lib ...since the lib folder was put under source-control anyway it was the quickest choice
Log "History" is preserved (though you might have to make sure "Stop on copy/rename" is unchecked in the Log messages dialog).

Ok, the gcAPI.lib is pretty small file and it's likely not going to change very often so it shouldn't grow the repository size much. What about the surface micro textures ? I guess it would require a folder without any-kind of versions control applied to it. Is it possible ? How does the SSU project manage textures ?

 

[GLS]

There is a bug in the Polygon function: the specified points are all connected, but the fill of the shape is not correct as the image shows...

 

[kuddel]

I have VS2015 and VS2008 in "parallel" so that I can open VS2008 projects in VS2008 and others in VS2015. I prefer VS2015 since it is more productive due to better real-time error checking, intellisense, and debug features.

O.K. That's what I've expected :thumbup:
The "VS2012 changes" I do are only because
1. I can
2. I can fiddle a bit around @ work during lunch periods
...so it seems that VS2015 is the "main" tool-chain.

I am sure there are plenty of other options to distribute D3D9.

Distribution is not really an issue; I was just thinking loud and these systems have served me well so far in:
1. providing a 'standardized' build environment (same compiler etc. every build)
2. "no extra work" whenever a new tag / revision is commit'ed (I love automatic processes )

I'd be happy if there's someone willing to maintain a distribution site for the D3D9.

Yeah, but couldn't we upload releases to Orbit-Hangar?
I have no idea how "updating" etc. of an addon works there, but in general it should be the place to point people to, or not?

Ok, the gcAPI.lib is pretty small file and it's likely not going to change very often so it shouldn't grow the repository size much.

My concern was more of a conceptual one. If it is not "source" it should not be under source-control...
But let's rest this issue. As you've said: If it really needs an update, one has to do it with VS2008.

What about the surface micro textures ? I guess it would require a folder without any-kind of versions control applied to it. Is it possible ? How does the SSU project manage textures ?

I hope I remember this right: The micro-textures are the one referenced by Config\MicroTex.cfg, right?
I was thinking this way:

• D3D9Client puts it's standard micro-textures (version controlled) at e.g. Textures\Moon\.If you have a D3D9Client workingcopy and want to use different micro-textures you can just copy those to Textures2\Moon\.
  In this case your workingcopy will not complain about modifications to those files (no red icons ).
• Another approach would be to have them at e.g. Orbitersdk\D3D9Client\MicroTex\ and during compile, they would be copied to Textures\ in case there are not yet ("create on demand").
  The release-ZIP would always contain them under Textures\, too.

...the more I write about this the more I prefer option 2...

 

[jarmonik]

There is a bug in the Polygon function: the specified points are all connected, but the fill of the shape is not correct as the image shows...

I was hoping never to see anything like that. It's a somewhat complex algorithm that does the polygon triangularization process. I have no idea what goes wrong in there. To have any change of catching the problem, I would need to check the process a triangle by triangle. Also the process is done every time when the polygon is rendered, so, a use of it is not recommended in greater quantities.

1.) I would need the code and data for the polygon. So that I can reproduce it with my test MFD.
2.) How did you create the data (points) ? Do you have it sketched on a paper ? I would need to print the polygon on a paper without filling just the data points.

 

[birdmanmike]

So just to confirm this last D3D9 24.1 for 58 r733 is OK with 2016 BETA and the RC1? Thanks

 

[GLS]

I was hoping never to see anything like that. It's a somewhat complex algorithm that does the polygon triangularization process. I have no idea what goes wrong in there. To have any change of catching the problem, I would need to check the process a triangle by triangle. Also the process is done every time when the polygon is rendered, so, a use of it is not recommended in greater quantities.

1.) I would need the code and data for the polygon. So that I can reproduce it with my test MFD.
2.) How did you create the data (points) ? Do you have it sketched on a paper ? I would need to print the polygon on a paper without filling just the data points.

color defs

#define CR_BLACK RGB( 0, 0, 0 )
#define CR_LIGHT_GREEN RGB( 0, 255, 0 )

brush and pen creation

skpLightGreenBrush = oapiCreateBrush( CR_LIGHT_GREEN );
skpBlackPen = oapiCreatePen( 1, 2, CR_BLACK );

display code

skp->SetBrush( skpLightGreenBrush );
skp->SetPen( skpBlackPen );
oapi::IVECTOR2 fd[18] = {{214,221},{214,225},{238,225},{243,235},{252,241},{260,241},{269,235},{274,225},{298,225},{298,221},{270,221},{270,225},{266,232},{259,237},{253,237},{246,232},{242,225},{242,221}};
skp->Polygon( fd, 18 );

I'm not understading what you want in point 2...

 

[jarmonik]

Yeah, but couldn't we upload releases to Orbit-Hangar?
I have no idea how "updating" etc. of an addon works there, but in general it should be the place to point people to, or not?

Yes, that is one option but I have no experience of it. I guess we would need one page containing the all most needed reversions of the client. For an example the R15 is considered to be the most stable revision for P1. So, it would be good to keep it available too for whoever wants to use it, even if it's not the latest one.

My concern was more of a conceptual one. If it is not "source" it should not be under source-control...

Sorry, a newbie here. Are there other control schemes than source-control ?

I hope I remember this right: The micro-textures are the one referenced by Config\MicroTex.cfg, right?

Yes. My micro texture folder is 600MB from where 90% is mostly garbage, which would still leave 60MB of source art-work for the micro textures and it only exists on my local hard-drive.

[*]D3D9Client puts it's standard micro-textures (version controlled) at e.g. Textures\Moon\.If you have a D3D9Client workingcopy and want to use different micro-textures you can just copy those to Textures2\Moon\.
In this case your workingcopy will not complain about modifications to those files (no red icons ).
[*]Another approach would be to have them at e.g. Orbitersdk\D3D9Client\MicroTex\ and during compile, they would be copied to Textures\ in case there are not yet ("create on demand").
The release-ZIP would always contain them under Textures\, too.
[/LIST]
...the more I write about this the more I prefer option 2...

We already have OrbiterSDK\D3D9Client\Art which contains some obsolete micro textures. But anyway, I let you make the decision since I have no idea what's the best choice there.

---------- Post added at 18:40 ---------- Previous post was at 18:35 ----------

I'm not understading what you want in point 2...

Just forget that, nothing important.

Thanks about the code. I'll check it out.

 

[SolarLiner]

I'd be happy if there's someone willing to maintain a distribution site for the D3D9.

I can do that. If it's about a landing page that provides downloads then I can do that, it won't take a lot of time.

 

[Ripley]

Re: Orbit Hangar
The first time you upload a new addon, you get a new page with its static address.
Whenever you update that addon, page address stays the same.
So we could have a page for, say, D3D9 for Orbiter2010, another one for D3D9 for Orbiter2016, and so on.

 

[jarmonik]

There is a bug in the Polygon function: the specified points are all connected, but the fill of the shape is not correct as the image shows...

A quick fix for this has been commited to SVN. I still need to think about a better algorithm. Algorithms's current choices for triangles are pretty bad, but they do work at-least in that case.

 

[Marg]

I am looking through the posts, trying to set up d3d9 client with lens flares, but no success. Is there any version working (at least partially)?

 

[SolarLiner]

I am looking through the posts, trying to set up d3d9 client with lens flares, but no success. Is there any version working (at least partially)?

I have compiled a version that works with RC1, but there's no support for the compressed planetary textures, and text is a bit... unstable, to say the least. i've hesitated to share that version, but it has HDR rendering, color correction, bloom and the lens flare.

I've sent a request for write access on the svn to upload my changes, no response yet.

 

[SolarLiner]

Here's a build that should work with RC1 - I have merged my changes with the trunk.
To reduce file attachment size, the source is downloadable here.

 

[jarmonik]

Here's a build that should work with RC1 - I have merged my changes with the trunk.
To reduce file attachment size, the source is downloadable here.

Still having some trouble running it.

I check the code quickly and this is very bad. It will create and delete planet visual for every frame.

vPlanet vP = vPlanet(hP, this);

Try replacing it with this one but don't delete the vP.

vPlanet *vP = GetCameraProxyVisual();

 

[Marg]

I also get black and white static picture with SolarLiner's version...

 

[SolarLiner]

I also get black and white static picture with SolarLiner's version...

What are your computer spec? Can you take a screen shot of it?