PDA

View Full Version : Why always C and C++ for games?


one
07-01-2004, 01:13 PM
Why are almost all games programmed in C or C++?
It is possible to use DirectX and OpenGL with lots of other languages. And in part they are really fast.
What are the advantages of C and C++?

Brian Damage
07-01-2004, 04:29 PM
C and C++ are really, really fast :E.

Other reasons, too, I suppose (tradition?), but the main reason is their power and versatility.

ComradeBadger
07-01-2004, 05:39 PM
Less of C now tbh

Go OO programming :)

Brian Damage
07-01-2004, 06:35 PM
Yeah, OO is TeH RoXXors

Ricebowl
07-01-2004, 06:41 PM
C and C++ are so powerful and fast. What other programming language is as powerful AND as fast? Not even Java.

Java is great, but not great for games like HL2.

Majestic XII
07-01-2004, 06:42 PM
C and C++ are so powerful and fast. What other programming language is as powerful AND as fast? Not even Java.

Java is great, but not great for games like HL2.

Assembler? :)

one
07-01-2004, 07:44 PM
What about C#? I don't really know this language. It is interpreted, but I played the Quake 2 .NET Version (written in Visual C++ .net) and it ran very fast. C# is a new language, perhaps it will be important in future, for games?

Pendragon
07-01-2004, 10:21 PM
A few new languages are also in development that will overcome some of the limitations of C++, like its terminal inefficiency. I don't know much about them, but I look forward to their debut.

FictiousWill
08-01-2004, 12:12 AM
DirectX Libraries are avaliable for multiple languages. With today's fast computers, the tiny slowdown of a higher level language (such as java) is not noticable. Apart from cutting edge number crunching such as in the doom3 lighting engine, a programer can really choose what language he or she genuinely is more comfortable with. The reason why c and c++ are so prevalent is because a.) not everybody has the cpu cycles to spare on higher level compiled programs (though most do, but not all. yet!) and b.) it's what the programmers learn. Then they take it to business. The business (game developer) then wants to hire similar coders. c++ self-propegates. Also, c++ is the foundation of many programs so c.) it's platform indepenent and it's somewhat of a standard.

Don't flame me unless you know what you're talking about, but VB is a hell of a lot more powerful than it appears on the surface when you do custom compiles and dll-links and strip off the gui in favor of pure directx.

Anable
08-01-2004, 01:14 AM
So a game devolped in VB would be faster than a game created in C++? My fragile little world has just crumbled. I've been led to believe that VB is out of date and pretty pointless.

FictiousWill
08-01-2004, 01:19 AM
No, I meant that it would be slower, but the amount of slowerness (sorry!) would be so microscopically small that you wouldn't notice. Native C++ is always faster, but if you have anything above a 500mhz processor you can't tell.

Sandman
08-01-2004, 02:52 AM
I thought C# was created mainly for web-applications? Unless my memory is totally inaccurate, which is extremely likely : )

FictiousWill
08-01-2004, 05:26 AM
I've not used C#, but from what I've heard from friends that have tried it is that it's the language that should get all the flack VB does. Apparently (I have no 1st hand experience) it is extremely slow and very unfamiliarly and illogically laid out - cumbersome in general.

one
08-01-2004, 01:11 PM
A few new languages are also in development that will overcome some of the limitations of C++, like its terminal inefficiency. I don't know much about them, but I look forward to their debut.
Can you tell me some of them, please? (names) :)

Onions
08-01-2004, 05:12 PM
i believe c# is more for fast application development, and isn't fast enough for games programming. though i have nothing to back that up, just word of mouth :)
as for other languages, java is quite nice. i'm not too sure on the speed of the compiled code, in my experience java apps run a lot slower than c++ apps, but its a nice language to use, and if you don't already know c++ its a great way to get into opject orientated programming.

Anable
08-01-2004, 07:37 PM
What a....um...delightful avatar you have there Onions.

qckbeam
09-01-2004, 05:42 AM
yes Onions, your avatar is wonderful :)

EvNTHriZen
09-01-2004, 10:24 AM
If you don't use OO in C++, then it is just as fast as C (because it is C). Thing is though, when you start programming using classes, it makes creating large projects, like halflife 2, much easier. I cant imagine creating the database for HL2 using C.... And just programming the different objects? Forget it. I'd rather a hole in my head.

