C#

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
Old 09 September 2003   #1
C#

Hi all
MS says C# has the power of C++ but with more productivity or C# has the power of C++ and is simple like Visual Basic.
so if it was true,why nobody use C# for graphics programing?In the other words can C# be used for writing plugins(ie for max or xsi)?
 
Old 09 September 2003   #2
Because C# wasn't made to replace C++. It was made to put SUN's Java out of it's misery. Microsoft would just love to see Java burn in the flames of hell.
__________________
Steven
 
Old 09 September 2003   #3
C# is a slow, feeble, cheap-@$$, piece of junk as far as normal programming goes. True it does have some nice points but in my opinion, admittedly from only a very short exposure to using it, it is a massive waste of time. And regardless of what M$ wants to claim it does NOT have the full power of c++. I never tried any graphics with it and I doubt I ever will. In fact I uninstalled my whole Studio.net and work with Studio6/VC6 still.
Just one mans opinion nothing more.
__________________
Shirow Project Webpage
 
Old 09 September 2003   #4
Never trust anything from Microsoft, especially when they try to "improve" standardised programming languages
__________________

You can have your characters photoreal, fast or cheap. Pick two.
 
Old 09 September 2003   #5
especially when they try to "improve" standardised programming languages


Never mind the fact that even with VC.net theit still cannot handle templates properly and in some case 'specilization' not at all.
__________________
Shirow Project Webpage
 
Old 09 September 2003   #6
Hi and thanks
I do not want to begin a traditional war between x and y.But I want to know if could C# be used for these subjects?
If yes,why?
If no,why?
 
Old 09 September 2003   #7
Sure it can. The DirectX SDK comes with C# examples that work perfectly fine. The code is much shorter too than the equivalent C++ examples. But believe me, the C++ and C# DirectX sample programs don't behave the same. Run them and see for yourself.

There are a few things you have to consider:

1.) NO OPENGL SUPPORT. You have to download a wrapper or create your own. Microsoft does not like competition. They seek to eliminate it and that means not supporting certain competing APIs.

2.) The C# code is smaller than the equivalent C++ code because much of it is wrapped. And wrapping things tends to slow things down quite a bit. The DirectX C# SDK hides COM from you by wrapping it. So for every graphics call you are going through 2 DLLs, if not even 3, and not just one.

3.) Array access is not as fast in C# as it is in C++.

4.) You want to create a BSP Tree in C#? LOL. That's right, I didn't think so .

5.) C# classes in the DirectX SDK uses it's own message pumping scheme. Will this be suitable for your game or app? More than likely not. C#, VB, Java, and all these other scripting/scripting-like languages are supposed to make Windows programming transparent. And no matter how you call it, it's just not good enough for a full blown 3D game or hardcore graphics app like lightwave, maya or xsi. Do you see Newtek saying, "Hey, Lightwave 8.0 is going to be programming in C#?" LOL. I think not .

6.) Who is using C# in the computer graphics industry anyways? Newtek? Softimage? Id Software? Is John Carmack saying how wonderful C# is? Last I checked, no.

7.) When comparing C# to C++, I like to think of comparing GDI+ to the standard GDI. I've tried using GDI+ in my photomosaic app only to see my photomosaics render in the window painfully slow. I will never touch GDI+ as will never touch C# either.

8.) Try this too. From the DirectX SDK run the C# Lighting demo and the C++ version as well. On each one, activate another app while the demo is running. Notice the frame rate drop drastically for the C# on but not the C++ one? C++ gives you more control over the message pumping than C# does.

9.) How is C# with multithreading? Internet capable video games are typically multithreaded, with game and networking threads. Can C# do this effectively? Hmmm... I don't know the answer to this one, but I bet you the answer is no.

10.) C# is dependent on a whole slew of .NET DLLs on top of all the standard Windows stuff. Many people complain of latency in their programs, but note that C# exes are usually much smaller than thier equivalent C++ exe counterparts. And you pay a price for this. That's right, performance.

So I guess my final answer is: You can use C#, sure, but don't because scripting/scripting-like languages will never have the power of C++.

