Archived

This topic is now archived and is closed to further replies.

.NET Platform

This topic is 5570 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Has there been any movement, to start programming in VS .NET, or is everyone pretty much still sticking with VS 6.0? I''ve been out of the loop for a while, and I''m just getting back.

Share this post


Link to post
Share on other sites
I''ve been using VS.NET for 14 months now



When I look upon seamen, men of physical science, and philosophers, man is the wisest of all beings. When I look upon priests, prophets, and interpreters of dreams, nothing is so contemptible as man.


  Diogenes

Share this post


Link to post
Share on other sites
Hi! Well, most companies still prefer C++ for their game project. Most of them (I guess) are using VS.NET but without using the the .NET platform!
Currently I''m playing a little bit around with C# and I''m quite sure, that C# will become the future language for games (in the next 3-5 years)
If you are interested - take a look at:
www.bunnz.com

Have fun
Bunnz

Share this post


Link to post
Share on other sites
Thanks for the info and the URL. I''ll look into this. I''m really excited about this, because I''ve been programming in VS .NET now for about 4 months, and it just occured to me that hey I like the VS .NET Environment much better, so it would be great to program my games with it. Thanks again.

Share this post


Link to post
Share on other sites
quote:
Original post by Bunnz
Currently I''m playing a little bit around with C# and I''m quite sure, that C# will become the future language for games (in the next 3-5 years)



Do you think it is fast enough? I remember when people use to develop games with Watcom C because it produced code that was like 5 or 10% faster than other compilers.

Do you think the garbage collection is an issue?

Share this post


Link to post
Share on other sites
Hi Jim
C# is definitely slower than C++, maybe it''s too slow, but you can implement the speed critical parts in (managed) C++. It is also really easy to access nonmanaged dlls!!!
In my opinion it''s much more important to speed up the game creation process than the actual game. Better a slow game than no game
I know this is a very controversial opinion in the gaming industry, but I think that the average game programmer tend to overestimate the speed factor.
However, gfx boards become faster and free a lot of ressources which can be wasted by using C#

Have fun
Bunnz

Share this post


Link to post
Share on other sites
I have been looking at C# and this is what my thoughts (and predictions) are...

C# is too slow for the gaming standard. Sure it is cleaner and easier, but ''easy'' has never actually been an issue for hardcore gaming companies. Just look at Doom III, the people there are doing -everything- they can to gain frames. That''s how it is right now I''m afraid...

Although there is another future for C#, for it is the perfect application-development language. Clean and easy it makes for perfect business applications. This is what my best guess is anyway.

-----------------------------
Valkyrias: Tears of Valkyries
quote:
Original post by Bunnz
but you can implement the speed critical parts in (managed) C++.



I assume you mean unmanaged C++, because managed C++ is compiled to the exact same byte-code as C# and undergoes the same JIT''ing and garbage collection that C# does (hence making managed C++ no faster than C#).

If I had my way, I''d have all of you shot!


codeka.com - Just click it.

Share this post


Link to post
Share on other sites
quote:
Just look at Doom III, the people there are doing -everything- they can to gain frames.

This argument is not as damning for the language as it may first seem since most top-selling games do not use bleeding-edge performance like Doom III and since unmanaged code can be used to optimize the performance-critical sections of applications that really need it.

The worst problem with a language like C# is that it is not likely to make it onto consoles, except MAYBE the Xbox (and the Xbox only holds a tiny share of the market). The console market is very important for serious developers and currently C and C++ are the only languages that offer any form of portability between both PCs and consoles.


[edited by - HenryAPe on September 13, 2002 1:41:30 AM]

Share this post


Link to post
Share on other sites
I''m still personaly not convinced about the raw speed of C#
yes, it is good when being used for a server side system, or a bussines app (althought, saying that the only .Net application i have has VERY slow responce when i click on buttons, and my system isnt too shabby either ) and is probably the way forward, but when it comes to games its a whole different beast.

For one thing, you have a whole extra layer between you and the hardware as the JIT conversion still has to take place, which has to make it slower and will be noticeable when it comes to frame rate.

also, games WILL be using bleeding edge tech when they start using the Doom3 and UT2K3 engines for game production (as has happened with the UT and Quake3 engine already)

But, part of me can see some logic behind going to C# from the hardware venders point of view, we all goto C#, programs react slower, maybe even require more memory so people upgrade RAM and CPUs to get back to the performance they already had.

Someone pretty much said ''oh, things are getting faster, people have more RAM, so we can waste more resouces with C#'' to that I say utter utter rubbish, we should be using these extra resources to make things work better, faster and in the case of games look and feel better, more AI, better sounds, better maps, better collision detection, not bloat out your code just because you have the space... I spent ages one night defending games programmer for not being lazy just because games demand higher specs, but that kinda arguement makes me wonder if its worth while defending the idea, personaly I prefer small, tight code, min. wasteage, heck i''m loathed to add a varible to a class at times until I have used up any way of reusing i can think of doing.

