Perf numbers for t2d

#21 Fyi, i compiled everything as a release build and turned on every compile-time optimization i could, and perf numbers increased about 40%, which is good. (about 450 big static sprites (using same imagemap) before slowdown)

#22

Quote:Fyi, i compiled everything as a release build and turned on every compile-time optimization i could, and perf numbers increased about 40%, which is good. (about 450 big static sprites (using same imagemap) before slowdown)

That makes it seem much more likely that it is CPU that is causing the bottleneck, not the graphics chip. Which is pretty reasonable.

#23 @Smaug

great hypothosis smaug!

I started up task manager and saw that one of my processors crept upto about 90% utilization when i had 500 sprites on the screen.

So it does indeed seem to be cpu based. I hope that makes future optimizations easier!

(i checked this against my debug build, not the optimized release)

#24 Most games will use 99% of the cpu because they don't use the windows event system. Games are always updating themselves, and usually never free themselves up to the operating system.

Also, if you are using .NET to run Torque 2D you will most likely notice that the system starts to "chug" when you hit a certain amount of temporary objects being created each frame. This is due to the fact that the garbage collector doesn't run constantly, and can cause serious problems for a game's performance. Another thing that will start to happen, is after you run your game for lets say 5 minutes, it will start to chug. .NET is a poor platform for creating games at the moment, due to the garbage collector, and a load of other issues.

#25 I want to be very clear so that no one gets this assumption about T2D.NET. Ray's statement is false.

Why? Because t2d.net doesnt use .NET for the engine. The engine is pure C++, just as fast and performant as the current t2d engine (because it is the same engine).

I am using .NET for the higher-level functionality, generally you can think of it as replacing torquescript.

@Ray: I'm not really saying you are wrong, just wrong in this case. I dont know enough about .net game engines to know what the biggest perf issues come from. (Though GC happens asynchronously, so i would think it's not that big of an issue, just something that needs to be taken into consideration when designing your engine)

#26 To add to Jason S's comments, let's not forget that TorqueScript is ALSO garbage collected. Otherwise, Torque based games would eventually run out of system resources too.

#27 Well I have programmed a .NET game engine. In addition I have been using the .NET platform full time since the original betas of .NET. The way the automatic garbage collection works in .NET, you will end up running into issues in an non-trivial game situation. If you search the net you will find that a lot of smart people have proven this true, and through my own testing I have found it is true. There are some tricks you can do to get around this problem, but they are hacks. For example you can do a GC.Collect(); every frame to force .NET to collect short term objects. All garbage collection in .NET happens on the same thread as the currently running application, synchronously (except for in ASP.NET). So when the garbage collector gets called your application with freeze while it automatically collects and objects without references.

TorqueScript on the other hand, doesn't have that sort of automatic garbage collection. You have to actually destroy the objects yourself. For example if you create a ScriptObject, you must explicitly call a delete on it, when you want it to be destroyed. In other cases the SimGroup an object is in, will automatically destroy the child objects inside it when its deleted.

Now in summary, TorqueScript is a standardized language for development in the Torque series of game engines. It has been designed from scratch for realtime games, and gives developers a common language they can work with. In my opinion, and in the opinion of many other developers, .NET isn't good for games. Between the GC issues, the complexity of the language (its close to the complexity of C++ so it is definitely not the ideal scripting language), the lack of true crossplatform support, and various other issues, it makes it a poor target for games. In addition it fragments the community into developers using various different languages. This creates a rift between different developers and makes cooperation and code sharing harder.

#28 Oh and by the way, I am not bashing .NET. Its one of the most awesome platforms I have developed with. I just hope Microsoft makes the necessary changes in the langauge to make it better suited for realtime applications. And maybe integrate a simple, typeless language, that is easy for non-programmers to use into the platform.

#29 In general, your concerns are valid Ray.

I agree that you probably do *not* want to write a game engine in .NET (due to the issues you mentioned)

