quote:Original post by wyrd
Lots of people no doubt support C#. But I''m curious, for those that do, where are your games and/or apps? I scroll these forums almost every day, and have yet to see a post for a game made in either C# or .NET (aside from my own).

It''s one thing to support and like a language. It''s another to actually make something with it.

a) Our company switched from developing about 80%+ of applications in C++ to 95% C#. We have done approximately 14 LARGE scale projects using the language. According to productivity reports we would have only completed 9-10 of those projects if we hadn''t switched to the new language.

b) C# is still new and managed DirectX is even newer. It is like when game developers started "meddling with C and C++" back in the day when things were done in assembly, it takes a little while for finished projects to start showing up. Right now my current game project I am working on after work hours is being completely written in 100% managed C#.

You could look up the Axiom engine here: http://axiomengine.sourceforge.net/

It is a port of the OGRE (C++) Engine and is written entirely in C# and makes use of managed DirectX as well as OpenGL through TaoGL. Please note the benchmarks as it currently outperforms it''s C++ "big brother" =]

quote:Original post by jonbell
Game Development is about making money, most of the money comes from PS2 sales, try getting a C# compiler for PS2.

Game development is an Art as well as movie making or writing books.

quote:Original post by maxd gaming

quote:Original post by Raghar
BTW I use ASM. (After while ASM programming you'd know that even C++ is so slow) ~_^
[edited by - Raghar on January 7, 2004 8:19:10 PM]

rofl...

You are welcome. Just be carefull to not be so dirty. ^_^

*_*


[edited by - Raghar on January 8, 2004 7:09:37 PM]

quote:Original post by Imperil
Why do people continue to post on topics they have NO KNOWLEDGE ABOUT!

So: please go away?!

quote:Original post by Imperil
C# DOES NOT run on a virtual machine. It is compiled at runtime and executes normally, maybe you need to read up some? Please note that on Windows Longhorn and all future Microsoft operating systems, managed code and .NET are "native" to the platform, and your native code that you claim to be so fast right now will be sitting on top of that being slowed down due to .NET and security regs.

Wrong again. Sure you won''t run drivers and memory managers in C#, that is what C++ is made for... lower level code that can be used in most situations on any platform. Also please note again that C# does not run on a virtual machine, wherever you got this information from is wrong. Also the reason for the garbage collector is for security reasons, you should notice that over 90% of security problems today are from memory leaks and bad memory programming.

encapsulates lot''s of stuff? umm maybe you should tell us what because that makes no sense at all.

Also what is this price you are speaking of? The only one I know of is a 3-5% performance loss in SOME cases.

Also what are these "obscure things that aren''t available to C# even in programming windows"? I would REALLY LOVE TO KNOW considering C# is the forefront language for programming on the Longhorn OS and I believe 80% of the common is even written in C#.

You really have no idea what you are talking about do you? You can use NATIVE ASM, NATIVE C++, OR IL ASM with C#. You can also use your own memory management and pointers with C#, you just have to denote that you are in unsafe mode.

Now I don''t mean to make you look stupid.. but you really have no idea what you are talking about when mentioning C#. You haven''t talked about ANY of the languages features, pros, or cons. All you have said are a bunch of made up ideas that I have no idea what you are talking about.

Also FYI the .NET framework is a beta test on 2000/XP and you should note that. It is the CORE SYSTEM that Windows Longhorn and future OS''s use, native code is now the one that has to pass through security channels, etc on top of the OS. The only thing native code will be good for on Longhorn are memory managers, drivers, etc like you said. Otherwise boxes pop up for the user telling them "THIS APPLICATION IS DEEMED UNSAFE CLICK HERE TO SHUT THE APPLICATION DOWN OR CLICK HERE TO ACCEPT".. and right there over 80% of users are going to shut it down =]

Well, thanks for not trying to make me look stupid. Altought, I can''t really make the same thing to you...

Please have a look here: http://homepages.com.pk/kashman/jvm.htm#_jvm

There you can read: "You should most definitely expect your programs to run faster than an equivalent java program [11]; but your program would still run slower than an equivalent C/C++ program - or any other program that is compiled into machine language. That''s a limitation that ALL interpreted languages have, and that''s the price you pay for platform independence."

As for using ASM, Native C++, with C#: well, great, because you can actually compile ASM and Native C++ to IL, just like compiling to x86. But try and compile C# code into machine language...

And from a PowerPoint presentation in the micro$soft website (search it yourself), one can read:

"Anytime it makes sense: use Native Windows (read: C++)"
"Total access to the .NET Framework"
"VisualC++ .NET 2003 keeps being the best and biggest tool for the high-end developer."

I am really sorry, but I tried my best not to make you look stupid! Sorry if I failed...

quote:Original post by SigmaGL

Well, thanks for not trying to make me look stupid. Altought, I can''t really make the same thing to you...

lol so you completely dodged every single question, then write a bunch of nonsense and you think you make me look stupid?

quote:
Please have a look here: http://homepages.com.pk/kashman/jvm.htm#_jvm

There you can read: "You should most definitely expect your programs to run faster than an equivalent java program [11]; but your program would still run slower than an equivalent C/C++ program - or any other program that is compiled into machine language. That''s a limitation that ALL interpreted languages have, and that''s the price you pay for platform independence."

Since when are we talking about Java here? I specifically stated C#.. maybe you have a slight reading comprehention problem?