Speeding up the game creation process is all very well and good, but its not going to help you if you bung out a load of games which run @ 20fps max and say to the consumer, he dont make fast games, we just make games quickly.

To the person who said you can just used normal C/C++ in critical sections, i''d be VERY surprised if that kinda swap didnt have some performance hit of its own.

I''m not saying C# and the .NET thing is a bad thing, it looks good and looks like what Java should have been, but like Java, even with JIT I dont see how it can perform at the same level as C/C++ (and yes, i know there are some test somewhere which show C# performing at the same speed as C++, but as was once said, you can make stats prove anything, and if your pushing and langauge you want to make it look as good as you can)

btw, personaly, I dont think you can beat VS.Net for C/C++ developement

Share this post


Link to post
Share on other sites
C# will be fine for almost all games (except the very bleeding edge) once they release a couple more versions and get the garbage collection issues sorted (it tends to run the garbage collection too infrequently and then causes a long pause when it does finally run).

If you don't believe this, wait until the DX9 release with C# support. You'll be very surprised.

I currently still do all of my real development in C++ because C# still has some issues that need to be settled (again... the GC issue, poor DX support until DX9 is finalized, the runtime is pretty large to distribute for net-distributed games (not an issue for CD distribution, though)). But in the long term I see myself moving more and more of my development to C#.

To Phantom:

Microsoft is addressing a large part of the speed issues with C# for games by having DX9.Net handle a lot of things internally that C++ programmers might handle on their own. As you might guess they are implementing that layer in very well optimized C++, so a C# 3D game will be easily capable of doing a lot more than 20 fps. (You might also want to keep in mind that anyone with less than a GF3 card is going to be running Doom3 at 20 fps or less even though its optimized C/C++. All depends on the feature set used, etc, so you need some context to go with that statement).




[edited by - gmcbay on September 13, 2002 2:27:51 AM]

Share this post


Link to post
Share on other sites
People make games in everything from php to visual basic... give said people time, and there will definately be a C# game.

/*-=-=-=-=-=-=-=-=-=-=-=-=
trae@illicitstudios.com
=-=-=-=-=-=-=-=-=-=-=-=-*/

Share this post


Link to post
Share on other sites
Nice discussion

