New Release D3D9Client Development

[jarmonik]

This is D3D9Client development thread.


D3D9Client is available for download from Project Site as well as from Tuttovola.org



Some Older Releases:
R2.1 for Orbiter 2016: https://www.orbiter-forum.com/showthread.php?p=561162&postcount=4381
R2.2 for Orbiter 2016 https://www.orbiter-forum.com/showthread.php?p=575342&postcount=4485
R3.0 for Orbiter 2016 https://www.orbiter-forum.com/showthread.php?p=576078&postcount=4494
R3.1 for Orbiter 2016: https://www.orbiter-forum.com/showthread.php?p=582606&postcount=4592
R3.2 for Orbiter 2016: https://www.orbiter-forum.com/showthread.php?p=582991&postcount=4609
R3.3 for Orbiter 2016: https://www.orbiter-forum.com/showthread.php?p=585898&postcount=4694
R3.4 for Orbiter 2016: https://www.orbiter-forum.com/showthread.php?p=586107&postcount=4699



Bug reporting guidelines:
- See if Orbiter.log contains any errors. Always provide this when reporing a problem.

- See if the D3D9ClientLog located in /Modules/D3D9Client/ contains any errors that could be helpfull.
- Vessel / Add-On related bugs should be reported to an add-on developper and let the add-on developper to report the bugs in here. Because the add-on developper will have more insight and information about what's going on inside the add-on and that information is vital for tracking down a bug.


Orbiter/D3D9Client is tested to be OK with:
- NASSP, SSU, AMSO
- DeltaGlider IV
- dbeachy1's XR-Fleet
- thorton's Soyuz FG/U/TMA
- All default vessels in Orbiter distribution.


Not yet Implemented:
- Trains, Solar plants

 

[Zachstar]

I apologize if this if this is seriously off topic but in my opinion DX9s days have come and gone.

In my opinion any project of this magnitude will take years to implement, expand, and support. Meanwhile technology moves on. Getting a Direct X 10 GPU is as easy as getting a motherboard these days as many IGPs support it not to mention multiple generations of video cards. With many on the market for less than 20USD. And most recent low end versions at 40-50USD.

DirectX10 in my opinion ought to be the goal here because while there are still members of this community that use DX9 hardware or Windows XP. What about in a year? What about 2 years?

DX10 SM4 in my opinion will give an amazing amount of ability for addon designers to exploit and make sure of the latest hardware.

 

[Wishbone]

In 2 years I'll still be using WinXP. Please call me a retrograde... and I'll call you a prograde

 

[tl8]

Please try and keep this thread on topic, discussing what client should be developed is not the object of this thread.

 

[jarmonik]

I apologize if this if this is seriously off topic but in my opinion DX9s days have come and gone.

You are right and I have thought about it but there is already enough trouble with the client as it is and I am not familiar with DX10. It should be easier to move to DX10 later. Currently I don't have a good picture about the layout of the client and there are a lot of open questions without answers and I am starting to understand why the project was shutdown from the first place.

 

[Xyon]

As TL8 said, this is not the place to discuss which client should be developed, but a D3D9 client would represent a significant update to Orbiter's aging D3D7 native graphics, and I'd love to see this project survive and produce a working client.

I don't have the first clue about DirectX programming, but I believe someone (possibly Poscik, but I'm not sure) was developing the D3D9 client a few months back, perhaps he would be a good extra set of eyes on the code. Forget DX10 for now, that's a project in its own right and really DX10 has all but disappeared in favour of DX11.

 

[jarmonik]

