New Release D3D9Client Development

jarmonik · Aug 29, 2012

D3D9Client R1f

I couldn't produce any CTDs with the boiled down scenario. However, there are many changes in the latest build that may effect so here is the latest build for testing.

To anyone reading this post:
If the log contains any errors written in red, except the one below, let me know about them.

There is something special in the Shuttle Fleet since it's attempting to use a feature that's not used by any other add-on I know. Resulting an error "EVENT_VESSEL_CLEARANIM Not Implemented". I am not exactly sure what should it do. If there are no problems related to animations then we can probably ignore it for now.

PAPI configuration has been changed to be more compatible with the inline engine. PAPI2 defination is no-longer valid. See more details form /Doc/D3D9Client_forDeveloppers.doc

kuddel · Aug 29, 2012

Hi jarmonik,

thanks for the R1f !
While I was testing VLD (which is a very very nice, free tool!) I found two memory leaks that sneaked into the code...
- TileCatalog wasn't deleted @ D3D9Client.cpp
- MESHGROUPEX members Idx and Vtx weren't deleted @ RingMgr.cpp

Attached you'll find the changed files (based on R1f).
Note to users: This ZIP does not contain any module, just two source files. So you might not need to download this. Only jarmonik releases 'official' packages!

Good Night,

Kuddel

Donamy · Aug 29, 2012

Does cameraMFD work with Dx9 ?

jarmonik · Aug 30, 2012

kuddel said:
While I was testing VLD (which is a very very nice, free tool!) I found two memory leaks that sneaked into the code...

I already downloaded that a while ago but I haven't had time to install it.
Thanks, I'll merge the code with mine.

Jarmo

---------- Post added at 07:15 ---------- Previous post was at 07:13 ----------

Donamy said:
Does cameraMFD work with Dx9 ?

I don't know haven't tested it. But there is a feature under a work that would allow to render the scene into a surface.

kuddel · Aug 30, 2012

Hi jarmonik,

I've spend a little time debugging the D3D9Client and found some strange things...maybe you (or someone else) can shed some light into it

Whenever I run the session and exit, there are many "Access Violations" during shutdown. This of cause only happens when Orbiter shutdown options are set to 'De-allocate memory and display launchpad dialog'.

So I tried to find out what sequence of callbacks / destructors were called, here's what I found:
During shutdown,
first the Destructor of D3D9Client (D3D9Client::~D3D9Client()) is called and after that ExitModule is called.
So I changed the code so, that oapiUnregisterGraphicsClient(g_client) is called at the destructor (instead of deeing done at/in ExitModule) and the number of violations drastically decreased!
To me it seems that during the oapiUnregisterGraphicsClient(...)-call Orbiter still calls some methods of that given Object (g_client).

But what's still puzzling me is that there are still some Access-Violations appearing...
Do you have any information about this behaviour? Has martin wrote something about the shutdown sequence?

Thanks in advance for any hints,
Kuddel

P.S.: Here's what the changed Destructor/ExitModule looks after my changes:

PHP:

DLLCLBK void ExitModule(HINSTANCE hDLL)
{
    if (bException) LogErr("!!! Abnormal Program Termination !!!");
    
    delete TileCatalog;
    delete MeshCatalog;
    delete SurfaceCatalog;
    delete Config;

    LogAlw("--------------ExitModule------------");

    DebugControls::Release();

    LogAlw("Log Closed");
    D3D9CloseLog();

#ifdef _NVAPI_H
    if (bNVAPI) if (NvAPI_Unload()==NVAPI_OK) LogAlw("[nVidia API Unloaded]");
#endif

}

PHP:

D3D9Client::~D3D9Client()
{
    LogAlw("D3D9Client destructor called");

    if (g_client) {
        oapiUnregisterGraphicsClient(g_client);
        g_client = 0;
    }

    SAFE_DELETE(vtab);
    SAFE_DELETE(pFramework);
}

jarmonik · Aug 31, 2012

kuddel said:
During shutdown,first the Destructor of D3D9Client (D3D9Client::~D3D9Client()) is called and after that ExitModule is called.

Interesting, I would have assumed that oapiUnregisterGraphicsClient() would call the destructor. It's not documented as far as I know.

kuddel said:
So I changed the code so, that oapiUnregisterGraphicsClient(g_client) is called at the destructor (instead of deeing done at/in ExitModule) and the number of violations drastically decreased!