Do you not understand that C# IS NOT INTERPERETED?!? It is compiled at run-time by the JIT. You are using compiled bytecode not interpretation.

rofl you show me a Java link about virtual machine and want it to somehow mean something about C#?

quote:
As for using ASM, Native C++, with C#: well, great, because you can actually compile ASM and Native C++ to IL, just like compiling to x86. But try and compile C# code into machine language...

Why would I want to do this? C# is meant for development of applications on the current and future Microsoft Windows platforms. If I wanted to write low-level drivers or other low-level code I wouldn''t be using C# now would I? What many of you will learn at some point is that you must select the proper tool for the job.

quote:
And from a PowerPoint presentation in the micro$soft website (search it yourself), one can read:

"Anytime it makes sense: use Native Windows (read: C++)"
"Total access to the .NET Framework"
"VisualC++ .NET 2003 keeps being the best and biggest tool for the high-end developer."

Correct. NOWHERE did I state a C# program is going to perform better than a fully optomized C++ program.. ON THE CURRENT OS. Please note Windows Longhorn is not an "upgrade OS", it is a new OS the same as how Win95 was to DOS.

At the current time IF you are one of the select 1-2% of people ON THIS SITE that know how to use the C++ language to it''s fullest and completely optomize an application, than yes C++ will outperform the C# equivelent by approximately 3-5%.

quote:
I am really sorry, but I tried my best not to make you look stupid! Sorry if I failed...

Nonsense you didn''t fail at all, you did quite well at stating a bunch of wrong facts with some odd URL that means nothing to the conversation, not to mention dodging every single question asked =]

quote:Original post by Rick Scott
then, I don''t know if C# is currently viable for game development. But I know its awesome for every windows (and intranet) application I''ve used it for.

Are you talking about C# the language here, or Visual Studio.NET the tool/platform? How would your productivity here compare to a WYSIWYG C++ environment like Borland C++ Builder for developing Windows applications?





--
Dave Mikesell Software & Consulting

quote:Original post by jonbell
My original point remains, you cannot get a C# or Java compiler for any of the major consoles (XBox is a PC so its an exception).

I have worked as a programmer in the games industry for just over a year so while i am certainly no veteran i can tell you that what matters most is always the PS2 build, thats were the money is. This is why C and C++ are the 2 languages used in industry. When a new platform comes put you get a C compiler straight away and then 6 months later you''ll get a decent C++ compiler.

Why is nobody refuting Jon''s point here?


--
Dave Mikesell Software & Consulting

quote:Original post by dmikesell

quote:Original post by jonbell
My original point remains, you cannot get a C# or Java compiler for any of the major consoles (XBox is a PC so its an exception).

I have worked as a programmer in the games industry for just over a year so while i am certainly no veteran i can tell you that what matters most is always the PS2 build, thats were the money is. This is why C and C++ are the 2 languages used in industry. When a new platform comes put you get a C compiler straight away and then 6 months later you'll get a decent C++ compiler.

Why is nobody refuting Jon's point here?


--
Dave Mikesell Software & Consulting

Because that is the way it works, he's dead on the money =]

C# is for Windows PC development (games and apps). If you want to build for consoles, or if you want to cross-platform to a console later on than don't use C#. The only console that .NET "may" be available on would be the X-Box.


[edited by - Imperil on January 9, 2004 9:43:08 AM]

quote:Original post by dmikesell

quote:Original post by Rick Scott
then, I don''t know if C# is currently viable for game development. But I know its awesome for every windows (and intranet) application I''ve used it for.

Are you talking about C# the language here, or Visual Studio.NET the tool/platform? How would your productivity here compare to a WYSIWYG C++ environment like Borland C++ Builder for developing Windows applications?

C# the language. BCB (which is where I actually learned C++ and Win32) isn''t any better then Visual Studio (as of the BCB version around when VS6 was around) when discussing the window editor.

The only complaint I have about VS.NET''s window editor is this: When I double-click on a component (using C++), the default action is to bring me to the "Add Class Wizard." I guess this is for MFC development? I really wish it would take me to the properties page instead...

When using C#, the default action is to automatically add an event handler for that component so no complaints there.

quote:Original post by Rick Scott

quote:Original post by dmikesell

quote:Original post by Rick Scott
then, I don''t know if C# is currently viable for game development. But I know its awesome for every windows (and intranet) application I''ve used it for.

Are you talking about C# the language here, or Visual Studio.NET the tool/platform? How would your productivity here compare to a WYSIWYG C++ environment like Borland C++ Builder for developing Windows applications?

C# the language. BCB (which is where I actually learned C++ and Win32) isn''t any better then Visual Studio (as of the BCB version around when VS6 was around) when discussing the window editor.

The only complaint I have about VS.NET''s window editor is this: When I double-click on a component (using C++), the default action is to bring me to the "Add Class Wizard." I guess this is for MFC development? I really wish it would take me to the properties page instead...

When using C#, the default action is to automatically add an event handler for that component so no complaints there.

I''m using C++ Builder 6 Professional. I''m not much of a Windows developer, admittedly, but I drag and drop components onto forms, and when I double-click on an event for a widget in the properties Window, it takes me to the event-handling code. The components have read/write properties to maniuplate settings at runtime. It all seems very easy to me, but I''ve never done anything terribly complex.



--
Dave Mikesell Software & Consulting