Still Using C++?

[None]

Hi,

I am a game developer, sometimes "indy" and sometimes for a small-sized
company. I can't speak for all game developers, but everywhere I've ever
seen people working on games, execution speed has always been the most
important constraint in writing code. Writing readable and maintainable
code is important, but takes a back seat to execution speed.

I work with DirectX and/or OpenGL, always in C++. There are plenty of
things that I'd like to see improved in C++. But as far as I have seen,
C++ continues to be the workhorse of the gaming business. I've noticed, as
I was searching for examples of how to do some particular trick in D3D, a
few samples written in C#.

But what I know about C# is two things: 1) managed code, and 2) garbage
collection. These are both deal breakers for execution speed, in my
opinion. Trying to squeeze the maximum number of triangles and shaders
through the graphics pipe using code running on a virtual machine seems...
well, silly. And as for garbage collection, I've found that any serious 3D
code I've written has needed very explicit control over when things are
allocated and deleted. Rendering 3D invloves lots of very large buffers of
data, many of them changing drastically in size (meaning possible
reallocation) between every frame. Minimizing the expense of
allocation/deletion/reallocation through intelligent code is crucial.

Anyway, it just seems like C++ has been the "big hammer" for game
development for long enough that we've figured out what's good and what's
bad about it. I certainly have my own fairly long list of annoyances, but
I'm not really interested in opening that can of worms here, since it's
already been debated to death.

But I am interested in looking for alternatives. Am I wrong about C# -- is
it a viable alternative for serious programming, or is it a toy? How about
"D? "I've heard good things about it, but I don't know how widely
supported it is. Having well-supported tool chanins, libraries, IDEs,
documentation, and other resources is important.

Just wondering...

[Juha Nieminen]

None wrote:

But what I know about C# is two things: 1) managed code, and 2) garbage
collection. These are both deal breakers for execution speed, in my
opinion.

An opinion based on prejudices and rumors, I assume. You should base
your opinions on actual experimentation , not on what some C hackers tell
you.

As time has passed, the speed gap between C++ and "higher-level"
languages has diminished. However, there's one thing where C++ still
excels compared to many other languages (although I can't say for sure
if compared to C#): It's possible to make extremely memory-efficient
programs with it (while still preserving a good level of abstraction,
which makes C++ better than C, IMO).

[ave]

But what I know about C# is two things: 1) managed code, and 2) garbage

collection. These are both deal breakers for execution speed, in my
opinion.

This is very wrong, C# is not as performant as C++ but these two points are
not related to the performance difference.

1) Managed Code
Managed code is compiled at execution time, okay there's some overhead there
as the JIT compiler processes the function. But it only performs the JIT
once. Because of the intermediate code and it's associated information used
to produce the native code, it is highly likely the JIT compiler has better
knowledge of what your code is doing than a C++ compiler. And it's entirely
possible the JIT compiler could produce better native code than a C++
compiler, leading to faster execution times.

2) Garbage Collection
Garbage collection is not a performance hindrance, it's just an environment
change. Typical game development practices attempt to reduce the number of
allocations\fre es during gameplay as much as possible. In a garbage
collected language like C# similar practices can mean no garbage is
collected, meaning no loss of performance. Of course, the language is
different and it means different rules need to be practiced during
development, but it's a different language + environment what do you expect?
:)

That being said, C++ is a preferable development language for games because:

1) Cross-platform, PC, PS3, X360, Wii, whatever, all have C++ compilers
maintained by their manufacturers. And whilst the quality of C++ compiler
can vary across platforms, they are (by and large) fairly language
compatible.
2) Inline assembly, when raw speed is necessary. The programmer can simply
drop to the machines level. Until such things as
vectors\matrice s\quaternions become intrinsic types of languages it's
unlikely C++ will be left.
3) Familiarity, just about every game developer is familiar with C++, evey
game company expects their engineers to understand C++.
4) It's unlikely every console manufacturer is going to agree on another
language all at once. Leaving C++ the only option currently.

ave

[Matthias Buelow]

None wrote:

Just wondering...

