Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK .NET / Odd vertexdata behavior

Author
Message
scientist
18
Years of Service
User Offline
Joined: 6th May 2005
Location: texas
Posted: 26th Feb 2010 00:57
I am working on a class to implement very large terrains(10,000+ vertices). I have it locking and unlocking the vertexdata almost every frame, and I noticed that as I more changes to the vertexdata it would slowly take more time for each operation.
Has anyone experience this before, or now how to fix it?
Or does anyone know how fast editing a large mesh using memblocks is?
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 27th Feb 2010 11:49
Quote: "Or does anyone know how fast editing a large mesh using memblocks is?"


Slower than the vertexdata commands, as when you do an update from a memblock it updates all of the vertices.
scientist
18
Years of Service
User Offline
Joined: 6th May 2005
Location: texas
Posted: 27th Feb 2010 18:48
I fixed it. It was not caused by the vertexdata commands. I was creating 15 or so Vector3's each frame and there were not being freed correctly after the method calls.

So there is a problem with the garbage collector. Objects that are created within a method are not freed after the method call finishes and the dark basic engine believes that they still exist, and can cause a slowdown if a lot of them are created.

Also the Vector3 delete method is really slow.
APEXnow
Retired Moderator
20
Years of Service
User Offline
Joined: 15th Apr 2003
Location: On a park bench
Posted: 2nd Mar 2010 20:30
The freeing of objects is a side effect of removing references from the classes when the function is exited. Because the 3D engine is native and does not fall into the garbage collection queue, you will need to physically delete the objects before you exit any function if that's the behaviour desired.

Paul.

Stefano
User Banned
Posted: 31st Mar 2010 13:25
Quote: "The freeing of objects is a side effect of removing references from the classes when the function is exited. Because the 3D engine is native and does not fall into the garbage collection queue, you will need to physically delete the objects before you exit any function if that's the behaviour desired."

This is quite a surprise. Automatic garbage collection is a .NET 'plus'.
What method was used to 'wrap' the native 3D engine?
veltro
User Banned
Posted: 6th Apr 2010 17:00
Don't know how the DarkGDK.NET is wrapped around the native engine.

I think it should be something like

// wrapper class for native vector3
Class Vector3 {

public Vector3()
{
// create the native engine vector3
}

public ~Vector3()
{
// delete the native engine vector3
}
}

This way when a NET Vector3 goes out of scope, the garbage collector can delete native engine data and free native engine memory
APEXnow
Retired Moderator
20
Years of Service
User Offline
Joined: 15th Apr 2003
Location: On a park bench
Posted: 7th Apr 2010 18:13
A majority of the classes need to be changed so that they implement the IDisposable interface for dealing with DarkGDK Native object resource freeing.

Presently, deletion of object data is done via the class Delete Methods. I know this is not ideal at present.

Paul.

scientist
18
Years of Service
User Offline
Joined: 6th May 2005
Location: texas
Posted: 18th Apr 2010 17:43
I fixed the problem a while ago using the managed direct x vectors instead because the delete methods were far to slow with the number of vectors I was creating. It will be nice when DarkGDK objects are freed by the garbage collector properly.
veltro
User Banned
Posted: 19th Apr 2010 16:30
You can also view SlimDX code to see how to build good NET wrapper for basic DirectX object like Vector, Matrix, Plane, etc,.

I think the way DarkGDK.Net does is the worst...
kBessa
17
Years of Service
User Offline
Joined: 8th Nov 2006
Location: Manaus, Amazonas, Brazil
Posted: 20th Apr 2010 03:00
The problem is that it's a BIG collection of wrappers. We have:

DirectX -> DarkGDK -> DarkGDK.NET -> Class Library (if you use it).

[center][center]
veltro
User Banned
Posted: 20th Apr 2010 11:49
yes too many wrappers. Having darkgdk source code available you can remove 2 steps.

DirectX -> DarkGDK.NET (with classes)

Sure you had to completely rewrite DarkDGK.NET
APEXnow
Retired Moderator
20
Years of Service
User Offline
Joined: 15th Apr 2003
Location: On a park bench
Posted: 20th Apr 2010 13:18
The class library is a beginner's step into programming with the Visual Basic and C# languages. Once you are confident in how to use the toolkit, I seriously suggest using the Interop library which is what I have used with my Asteroids game. (See sticky)

Yes, there is a slight bottle neck because of the wrapper, but lets be honest, using the advanced interop functionality of DarkGDK.NET, is alot easier to setup and use if you have had difficulties with Headers and Compiler errors when using C/C++. This was the whole point of developing DarkGDK.NET in the first place, to remove the complexities of C/C++ compiling complications.

It's not fast, and we all know this, but if you use the Interop library with good optimized VB/C# code, the differences are very close to using DarkGDK alone.

Paul.

Login to post a reply

Server time is: 2024-03-29 11:41:59
Your offset time is: 2024-03-29 11:41:59