Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Visualization Project
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter Visualization Project Orbiter external graphics development.

Reply
 
Thread Tools
Old 01-13-2020, 01:13 AM   #5071
Donamy
Beta Tester


Default

Are you trying to start with a .dll not recompiled for 2016 ?
Donamy is offline   Reply With Quote
Old 01-13-2020, 01:57 AM   #5072
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Donamy View Post
 Are you trying to start with a .dll not recompiled for 2016 ?
No...
GLS is offline   Reply With Quote
Old 01-13-2020, 04:44 PM   #5073
jarmonik
Beta Tester

Default

Quote:
Originally Posted by GLS View Post
 Running Orbiter 2016 with D3D9 R3.12, R3.13 or R4.0 and loading a mesh with a group containing FLAG 8 produces a CTD +/- when the sim should start. Both logs show the message:
Code:
[ERROR] MeshGroupFlag 0x8 in use (OPERATION NOT IMPLEMENTED)
I'm sure this worked without the CTDs in Orbiter Beta... not sure if the log message was present...
So is this something not available just for Orbiter 2016, or it's not available at all and the CTD is (maybe) something else?

We have had never support for Flag 0x8, this is the first time I know that someone have tried to use it. Of course, if the "additive with background" feature is really required then of course we can add a support for it. The reason for not having a support is simply that if no-one uses it, there's been no adaquate way to test it. I don't know about the CTD, it's possible that assert() is use to trigger it. What are you trying to do with flag 0x8 ?
jarmonik is offline   Reply With Quote
Old 01-13-2020, 06:53 PM   #5074
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by jarmonik View Post
 We have had never support for Flag 0x8, this is the first time I know that someone have tried to use it. Of course, if the "additive with background" feature is really required then of course we can add a support for it. The reason for not having a support is simply that if no-one uses it, there's been no adaquate way to test it. I don't know about the CTD, it's possible that assert() is use to trigger it. What are you trying to do with flag 0x8 ?
I'm just playing with things, figuring out what "tools are in the toolbox"... It's fine if you don't support it (if I really need it, for sure I'll ask for it), but I don't think it should go CTD...

It doesn't seem to be an assert, as it shows the "orbiter.exe. has stopped working" window, and not the "assertion failed" window. Debugging gives: "Unhandled exception at 0x5DC64DAD (igdumdim32.dll) in orbiter.exe: 0xC0000005: Access violation reading location 0x00000030."
Just looked up that dll and it's used by the Intel GPU, so tried running in the NVIDIA GPU and it works. It might something uninitialized, that the NVIDIA GPU doesn't care about, but makes the Intel GPU go nuts.
Anyway, when I was running Orbiter Beta there was no CTD.
GLS is offline   Reply With Quote
Old 01-16-2020, 03:21 PM   #5075
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by jarmonik View Post
 New build 3.13 of the client is out for Orbiter 2016. There are a lot of changes but, the most important ones are related to shadows and terrain.

- Stencil shadows are now better aligned with a terrain and should appear in the right place for vessels and base object meshes.

- Underground meshes are nolonger creating a "false" shadows.

- When "linear interpolation" and "Experimental lunar terrain interpolation" are selected the resulting visual terrain should match the surface used by physics with an accuracy of 2cm. Otherwise, the deviation can be a few meters.
One thing that also changed with r3.13 (and also r4.0) is that we now have that infamous "collision" between debug/release, static/dynamic CRT libraries:
Code:
error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MDd_DynamicDebug'
GLS is offline   Reply With Quote
Old 01-17-2020, 01:48 PM   #5076
kuddel
Donator
Default

Quote:
Originally Posted by GLS View Post
 One thing that also changed with r3.13 (and also r4.0) is that we now have that infamous "collision" between debug/release, static/dynamic CRT libraries:
Code:
error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MDd_DynamicDebug'
So, only the initial version (rev.1229) works for you?