Well, since you claim to be a game developer, how about trying out other
languages (with small demo programs that test issues you are interested
in, not full-blown games, of course) and report back your findings to
this group?

[Christopher]

On Apr 22, 2:09 am, None <[e-mail] wrote:

Hi,

I am a game developer, sometimes "indy" and sometimes for a small-sized
company. I can't speak for all game developers, but everywhere I've ever
seen people working on games, execution speed has always been the most
important constraint in writing code. Writing readable and maintainable
code is important, but takes a back seat to execution speed.

I work with DirectX and/or OpenGL, always in C++. There are plenty of
things that I'd like to see improved in C++. But as far as I have seen,
C++ continues to be the workhorse of the gaming business. I've noticed, as
I was searching for examples of how to do some particular trick in D3D, a
few samples written in C#.

But what I know about C# is two things: 1) managed code, and 2) garbage
collection. These are both deal breakers for execution speed, in my
opinion. Trying to squeeze the maximum number of triangles and shaders
through the graphics pipe using code running on a virtual machine seems...
well, silly. And as for garbage collection, I've found that any serious 3D
code I've written has needed very explicit control over when things are
allocated and deleted. Rendering 3D invloves lots of very large buffers of
data, many of them changing drastically in size (meaning possible
reallocation) between every frame. Minimizing the expense of
allocation/deletion/reallocation through intelligent code is crucial.

Anyway, it just seems like C++ has been the "big hammer" for game
development for long enough that we've figured out what's good and what's
bad about it. I certainly have my own fairly long list of annoyances, but
I'm not really interested in opening that can of worms here, since it's
already been debated to death.

But I am interested in looking for alternatives. Am I wrong about C# -- is
it a viable alternative for serious programming, or is it a toy? How about
"D? "I've heard good things about it, but I don't know how widely
supported it is. Having well-supported tool chanins, libraries, IDEs,
documentation, and other resources is important.

Just wondering...

I am a hobbiest game developer as well. I do more scientific type apps
on the job. I am frustrated as heck myself. There is a feeling of
limbo right now as far as game development.

Here are my findings:

MS is doing its best to _force_ me to use C# for everything Windows
related
Almost all the new VS enhancements are centered around managed
code.
MSBuild does not work with native C++
Visual designers in VS do not work with native C++
MS's DB integration in VS is limited to managed code
Everytime I look something up in MSDN, I am plagued with
managed code examples instead of native C++
Activity on native C++ forums, for the language, for DirectX,
and otherwise has dropped substantially

I wouldn't mind switching to C# for game development, but fact is, it
is not possible right now.
The problem is that the _only_ library available for C# and DirectX is
XNA
MS admitted themselves XNA is a hobbiest tool in its current state,
has many shortcomings and is not feasable for commercial development.
Worse, MS is going down the path of charging fees for using it!
I started converting my engine to XNA and gave up as the low level
control that is needed for quality game development just isn't there
period.

I am left in Limbo. MS took out hardware excelerated OpenGL. MS's
documentation, IDE, tools, and APIs are all aimed at managed code more
so than native C++. Yet the only graphics API we are available is an
"Indie developer's toy"

So, while I would love to use C#, to make my resume look pretty, and
because development can be much more rapid, not to mention my opinion
that is forces more OO and has some features I like. I simply cannot
development any graphical app and expect any sort of quality.

I really wish MS would make an official statement on their intentions
for the future concerning game development.
I really wish MS would stop forcing things down my throat and give me
options.
I used to be one of those developers that was very pro MS, now they
are really irritating me.

My latest problem is embedding SQL Server Compact for one of my game
apps. Come to find out that if I want to use any of the tutorials or
documentation they have on it, I have to use IDE features in VS 2008,
forcing me to make a $800 upgrade! Could they just patch 2005,
nah....Try to install an old version of SQL Server? error: Your OS is
not supported.

*scream* *end rant*

[Matthias Buelow]

Christopher wrote:

My latest problem is embedding SQL Server Compact for one of my game
apps. Come to find out that if I want to use any of the tutorials or
documentation they have on it, I have to use IDE features in VS 2008,
forcing me to make a $800 upgrade! Could they just patch 2005,
nah....Try to install an old version of SQL Server? error: Your OS is
not supported.

