New Release D3D9Client Development

[Poscik]

I think we have to create new project on sourceforge, because we don't have rights to commit any updates right now. What do you think about VS2010? It won't be a problem for me to convert VS2008 project to VS2010, but it might be a problem in the other way.

 

[jarmonik]

I am using VS2008. If you have VS2010 then you should be able to use the project files of VS2008 without any problem. I suppose the project page isn't a major consern at this point of development. At first I need to get the basics up and running properly. I made the first successful build without errors yesterday and I have spend the last 9 hours trying to find why the Orbiter will stop responding while loading the Phobos.dll, the Orbiter is probably stuck in a loop. Something in the D3D9Client is causing the Orbiter to fail. No errors, nothing in a trace logs. The D3D7Client compiles and runs fine.

 

[Poscik]

I think we should write D3D9Client from zero. We can of course look at the old code to see "how it's made". But there is no sense to fix all errors.

 

[jarmonik]

I am still stucked in a failing Phobos.dll, could someone give this a try and see what happens. This is in a very early state of development, so, if it will pass the phobos.dll it will very likely crash soon after that. Place the dll in a Modules/plugin/ folder. The D3D9Client will create a log file called D3DClientLog.html there is also some output in the Orbiter.log

If the Phobos.dll is removed then the orbiter will get stuck in a Satsat.dll during initialization.

When I build the D3D7Client from a source codes it will run properly. The biggest difference is that most features are disabled from D3D9 but that shouldn't cause the initialization of the other modules to fail like that.

EDIT: There will be no progress with this project until this issue is solved.

 

[jarmonik]

If you want to install the project. Extract the package into the /Orbitersdk/ folder. In that case the project will be able to located includes and libraries. Also the DLLs will go in a proper placed when build. The same applied to GDIClient and D3D7Client.

 

[Poscik]

I compiled client from sources, and made few changes in log (txt instead of html). But it isn't important right now. I even can't load simple scenario with one Delta Glider. It's freezing at:

(Mon Oct 11 18:16:09 2010)(0xAA0)D3D9Client::clbkLoadTexture(LCC_DRS.dds,0x8)<br>
(Mon Oct 11 18:16:09 2010)(0xAA0)D3D9Client: LCC_DRS.dds<br>
(Mon Oct 11 18:16:09 2010)(0xAA0)Texture LCC_DRS.dds found

Buffer or memory overload? But phobos loaded very well for me.

---------- Post added at 04:46 PM ---------- Previous post was at 04:18 PM ----------

Okay, now no matter what I said post earlier

(Mon Oct 11 18:46:17 2010)(0x838)D3D9Client::clbkLoadTexture(LCC_DRS.dds,0x8)
(Mon Oct 11 18:46:17 2010)(0x838)D3D9Client: LCC_DRS.dds
(Mon Oct 11 18:46:17 2010)(0x838)Texture LCC_DRS.dds found
(Mon Oct 11 18:46:17 2010)(0x838)D3D9Client: ASSIGNING TEXTURE OK

And now I see - it's freezing on Phobos.dll.

Maybe there is the reason (look at the Build and API dates)

Module Moon.dll .............. [Build 100830, API 100830]
ELP82: Precision 1e-005, Terms 116/829
Module Mars.dll .............. [Build 100830, API 100830]
Module MarsAtm2006.dll ....... [Build 100830, API 100830]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
Module Phobos.dll ............ [Build ******, API 060425]

 

[jarmonik]

Yes, that's the point where it's freezing from the client's point of view. If you look at the Orbiter.log it will show that the Orbiter will continue loading other modules after loading the texture LCC_DRS.dds. What's the last line in your Orbiter.log ?

Memory overload is probably the best guess but I have already spend two days trying to find it and I have found nothing. It's not always the Phobos.dll it has stopped in the Saturn.dll atleast once.

I have also implemented the trace log in the D3D7Client and it will do exactly the same things in a same order. The next texture in a line is the ISS_DC.dds but the Orbiter will never call the clbkLoadTexture() because it's stuck in a loop before that. The assemply code of the loop is shown in a debugger but there is no way to tell why it got in that condition. This isn't the best start for a D3D9Client development.