Changes to gcAPI.lib[1] were only at rev.1239 and rev.1243;
and version 3.13 was rev.1230 and version 4.0 was rev.1248.

Building a Module (DLL) as debug however might almost *never* work with the provided library. You might have to re-build a debug library of gcAPI (gcAPI_dbg.dll) yourself from the sources...
See current 'trunk'-changes[2] for how you might be able to do this.

As these debug-build capability is still work in progress here, your mileage might vary



[1] ...on the '2016' branch. 'trunk' revisions might be another story.
[2] For example: trunk\Orbitersdk\samples\GenericCamera\GenericCame ra.sln
Here gcAPI is *not* (re-)build for release builds,
but for debug-builds gcAPI is build as 'gcAPI_dbg.lib' with different runtimes.
kuddel is offline   Reply With Quote
Thanked by:
Old 01-17-2020, 06:46 PM   #5077
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by kuddel View Post
 So, only the initial version (rev.1229) works for you?

Changes to gcAPI.lib[1] were only at rev.1239 and rev.1243;
and version 3.13 was rev.1230 and version 4.0 was rev.1248.

Building a Module (DLL) as debug however might almost *never* work with the provided library. You might have to re-build a debug library of gcAPI (gcAPI_dbg.dll) yourself from the sources...
See current 'trunk'-changes[2] for how you might be able to do this.

As these debug-build capability is still work in progress here, your mileage might vary



[1] ...on the '2016' branch. 'trunk' revisions might be another story.
[2] For example: trunk\Orbitersdk\samples\GenericCamera\GenericCame ra.sln
Here gcAPI is *not* (re-)build for release builds,
but for debug-builds gcAPI is build as 'gcAPI_dbg.lib' with different runtimes.
The change was probably not in the code, but in the build process: 3.12 was probably built with an older VS that didn't enforce the CRT library type like the more recent versions do.
Anyway, I'm setting things up to build "my own" version of the library. I'll probably create a second debug config in SSU to target the "_dbg" flavor of the library. It also solves the "static vs dynamic" issue, unless you don't want your library included when compiled with static?

---------- Post added at 06:46 PM ---------- Previous post was at 05:14 PM ----------

Built a static debug version and it works!
GLS is offline   Reply With Quote
Thanked by:
Old 01-17-2020, 08:44 PM   #5078
kuddel
Donator
Default

Quote:
Originally Posted by GLS View Post
 [...]It also solves the "static vs dynamic" issue, unless you don't want your library included when compiled with static?[...]
The lib itself is Jarmonik's brainchild and as far as I know he deliberately build it with Visual Studio 2008...(please correct me if I'm wrong here )

I am currently trying out several options on how to build all the stuff and the gcAPI.lib thing is one of the issues these endeavors should explore

I will also probably try a completely different runtime setup for all of the D3D9Client related builds, as I noticed that the "recommended" setup by the Orbiter-BETA provided prop-sheets use MultiThreadedDLL for release builds and MultiThreadedDebugDLL for debug builds[1].

As far as I know, for a complete coverage we would need to provide a lib for all possible combinations:
Release/Debug <=> Multithreaded/Singethreaded <=> Statis/Dymanic
...and possibly some more I've missed.
The general goal however is: Provide one library for all release module DLLs that need gcAPI support, while during development the Modue-developer still can do so by getting the source-code.

Complicating the tasks is that I like to keep the ability to build D3D9Client with several versions of Visual Studio (2008, 2015, 2017, 2019), all preferably as debug and release builds.
Adding the two main branches (trunk for BETA, 2016 for Orbiter-2016) sometimes makes this more complicated then it looks

Nevertheless, I'm glad that you could make a debug-build for your purpose.


[1] See Orbitersdk\VS2015\PropertyPages\orbiter.props & Orbitersdk\VS2015\PropertyPages\orbiter_debug.prop s
kuddel is offline   Reply With Quote
Old 01-17-2020, 09:26 PM   #5079
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by kuddel View Post
 The lib itself is Jarmonik's brainchild and as far as I know he deliberately build it with Visual Studio 2008...(please correct me if I'm wrong here )