Thanks for doing this, it's good to know that. I don't know what's going on there.

kuddel said:
To me it seems that during the oapiUnregisterGraphicsClient(...)-call Orbiter still calls some methods of that given Object (g_client).

There are many non-callback functions in the client's base class.
There has been problems with these:

oapi:

3D9Client::LaunchpadVideoWndProc
oapi:

3D9Client::RenderWndProc

There is already a code section added in RenderWndProc

PHP:

if (hRenderWnd!=hWnd) {
LogWrn("Invalid Window in RenderWndProc() Window is already destroyed");
return 0;
}

kuddel said:
Has martin wrote something about the shutdown sequence?

Nothing that I am aware of.

kuddel said:
Do you have any information about this behaviour?

There is an access violation caused by LUA and it's very likely fixed from the latest beta. And there are many vialations in many add-ons. Is this a D3D9Client specific ?

P.S. When you are doing debugging remember to enable a proper set of _TRACE macros from D3D9Util.h there are some problems with #ifdef _DEBUG

kuddel · Aug 31, 2012

jarmonik said:
Interesting, I would have assumed that oapiUnregisterGraphicsClient() would call the destructor.

Me too

jarmonik said:
There are many non-callback functions in the client's base class.
There has been problems with these:

oapi:3D9Client::LaunchpadVideoWndProc
oapi:3D9Client::RenderWndProc

There is already a code section added in RenderWndProc

PHP:

if (hRenderWnd!=hWnd) { LogWrn("Invalid Window in RenderWndProc() Window is already destroyed"); return 0; }

Yeah, I already noticed that. I am not sure if there might be a need for extra handling of WM_DESTROY or something like that.

jarmonik said:
There is an access violation caused by LUA and it's very likely fixed from the latest beta.

Any chance to start the testing without LUA (dll)? Maybe with a dummy-dll?
I have used both v100830 and v111105 Orbiters, but both do not shut-down nicely...

jarmonik said:
And there are many vialations in many add-ons. Is this a D3D9Client specific ?

I can not tell for sure, but I am always testing without any other add-on!
Not even OrbiterSound. ...the symbolic link to "Sound" is present, but leads to an empty directory.

Maybe I will start a Debug session of the external D3D7Client and see what's the deal with those violations etc. there.

jarmonik said:
P.S. When you are doing debugging remember to enable a proper set of _TRACE macros from D3D9Util.h there are some problems with #ifdef _DEBUG

O.K. I see! I'll come back as soon as I have more insight (hopefully

)

Regards and thanks for the informations,
Kuddel

jarmonik · Sep 1, 2012

I can see only one access violation. Or are you talking about something else ?

Any ideas what's the story behind the "normal blocks", what are they anyway ?

Code:

