Why always C and C++ for games?

O

one

Newbie
Joined
Jan 6, 2004
Messages
157
Reaction score
0
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++?
 
C and C++ are really, really fast :E.

Other reasons, too, I suppose (tradition?), but the main reason is their power and versatility.
 
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.
 
Ricebowl said:
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.
Click to expand...

Assembler? :)
 
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?
 
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.
 
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.
 
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.
 
I thought C# was created mainly for web-applications? Unless my memory is totally inaccurate, which is extremely likely : )
 
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.
 
Pendragon said:
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.
Click to expand...
Can you tell me some of them, please? (names) :)
 
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.
 
What a....um...delightful avatar you have there Onions.
 
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.
 
Wow.. the VC++ compiler is pretty good. What about Devc++? or Borland?
 
They should do a comparison between the different c++ compilers..
 
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...
 
But you can use DirectX, OpenGL and SDL with C#, as far as I know. So you can make graphical applications, too.
 
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.
 
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"
 
It depends on the person. When you're bogged down in 'hello world', it takes some real stamina to see it through to Direct3D.
 
*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.
 
bobvodka said:
*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.
Click to expand...

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.
 
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.
 
The Mullinator said:
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.
Click to expand...
Yes, it's right that it would be damn efficient, but I think they would need more than one year longer. :D
 
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 :)
 
one said:
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.
Click to expand...

.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
 
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?
 
uh, the unreal engine is very complicated, that's all. And a plug for vb: the original unrealed was coded in vb! nyahh!
 
FictiousWill said:
uh, the unreal engine is very complicated, that's all. And a plug for vb: the original unrealed was coded in vb! nyahh!
Click to expand...
Which original UnrealEd? The one from Unreal 1? And what ist the UnrealEd from UT2003 or UT2004 coded in? Probably C++ ...
 
Just peeking in:
one said:
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?
Click to expand...

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...
 
Konfuzzyus said:
Just peeking in:
AND C# will certainly NOT gain much ground in game development because it has a garbage collector => WAAAAAY TOO SLOW
Click to expand...

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.
 
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!
 
You must log in or register to reply here.

Similar threads

Tollbooth Willie
HL2.NET HORROR SLAP
Replies
7
Views
2K
Tollbooth Willie
Tollbooth Willie
Tollbooth Willie
To Those That Stand, Those That Fell
Replies
6
Views
2K
Tollbooth Willie
Tollbooth Willie
TechnoHippyChic
If you post it, they will come...
2
Replies
63
Views
6K
TechnoHippyChic
TechnoHippyChic
Lizardizzle
  • Poll
A proposition: ValveTime Half-Life 1 co-op event
Replies
5
Views
1K
Tollbooth Willie
Tollbooth Willie
TechnoHippyChic
The Many Diversions of THC's Work Lunches
Replies
3
Views
2K
TechnoHippyChic
TechnoHippyChic
Back
Top