3.12 maybe, but the last 2 versions where probably built with a more recent VS. I used the 201x solution, and only changed the CRT libs from static to dynamic, compile, copy to the SSU folders, compile and it all works.



Quote:
Originally Posted by kuddel View Post
 I am currently trying out several options on how to build all the stuff and the gcAPI.lib thing is one of the issues these endeavors should explore

I will also probably try a completely different runtime setup for all of the D3D9Client related builds, as I noticed that the "recommended" setup by the Orbiter-BETA provided prop-sheets use MultiThreadedDLL for release builds and MultiThreadedDebugDLL for debug builds[1].

As far as I know, for a complete coverage we would need to provide a lib for all possible combinations:
Release/Debug <=> Multithreaded/Singethreaded <=> Statis/Dymanic
...and possibly some more I've missed.
The general goal however is: Provide one library for all release module DLLs that need gcAPI support, while during development the Modue-developer still can do so by getting the source-code.

Complicating the tasks is that I like to keep the ability to build D3D9Client with several versions of Visual Studio (2008, 2015, 2017, 2019), all preferably as debug and release builds.
Adding the two main branches (trunk for BETA, 2016 for Orbiter-2016) sometimes makes this more complicated then it looks

Nevertheless, I'm glad that you could make a debug-build for your purpose.


[1] See Orbitersdk\VS2015\PropertyPages\orbiter.props & Orbitersdk\VS2015\PropertyPages\orbiter_debug.prop s
AFAIK, there are (only) 4 possible configurations: static debug, static release, dynamic debug, dynamic release.
BTW: if you are doing re-organization work, you could put the dll and library under the same solution.

For now it all works.... until M$FT changes the rules again....
GLS is offline   Reply With Quote
Old 01-18-2020, 08:43 PM   #5080
jarmonik
Beta Tester

Default

I can confirm that the gcAPI.lib has been previously build with VS2008 and the latest was build with VS2015 under an impression that it's working. So, I can make one last rebuild of it using VS2008 and after that the gcAPI.lib is becoming obsollete since the functionality will be provided via virtual gcCore interface which is more developper friendly. And no more modification or features are added to gcAPI.lib

The gcCore interface will be officially published when it's ready enough and no more compatibility breaking modifications are made to it. Right now any application using it will need to be recompiled after every change made to the interface.

Connection to gcCore Interface can be easily acquired by including the following code into a user application. This does NOT require to link the gcAPI.lib into a work.

PHP Code:
typedef gcCore * (__cdecl *__gcGetCoreAPI)();

gcCore gcGetCoreAPI()
{    
    
HMODULE hModule GetModuleHandle("D3D9Client.dll");    
    if (
hModule)  {
         
__gcGetCoreAPI pGetCoreAPI = (__gcGetCoreAPI)GetProcAddress(hModule"gcGetCoreAPI"); 
         if (
pGetCoreAPI) return pGetCoreAPI();
    }       
    return 
NULL;

EDIT: I am working on a Terrain ToolKit right now to import/export terrain information to Orbiter and There is plenty of development going on with the gcCore Interface. After the toolkit is out the gcCore sould be stable enough to publish it. The work is about 75% completed. Lot of progress is made but the workload was 10 times bigger than initially estimated.

Last edited by jarmonik; 01-18-2020 at 08:58 PM.
jarmonik is offline   Reply With Quote
Thanked by:
Old 01-18-2020, 10:27 PM   #5081
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by jarmonik View Post
 Right now any application using it will need to be recompiled after every change made to the interface.
You mean for current library version, right? With that new interface, unless the signature of the functions gets changed, a new version will be transparent to the code of the client. It will be like a dll.
GLS is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Visualization Project

Tags
d3d9client, graphicsclient


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 04:41 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.