I take my first programming class in a few weeks and I’m wondering a couple of things.
Anyone know anything about C#? I picked up my textbook today and we’re going to be learning C#. Can it potentially be used to write plug-in types of programs for graphics?
If not, how much different is is from C++? I heard that C# was Microsofts version of Java but I don’t know how useful that is either. Does anyone know of it’s limitations in the graphics area?
Anyone know anything about C#? … Can it potentially be used to write plug-in types of programs for graphics?
I’ve programmed in C# on half a year now, and I must say that I like the language, but as far as I know no application used in the industry is supporting plugins programmed in C#. First of all I think this is to early, and second it can’t be as effective as compiled machinecode since every .NET assembly is compiled into MSIL code (Microsoft Intermediate Language) and is running by a virtual machine like Java.
If not, how much different is is from C++?
The way I see it, C# has taken the best from Java and C++ together with Microsofts own experience to make a better programming language.
I heard that C# was Microsofts version of Java but I don’t know how useful that is either. Does anyone know of it’s limitations in the graphics area?
If so, it must be the speed of execution. The best way to use OpenGL with C# is to use
Colin Fahey’s C# OpenGL Wrapper. CsGL has been a solution for some time now, but Colin Fahey’s wrapper library is a more direct solution.
If you want to compile your C# code on Unix you can use Mono, which is a free implementation of the .NET Development Framework. I’ve used it on a bigger project over the past six months and all code I’ve written compiled just like in Windows.
Good luck! 
it can’t be as effective as compiled machinecode since every .NET assembly is compiled into MSIL code (Microsoft Intermediate Language) and is running by a virtual machine like Java.
I’ve been hearing that a lot, that MSIL running through the CLR isn’t as fast as native code. In some cases that’s correct and there are still areas where native code will outperform managed code. The benefits of the CLR and JIT, however, are far greater once you start to deploy on different target systems. For example, take a computationally intensive app written in C# and run it on a older P3, then take the same deployment package and run it on a dual Xeon, or a quad Itanium. What you will see is the JIT compiler will optimize the code ‘on the fly’ for that specific hardware (e.g. the CLR and JIT already know what it’s running on). This provides a huge advantage for software developers because you don’t have to tailor different native code images of DLL’s and EXE’s to take advantage of compiling for specific instruction sets. Instead, the CLR/JIT will take care of that and provide you instant optimization at a level that would be hard to maintain when dealing with multiple native code targets.
We have been doing managed code since the early beginning and so far we have found that the advantages of managed code outweigh a little performance loss in certain areas (saving 3-4 man-months of effort measured against a 2-5% performance hit is more than acceptable in most cases). We also found that the JIT compiler oftend did a slightly better job in certain situation than similar hand-optimized native code. For areas where you absolutely require native code and manual optimization you could always write a few native code DLL’s and call it as unmanaged (unsafe) code from managed code so that’s not a big deal at all (it’s like how in the late 80’s and early 90’s development started to shift towards C++ while system critical performance was covered in good old ASM… something you won’t see much of these days). Another area to optimize MSIL and pre-JIT would be to use NGEN. It’s not useful in all cases but in those rare cases where you need it (and can run a few stress tests) it will shave off all the JIT compiling that is done during run-time.
The only serious performance hits we have encountered are in the areas where one would be calling legacy components such as COM components or using other legacy DLL’s through Interop. The overhead can be debilitating. Similarly are situations where various class wrappers are used to provide managed code interfaces and access (for example those C# OGL wrappers you mention). Then again, any form of execution will suffer a bit when you start layering code like that so it’s not really an achilles heel of managed code but rather a penalty for the construct itself.
As for the difference (or similarity) between the CLR and Java’s VM, there is a huge fundamental (and important) difference. On the Java side a JIT-like compiler will transform Java into byte code (platform independent) and is not an intermediary language compiled to native hardware-optimized code; instead it’s interpreted at execution time by the Java VM. This makes the Java VM process of interpretation result in slower execution when compared to the compile-and-cache concept used by the .NET JITer.
C# was done by the same group that did Borland’s Delphi and C++Builder products. (Microsoft waved millions in their faces.) And it’s a very good compiler for many of the same very-good reasons. You definitely need to study it. You should study Borland’s tools also.
In a lot of real-world situations, “bytecode vs. native-code” really isn’t an important distinction, because the process being performed is not so totally CPU-intensive that the overhead of the bytecode interpreter really matters. The bytecode amounts to a whole bunch of table-lookups and subroutine calls, executed by a very tight central bytecode dispatcher. It’s almost as efficient as native code and sometimes even more-so, because the bytecode “machine” architecture might be more appropriate to the task than the architecture of the native CPU. As previously noted, the bytecode interpreter can also recognize the presence of more vs. less-advanced CPUs and adjust its execution paths on the fly. The bytecode does not change; the interpreter does. Usually the only way to obtain CPU-model-specific benefits with native code is to recompile the source-code with appropriate compiler switches; not a practical thing to do when you consider deployment.
While it is true that JIT byte code systems sometimes approach the speed of native code, it is fairly straight forward to see why this will not be the case fairly often.
What sundial writes, “the bytecode amounts to a whole bunch of table-lookups and subroutine calls,” is the running point in such an argument. That overhead will never go away. In some cases, that overhead will be sitting right where you don’t need it, depending on the performance of the JIT compiler.
More importantly, more resources are consumed. Imagine trying to write a program like Photoshop in Java. Many people with experience with traditional byte-code systems would just shiver at the thought of a complex program being JIT compiled; multiple code paths being kept in memory at the same time, more memory being touched constantly, reducing the effectiveness of swap, not to mention trying to compile an enormous program in real time.
To compile a good sized program nowadays, a C compiler like GCC will often use 100s of MBs of memory and a good deal of time, often measured in hours on a modern computer. The compiler does something with all that time, and that something is not so easy to recreate in real time.
Granted, I have no experience with C# or its byte-compilers; maybe good progression was made since the days of Java JIT and today byte-compilers are smaller in memory footprint and use the processor knowledge to do wonderful things.
At the end of the day you often don’t really need the fastest executable code though but the code that is fastest to develop.
personally i find interpreted / VM languages to be a bit sketchy. i just somehow feel safer when i use compiled code.
for developing games, i’m also not so sure C# is the best way to go. yes, it’s cool that it will use optimizations if they are available on the fly, but really - most commercial games made today are designed for the fastest, most feature-ridden systems we have. it wouldn’t make sense to use a language that can automatically accomodate systems ranging from a pentium 75MHz up to a 64-bit 3GHz system, when the game will only be run (mostly) on processors one year or newer. this only really applies to games, though, as they have a sort of niche markent when it comes to computer specs.
now if you’re developing an app for something business-oriented (which is, i suppose, what C# is really made for), then i could understand perfectly.
something else you might be interested is a language called D, from Digitalmars. it is a fully compiled language like C++ (in fact it is called D because it comes after C++…), but it takes some things from C# and java, like garbage collection. it’s a very clean language, and though it’s not yet to version 1, it’s still cool. it has bugs, of course, but i’m definitely keeping my eye on it, as i’ve about had it up to here with C++.
Thanks for all the feedback! I suppose for games or graphics in general, I would rather be learning to program in C or C++ but most importantly, I’m just glad I’m learning to program. I supposed a lot of that information will hold true for other languages I learn…
Using .NET everyday I’d say use C# if you had lots of GUI work, database work, GDI+, printing, etc… I would not recommend it for the inner loop of a graphics engine or a rendering engine. The exception would be if you needed to keep a project monolingual and your GUI oriented code was already C# based.
If your career involves writing programs for Fortune 500 companies, I’d recommend C# or VB.NET due to configuration supportability and career opportunities. It would come however with a noticeable hit in performance.
A small C++ compiled program can drop right into L2 cache and execute blazing fast. The performance I’m seeing for projects I do solely in C# and VB.NET is maybe 1/2 as fast. The only place I really notice it as a bottleneck is when attempting to get the best frames per second in computer graphics.
While 30 FPS is acceptable since it will fool the human eye, it is nice to start a project with a much higher FPS since you will be adding as much to the scene as possible.
I’d recommend using C++ to create the inner loop of your engine as a reusable object, then use C# for your interface if you really want to use C#. I’ve used VB.NET and Java quite a bit as well.
Staying power? With Java, the speed of most projects I’ve done was laughable… It is hard to prevent a JVM from being a huge unsightly bottleneck. Most Java projects I was on will be rewritten in the next one to three years or retired due to load and performance problems. In contrast, I still use software written in C++ eight to ten years ago and it keeps performing better and better with each new release of cheap PCs.
Dotnet languages have a staying power beyond Java since Microsoft has been doing good RAD runtimes since VB 3.0 (circa 1993). I’m pessimistic about the future of Java with .NET around despite doing Weblogic projects semi-frequently and using JSP and servlets quite a bit.
For comparison, I’ve tested some of the billboard/surface code I’m working on with different compiled versions.
Here are my quick and dirty test results:
Load test: Less users for multi-user system in C#
Stress test: Roughly equal
Volume test: the number of models that can be loaded is slightly higher for C++
Performance test:
-C++ version is running at average 424 FPS
-C# version is running at average 248 FPS (58% as fast)
-VB.NET version is running at average 248 FPS (58% as fast)
The bottleneck is definitely .NET. The code uses the same Direct3D functions which come from a DLL compiled with C++. I’d be interested if others have found the same results.
On the flip side, C# and VB.NET are much more enjoyable for me to program in and I feel that it is a significantly less amount of work. In 30 minutes I have a working app. You can do nearly anything in C# or VB.NET due to the amount of classes in the .NET runtime. It would take you years to do the same types of things in C++ from scratch. I haven’t used Managed C++ enough to have an opinion on it.
If I’m building a metaphorical dog house, I use C# or VB.NET. If I need to build a skyscraper and I have 1-2 months to plan and design, I’ll use C++. When consulting, most companies I work for build lots of dog houses and have never built a skyscraper.
Wow, you all seem very knowledgable about programming and I’m jealous of your experience. I’m very excited about programming and I love what I’ve done so far even though the programs I’ve written are very simple compared to the things I would like to do. Right now, I just feel smug that I’m a few weeks ahead of the other people in my class who are still struggling to identify and add comments to indicate their methods, headers, and method calls. :rolleyes:
True, the programming I’m learning in school will be more inclined towards business applications rather then graphics applications but I’m very motivated to learn many things on my own to expand my knowledge beyond the classroom. Plus there are usually at least a group or two of students who get together to do some game programming that I’m trying to get involved wtih. Again, thanks for all your feedback.
Hi all…I just wanted to clear up a few misconceptions about the .Net framework I noticed while reading the thread. This is in no way meant to offend anyone or incite an argument, I just thought it might be helpful.
.Net applications are not interpreted like Java applications which run inside a virtual machine. When executing an application managed by the CLR the JIT compiles pieces of the assembly as needed, and it compiles it into native code.
It is also possible to bypass JIT all together and precompile your assemblies. Although the CLR still has to have access to the original assembly (to extract the metadata), the code itself is already in native, machine-language form and is executed as such.
With that in mind, the perfomance loss/bottleneck isn’t due to .Net so much as it is due to the fact that the application is being managed. .Net applications trade performance in exchange for code security, stability, automatic memory management, etc. While developing with .Net is definitely easier it won’t have the same performance as unmanaged code when it comes to time critical tasks such as those found in 3d games…at least not in the current versions of .Net.
As far as writing a plug-in goes…your assembly written in C# will require the CLR to run. That means the target machine will have to have the .Net framework installed and the app the plugin is written for will have to be able to play with managed code.
Let us not forget:We are currently seeing only the first versions of MSIL and JIT-Compiler.
Probably later versions will do much more “agressive” optimizations.
An unmanaged code context in .NET might be as fast for an inner loop. I’ll doubt it until I can see it first hand.
.NET compiles into an intermediate language MSIL, then at run time uses a JIT compiler to compile it to native code on first execute and stores it. The JIT compiler might be optimizing for compile time rather than execution speed.
Visual C++.NET allows you to have managed and unmanaged run side by side. You might be able to use it to get the best of both worlds. This doesn’t exist for C# to my knowledge.
I should add the preprocessor directive for unmanaged in a Visual C++.NET sample and see if it improves the FPS significantly.
I still intend to use .NET (C#, VB.NET) but see a performance difference. Using .NET however I do sometimes feel that Microsoft just wants to be the middle layer for everything.
If .NET is the sole future for Wintel platform, then how come MS still is using C++ without it. Hmm. I do like .NET but am always curious what is under the hood of anything that requires a runtime. I’ll have to play around with pinning pointers, wrapper classes and a few other of the obscure interoperability approaches to see what kind of speed we can squeeze out of .NET. However, I’m also thinking that data type conversion and lack of direct memory addressing hurts .NET in a big way and is responsible for the slowdown when I interact with DLLs from DirectX 9.
For performance critical apps, the benefits provided by the CLR doesn’t outweigh the performance cost and low level system control. Yet. Maybe it will by this time next year 
If anyone is currently using VisualC++.NET on a gaming or graphics project, please shoot me an email. I’d like to hear how it is going and what the challenges are.
There’s a lot that can be done in managed code to slow things down using the .NET framework and often very simple things (for vs. foreach for example) that can impact performance. If you haven’t yet I’d recommend looking over http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftips.asp just as a reminder of where some caveats are.
Well, I just tried compiling my C++ samples with the /clr switch and without. The ones with inline assembly didn’t compile (not surprising). The ones that did compile ran at an identical FPS rate.
In other words, the graphics program using native code (no MSIL assembly) ran at around the same speed as the compiled program that was a MSIL assembly. Very interesting…
I should check why the C# and VB.NET samples were so slow now. Maybe data type marshalling…
Also remember that as the GPU’s and CPU’s become faster and more powerful, the need for counting cycles and writing hyperfast native code lessens as compared to having application development times cut short and the development process made much more secure.
We all know the curse of bugs, and even though obviously C# & .net doesn’t produce bugfree code, it is however a lot faster to develop and debug the software. This gives more time to spend on testing and optimizing your application.
Is it possible to write a graphics engine or a game in C#? Of course. Will you write the next DOOM 4 engine in it? Most likely not yet But how often do we need to do that.
You do realise that this is a graphics programming forum don’t you?
So, how often do I need to write really fast 3d graphics code? Every day.
And you do realize there is a world of difference between writing a 3D game engine trying to cream out every single pixel as fast as possible, and writing a 3D modelling & animation package where you are more concerned with workflow and ui design than putting pixels on the screen the fastest.
Granted it’s a balance even in an application with speed & usability but C# & .net is perfectly workable for graphic intensive apps using either managed Direct X or GDI+.
It is always a usability requirement to write programs so they run as fast as possible. Ask a business application user once if they would rather wait 5 seconds while their data saves or wait 10 seconds
.NET has a promising future but in the short run it does make your deployment more difficult, reduces your reach since most desktops don’t have the runtime yet, and makes your programs slower in some cases but in other cases the speed is identical…
Since it is new, there are unforeseen bugs and security problems laying in the shadows.
Despite these challenges, I still really like .NET. It hasn’t made any of my development time shorter (it’s much longer actually due to relearning), but in power and flexibility it is markedly better. For example, sharing code between thick clients, thin clients, and mobile clients is a step forward.
ATL/COM is also not going anywhere for awhile so C++ is still friendly and familiar. VB is gone now though and replaced with VB.NET, so I intend to stop using VB6 and J2EE in lieu of .NET for good if I can help it which should please Microsoft…
Most importantly, knowing .NET increases your skills and marketability. Since its currently in demand, that is good news. Everything old is new again hehe
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.