Well some time ago, people thought games have to be developed using asm and C. Now most games are implemented in C++ using technologies like Smart Pointers, Reflection(Meta stuff), and scripting(even slower than C# .

A few years ago, there was a similar discussion about using C++ and OOP in game programming (cause some thought it is sooo damn slow)!

Well, in my opinion C# is fast enough for the game logic and the speed critical stuff can easily be implemented in C++!

However, nobody knows what the future will bring!

Have fun
Bunnz

a href="http://www.bunnz.com">www.bunnz.com

Share this post


Link to post
Share on other sites
quote:
Original post by Dean Harding
managed C++ is compiled to the exact same byte-code as C# and undergoes the same JIT''ing and garbage collection that C# does (hence making managed C++ no faster than C#).

I believe the MC++ compiler does more optimizations up front than the other languages.



When I look upon seamen, men of physical science, and philosophers, man is the wisest of all beings. When I look upon priests, prophets, and interpreters of dreams, nothing is so contemptible as man.


  Diogenes

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by _the_phantom_
...For one thing, you have a whole extra layer between you and the hardware as the JIT conversion still has to take place, which has to make it slower and will be noticeable when it comes to frame rate...


I think there is a misconception. The JIT is on used if you precompile you program in the first place. Mostly with WEb pages. The Just In Time Compilier (JIT) is used when a request for a page is called and the server notices there is no compiled code, so the server then uses the JIT to quickly, and I use the term loosely, to bring the ASPX page up for viewing. When compiling for applications, you compile your project and the JIT isn''t used at all because the code is already compiled. In fact you don''t even have to use the JIT in web applications either if you compile all you behind code ahead of time. So this issue with the JIT compiler slowing the program down isn''t really an issue.

Share this post


Link to post
Share on other sites
quote:
Original post by _the_phantom_
...For one thing, you have a whole extra layer between you and the hardware as the JIT conversion still has to take place, which has to make it slower and will be noticeable when it comes to frame rate...


I think there is a misconception. The JIT is on used if you didn't precompile you program in the first place. Mostly with Web pages. The Just In Time Compilier (JIT) is used when a request for a page is called and the server notices there is no compiled code, so the server then uses the JIT to quickly, and I use the term loosely, compile and bring the ASPX page up for viewing. When compiling for applications, you compile your project and the JIT isn't used at all because the code is already compiled. In fact you don't even have to use the JIT in web applications either if you compile all your behind code ahead of time. So this issue with the JIT compiler slowing the program down isn't really an issue.

[edited by - Tollman on September 13, 2002 9:42:21 AM]

Share this post


Link to post
Share on other sites
I don't think that is accurate. The JIT compilier is used in Windows Applications written in .Net. When the source code is "compiled" and first executed, it is stored in memory in its CIL form. As the code is executing, the chuck of code about to execute is then compiled to lower level instructions by the JIT compilier. That way code that is never executed is never really compiled and never has resources wasted on it(except the memory used to store it in the first place).
I could be wrong, but I think that is the way it works.

"Wisdom is proportionate to your reference base. Intelligence is the ability to appropriately use that Wisdom."






[edited by - Leathrewulfe on September 13, 2002 9:58:33 AM]

Share this post


Link to post
Share on other sites
It was totally inaccurate, so to say.

ASp.NET has 2 compile steps - the MSIL step where the page is parsed and a dll generated for every page, and the JIT phase like any other application.

The JIT is compiling the application "function by function" as the function is first called, outputting the generated image to a cached file. It is responsible for bytecode/native conversions.

It is run whenever a non-compiled function is used. Now - we dont talk of C# as compiler here,a s this generates bytecode.

You can avoid the JIT "in time" by calling ngen.exe on the executables and prejtting them.

So, Tollman, please read up on topics before posting bad advice and false information.


Regards

Thomas Tomiczek
THONA Consulting Ltd.
(Microsoft MVP C#/.NET)

Share this post


Link to post
Share on other sites
Thona,


I never knew about the ngen.exe. I assume you get faster execution time for the trade-off of a bigger binary size, when that is used?

"Wisdom is proportionate to your reference base. Intelligence is the ability to appropriately use that Wisdom."

Share this post


Link to post
Share on other sites
There is a little difference between C vs C++ and C++ vs C#.
With the new compilers C++ code shouldn''t be slower than C, but C# will NEVER be as fast as C or C++.
Also I don''t think C# is easier to use if you have to do 3D Stuff. (no serious programmer would need GC)

Share this post


Link to post
Share on other sites
The problem with C# is not speed. It''s the lack of features. While it''s a perfect language for server side applications (stuff like web sites) and possibly(I''m not sure about that) GUI client stuff it absolutely blows in terms of features. No multiple inheritance, no default parameters, etc. Come on, what serious game programmer will buy that?

Share this post


Link to post
Share on other sites
Well, I think judgement on C# and multi-media programming should be reserved until DirectX 9 is released.

I can get decent performance using GDI+ with C# on a low-end system. So, I am optimistic about C#'s future for entertainment software.


No multiple-inheritance? Is that the best you got? Through a clever use of the internal keyword or using Interfaces you could emulate multiple-inheritance in C#.
Also, for what it's worth...the ANSI/ISO board for C++ almost decided against multiple inheritence.

"Wisdom is proportionate to your reference base. Intelligence is the ability to appropriately use that Wisdom."


[edited by - Leathrewulfe on September 13, 2002 10:36:37 AM]

Share this post


Link to post
Share on other sites
ngen does not do anything with your exe/dll. What it does is basically forcing the JIT to pre-jit the whole thing, and pdate it''s cache accordingly. So while your files do not grow, you get the full cache (and it''s space usage) immediatly.

Now, for never having heard about it - I strongly suggest you start reading the documentation.


Regards

Thomas Tomiczek
THONA Consulting Ltd.
(Microsoft MVP C#/.NET)

Share this post


Link to post
Share on other sites
quote:
Original post by kill
No multiple inheritance,


It has yet to be proven that the benefits of MI outweigh the complexity(both on the compiler level and from the programmer POV) it adds. In 90%++ of the cases, interface inheritance and/or delegation will be far preferrable.
Yes, I do see the advantage of mix-in classes(quite possible the only legitimate use of MI), and there are times when I regret not being able to use them in C#. However, it''s a feeling that rarely lasts long since I''m usually able to find alternative(and in many cases better) ways of doing what I want.
quote:

no default parameters, etc.


C# doesn''t have default parameters because they dont version well. If you compile against a library that has methods with default parameters, those defaults get compiled into the calling code. If that value changes, all client code will have to be recompiled.

However, you get the exact same functionality(without the drawbacks) with method overloading.



When I look upon seamen, men of physical science, and philosophers, man is the wisest of all beings. When I look upon priests, prophets, and interpreters of dreams, nothing is so contemptible as man.


  Diogenes

Share this post


Link to post
Share on other sites
For anyone interested: MS Research has released Gyro[1], which is a sample implementation of generics(templates in C++-speke) in C# and the CLR. It is distributed as a patch to the Rotor[2] source tree.

[1]http://research.microsoft.com/projects/clrgen/
[2]http://msdn.microsoft.com/downloads/default.asp?URL=/downloads/sample.asp?url=/msdn-files/027/001/901/msdncompositedoc.xml

Share this post


Link to post
Share on other sites