 |
|
|
WTF, 725Mb??? 
Nice intro to this engine by the way. 
thanks
Sonork 100.41263:Anthony_Yio
Life is about experiencing ...
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I couldn't not notice that many people laugh at the idea of using C#/.NET because of it's executing performance. However, in my opinion, performance of the C# is the last thing that stops C# (or slows it?) in replacing C++. Real issues are development community inertia, politics (it's bad, it's Micro$oft, etc.), lack of support (literature, tools, code samples), some code reuse difficulties, deployment issues (maybe Xbox2 will support .NET platform, but other than that only really supported platform is PC/Win) and the lack of general knowledge of the .NET/C#.
Why is performance of C# the least important of those reasons?
First of all, in reality, C# is approximately twice slower (the actual values depends on comparision area) than regular C++ when doing hard core calculations and algorithms, and that can be somewhat reduced with proper knowlidge of C# & .NET IL. It takes less time than a single game development cycle, for the PC hardware improvements (CPU speed) to offset that difference. More than that, as the game software becomes more and more complex, most of the CPU processing power is lost pushing unoptimized algorithms, and the optimizations simply require too much development time and are too expensive. Also more programmer's development time is used for code organization, not for coding. So if a C# as a development environment can payoff in better organization and reduced development time than more time could be spent on performance optimization, giving the project even better performance than it's C++ counterpart. Or more likely making the project much cheaper, with greater hardware requirements  But that is nothing new, it's a process that's happening in all programming fields for a long time, and that is a reason why no modern game is written in asm. The programming language level is shifting up with the complexity of the project.
And C# even enables C++ code integration, so old C++ code can be reused, however with some overhead work.
The second reason is that in the game development more and more processing work is shifted from CPU to graphic card's GPU. That even more reduces the importance of C# vs C++ performance difference. So the main question is if/when Microsoft will push C# as a game programming language, with some more serious support.
At the end I must say that I'm still very much new in the game development business, so I might be overlooking some important factor. My main experience comes from my C#/DirectX9 project that pushes 8Mil polys/sec on the 1Ghz Celeron/GF FX 5200 (more than 10mil on faster FXs) in 1024x768 with two mesh blend, two textures blend, range based fog, normal based lighting, etc. Although most of the work is done on the GPU the project still does some CPU work using C# - data multithread streaming, simple cclusion and simple display optimizations, and leaves most of the CPU time free. It's not a 3D engine, simply a small part of it used to demonstrate my LOD technique, but it shows the possibilities of C#. More info about the project (and project download) can be seen at www.affinegraphics.com. And I plan on releasing the source code of the renderer as soon as I make it more readable
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Finally someone is smart enough to understand the benefits of C# over C++.  
You are working for a game developer? If I may ask, what's the name of that game developer and what are they doing?
-- Roman Godhill, get the Geek ON!
|
| Sign In·View Thread·PermaLink | 1.00/5 (1 vote) |
|
|
|
|
|
|
What hardware were u running this on for the screenshots? With around 10 FPS for 7k/tris per frame I'd say it must be a very, very old card.
If your're running this on something more modern (say a GF2) either u need a major rewrite (are u using immediate mode? coz it seems like it) or your drivers are f**ked up.
I admire your experiment of C# in real-time graphics. In the real world most people use C++/some assembly and to hell with .Net for graphics.
bibamus, edamus, cras moriemur [eat, drink, for tomorrow we die]
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
|
|
|
I tried to compile and run it under v1.0, but it crashed on execution. Have you made it compatible with the final release yet? I would really like to get an updated version, as this looks very good.
Trond
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Yes, it has been updated for version 1.0. Although I haven't updated this article you can get the updated binaries and source from this website:
http://www.exocortex.org/3dengine
-ben
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Is this not already part of the OpenGL/C# distribution? One of the samples is name ExoEngine, anyway.
Best regards,
Paul.
Paul Selormey, Bsc (Elect Eng), MSc (Mobile Communication) is currently Windows open source developer in Japan, and open for programming contract anywhere!
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
One of the earlier versions of this engine was posted on the CSGL website and portions of it (the math libraries) were included in the distributed. But ExoEngine is not part of the CSGL distribution.
-ben houston
www.exocortex.org
|
| Sign In·View Thread·PermaLink | 3.67/5 (2 votes) |
|
|
|
|
|
|
|
|
|
|
|
|
I wish it really was all C then I wouldn't have had to write the other 600kB of C# code to make it work. OpenGL is really just a thin wrapper/interface/standard for 3D hardware accelerators. One still has to do all the lighting calculations, visibility calculations, collision detection, texture management, sprite loading, etc... one's self -- OpenGL does not do this.
Hmm.... based on your standards of judging 3D engines would any C# engine that used 3D hardware acceleration (either through OpenGL or DirectX) quality would qualify as a real-time engine in C#?
Just wondering,
-ben houston
www.exocortex.org
|
| Sign In·View Thread·PermaLink | 1.00/5 (1 vote) |
|
|
|
|
|
|
|
|
|
I wouldnt say that, since, as stated, OpenGL is a fairly thin layer over hardware.
Virtually all 'rendering' is done by the language manipulating the API. Here, C# is putting points in space, animating them, and all the rest of the hard work typically done by a 3D engine.
The hardware is texturing and rendering it, and, like all 3D programs, OpenGL (or DirectX) is just the API through which this is communicated to the hardware, and very little work is ever done by OpenGL itself (with most modern cards anyways).
Now, if you are using software OpenGL, it would be a different story. Then you can say C/Assembly is doing most of the work.
// Rock
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
|
|
|
I have to agree with Fazlul when he disagrees with your statement that:
it seems like it is a decent language after all and possibly an effective replacement for the C++ even in demanding field of real-time graphics
Why? Because small engines (like this one) spend most of their time doing rendering (in hardware) - as opposed to interpeting C#. Rest assured that as the engine gets bigger and implements better algorithms (like visibility culling which is more complex than a BSP tree, terrain algorithms, AI, script parsing, etc), the engine will fall further and further behind the benchmarks of a C or C++ engine because the engine will actually begin to spend a significant amount of time inside the C# code (which will be inherently slower than C/C++).
Here's an example:
Let's say that your application spends 0.01 seconds of it's time interpreting 10000 lines of C#. Then, it spends 0.03 seconds actually inside OpenGL (C/asm code) and doing rendering. This makes the entire scene rending take 0.04 seconds, or 25 frames per second.
Now, 10000 lines of code for an engine isn't much. As the engine gets bigger and starts doing more complex things, it might grow to 100,000 lines. This pushes the time spent in C# to 0.1 seconds, for a total of 0.14 seconds, or 7 frames per second.
The problem is that you don't see the speed problems of a C# engine when it is small.
|
| Sign In·View Thread·PermaLink | 1.50/5 (2 votes) |
|
|
|
|
|
|
Brit wrote:
Here's an example:
Let's say that your application spends 0.01 seconds of it's time interpreting 10000 lines of C#. Then, it spends 0.03 seconds actually inside OpenGL (C/asm code) and doing rendering. This makes the entire scene rending take 0.04 seconds, or 25 frames per second.
Now, 10000 lines of code for an engine isn't much. As the engine gets bigger and starts doing more complex things, it might grow to 100,000 lines. This pushes the time spent in C# to 0.1 seconds, for a total of 0.14 seconds, or 7 frames per second.
Fortunately, performance degradation is not quite as linear as that. Just because 10K lines take 0.01sec, it doesnt mean that 100K takes 10 times as long. In most cases, 99% of the performance hit occurs in 1% of the code. Its quite feasible to use a language like C#, or Java to develop a game engine. You'd certainly develop it faster. Then find the code that is bottleneck and optimise it, perhaps by writing that in unmanaged C++.
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
I was not really assuming it was linear. Rather, I was making the point that the more processing which must be done in the engine's code (which is C#), the more you'll see performance degrade - because the C++ version of the same function would be much faster (5x faster from what I've seen). I wanted to illustrate the fact that a small C# engine doesn't prove anything about whether a big C# engine is fast enough to be competitive with a C++ engine. Even worse, you won't really see the preformance problems until the engine is pretty well developed.
The 99%/1% figure that you use is not terribly realistic. In 3D software I've written, we had to limit each component a budget -- because each part (animation, physics, occlusion, etc) wanted a big chunk of rendering time. Each time we'd add a new component, we'd say, "Why did that hit our framerate so much?"
If the engine remains small and doesn't need a whole lot of functionality, fine. Afterall, most processors are fast enough that an inefficient engine can still get a good framerate. But, if it is to be a full-featured finely-tuned engine, and you wanted as many polygons as possible in the scene, I wouldn't go anywhere near C#. (At least not until MS creates it's C#-to-native-code compiler.)
|
| Sign In·View Thread·PermaLink | 1.00/5 (1 vote) |
|
|
|
|
|
|
You guys keep writing things like "interpreting" and "until MS
creates its C#-to-native-code compiler". Am I missing something
or is that just bogus? To my understanding, C# (or any other
.NET language for that matter) code *is* compiled to IL code
at compile-time and JIT-compiled at (first) run-time to
native processor code. So the first time you run a C#
executable there is a delay before the program runs caused
by the JITting but from then on it's all just as fast as
running native code produced in the unmanaged world.
I think that, if your code is careful in avoiding garbage
collection as much as possible in "the inner loops",
C# code should execute just as fast as C++, if not
faster (more specific hence better processor
optimizations).
Just my 2 cents, I would love to be proven wrong
though. (really!)
eltwo
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
You are correct. In many ways it is as fast or faster especially with string type manipulations. There can be a JIT performance hit if the assembly hasn't been compiled yet but even this can be circumvented with NGEN.exe (native image generator).
There can also be opportunites (when you're really sure) when you can use unsafe pointers to speed up tiny loops; and all this without the exorbitant c++ syntax.
One thing to avoid is the CLR/unmanaged boundary which, because of marshalling, is very expensive performance wise. With that said, even DX9 is fully CLR/managed accessible.
|
| Sign In·View Thread·PermaLink | 1.00/5 (1 vote) |
|
|
|
|
|
|
Thank you for making that point. Here is some evidence to support that C# can be faster than C++:
Two open-source Linux implementations of Microsoft's .NET are called Portable.NET and Mono. Each have a C# compiler. Portable.NET's C# compiler is written in C. Mono's is written in C# itself. Mono's is significantly faster. 
Whether that's optimizations by the compiler or simply because it's a more elegant language, the point is that it is easier to create a fast program in C# than in C.
My source: http://www.go-mono.com/faq.html#pnpproject
|
| Sign In·View Thread·PermaLink | 5.00/5 (1 vote) |
|
|
|
|
General 
News 
Question 
Answer 
Joke 
Rant 
Admin