C# is absolutely wonderful for some things though. I hear it's great for networking apps. Much better than having to use Winsock and all those nasty WSA functions .
__________________
Steven

Last edited by dead_eye : 09 September 2003 at 06:37 AM.
 
Old 09 September 2003   #8
Dang, that was a good reply dead_eye! I will also say that if you are interested there is at least one book on using C# for writing games. I saw it yesterday at the Borders but don't remember the name since I really did not care to look at it. As for GDI+ it is better then the old GDI but it will never be something for high level, or even mid level, graphics design. But it does work great for the program that just needs to display some image maybe for a logo or something.
__________________
Shirow Project Webpage
 
Old 09 September 2003   #9
Thanks dead_eye
This is a very good reply.If anyone else had a reply like that (advantage or disadvantage) we will be very glad to see that.

thanks again
 
Old 09 September 2003   #10
Discreet says that their CleanerXL is written in C#. It surprised me as I did not think the language had been out that long.
 
Old 10 October 2003   #11
I have to disagree with dead_eye, I think C# is perfectly suited for game development.

Originally posted by dead_eye
1.) NO OPENGL SUPPORT. You have to download a wrapper or create your own. Microsoft does not like competition. They seek to eliminate it and that means not supporting certain competing APIs.


If having a wrapper for a C-API is defined as no support for it, then there is also no support for Direct3D. The only difference is the OpenGL wrappers use P/Invoke and the Direct3D wrapper uses manged C++ as interface.

Originally posted by dead_eye
2.) The C# code is smaller than the equivalent C++ code because much of it is wrapped. And wrapping things tends to slow things down quite a bit. The DirectX C# SDK hides COM from you by wrapping it. So for every graphics call you are going through 2 DLLs, if not even 3, and not just one.


That`s true, but it is not such a big performance hit as you make it sound.

Originally posted by dead_eye
3.) Array access is not as fast in C# as it is in C++.


I think this is only really an issue with multidimensional arrays,
which should be avoided.

Originally posted by dead_eye
4.) You want to create a BSP Tree in C#? LOL. That's right, I didn't think so .


Then what is the problem with BSP trees in C#?(no offense )

Originally posted by dead_eye
5.) C# classes in the DirectX SDK uses it's own message pumping scheme. Will this be suitable for your game or app? More than likely not. C#, VB, Java, and all these other scripting/scripting-like languages are supposed to make Windows programming transparent. And no matter how you call it, it's just not good enough for a full blown 3D game or hardcore graphics app like lightwave, maya or xsi. Do you see Newtek saying, "Hey, Lightwave 8.0 is going to be programming in C#?" LOL. I think not .


I don`t think Newtek is a good example for superb software engineering, I believe they still write most of their code in C, not C++. C# is a very new language, it`s really not fair to say that it`s not good enough.

Originally posted by dead_eye
6.) Who is using C# in the computer graphics industry anyways? Newtek? Softimage? Id Software? Is John Carmack saying how wonderful C# is? Last I checked, no.


It is not widely used, but that doesn`t mean anything.

Originally posted by dead_eye
7.) When comparing C# to C++, I like to think of comparing GDI+ to the standard GDI. I've tried using GDI+ in my photomosaic app only to see my photomosaics render in the window painfully slow. I will never touch GDI+ as will never touch C# either.


GDI is hardware accelerated, GDI+ is not. That`s not a language problem.

Originally posted by dead_eye
8.) Try this too. From the DirectX SDK run the C# Lighting demo and the C++ version as well. On each one, activate another app while the demo is running. Notice the frame rate drop drastically for the C# on but not the C++ one? C++ gives you more control over the message pumping than C# does.


Sounds more like a problem with the specific example program or windows forms(not that it really matters).

Originally posted by dead_eye
9.) How is C# with multithreading? Internet capable video games are typically multithreaded, with game and networking threads. Can C# do this effectively? Hmmm... I don't know the answer to this one, but I bet you the answer is no.


That comment didn`t make sense. It`s like me saying:
I don`t know nothing, but i bet the answer is yes.

I have done some network multithreading with C# and I didn`t have a problem with it.