...but I believe someone (possibly Poscik, but I'm not sure) was developing the D3D9 client a few months back, perhaps he would be a good extra set of eyes on the code.

That would be great but why haven't anyone created a D3D9 client development thread earlier I wonder. In order to success in this project it's vital to share information and ideas.

 

[Xyon]

I have wondered at this myself. Looking at the code already present in the project it's clear that someone or a collection of somebodys have put a fair amount of work into the concept, but there is no thread on the development.

Well, until now, of course. I really wish I could assist on a technical level but I fear I would be more of a hindrance than an asset right now. :/

 

[tl8]

That would be great but why haven't anyone created a D3D9 client development thread earlier I wonder. In order to success in this project it's vital to share information and ideas.

Poscik has indeed got something done, I also think he got it partially working in Orbiter.

He has hit the same problem that the first group did back on M6.

Also as they hit that problem, they haven't moved to O-F and hence there is no thread on DX9 development.

 

[jarmonik]

Poscik has indeed got something done, I also think he got it partially working in Orbiter.

Then he is ahead of me a lot. I'll put my development on hold for now.

He has hit the same problem that the first group did back on M6.

M6 Forum is down so, could someone tell me what is the problem they hit ?

 

[Artlav]

There were problems with 2D panels giving crashes, and some add-ons (shuttle-a?) were CTDing as well.
The solution to 2D stuff was proposed as using textures, but was never done. Curiously, that's what was eventually implemented in the core, so now it should be less of a problem.

I tried to refurbish the DX9 code once into a working client for the current version, but i got too far out of my knowledge to make anything useful. Plus the code is quite out of date with the current OVP api, essentially a D3D7 client from that time with some improvements and DX7 calls replaced with DX9 ones.

 

[jarmonik]

Yeah, It looks like the D3D7Client has changed a lot since the creation of D3D9 Project and the source codes are pretty much useless. Initial implementation is also made by replacing class and structure names with DirectX9 counterparts. That's probably the easiest way to get something done but what kind of results it will lead ?

I suppose one purpose of a graphics client is to provide a better graphics with features like normal mapping, reflections, planet multi-texturing and so on. Is the implementation of the client interface free enough for that ?

The programmable pipeline has a lot more freedom than the fixed function pipeline and it's more easier to use. Should the client move over to use the programmable pipeline ?

There are a lot of build in features in the DirectX9 like the ID3DXMesh interface and the ability to reduce and increase the face count of a mesh. Also, a vertex processing could be moved from the CPU to the GPU. It would seem that a proper client would require quite lot of design.

Are Poscik's source codes available from somewhere ?

BTW, does anyone know why clbkEditMeshGroup() is implemented ? I know what it does but where is it used and why ? Meshes are usually pretty much static.

 

[Poscik]

I didn't commit any code update to repository. D3D9 Client compiled from sources without changes in code will not work. Some problems with Orbiter Launchpad. I bypassed it, but really don't remember what I changed in code. As far as I remember, vessel was illuminated even in earth shadow. So light could "fly through" everything being unaffected. So as I wrote in PM, D3D9 has to be rewritten. There are plenty of API functions, that aren't implemented.

I also don't have any OVP sources on my HDD.

[EDIT]
Ah, I finally realised how I made it to work. I had to exclude some headers and source files from project.

 

[jarmonik]

So as I wrote in PM, D3D9 has to be rewritten. There are plenty of API functions, that aren't implemented.

Yes, I agree. There is no point in making a D3D9Client the same way as the D3D7Client. Most of the code would need to be rewriten from most parts.

Looks like the surface manager is already rewritten to use D3DXCreateTextureFromFile and D3DXCreateTextureFromFileInMemory. Which is good. I assume, that part of the code is fully operational.

The device ennumeration can be removed. There is not much to ennumerate and the little there is can be implemented later. Also, there is no need for the VideoTab at this point of development. In a code that I have been working on, all configurations will come from D3D9Client.cfg file.

I have been working on a D3D9ClientSurface interface. It's a class that will encapsule a IDirect3DTexture9 and IDirect3DSurface9 interfaces. It can change the surface type and format in a fly. It will also provide a blitting with a source colorkey. Target colorkey will cause a performance impact if used. Also a use of GDI drawing, in a cases where the GDI surface is also a target surface for HW blitting, will cause a performance impact. A use of a sketchpad would solve the problem.

The D3D9Mesh class should be rewritten to use a ID3DXMesh interface and HW vertex processing. Also, that would probably reduce the code lines in half. But there is also a problem in HW vertex processing due to single-precision floating point numbers. Currently I am aware of only one situation and that's when a camera is near the surface of a planet. One possibility is to use different rendering technique near a surface (below 100km), that would include creating a reference point for surface mesh near the surface instead of planet's center. That might also allow a better atmospheric implementation. I suppose the D3D7Client has already a solution in this problem but I haven't been able to pinpoint the code section.

I suppose the first goal should be geting the basic things to work like:
-Vessel exterior
-Virtual cockpit
-Glass cockpit
-2D Panel
-HUD
-Planet Rendering from high orbit (>100k)
-Celestial Grid, Stars, Constellations.

Things to implement later:
- Particle systems
- Cloud rendering
- Atmospheric haze
- Surface bases
- Near surface rendering (requires a lot of design work)

 

[Poscik]

Ok, I just have to complete whole stuff after HDD change, and I can help you. But only a little I can do only simple things in directx, but "Documentation is your friend". :lol:

 

[jarmonik]

Looks like the D3D7Client is incomplete. Functions GetVCHUDSurface() and GetVCMFDSurface() are used in a Vessel code but they are not defined in anywhere. How is this supposed to work anyway ? I just can't figure out the MFD update mechanism.

---------- Post added at 01:24 ---------- Previous post was at 00:17 ----------

This is the code:

if (bVC) {
        sHUD = gc->GetVCHUDSurface (&hudspec);
        for (mfd = 0; mfd < MAXMFD; mfd++)
            sMFD[mfd] = gc->GetVCMFDSurface(mfd, &mfdspec[mfd]);
}

 

[Poscik]

Those functions bodies, sHUD and sMFD are (I think) in *.lib file, so they don't have to be defined in code. And about mfd mechanism: I think it's only obtaining handles of all MFDs. All the update work is made by Orbiter.exe. When trying to update MFD, exe refers to sMFD to check if there is any MFD, and then applies Update() to selected MFD. But I don't have a clue why GetVCHUDSurface is used there. I wonder it's for updating MFDs even in VC mode.

 

[jarmonik]

Yes, you are right. Those functions comes from the base class implementation oapi::GraphicsClient.:thumbup: I should have noticed that, I was obviously too tired when working with that code. The HUD surface has nothing to do with the MFDs. The client is just getring the pointer into the surfaces in the same place.

 

[Poscik]

Today I'll complete whole C++ stuff, so I can start helping you. The best way to learn DirectX is practice.

 

[Xyon]

Based on that principle I will watch with interest, but I will be of little practical assistance with the project. I wish I could actually contribute, but who knows, maybe I can do something useful later on (though it is unlikely).