The thread 'Win32 Thread' (0xc1c) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x960) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x8e4) has exited with code 0 (0x0).
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\ShuttlePB.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\DeltaGlider.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\ShuttleA.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Sun.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Mercury.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Venus\atmosphere\VenusAtm2006.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Venus.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Earth\atmosphere\EarthAtmJ71G.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Earth.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Moon.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Mars\atmosphere\MarsAtm2006.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Mars.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Phobos.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Deimos.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Jupiter.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Io.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Europa.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Ganymede.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Callisto.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Galsat.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Saturn.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Mimas.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Enceladus.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Tethys.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Dione.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Rhea.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Titan.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Iapetus.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Satsat.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Uranus.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Miranda.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Ariel.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Umbriel.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Titania.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Oberon.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Celbody\Neptune.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Vsop87.dll'
The thread 'Win32 Thread' (0x53c) has exited with code 0 (0x0).
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Startup\AtlantisConfig.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Startup\AtmConfig.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Startup\DGConfigurator.dll'
Detected memory leaks!
Dumping objects ->
{4325} normal block at 0x04309C60, 0 bytes long.
 Data: <> $üŸ
{4319} normal block at 0x04309C30, 0 bytes long.
 Data: <> $üŸ
{4313} normal block at 0x04309C00, 0 bytes long.
 Data: <> $üŸ
{4302} normal block at 0x04309BD0, 0 bytes long.
 Data: <> $üŸ
{4296} normal block at 0x04309BA0, 0 bytes long.
 Data: <> $üŸ
{4290} normal block at 0x04309B70, 0 bytes long.
 Data: <> $üŸ
{4284} normal block at 0x04309B40, 0 bytes long.
 Data: <> $üŸ
{4278} normal block at 0x04309B10, 0 bytes long.
 Data: <> $üŸ
{4272} normal block at 0x04309AE0, 0 bytes long.
 Data: <> $üŸ
{4266} normal block at 0x04309AB0, 0 bytes long.
 Data: <> $üŸ
{4259} normal block at 0x04309A80, 0 bytes long.
 Data: <> $üŸ
{4253} normal block at 0x04309A50, 0 bytes long.
 Data: <> $üŸ
{4247} normal block at 0x04309A20, 0 bytes long.
 Data: <> $üŸ
{4236} normal block at 0x043099F0, 0 bytes long.
 Data: <> $üŸ
{4230} normal block at 0x043099C0, 0 bytes long.
 Data: <> $üŸ
{4224} normal block at 0x04309990, 0 bytes long.
 Data: <> $üŸ
{4218} normal block at 0x04309960, 0 bytes long.
 Data: <> $üŸ
{4212} normal block at 0x04309930, 0 bytes long.
 Data: <> $üŸ
{4206} normal block at 0x04309900, 0 bytes long.
 Data: <> $üŸ
{4199} normal block at 0x043098D0, 0 bytes long.
 Data: <> $üŸ
{4193} normal block at 0x04309438, 0 bytes long.
 Data: <> $üŸ
{4187} normal block at 0x042DF800, 0 bytes long.
 Data: <> $üŸ
{4181} normal block at 0x042DF7D0, 0 bytes long.
 Data: <> $üŸ
{4175} normal block at 0x042DF770, 0 bytes long.
 Data: <> $üŸ
{4155} normal block at 0x042A4D18, 0 bytes long.
 Data: <> $üŸ
{4140} normal block at 0x04299E78, 0 bytes long.
 Data: <> $üŸ
{4095} normal block at 0x0425DC68, 0 bytes long.
 Data: <> $üŸ
{4082} normal block at 0x04284E38, 0 bytes long.
 Data: <> $üŸ
{91} normal block at 0x04244220, 0 bytes long.
 Data: <> $üŸ
Object dump complete.
Detected memory leaks!
Dumping objects ->
{4325} normal block at 0x04309C60, 0 bytes long.
 Data: <> „üŸ
{4319} normal block at 0x04309C30, 0 bytes long.
 Data: <> „üŸ
{4313} normal block at 0x04309C00, 0 bytes long.
 Data: <> „üŸ
{4302} normal block at 0x04309BD0, 0 bytes long.
 Data: <> „üŸ
{4296} normal block at 0x04309BA0, 0 bytes long.
 Data: <> „üŸ
{4290} normal block at 0x04309B70, 0 bytes long.
 Data: <> „üŸ
{4284} normal block at 0x04309B40, 0 bytes long.
 Data: <> „üŸ
{4278} normal block at 0x04309B10, 0 bytes long.
 Data: <> „üŸ
{4272} normal block at 0x04309AE0, 0 bytes long.
 Data: <> „üŸ
{4266} normal block at 0x04309AB0, 0 bytes long.
 Data: <> „üŸ
{4259} normal block at 0x04309A80, 0 bytes long.
 Data: <> „üŸ
{4253} normal block at 0x04309A50, 0 bytes long.
 Data: <> „üŸ
{4247} normal block at 0x04309A20, 0 bytes long.
 Data: <> „üŸ
{4236} normal block at 0x043099F0, 0 bytes long.
 Data: <> „üŸ
{4230} normal block at 0x043099C0, 0 bytes long.
 Data: <> „üŸ
{4224} normal block at 0x04309990, 0 bytes long.
 Data: <> „üŸ
{4218} normal block at 0x04309960, 0 bytes long.
 Data: <> „üŸ
{4212} normal block at 0x04309930, 0 bytes long.
 Data: <> „üŸ
{4206} normal block at 0x04309900, 0 bytes long.
 Data: <> „üŸ
{4199} normal block at 0x043098D0, 0 bytes long.
 Data: <> „üŸ
{4193} normal block at 0x04309438, 0 bytes long.
 Data: <> „üŸ
{4187} normal block at 0x042DF800, 0 bytes long.
 Data: <> „üŸ
{4181} normal block at 0x042DF7D0, 0 bytes long.
 Data: <> „üŸ
{4175} normal block at 0x042DF770, 0 bytes long.
 Data: <> „üŸ
{4155} normal block at 0x042A4D18, 0 bytes long.
 Data: <> „üŸ
{4140} normal block at 0x04299E78, 0 bytes long.
 Data: <> „üŸ
{4095} normal block at 0x0425DC68, 0 bytes long.
 Data: <> „üŸ
{4082} normal block at 0x04284E38, 0 bytes long.
 Data: <> „üŸ
{91} normal block at 0x04244220, 0 bytes long.
 Data: <> „üŸ