botman
09-01-2004, 09:47 PM
Check out this comparison of various languages (Visual C++, Visual Basic, Visual C#, Java, Python, etc.)...

http://osnews.com/story.php?news_id=5602

Look at the Results at the end. Visual C++ is teh winnah! (in terms of raw speed anyway)

botman

EvNTHriZen
09-01-2004, 10:16 PM
Wow.. the VC++ compiler is pretty good. What about Devc++? or Borland?

one
09-01-2004, 10:33 PM
Or the GCC.

EvNTHriZen
09-01-2004, 10:36 PM
They should do a comparison between the different c++ compilers..

one
09-01-2004, 10:39 PM
I'm sure there are comparisons between C++ compilers. Search for it with http://www.Yahoo.com or http://www.Google.com ! :-)

Retro_X
09-01-2004, 11:50 PM
c# isn't for games. C and C++ are used for most apps...i even used it to program a small but versitile media player, call RetroAMP...

one
10-01-2004, 12:19 AM
But you can use DirectX, OpenGL and SDL with C#, as far as I know. So you can make graphical applications, too.

FictiousWill
10-01-2004, 02:00 AM
That benchmark didn't touch on more interesting stuff like dll call speed etc. Nvm finding more tho, I've seen all these type of benchs anyway.

magnetmannen
10-01-2004, 11:20 AM
ive been learning modelling for 1, 4 years, and it made me wonder, if i set of 1 hour every day to learn c coding, how long will it take me to "get good" at it? for hl2 coding ofcourse, i have no big ideas about becoming the "god of code"

FictiousWill
10-01-2004, 07:13 PM
It depends on the person. When you're bogged down in 'hello world', it takes some real stamina to see it through to Direct3D.

bobvodka
17-01-2004, 06:13 PM
*up steps the experianced programmer*
First up, C# isnt too slow for games, it has 95 to 98% of the speed of C++ apps thanks to the JITing which is done at first run time and given that in most games the bottle neck is the gfx card drawing rate that 2% doesnt make a huge difference :)
C and C++ are primaryly used atm for gamedev simply because thats where everyones experiance/libs happen to be, also most games have been in production for a couple of years, before C# and the .Net thing really took off.
Also, currently C# code isnt really portable, the Open Source ports arent that complete yet (at least when i last checked) and there isnt a version for the GC or PS2.

Its also worth noting that outside of games and into teh bussiness world languages such as VB, Java and increasingly C#/VB.Net are used alot more often than C or C++ simply because they are so much faster to develope with and they dont need all of the speed thats a C/C++ application would bring, but they do need the Rapid App. Dev times.

Finaly, with Longhorn the whole system is moving to Managed code and while C and C++ will be able to run still C# etc will become more common.

Onions
17-01-2004, 10:10 PM
thank you, my avatar is indeed delightful :)

one
17-01-2004, 11:22 PM
*up steps the experianced programmer*
First up, C# isnt too slow for games, it has 95 to 98% of the speed of C++ apps thanks to the JITing which is done at first run time and given that in most games the bottle neck is the gfx card drawing rate that 2% doesnt make a huge difference :)
C and C++ are primaryly used atm for gamedev simply because thats where everyones experiance/libs happen to be, also most games have been in production for a couple of years, before C# and the .Net thing really took off.
Also, currently C# code isnt really portable, the Open Source ports arent that complete yet (at least when i last checked) and there isnt a version for the GC or PS2.

Its also worth noting that outside of games and into teh bussiness world languages such as VB, Java and increasingly C#/VB.Net are used alot more often than C or C++ simply because they are so much faster to develope with and they dont need all of the speed thats a C/C++ application would bring, but they do need the Rapid App. Dev times.

Finaly, with Longhorn the whole system is moving to Managed code and while C and C++ will be able to run still C# etc will become more common.

Yes, maybe with the new Windows (Codename Longhorn) and the progression of Mono and other .net implementations for other plattforms. Interpreted languages are fast enough for games, Quake 2 for .net shows that.

The Mullinator
18-01-2004, 12:21 AM
They should all just switch to assembly language. Sure it would take like an extra year to program but it would be really damn efficient.