Have you looked at SQlite3? http://www.sqlite.org/

[Christopher]

On Apr 22, 12:46 pm, Matthias Buelow <m...@incubus.d ewrote:

Christopher wrote:

My latest problem is embedding SQL Server Compact for one of my game
apps. Come to find out that if I want to use any of the tutorials or
documentation they have on it, I have to use IDE features in VS 2008,
forcing me to make a $800 upgrade! Could they just patch 2005,
nah....Try to install an old version of SQL Server? error: Your OS is
not supported.

Have you looked at SQlite3? http://www.sqlite.org/

Yes, its has limitation that won't work for the particular project.

[Your Name]

Matthias Buelow <mk*@incubus.de wrote:

Well, since you claim to be a game developer, how about trying out other
languages (with small demo programs that test issues you are interested
in, not full-blown games, of course) and report back your findings to
this group?

I don't need to "claim to be a game developer" to do that. I don't even
need to write code. Just download the latest DirectX SDK. Most (or all?)
of the samples are offered in both C++ and C#. The samples provide a
decent coverage of the basic aspects of game development.

And there's already plenty of discussion of the perfomance of C++ versus
C#. Just a taste:

http://developers.slashdot.org/artic...3/04/28/163219
&mode=thread&ti d=126&tid=127
I think that my original post was worded poorly. Basically, I'm just
wondering what's next, after C++. I use C++, I love C++, I haven't used
anything that suits game development better. But it has its limitations
and its annoyances. Like I said initially, I don't care to enumerate and
debate them. So I just thought some of the comp.lang.c++ gurus might have
some insight on the next workhorse for high performance code... And I was
secertly hoping that the answer isn't C#. :)

[Matthias Buelow]

Your Name wrote:

Basically, I'm just
wondering what's next, after C++.

I don't believe in a "now this, next that" approach to technology; use
whatever you like and is appropriate. C++ (and C) most likely have a
very long life still before them (hundreds of years?), probably Java
too, not so sure about C#. I would think that dynamic languages (new
dialects of Lisp, etc.) will see a renaissance in the medium-term
future, simply because hardware is now available to accomodate these
systems and languages like Java, Python are all moving in that direction
(especially when mixed with Javascript and XML to provide some poor
man's S-expressions), and more ambitious projects in dynamic modelling
and simulation can be attempted because of more powerful hardware and
better understood problem domains than 20 years ago. This doesn't mean
languages like C++ or C will be left out -- we will likely continue to
see a mix of languages, despite the hype gravel train that needs to move
on from station to station simply because it feeds a number of people. I
think mono-anything is always bad, and a diverse mix of languages and
methodologies is a good thing.

[Your Name]

Matthias Buelow <mk*@incubus.de wrote:

I don't believe in a "now this, next that" approach to technology; use
whatever you like and is appropriate.

[...]

I think mono-anything is always bad, and a diverse mix of languages
and methodologies is a good thing.

I know that the "big hammer" approach is not appealing from an idealistic
point of view, but unfortunately, that's just the way it is in game
development. Things just move incredibly fast. There's a new high-end 3D
card every six months. Then there's bound to be a new version of DirectX
to take advantage of the new features of the hardware. Then there are
bound to be middleware companies scrambling to create the first game engine
to take advantage of the new API. There's so much radical overturn in the
industry that SOMETHING simply must become the de facto standard. You
can't just send everyone an e-mail suggesting that we all move to a more
balanced approach. And even if you want to be a lone daredevil and defy
convention by developing your game in some new language or combination of
languages, you run the risk of being a day late with your release, and
having reviewers look at your game and say "Ewwww, those graphics look like
a game from early 2007! What a joke!"

But, progress happens. John Carmack wrote Doom in C, and it was convincing
enough to get the gaming world to part ways with assembly language. If
someone today could offer something that was absolutely 100% backwards
compatible with C++ (meaning that you could just directly plug in existing
DLLs and LIBs), but IN ADDITION provided next-generation features, then we
might get somewhere. It just seems like it's overdue, at this point.