Amazing Frame Rate and MSPF w/ Next version of DNT

#1 Hey Vince, could you compare it to the current non-dnt?

And system specs?

Also I remember something about DNT not going to be upgraded past the current MIT release?

#2 There ya go, showed the same scene between the two version w/ trees.

#3 Added in all the shaders to see what effect turning them all on would have.

#4 Excellent work Vince!

#5 Ah now I AM impressed! That's damn good.

#6 Is the processing of scripts and things that heavy one FPS?

#7 The reason the framerate difference is so much when all shaders are enabled is because the engine calls setShaderConst every frame tick (if I remember right)

In stock t3D it is doing a namespace/object lookup, finds the entry point to the function, then goes into the script engine and runs it.

So, even if the code is minimal, you still have lookups to the stringtable, if it calls another function it needs to do more lookups, etc.

In DNT, it's a bit different.

First, I hijack the function call before it hits the console right off. If DNT can't find a function to meet the requirements of the requested object and function, it then and only then passes it to the console.

Second,

The local variables inside the function live only in C#, so that is less entries in the stringtable and variable tables. Also, when the c# function needs to get a torque variable or call a console command, it's not using the console, it's using a direct casted pinvoke, thus reducing overhead of casting objects between strings and int's, etc.

Third,
Since as I convert the script I am removing the TorqueScript from the code files, that means there is less entries in the function lookup tables etc, so the remaining ones are found faster.

So in general, the engine actually starts to go faster and faster the farther I get into converting all the torquescript to csharp simply because I am reducing lookups in T3D memory lists. Compound that with the fact the C# is compiled into IL (which is dot.net assembly language basically). This means that it is not compiling on the fly, it is just running down an instruction set.

I'm sure there are other things going on here, but there the ones that my analytics report as the biggest gainers.

Vince

#8 The object lookup in TorqueScript really is terribly unoptimized - for instance when calling all those setShaderConst functions it will typically lookup the object in the local variable table then lookup the id in the global id table then lookup the function in the namespace, etc... its no wonder you are seeing such improvements with per-frame calls ;)

#9 Is that FPS counter in the templates somewhere, or did you make it yourself?

#10 console: metrics(fps)
metrics(gfx) is also nice, it gives you polycount and drawcalls

#11 Thanks. Found it in core/scripts/client/metrics.cs and core/art/gui/FrameOverlayGui.gui.