Originally posted by dead_eye
10.) C# is dependent on a whole slew of .NET DLLs on top of all the standard Windows stuff. Many people complain of latency in their programs, but note that C# exes are usually much smaller than thier equivalent C++ exe counterparts. And you pay a price for this. That's right, performance.


And you gain nearly non-existant compile times.

Originally posted by dead_eye
So I guess my final answer is: You can use C#, sure, but don't because scripting/scripting-like languages will never have the power of C++.


C# is just a tad slower than C++ in most situations,
but C# is just so much more productive.

At the end you will have so much time left to optimise the slow parts of your program and sprinkle some managed C++ in the 5% of your code that really need it, that your program may even be faster than if you had used C++.

And it doesn`t matter so much anyways because most games are limited by graphics hardware, not CPU.

And as a bonus C# can also be used as the scripting language for your game, thanks to the nice reflection features.
 
Old 10 October 2003   #12



limited by graphics hardware ?
__________________
Steven

Last edited by dead_eye : 10 October 2003 at 02:04 AM.
 
Old 10 October 2003   #13
and pure HW VP



Have to try this on some newer hardware, as MX 2's are quite old, but both versions are going through the same hardware so it's a fair fight. I wouldn't even want to think about the performance difference once you add a scene graph and thousands of more polys. It's definitely interesting though and I'd be surely interested if you can explain this performance difference for me. The only difference is the language for these basic tutorials.

The first two images are full screen apps, both active. The third image is both windows deactivated, but still running.

Like I said before, C# is meant to put Java out of it's misery, and isn't seen as a big competitor to C++. But then again, I can't agree with Bruce Eckel lol, MFC not worth learning? It was to me.
http://www.mindview.net/WebLog/log-0021

EDIT: I can see now why there's a major frame rate drop-off when a window is deactivated. Happens because of the active flag in the common code D3DApp.cs. Had to remove it so it renders properly when inactive. But it still runs slower that the C++ version.

/// <summary>
/// Called when our sample has nothing else to do, and it's time to render
/// </summary>
private void FullRender()
{
// Render a frame during idle time (no messages are waiting)
if (active && ready) {
try {
__________________
Steven

Last edited by dead_eye : 10 October 2003 at 05:34 AM.
 
Old 10 October 2003   #14
fractal benchmark

here's my own sample program too. i converted one of my C++ proggies that i wrote when i took complex analysis that generates one of those Newton's Method fractals with complex numbers. you can see the C++ and C# codes are nearly identical, except for the bitmap code, but the program spends most of it's time doing Newton's Method so the bitmap code isn't the bottleneck. One sweet thing about C# though is that is saves you from having to know what BITMAPFILE(INFO)HEADERS and pitch bytes are .

C++ Code

C# Code

and here's the performance on my computer:
Time elapsed = 12.0039935 seconds (C#)
Time elapsed = 6.40560015 seconds (C++)

C++ = 2x's faster just to generate this:
__________________
Steven

Last edited by dead_eye : 10 October 2003 at 12:21 PM.
 
Old 10 October 2003   #15
Re: fractal benchmark

This is soo much fun!

I think you have a hardware/drivers/os problem.
What are your complete system specs?
Do you have Windows XP?
I have an old system, athlon 900 with a geforce ti 4200, but my results are quite different:

C++/C#

fullscreen(alt-enter):

dolphin demo 1280x1024 100.4 100.4
lighting demo 1280x1024 100.5 100.4

windowed:

dolphin demo 400x300 ~422 ~303
lighting demo 400x300 ~1800 ~1300

The reason for the performance difference in windowed mode is probably caused by hardware GDI vs. software GDI+.

Originally posted by dead_eye
You can see the C++ and C# codes are nearly identical, except for the bitmap code, but the program spends most of it's time doing Newton's Method so the bitmap code isn't the bottleneck.


The pixel plotting code is completely different, and think that this is the bottleneck. Your C++ version uses efficient inline array acess, while the C# version calls a SetPixel method from a bitmap class that is not optimised for performance.

Please make that C# code unsafe, use pointers like in the C++ example and test again.
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 04:56 PM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.