but I have to disagree with your issues on C# language complexity. It can be complex if you need to use complex features, but unless you count things like strict type casting and case sensitivity, it's as "easy to use" as any other language out there. (i forgot the semi-colon at the end of each statement)

I just want people to be clear that T2D.NET isnt written in C#, it's the regular t2d engine but with functionality exposed to .NET. In fact I wouldnt be supprised if it's faster than TorqueScript, because toruqescript needs to be parsed at runtime, t2d.net is compiled. and the perf issues i'm seeing here are not due to .net

If the reader wants to see my "pros of t2d.net" then check the first and second post of this thread.

#30 If anyone has a copy of VTune, we can find out where the time is being spent for sure.

#31 Torquescript is compiled at runtime.

#32

Quote:Torquescript is compiled at runtime.

Not into assembly. It's still interpreted at runtime.

#33 @Matthew and Smaug:

yeah, i guess it all depends on a person's definition of "compiled"

I would have to lean towards smaug's answer, because even though Torquescript is "compiled" down (it appears through a lex parser) it is definatly still an interpreted language at runtime.

Of course, I dont have any expertise in the field of C++ code optimizations and 'big O" to know just how fast (or slow) a bunch of switch statements and stack push/pops are compared to "really compiled" code..

==== now for some musings about t2d.net perf... (ignore if you are not interested)

If anyone has noticed, i am steering clear of any claims that my "t2d.net" is better performant, as while I can virtually gurentee t2d.net is faster at logic processing, (it is really compiled) the fact that t2d.net has to cross assembly boundaries and convert char* to/from Managed strings adds a large (and very real) amount of overhead.

At this point t2d.net is "fast enough" but eventually (after feature complete) I need to run perf numbers on it, and figure out ways of performance tuning. I am not too worried about that though.. my big "secret" (not so secret anymore) plan is to make t2d.net's game logic asynchronous to the graphics processing (t2d c++ engine) which itself should offer gains that would dwarf any marshaling improvements i make.

-Jason

#34 I don't see T2D scripting language becoming such a speed barrier anyway. You can always write some parts in C++ when needed. As I see it we would first need subframe interpolation so that the physics & onupdate code can run at a lower rate.. and then the T2Ds rendering needs to be improved. I am considering writing a faster and new map/tiles objects where I can use variable size tiles taken from one (or more) large textures so that I can have 100s of tiles on screen without suffering the current slow downs which seriously limits gamedesign.

#35

Quote: As I see it we would first need subframe interpolation so that the physics & onupdate code can run at a lower rate..

Um, why? Physics running slower causes problems, not the least of which is less accurate collision detection.

No, if you want to desynchronize your game loop from your render loop, you want to go the other way. That is, you want to run multiple game loops for every render loop. Rendering more than your game loop is a bad idea on many levels, gameplay included. It's never a good idea to show the player multiple frames that they have no control over (since player control happens as part of the game loop). Nor do you want your AI to go for more than 1/30th of a second without taking a look around to decide what to do.

Quote:and then the T2Ds rendering needs to be improved. I am considering writing a faster and new map/tiles objects where I can use variable size tiles taken from one (or more) large textures so that I can have 100s of tiles on screen without suffering the current slow downs which seriously limits gamedesign.

I don't think that has much to do with rendering. It probably have more to do with tiles being full-fledged SceneObjects, even when there is no specific need for them to be.

#36 @Smaug. The physics indeed doesn't pose so much of a problem. But running it at 150Hz to make movement smooth because it is not attached to the actual screen FPS is causing a (visual) problem. I would rather see it synchronized with the actual framerate. And I don't see a problem with physics running at 100Hz and the screenrefreshrate at 300Hz with physics being interpolated. Do you? Not to mention that this sort of action might be required anyway if you start networked games..

About the rendering: I was thinking about rendering and coding the maptiles/objects myself to improve this. I am aware that that rendering on its own won't change a single fps ( I tried ). But by having less overhead and the data of these objects in a ready-to-render format, I am sure there all large improvements possible.