Some TIPS on Direct3D

I

iMuYa

Newcomer
Joined
Sep 21, 2004
Messages
16
Location
Malaysia
Improving performance:
=================
extract:
'Use SoftwareVertexProcessing
Dim flags As Direct3D.CreateFlags = CreateFlags.SoftwareVertexProcessing

'Get the capability of the device
Dim caps As Direct3D.Caps = Manager.GetDeviceCaps(0, eviceType.Hardware)

'Use HardwareVertexProcessing
If caps.DeviceCaps.SupportsHardwareTransformAndLight Then
flags = CreateFlags.HardwareVertexProcessing
End If

'Use PureDevice
If caps.DeviceCaps.SupportsPureDevice Then
flags = flags Or CreateFlags.PureDevice
End If

device = New Device(0, DeviceType.Hardware, Me, flags, presentParams)

This way, the vertex processing will be done in Hardware if your hardware is supporting it. My game improve > 10% after I've done that.

Use Option Strict ON
I think those who have read Tom's book know the nightmare of the Boxing and Unboxing. Try minimise the Boxing and Unboxing work in your application. The best example is the C++ version of billboard and C# version of it. C# version run at 60% of the C++ version, bcs of the Boxing and Unboxing thingy.

2D Performance
I'm not using the ZBuffer for my game. It's a waste anyway. Disable some of the 3D option can help the performance of your 2D application.

Transparency:
==========
I used .PNG graphics for my game actually. I save spaces and save work on the transparency.

I'm actually looking for WAYS how to shrink the memory consumption, if anyone in this forum know, can you share with us?
 
Last edited:
iMuYa said:
Use Option Strict ON
I think those who have read Tom's book know the nightmare of the Boxing and Unboxing. Try minimise the Boxing and Unboxing work in your application. The best example is the C++ version of billboard and C# version of it. C# version run at 60% of the C++ version, bcs of the Boxing and Unboxing thingy.
Click to expand...

So you are saying....not to use late bound functions? You are probably correct, but for scripting purposes, what if you don't know the name of the class or the functions it contains until the script is loaded?

I use the CallByName() function in this situation, but this is probably just as bad as using late bound functions. Is there any way to use early binding with a scripting engine that loads the script at runtime?
 
Aragorn7 said:
So you are saying....not to use late bound functions? You are probably correct, but for scripting purposes, what if you don't know the name of the class or the functions it contains until the script is loaded?

I use the CallByName() function in this situation, but this is probably just as bad as using late bound functions. Is there any way to use early binding with a scripting engine that loads the script at runtime?
Click to expand...

Well, i do not really understand what's script that you referring to. Anyway, try to minimise but not to eliminate. If there is no way, then you will have to stick with that. Sorry...
 
iMuYa said:
Well, i do not really understand what's script that you referring to. Anyway, try to minimise but not to eliminate. If there is no way, then you will have to stick with that. Sorry...
Click to expand...

I use the CodeDom compiler built into VB.NET/C#. It basically can compile raw text (script), into a form that VB.NET can use. Its completely dynamic, and can even make its own EXE's if you want.

Its pretty flexible, and is a lot faster than the outdated "MsScriptControl" for VB6. With this, you can build dynamic code straight into your program while its running! So, obviously, the only way to call these functions is to use the CallByName() function.

I was wondering if CallByName() is just as bad as late binding? or better? or same?


Late Binding - calling functions and using variables from an object type not known at runtime.

Early Binding - calling functions and using variables from an object type that is known at runtime.

Strict ON does not allow Late Binding; it only allows Early Binding.
 
You should really think about using interfaces to expose the functionality of your scripts instead of CallByName. Look for an article about this in the Tutor's Corner subforum.
 
Ya, I do know how to do that, but I didn't like the boxed in functionality. To update the interface, you can't just change the script, you have to recompile. That is what bothered me about interfaces. I still use an interface to expose the script, but only for certain initialization steps. Some day I will change it, but in the beginning of the program/game, you really don't know how things will turn out by the end. So you might end up recompiling that DLL 10000 times if you aren't careful.
 
Back
Top