Object dump complete.
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\Plugin\D3D9ClientDebug.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\Modules\D3D9TK.dll'
'orbiter.exe': Unloaded 'C:\Windows\SysWOW64\D3DX9_42.dll'
First-chance exception at 0x0e0076a7 in orbiter.exe: 0xC0000005: Access violation.
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\LuaInline.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\LuaInterpreter.dll'
'orbiter.exe': Unloaded 'C:\Software\Orbiter2010-Clean\lua5.1.dll'
The thread 'Win32 Thread' (0xd24) has exited with code 1 (0x1).
The thread 'Win32 Thread' (0x674) has exited with code 1 (0x1).
The thread 'Win32 Thread' (0x95c) has exited with code 1 (0x1).
The thread 'Win32 Thread' (0xa44) has exited with code 1 (0x1).
The thread 'Win32 Thread' (0xdc0) has exited with code 1 (0x1).
The thread 'Win32 Thread' (0xc60) has exited with code 1 (0x1).
The thread 'Win32 Thread' (0xcbc) has exited with code 1 (0x1).
The thread 'Win32 Thread' (0x5cc) has exited with code 1 (0x1).
The thread 'Win32 Thread' (0xf30) has exited with code 1 (0x1).
The thread 'Win32 Thread' (0xfe8) has exited with code 1 (0x1).
The program '[2832] orbiter.exe: Native' has exited with code 1 (0x1).

asmi · Sep 1, 2012

jarmonik said:
Interesting, I would have assumed that oapiUnregisterGraphicsClient() would call the destructor. It's not documented as far as I know.

It is impossible to do since you are likely to have different CRT then the one used in Orbiter. Since you've created an object, you need to delete it as well.

kuddel · Sep 1, 2012

asmi said:
It is impossible to do since you are likely to have different CRT then the one used in Orbiter. Since you've created an object, you need to delete it as well.

Of course!
The question here was not if we have to delte, but when.
In our case we deleted the objects (Destructor of D3D9Client is called) and set the global reference (g_client) to NULL. After that the Orbiter core still tried to access some members of that (now invalid) reference.

Orbiter seems to store the object reference given to it at InitModule ( oapiRegisterGraphicsClient(g_client) ), but doesn't invalidate it's reference at oapiUnregisterGraphicsClient(g_client)...

So it is absolutely clear, that any object that we've created has to be deleted by us, but the core has to make sure not to access the reference anymore after destruction.

Kuddel

---------- Post added at 19:03 ---------- Previous post was at 18:54 ----------

jarmonik said:
I can see only one access violation. Or are you talking about something else ?

Any ideas what's the story behind the "normal blocks", what are they anyway ?

No, sorry.

Regarding those " 0xC0000005: Access violations", I usually have several of them, and sometimes it even ends up in an "stack overflow"

You are using VC2008, right? I am using VC2010. maybe that makes a difference.
For the record, here's my setup:
- Win7 (64bit)
- Orbiter v111105
- no further Add-ons
- Microsoft Visual Studio 2010 Version 10.0.40219.1 SP1Rel

Anyway, could you confirm the "destruction/ExitModule order"?

jarmonik · Sep 1, 2012

asmi said:
It is impossible to do since you are likely to have different CRT then the one used in Orbiter. Since you've created an object, you need to delete it as well.

Yes, that's what I first thought. However, deleting the client like this in the ExitModule() will result a CTD on exit.

PHP:

if (g_client) {
        oapiUnregisterGraphicsClient(g_client);
        delete g_client;
        g_client = 0;
}

Without deleting the client by my self the destructor is still called from the Orbiter.

---------- Post added at 20:40 ---------- Previous post was at 20:16 ----------

kuddel said:
Regarding those " 0xC0000005: Access violations", I usually have several of them, and sometimes it even ends up in an "stack overflow"