one
18-01-2004, 10:23 AM
They should all just switch to assembly language. Sure it would take like an extra year to program but it would be really damn efficient.
Yes, it's right that it would be damn efficient, but I think they would need more than one year longer. :D

bobvodka
20-01-2004, 09:08 PM
back on the old 486 and early pentium chips assembler was a valid choice for doing games, however modern chips are a nitemare to code on, multi-pipelines, out of order execution and other func techs mean that the stuff goes fast but its a nitemare to code, thus in 99.999% of cases it best left to the compiler to figure out :)

bobvodka
20-01-2004, 09:11 PM
Yes, maybe with the new Windows (Codename Longhorn) and the progression of Mono and other .net implementations for other plattforms. Interpreted languages are fast enough for games, Quake 2 for .net shows that.

.Net stuff ISNT interpreted, on first run the code is JITed to the machines binary format and run from that.
However, games which say run on the Unreal engine show that interpreted code is fast enuff and was some time ago and given the majority of games released now use scripting in some form that also proves it, infact i belive that HL2 will be one of the odd few which dont use scripting

one
20-01-2004, 10:13 PM
Why show games that run on the Unreal engine that interpreted code is fast enough? The Unreal engine is written in C++, isn't it?

FictiousWill
20-01-2004, 11:38 PM
uh, the unreal engine is very complicated, that's all. And a plug for vb: the original unrealed was coded in vb! nyahh!

one
21-01-2004, 02:20 PM
uh, the unreal engine is very complicated, that's all. And a plug for vb: the original unrealed was coded in vb! nyahh!
Which original UnrealEd? The one from Unreal 1? And what ist the UnrealEd from UT2003 or UT2004 coded in? Probably C++ ...

Konfuzzyus
21-01-2004, 02:40 PM
Just peeking in:
Why show games that run on the Unreal engine that interpreted code is fast enough? The Unreal engine is written in C++, isn't it?

actually "fast enough" is a strechable phrase... it's still much faster to use compiled code but due to the fact that game mechanics do not take up most of the processing time (graphics are doing that) and that (in good code) most of the game code is not processed in every frame, you can go with the slowdown of interpreted language...

And Unreal's Engine IS written in C++ & Assembler BUT it's mechanics are written in a scripting language, more similar to java (which "compiles" code into bytecode and interpretes that)

AND C# will certainly NOT gain much ground in game development because it has a garbage collector => WAAAAAY TOO SLOW

It's ok if you want to play games with computers of tomorrow with performance and graphics from yesterday but if you want to use the new computing power efficiently... well...

bobvodka
24-01-2004, 06:28 PM
Just peeking in:
AND C# will certainly NOT gain much ground in game development because it has a garbage collector => WAAAAAY TOO SLOW


Dont count on it.
For one thing the GC can be disabled so when you enter your critcal loop the GC doesnt kick in.
Also, the GC only really comes into effect when you have deleted something, and frankly its bad coding practice to be creating and deleteing objects in your critcal loop as well as frankly new and delete can be blimmin slow (pre-allocate or use your own memory controller system)

C# will most probably gain ground in Tool dev first where the speed of the system isnt as important as the speed of making the tools, and its easy enuff to plug a C++ engine into a C# GUI.

Also, a number of people are experimenting in making C# their scripting system.

ambershee
24-01-2004, 09:40 PM
Unreal engine - complicated? Blarg. Don't believe it.
Personally, it doesn't make a huge amount of difference which version of the C language they decide to use - it'll be roughly the same level of efficiency anyway.
Personally, I wouldn't want to wait for another year for HL2. There's no way they could get away with switching to assembly language!

Konfuzzyus
25-01-2004, 10:29 PM
the GC only really comes into effect when you have deleted something

I'm am not 100% sure, but, if I have understood the GC concept right, if you explicitly DELETE something, the GC should remain idle. The GC's job is helping sloppy programmers to keep their memory clean when they allocate memory and do not proplerly disallocate it (aka MEMORY LEAKS), which is a real bother when you start programming OO.

bobvodka
25-01-2004, 10:56 PM
not really a bother, the program i've written for work has zero memory leaks thanks to the useage of boost::shared_ptr<>s and various STL containers.

i'll have to read up on a GC, but the preception that its for 'sloppy programmers' isnt quite that true, it does have advantages and disadvantages over 'normal' memory handling.