---------- Post added at 20:05 ---------- Previous post was at 19:56 ----------

Maybe there is the reason (look at the Build and API dates)

Module Moon.dll .............. [Build 100830, API 100830]
ELP82: Precision 1e-005, Terms 116/829
Module Mars.dll .............. [Build 100830, API 100830]
Module MarsAtm2006.dll ....... [Build 100830, API 100830]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
Module Phobos.dll ............ [Build ******, API 060425]

The D3D7Client is working fine and the inline graphics engine. It's an ephemeris module it shouldn't have anything to do with the graphics client.

---------- Post added at 20:15 ---------- Previous post was at 20:05 ----------

The launch pad item stuff in a constructor should be a problem. I implemented it in a hope that it could sovle the problem with the Phobos.

 

[Poscik]

Maybe we should try to rewrite D3D7Client files for DX9. I think that's the best option. And another "bug" in D3D9: I replaced solar system to SolM, and when simulation begins, loading screen don't want to disappear. Simulation works "in background". I just pressed Ctrl+Q, and Orbiter turned off very well.

 

[Xyon]

I think part of the issue could be that the client as yet does not provide any video options tab (Like D3D7 and OGLA clients do, the "Video" button appears when you activate the module), so what settings does it fire up with?

Edit: Hmm, or maybe it's because I got this:

Error loading module Modules\Plugin\D3D9Client.dll (code 14001)

 

[jarmonik]

I think part of the issue could be that the client as yet does not provide any video options tab (Like D3D7 and OGLA clients do, the "Video" button appears when you activate the module), so what settings does it fire up with?

The Video tab is currently disabled via bool clbkUseLaunchpadVideoTab() callback function. The video tab will configure the video options located in VIDEODATA structure. There is nothing that should effect in loading of other modules. Video tab is currently disabled because the DX9 device ennumeration is different from the DX7.

Edit: Hmm, or maybe it's because I got this:

Error loading module Modules\Plugin\D3D9Client.dll (code 14001)

That is something new. I haven't seen anything like it before.

 

[Poscik]

Try this Xyon.
View attachment D3D9Client.zip

 

[jarmonik]

And another "bug" in D3D9: I replaced solar system to SolM, and when simulation begins, loading screen don't want to disappear. Simulation works "in background". I just pressed Ctrl+Q, and Orbiter turned off very well.

That's a good news. It's not a bug. Scene rendering is currently disabled and Scene.cpp will require a lot of work until it can be enabled. I am not giving up yet, there must be a reason for failure of Phobos. I'll implement the video tab and if it doesn't solve the problem I'll ask Martin to run the client under a debug version of the Orbiter, that would show the parameters those are used in initialization of the Phobos.dll and Satsat.dll

 

[Xyon]

Try this Xyon.
View attachment 5958

Aha! Now I crash where the rest of you do! \o/

 

[jarmonik]

I have implemented the video tab but it didn't have any effect in the problem with Phobos. It would appear that the "DG Mk4 in Orbit" scenario seems to "crash" in a phobos.dll and "Atlantis cockpit" scenario is "crashing" in a saturn.dll.

---------- Post added 13-10-10 at 00:07 ---------- Previous post was 12-10-10 at 16:58 ----------

This is geting more and more complicated... I placed a wrapper dll between the Orbiter and the Phobos as well as Mars for reference. The parameters passed from the orbiter to the Phobos.dll are the same for both clients D3D7 and D3D9Clients. Of course, some handles are different but they both look good. But anyway the problem is isolated to clbkFastEphemeris() which is called but will never return. :compbash2: There could be uninitialized local variable inside the module, that is for some reason, giving trouble with the D3D9Client. The same problem seems to apply to Saturn.dll, Mimas.dll, Enceladus.dll and probably many more.