You are using VC2008, right? I am using VC2010. maybe that makes a difference.
For the record, here's my setup:
- Win7 (64bit)
- Orbiter v111105
- no further Add-ons
- Microsoft Visual Studio 2010 Version 10.0.40219.1 SP1Rel

Anyway, could you confirm the "destruction/ExitModule order"?

I am using VC2008, Win 7 (x64), Orbiter 100830.

I can confirm that the destructor is called before ExitModule() which is very starange.

---------- Post added at 20:44 ---------- Previous post was at 20:40 ----------

I set a breakpoint into the destructor and it was called from the orbiter, Before calling oapiUnregisterGraphicsClient() in ExitModule().

(22298: 24.09s 1us)(0xB80)[TRACE] .\D3D9Client.cpp Line:1228 oapi:

3D9Client::LaunchpadVideoWndProc
(22299: 24.10s 1us)(0xB80)[TRACE] .\D3D9Client.cpp Line:1228 oapi:

3D9Client::LaunchpadVideoWndProc
(22300: 24.11s 4169us)(0xB80) D3D9Client destructor called
(22301: 24.11s 4227us)(0xB80) Deleting Framework
(22302: 24.11s 4261us)(0xB80)[WARNING] NOT RELEASED Refs=1, File=.\D3D9Frame.cpp Line=65
(22303: 24.11s 4308us)(0xB80) --------------ExitModule------------
(22304: 24.11s 5505us)(0xB80) Log Closed

---------- Post added at 20:46 ---------- Previous post was at 20:44 ----------

kuddel said:
Regarding those " 0xC0000005: Access violations", I usually have several of them, and sometimes it even ends up in an "stack overflow"

I have just one always. Have you enabled DirectX debugging from DX control panel ?

---------- Post added at 20:52 ---------- Previous post was at 20:46 ----------

Placing the oapiUnregisterGraphicsClient(g_client); into the destructor don't seem to have any effect in my computer.

jarmonik · Sep 2, 2012

D3D9Client R2

OK, here is a launch attempt for R2.

And a list of changes after R1

- CTD related to taxi lights fixed.
- Dynamic link creation and warning should be fixed.
- Moon visibility through atmosphere fixed.
- Shuttle Fleet animation issue fixed.
- Configuration file parser changes.
- NormalMap fx fix for shader model 2.0
- PAPI compatibility with inline engine improved
- Opacity and scale controls are working with force vectors and axes. (Thanks for Kuddel)

DebugControls related changes:
- Wireframe mode added in debug controls
- Dual sided rendering added in debug controls
- Logarithmic camera sensitivity
- If display mode is set to "Selected Mesh" then the mesh is visible recardless of visibility mode.
- If display mode is any other than "Everything" then the planet is also hidden.

It will probably take some time until a next version of D3D9Client is released. There are some license issues those need to be sorted out and I am planing to start working on a few other features those may take some time to implement.

But here is the R2 and if everything seems to be in order then I'll upload the package into the first post and the D3D9Client site.

Cras · Sep 2, 2012

Been flying around in the Shuttle with R2....so far so good!

kuddel · Sep 3, 2012

jarmonik said:
Any ideas what's the story behind the "normal blocks", what are they anyway ?

Indeed, now I have

They are from us :blush:

They are "zero-sized arrays" that were created at the constructor of vPlanet (Line 108)

PHP:

//...
    nbase = oapiGetBaseCount(_hObj);
    vbase = new vBase*[nbase]; // <- no good if nbase == 0
//...

The destructor will not free it (it checks for nbase)!
Anyway the rule "don't allocate zero bytes" does the job here. Just don't allocate anything in case (nbase==0) and those "zero sized blocks" don't get allocated and therefore don't need to be freed.:thumbup:

PHP:

//...
    nbase = oapiGetBaseCount(_hObj);
    vbase = nbase ? new vBase*[nbase] : NULL; // never allocate 0-sized memory
//...

Regards,

Kuddel

---------- Post added at 23:45 ---------- Previous post was at 23:24 ----------

Hi jarmonik,

here's another one (memory leak):
In VBase.cpp (line 62 ff.):

PHP:

