PDA

View Full Version : C#


farid
09-11-2003, 04:50 AM
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)?

dead_eye
09-11-2003, 06:28 AM
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.

aurora
09-11-2003, 03:40 PM
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.

playmesumch00ns
09-15-2003, 09:00 AM
Never trust anything from Microsoft, especially when they try to "improve" standardised programming languages

aurora
09-15-2003, 03:44 PM
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.

farid
09-16-2003, 04:41 AM
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?

dead_eye
09-16-2003, 05:35 AM
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 :p.

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 :p.

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 :scream:.

aurora
09-16-2003, 02:50 PM
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.

farid
09-16-2003, 05:35 PM
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

vintagetone
09-29-2003, 07:06 PM
Discreet says that their CleanerXL is written in C#. It surprised me as I did not think the language had been out that long.:shrug:

MutenRoshi
10-04-2003, 05:42 PM
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 :p.


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 :p.


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.

dead_eye
10-05-2003, 01:56 AM
http://www.rick-n-steve.com/temp/1.jpg
http://www.rick-n-steve.com/temp/2.jpg

limited by graphics hardware ;)?

dead_eye
10-05-2003, 02:19 AM
and pure HW VP
http://www.rick-n-steve.com/temp/3.jpg
http://www.rick-n-steve.com/temp/4.jpg

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 {

dead_eye
10-05-2003, 11:55 AM
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 :scream:.

C++ Code (http://www.rick-n-steve.com/temp/cpp_fractal.cpp)

C# Code (http://www.rick-n-steve.com/temp/cs_fractal.cs)

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:
http://www.rick-n-steve.com/temp/fractal.jpg

MutenRoshi
10-05-2003, 06:47 PM
This is soo much fun!:D

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.

dead_eye
10-05-2003, 10:37 PM
Yeah, it is fun :). Of all the C# books I have, none really go into the issue of performance. In fact, only one book even dared to do a C++ vs. C# paragraph, and it was pretty poor. Nothing about performance, just differences between the languages. Then again, if you read the EULA for the .NET components, you're not supposed to print public benchmarks without the permission from Microsoft first!!!

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetdep/html/redisteula.asp
You may not disclose the results of any benchmark test of the .NET Framework component of the OS Components to any third party without Microsoft's prior written approval.

Added unsafe code... At school with faster computers...
Here's the link to the code:
Unsafe C# Version (http://www.rick-n-steve.com/temp/cs_unsafe.cs)
and the executables
Executables (http://www.rick-n-steve.com/temp/fractal.zip)

And performance:
3.82 seconds (C#)
1.69 seconds (C++)
By the way, both files were built in Release mode.

Still 2x's as fast. See the pixel code only gets called 48,000 times. The sqrt code gets called millions. I bet directly calling sqrt from the CRT instead of using Math.Sqrt would help... but if I have to [DllImport("XXXXXX.dll")] every performance critical function, it really defeats the purpose of using C# :).

Gotta love that 6.5 KB EXE filesize though for C#. It kicks C++'s 168 KB (mainly cuz i used the STL) butt. But you pay a price for it.

By the way, I sure would like to see an example of that stuff where you said you "sprinkle" a little C++ over your C# code and it'll run even faster than the C++ version ;).

C# is very promising. And it's good too. I'm not ignoring it. Who knows where it will be in 10 years from now? I'm not saying it's utter crap or anything, as performance is fairly good, but still not 100% up to par with C++. And as I recall farid wanted to start coding games, where every bit of performance is critical. When I see a "successful" C# game engine, I will change my mind though :thumbsup:.

suvainteractive
04-09-2005, 07:46 PM
I find this an interesting thread! Our indie company (www.suvaonline.com (http://www.suvaonline.com/)) developed a pure managed code game engine using C# and Managed DirectX and we couldn't be happier with the results. In short, we love the fact that our developers spend less time chasing down bad pointer arithmetic and more time adding cool features. Yes, we do surrender a 5% performance penalty because of the wrapping and occasional boxing/unboxing in C#, but overall the quicker time to market makes all the difference for us.

Our game engine uses shaders so most graphics operations are GPU bound. In other words, the five percent overhead of calling through the wrapper does not decrease rendering performance. Given the simpler design afforded by the language we think we've struck gold. :)

Shaun

rakmaya
04-11-2005, 04:28 PM
C# is widely used nowadays in Games industry for creating Tools and UI applications such as Level Editor and so on.

C++ is used to create the Game Engine itself and program the game too. The reason C++ here and NOT C# is because of the requirement for complex memory management and platform independancy. Going through the Marshall or COM for game engines in PC is not viable option when you get to certain portions.

However, MOST engines especially for next generation systems is created in C++ and puts a COM support for C# game/utility development for PC. On Consoles, C++ is on all the way.

C# is very much as fast as C++ in ALL Windows application development. But when certain things relating memory management/related performance issues gets in the way, C++ is used.


Our game engine uses shaders so most graphics operations are GPU bound. In other words, the five percent overhead of calling through the wrapper does not decrease rendering performance. Given the simpler design afforded by the language we think we've struck gold

Shaders are not all that count for performace issues in the next gen consoles (and pCs). There are other things that are way more important and requires tight coupling which managed code lacks. Ofcource in 99% of the cases, this is not important. But if you want to go all the way to create one of those master pieces, this is very important. You can always put COM on top of the C++ to make is as much fast as the C# one PLUS you get the additional benefits as well.

Unlike VB, C# gives you the feeling of C++ when creating Tools. This I see a very important aspect why a lot of people use C# for such purposes. C# gives this without the overload of Java.

Oh, and C# will not replace Java in any extend. (Unless MS makes this for Linux, which I don't see happening)

suvainteractive
05-03-2005, 11:40 PM
Going through the Marshall or COM for game engines in PC is not viable option when you get to certain portions.

Rakmaya, can you be more specific as to when this presents a problem?

But when certain things relating memory management/related performance issues gets in the way, C++ is used.

Help me understand - can you provide an example?


Shaders are not all that count for performace issues in the next gen consoles (and pCs). There are other things that are way more important and requires tight coupling which managed code lacks.

Again, I don't follow because you are talking in abstract terms. What specific functionality do you need that managed code fails to provide?

My opinion remains unchanged. C# and Managed DirectX achieve 95% of the desired performance of unmanaged C++, albeit the platform limitations. However, if you're using DirectX you have chosen a platform anyway (except engines that support openGL as well, i.e. Axiom or Gambryo).

:)

rakmaya
05-04-2005, 03:24 AM
First of all I don't want to create a huge post. So I am sorry if it still doesn't explain things detail. I will send a private mail with details if you want more:

About the COM/Marshall issue:
We are creating one of the most productive parallel realtime rendering pipeline here that runs on over 200 cpus. We uses tight memory management that neither overload nor management of memory is an option. This is because to make things parallel in the most effecient way, we need direct access to memory. If the entire core was created in C#, we will be going through Marshall everytime such a memory is accessed. If we create our own COM implementation to do that for us, then we have the atl overload. At least few cycles per access. This biols down to all cpus and eventually the problem adds up. In one case we tested almost 4 second difference (in one minute) in the frame rate when we used an external library created in C++ loaded as dll to the job for us. That was a different issue but going outside the program scope to execute a particular instruction can be deadly in cases.

Another example would be loading a file into the memory. In game engines files are loaded into the memory and then given DirectX or OGl buffers. In Unified memory architecture in most console, you cannot waste memory in such load. So with memory massaging you can bring up the entire mesh data in one long sequence. This means that you not only save memory but also save duplicate effort.

Again, I don't follow because you are talking in abstract terms. What specific functionality do you need that managed code fails to provide?

In terms of functionality, there is nothing that C does that C# can't. It is the way it is executed internally. Once you reach the stage that the level of access you need to play with the memory contents of your mesh, the overhead of memory access comes into play:

In a General pipeline such as "Load->Place to DX Buffer->DrawPrimitive" will never see the performance difference. This is because 90% of the time, the code is spent in either the DX routines or Managed code sections.

It is hard to put all problems from the top of the head. I have run into many in the last 2 years. But neverthless, it defenitly the best thing to program UIs and Graphics Interfaces for Artists.

One thing we did on a project is to code the UI section of it in C# and the major processing such as screen graph generation, sorting, bsps etc in C++ via com. So we can keep the travel between the cores to minimum. See, it is NOT the execution time (both has no over load in primitive instructions), it is the traveling time between the core when Managed and Unmanged interacts.

suvainteractive
05-04-2005, 07:12 AM
Thank-you for a detailed explanation - I do appreciate your insight. I think we're making the argument an 'apple' is better than an 'orange' ... Use of Managed DirectX in a massively parallel system with 200 processors and real-time processing requirements is, I agree, less than ideal. I like to check every premise and question precepts. If I understand right, are you stating that Managed DirectX isn't sufficently fast (due to COM interop) to create an AAA software title/game engine?

(grr- must not break NDA). :)

rakmaya
05-04-2005, 12:43 PM
No. No. Managed DirectX is not the problem. See, managed code and unmanaged code doesn't have that big of a performance difference. But when you want to use unmanaged features, you need to switch over. That transition stage is expensive. It depends on how the render pipeline goes. If your pipline is simple then you will not have to worry about it. On the other hand if the pipeline spends time on handling unmanaged code, then you will see large difference.

C# by itself is as fast as C++. When we tries to switch over back and forth you experience the hit. Note that this is true either way. It just that noone goes the other way around.

Magallanes
05-05-2005, 02:11 AM
C# is quite slow that c++ and it's a fact. BUT speed is not all, for example Starcraft, it can run even in a pentium-2 and this game is even more popular rather that "rts that need the latest graphics card of the market"

In C++ you spend a lot of time "playing" with pointer, memory and such, in C# you can use this time for optimize the code and generate a even better program in less time.

Anyways, C# use the slowest GDI+. You can use GDI and gain 100% more speed. And you can spend some time and work with directdraw, gaining 1000% more speed rather GDI+.

dotTom
05-08-2005, 09:03 AM
Given the market failure of Visual Basic .NET (and the "My Classes" in Whidbey do little to help) the long term future for C# is to target "business" domain programming. This is born out by the fact that C# "3.0" (sic) will include set based and hierarchical data manipulation primitives as keywords in the language. In other words its being steered by Anders towards being the first class data manipulation language, the ideal glue for binding SQL queries to front ends etc.

If you really want to target .NET (and there are as many reasons for as there are against) and you care about performance then you should use C++/CLI in Visual Studio 2005 (aka Whidbey). The IL generated by C++/CLI is better than that generated by the C# compiler. In addition to which you'll get both compile time template support and runtime generics. Also C++/CLI (and to be fair Managed C++ which it replaces) also include IJW which makes calling C and C++ code from managed code far far more efficient that either COM Interop or PInvoke.

The real killer for me, and the reason why after 4+ years of programming in and around .NET I'm firmly going back to C++ and C++/CLI is that C++/CLI re-introduces the notion of deterministic destruction back into .NET programming. The problem with C# as a language is it does nothing to really help with implementing IDisposable (the "using" statement is just syntactic suger). IDisposable is not trivial to implement robustly. Worse you also have to remember to call it explicitly if you want early resource releasing. In this way the CLR IDisposable pattern is not a great step on from the AddRef/Release nightmare that COM gave us. The fact the C++/CLI lets us use destructor syntax ('~') and get true scope based deterministic finalization semantics is a killer feature.

Personally speaking I think .NET as a platform will become much more interesting in the post Visual Studio Orcas timeframe. Orcas is the version of Visual Studio that will be released around the time of Longhorn. Orcas will be based on the same major version of the CLR as Whidbey. Post Orcas things look more interesting, since Microsoft is actively doing research right now to help make multithreaded programming a LOT easier. This is vital given the impending prevalence of dual and multi core systems. You actually need garbage collection to really be able to do large scale threading (if your interested there are some great papers on implementing hazard pointers in C++ which demonstrate this). You have to remember that whilst most of the folks on this forum probably think of themselves as being able to handle multithreaded programming with ease, we do not represent the majority of programming talent/skill out there. Heck I've been writing C++ for 15 years and I'm still scared by threading "in the large" (go read up on the nasty details of implementing a truly thread safe singleton in a multi-cpu / core system, all the issues around volatile and member initialization etc. Ouch).

C++ is a system language, in terms of construction it's what you'd use to put up your steel frames and major superstructure. C# is what you bring in do to the light fittings and trimmings, it's glue (that's not to say "glue" language don't have their place - as Unix has historically shown "glue" is often good enough, especially when you call out to something else frequently).

rakmaya
05-08-2005, 01:42 PM
Very true. Multithreaded coding are nothing to concern in game development. But for other business centered areas in which majority of the applications are concerned, threading is a relatively new stuff. Those programmer do not like to go into the core to learn all the details. The way threading is already implimented in .NET, it seems like MS wants to take it more and more easy for regular applications to use it. But feature and power wise, it still lacks when compared to other threaded architectures.

The beauty of C# is in its ability to program complex interfaces for even new programmers. This allows the studios to divide the programming work into two sections with relatively no time loss. Once the engine is finished, C# can take care everything that deals with Atrist tools.

It such a shame that there aren't any DirectX libraries available that has good UI features for us to take care of. If that is the case, it would make the life much easier. OpenGL does have plenty of good UI libraries written by community. Before I came to work here, they were developing one for DX and decided to scratch that and use C#.

Joviex
05-08-2005, 02:51 PM
Well I have to disagree with all the proponents that c++ is faster. That may have been true when C# first came out, but with the 2.0 framework this is not entirely true.


Actually it is not entirely true with even the 1.0 framework as can be evidenced in a real working 3d render system as compared here:

http://realmforgewiki.castlegobs.nl/index.php/Ogre_vs._Axiom_Comparision

Ogre is 100% c++ and Axiom is a direct (90% complete) port of Ogre in C#, which means no inline unmanaged or supplimental DLL calling to "faster" routines. And the C# here is still written around 1.0 and not using some of the speedier things 2.0 has to offer (generics for example).

I think it boils down more to knowing how to code correctly with the language you are given.

rakmaya
05-08-2005, 06:02 PM
I think it boils down more to knowing how to code correctly with the language you are given.

About the perfomance test you have there:
NOTE that all tech demos that comes, the 99% percentage of the code is spent in render peipeline. The CPU usage for relational speed is minimum. A more mature way to test is with Physics and AI and a complex game play in action.

Every language has its pluses and drawbacks. C# is fast as C++ in many cases. However there are certain cases, where C++ is essential. I can't close my eyes on all things that I have experienced in the past 6 years in game development. Whether it is C++ or C# there are areas it excels and Axiom is not as fast as many engines that I have worked with either. But it does have many features created within the spectrum of C#. It all biols down to getting the job done with lowest possible number of instructions (in most cases). If you think C# can't do that, you C++, if the otherway around, use C#.

DonMeck
05-11-2005, 05:04 PM
This is a very interesting thread. Unfortunally I don't know much about dotNet. I observed that a couple of tools (like renderMan, fxComposer) etc are done with dotNet and it looks like having quite of couple of good GUI stuff. I once shortly worked with wxWidgets which is nice and easy but it seems to be that not much complex controls/components are available (and bug free).

So if one uses OGRE3D (without dotNet wrappers like Axiom or RealForge), one has to add a COM interface to it? (when one is looking for WYSIWYG and Stop-Edit-Continue functionality).

Moonblood
05-13-2005, 09:42 AM
there is nothing mor fast and easier than gui developement using c# and .net

CGTalk Moderation
05-13-2005, 09:42 AM
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.