Module Mars.dll .............. [Build 101012, API 100830]
-- MARS module wrapper loaded --
Module xMars.dll ............. [Build 100830, API 100830]
InitModule(HINSTANCE hModule=0x3C70000)
InitInstance(OBJHANDLE hBody=0x791FB58)
WrapperPlanet(CELBODY pPlanet=0x7920240)
clbkInit(FILEHANDLE cfg=0x9FEE70)...
Module MarsAtm2006.dll ....... [Build 100830, API 100830]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
...return
bEphemeris() called
clbkFastEphemeris(double simt=0, int req=15, double ptr ret=0x4DBDE0)...
...return(int 12)


Module Phobos.dll ............ [Build 101012, API 100830]
-- PHOBOS module wrapper loaded --
Module xPhobos.dll ........... [Build ******, API 060425]
InitModule(HINSTANCE hModule=0x7B30000)
InitInstance(OBJHANDLE hBody=0x7918B50)
WrapperPlanet(CELBODY pPlanet=0x2155C10)
clbkInit(FILEHANDLE cfg=0x9FEC30)...
...return
bEphemeris() called
clbkFastEphemeris(double simt=0, int req=15, double ptr ret=0x4DBDE0)...

---------- Post added at 00:14 ---------- Previous post was at 00:07 ----------

I thought that writing a graphics client would have been easier task.

 

[Poscik]

I'm trying to fix it, but still no results. As I mentioned earlier, we should write completely new client. Much faster than working out this error.

 

[jarmonik]

I'm trying to fix it, but still no results. As I mentioned earlier, we should write completely new client. Much faster than working out this error.

The implementation that I have been working is only containing online code in D3D9Client.cpp, D3D9Surface.cpp, D3D9Frame.cpp and Texture.cpp. Everything else is offline. These files are rewriten from most parts. Even if we could make a new client based more or less in the existing code of the D3D7Client there is only a very little chance that we will avoid this error. I already re-implemented the D3D9Client.cpp without using the D3D9ClientSurface class, just with a basic surfaces, but it didn't help.

The problem is that I have no means to debug the problem where it manifests it self. The Phobos.dll has been successfully used with the Orbiter very long time, therefore, it's unreasonable to expect that the Phobos.dll and many other modules would have a fundamental bug of somekind.

A Buffer overflow in D3D9Client is unlikely the reason because the Orbiter have not yet loaded the Phobos.dll when the Client runs the splash screen and loads a few textures. There is no client code executed between loading the Phobos.dll and getting stuck in a loop. This is the most frustrating bug I have ever encountered.

---------- Post added at 18:50 ---------- Previous post was at 17:10 ----------

I'll try to continue a development without Phobos and Saturn system. Removing them allows to pass the bug or what ever it is. There is nothing I can do about it. But nobody's going to use the client if it won't work with those modules so the problem must be solved. I'll leave the debugging of the Orbiter itself for Martin.

 

[Weirdo Earthtorch]

I'm no programmer and have little understanding of the issues discussed, so feel free to shoot me down, but discussion of phobos.dll in relation to graphics clients reminds me of a bug I posted in the D3D7 client http://orbiter-forum.com/project.php?issueid=129. Martin explained at the time that

Rendering mesh-based planet surfaces isn't yet supported by the D3D7Client.

(i.e. phobos, deimos, not sure about the Saturn system)
I wondered if the issue is related?

 

[jarmonik]

I made some progress with the Client. The 2D panel cockpit and the glass cockbit is online and working. But there is a terrible performance impact during MFD update. There is still a lot of work with it. There are also problems with the Orbiter like DeltaGlider falling down from an orbit.

Installation note: Place the MeshTech.fx in the Orbiter's root folder.
Installation note: Remove Phobos and Saturn system from the Sol.cfg
Installation note: Software Vertex processing must be unchecked from Video Tab

 

[jarmonik]

Also note that Phobos and Saturn system must be removed from Sol.cfg take a backup before editing it.

 

[Xyon]

Same again; Error loading module Modules\Plugin\D3D9Client.dll (code 14001)

Would this be because I don't have the DX9 SDK perhaps?