//...
    if (ntile) {

        MESHGROUPEX **grps = new MESHGROUPEX*[ntile];
        SURFHANDLE *texs = new SURFHANDLE[ntile];

        for (i = 0; i < ntile; i++) {
            DWORD ng = oapiMeshGroupCount(tspec[i].mesh);
            if (ng!=1) LogErr("MeshGroup Count = %u",ng);
            else {
                texs[i] = tspec[i].tex;
                grps[i] = oapiMeshGroupEx(tspec[i].mesh, 0);
            }
        }
        tilemesh = new D3D9Mesh(gc, ntile, (const MESHGROUPEX**)grps, texs);
        delete []grps; // <- we don't need 'em anymore!
        delete []texs; // <- we don't need 'em anymore!
    }
// ...

Those two "delete[]"s were missing (see my comments)

Regards and good Night,

Kuddel

DaveS · Sep 3, 2012

I think I have found a critical bug. It seems like D3D9Client can't handle more than one instance of RUNWAYLIGHTS. This problem results in any other runways lacking their PAPIs/VASIs.

This problem is easily reproduced by simply copying/pasting the PAPI/VASI data from the default KSC SLF to the default CCAFS Skid Strip runway lights data.

Now just orient the camera so that you have an unobstructed view of both the SLF and CCAFS Skid Strip. The lights should be missing from the Skid Strip while the SLF lights remains visible.

jarmonik · Sep 4, 2012

kuddel said:
Indeed, now I have

They are from us :blush:

They are "zero-sized arrays" that were created at the constructor of vPlanet (Line 108)

---------- Post added at 23:45 ---------- Previous post was at 23:24 ----------

here's another one (memory leak):
In VBase.cpp (line 62 ff.):
Those two "delete[]"s were missing (see my comments)

Ok, thanks. I have included the modifications. It's pretty easy to miss something like that while writing the code.

---------- Post added at 12:28 ---------- Previous post was at 12:19 ----------

DaveS said:
I think I have found a critical bug. It seems like D3D9Client can't handle more than one instance of RUNWAYLIGHTS. This problem results in any other runways lacking their PAPIs/VASIs.

This problem is easily reproduced by simply copying/pasting the PAPI/VASI data from the default KSC SLF to the default CCAFS Skid Strip runway lights data.

I haven't been able to reproduce this and the code seems to be ok. Are you using R2 release and have you noted that the PAPI configuration has changed and the PAPI2 is no-longer valid. The new configuration should be more backwards compatible with the inline engine. See /Doc/D3D9Client_forDeveloppers.doc

DaveS · Sep 4, 2012

jarmonik said:
I haven't been able to reproduce this and the code seems to be ok. Are you using R2 release and have you noted that the PAPI configuration has changed and the PAPI2 is no-longer valid. The new configuration should be more backwards compatible with the inline engine. See /Doc/D3D9Client_forDeveloppers.doc

Here's a screenshot showing the problem. The only PAPI and VASI lights showing up is the ones at the SLF. Here's the relevant sections:

Code:

RUNWAYLIGHTS ; KSC SLF lights
    END1 -8220 -3 -600
    END2 -12670 -12 -3155
    WIDTH 100
    COUNT1 40
    PAPI 20 3 -2000
    VASI 1.5 152 671
END
RUNWAYLIGHTS ; CCAFS Skid Strip lights
    END1 6860 -13 11805
    END2 4978 -7 9398
    WIDTH 100
    COUNT1 40
    PAPI 20 3 -2000
    VASI 1.5 152 671
END

jarmonik · Sep 4, 2012

I can see that but I am still unable to reproduce this. Here is the latest build, please let me know is the problem is fixed. This is released just to be sure we both have the latest build R2b.

So, This is only a PAPI/VASI problem, Runway lights are working ?

Is anyone else having the same problem or is it working.

jarmonik · Sep 4, 2012

If the runway lights are not working at all for the Skid Strip then it might be possible that you have two overlapping bases and they both render the base tiles so the light would be under the tiles. The light are rendered without depth buffer due to transparency.

If you enable the planetarium mode do you see multible base markers for KSC ?

DaveS · Sep 4, 2012

jarmonik said:
So, This is only a PAPI/VASI problem, Runway lights are working ?

Yes. The runway lights are working but not the PAPI/VASI. And no change with the R2B module. And no multiple base makers for KSC.

New Release D3D9Client Development

Well-known member

Attachments

Donator

Attachments

Addon Developer

Well-known member

Donator

Well-known member

Donator

Well-known member

Addon Developer

Donator

Well-known member

Well-known member

Attachments

Spring of Life!

Donator

Addon Developer

Well-known member

Addon Developer

Well-known member

Well-known member

Addon Developer

Similar threads