C++ sucks for games

[Vladimir Sedach]

Bullshit. Vague bullshit.

By any reasonable standards, C++'s type system is a brain-damaged
throwback to the 1960s. Much better static type systems can be found
in languages like Haskell and ML. Hell, there's even an assembler with
a better type system:
http://www.cs.cornell.edu/talc/

"function objects". Get over it! It's just syntatic sugar!

Yeah, and with just a bit more typing, you've got yourself a Turing
machine. You can do anything you want in C++, so why would you ever
want to switch to a better language?

"procedures"? Never heard of them. I've heard of "functions" alright. I must
say I don't... see... your argument, no pun intended.

Where do you think the word "function" comes from? It comes from
mathematics, where it has a very well-defined meaning and certain very
well defined properties. One of these properties is that for any
input, it always returns the same output. This particular meaning has
been universally adopted by the computer science community. In almost
all languages (Miranda and Haskell are the only two exceptions I
know), what you call "functions" are actually procedures or
subroutines, in that they can return different outputs for the same
input. This includes pseudo "functional" languages like ML too, since
it has assignment, references and mutable arrays.

Vladimir

 

[WTH]

<snip crap>

LOL, you're hilarious. Stop researching and write a game, then tell us what
you should write it in.

WTH

 

[Petter Gustad]

And MS-DOS was first written in the early 80's.

That was my point...

Petter

 

[Espen Vestre]

That was my point...

I don't know what Tim Paterson used when he wrote the original QDOS in
6 weeks in 1980, but I very much doubt that it was C, which I think
was still a rather experimental thing used by strange cult of unixists
at that point.

 

[Espen Vestre]

That was my point...

I don't know what Tim Paterson used when he wrote the original QDOS in
6 weeks in 1980, but I very much doubt that it was C, which I think
was still a rather experimental thing used by the strange cult of
unixists at that time.

 

[Gerry Quinn]

Hey

Recently, I researched using C++ for game programming and here is what
I found:

[snip]

What is it about Lisp that makes novices fall in love with it? They
don't actually *produce* anything with it, mind you, but they insist on
telling the world how superior it is to every other language.

Dude, write a good game in Lisp and that will impress us a lot more than
a load of blather about how C++ is unsuitable for game programming. The
thing is, we use C++ for game programming, so we know whether it is
suitable or not. We've even seen a few games in our time that are
written in Java, Delphi, Flash or VB. But from the Lispers, all we see
is the same old hot air...

- Gerry Quinn

 

[Maahes]

hmm. I remember vividly doing lisp at uni.

Post the C version (or just give a fuller spec) and I'll try it in Lisp.

It was 15 years ago so I only have the vague memories and impressions
left...

I wonder which Lisp you were using. The modern Common Lisp has all kinds
of ways to iterate, some simple, some complex, and one (LOOP) which is
effectively a built-in iteration mini-language. So no one is forced to
do recursion, and many Lispniks frown on it style-wise if an iterative
approach would work.

Well, sounds like its probably very different to the lisp we used 15 years
go. All we could seem to do is have lots of brackets with calls to functions
embedded..

2*(5+Speed)+Velocity

looked something like:

(+ (* 2 (5 Speed +)) Velocity)

 

[Maahes]

Didn't we switch from coal to oil yyeeaarrss ago?

Most powerplants run on Coal still (and some crazy countries use Nuclear).
I think oil is just used for cars and trucks and gays.

 

[Paul F. Dietz]

Most powerplants run on Coal still (and some crazy countries use Nuclear).
I think oil is just used for cars and trucks and gays.

Many run on natural gas.

Note followup.

Paul

 

[Maahes]

Read all that. Understand your gripes, but that's not C++, that's how you
use it.
We've done 8 projects in C++ and never had a failure. And that's on
cross-platform consoles (Gamecube, ps2, xbox, pc) where you cannot have a
crash or significant bug or you can't release the game.

If anyone else has failures, I doubt its because of C++. I have noticed
that some C++ coders have the worst habits of overcomplicating simple
problems that I've ever seen. Again, not C++'s fault, though templates,
references, constructors and inheritance makes it easy to write code that is
unreadable without a debugger.

To stop from failures, we restrict usage of C++ to as simple as possible. We
have our own memory management systems that are far better than garbage
collectors because they don't fragment memory at all, which is critical on a
console because you can't afford to run out of memory due to unforseen
fragmentation.

 

[Alex Drummond]

Well, sounds like its probably very different to the lisp we used 15 years

go. All we could seem to do is have lots of brackets with calls to
functions embedded..

2*(5+Speed)+Velocity

looked something like:

(+ (* 2 (5 Speed +)) Velocity)

Not really any different, that's just the basic syntax of Lisp. Even mini
languages like the loop macro are called the same way:

(loop for i from 0 to 10 collect i) ; Create a list of numbers from 0 to 10.

As are the less exotic macros:

(let ((lst 0))
(dotimes (i 11)
(push i lst))
(reverse lst)) ; Create a list of numbers from 1 to 10.

(Not intended to be sensible examples, Lisp gurus...) This syntax does not
in any way prevent you from doing long division Sounds like you were
probably just not /taught/ the imperative features of Lisp, and got the
erroneous impression that it was all lists and recursive functions. Lisp
doesn't force you to use recursion any more than C++ does.

Alex

 

[Jorge Tavares]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Gerry Quinn wrote:
|
| What is it about Lisp that makes novices fall in love with it? They
| don't actually *produce* anything with it, mind you, but they insist on
| telling the world how superior it is to every other language.
|
| Dude, write a good game in Lisp and that will impress us a lot more than
| a load of blather about how C++ is unsuitable for game programming. The
| thing is, we use C++ for game programming, so we know whether it is
| suitable or not. We've even seen a few games in our time that are
| written in Java, Delphi, Flash or VB. But from the Lispers, all we see
| is the same old hot air...

Please see:

for games written with Lisp,
http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml

what is it about Lisp,
http://alu.cliki.net/RtL Highlight Film


Regards,
Jorge Tavares


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBfkqNKHEUoQoCFcIRAkTtAJ0R1RxJ3EQB6VKy4TCC3foNCNa4jwCeKwup
UWXzHD90kcK+pL6984OEZMk=
=IVnR
-----END PGP SIGNATURE-----

 

[Svein Ove Aas]

We have our own memory management systems that are far better than garbage
collectors because they don't fragment memory at all, which is critical on
a console because you can't afford to run out of memory due to unforseen
fragmentation.

I'll have to address this.

While I understand that you don't want to use GC on a console, where you
presumably want every scrap of performance you could possibly get, it isn't
true that GC fragments memory.

There is an entire class of copying collectors that, as a neccessary
consequence of copying, defragment memory on the fly. You don't need to
lose half your memory to the GC, either; while it's true that you can only
use N-1 segments of memory for actual data, N need not be 2.

Of course, if N *isn't* 2 then you need to combine the copying collector
with something like a mark-and-sweep collector, which is probably slow.


I'm mostly interested in this from the viewpoint of OS design, where the
slow collector can be run in the idle loop while a fast generational
collector takes care of low-memory situations if they should occur, so this
probably doesn't apply to your situation.

That said, there's nothing fundamental preventing you from doing your own
memory management (Arena allocation, say) in Lisp - you just need a Lisp
version that has a lot more GC/memory-controlling declarations than current
editions do. See Barking Dog.

End note:
GC-ed applications are probably no more a victim of fragmentation than
applications using malloc/free, and can be far less so.
You don't use malloc/free very much on a console, though, do you?

 

[Svein Ove Aas]

We have our own memory management systems that are far better than garbage
collectors because they don't fragment memory at all, which is critical on
a console because you can't afford to run out of memory due to unforseen
fragmentation.

I'll have to address this.

While I understand that you don't want to use GC on a console, where you
presumably want every scrap of performance you could possibly get, it isn't
true that GC fragments memory.

There is an entire class of copying collectors that, as a neccessary
consequence of copying, defragment memory on the fly. You don't need to
lose half your memory to the GC, either; while it's true that you can only
use N-1 segments of memory for actual data, N need not be 2.

Of course, if N *isn't* 2 then you need to combine the copying collector
with something like a mark-and-sweep collector, which is probably slow.


I'm mostly interested in this from the viewpoint of OS design, where the
slow collector can be run in the idle loop while a fast generational
collector takes care of low-memory situations if they should occur, so this
probably doesn't apply to your situation.

That said, there's nothing fundamental preventing you from doing your own
memory management (Arena allocation, say) in Lisp - you just need a Lisp
version that has a lot more GC/memory-controlling declarations than current
editions do. See Naughty Dog.

End note:
GC-ed applications are probably no more a victim of fragmentation than
applications using malloc/free, and can be far less so.
You don't use malloc/free very much on a console, though, do you?

 

[Kenny Tilton]

It was 15 years ago so I only have the vague memories and impressions
left...

Well I saw "newbie would do in C without breaking a sweat" so I thought
you could just toss off the solution in your mail editor.

What is the idea? Write an algorithm that works the way we work when we
do long division, complete with remainders? How do you want the answer?
Just the integer result and remainder as, in C, a second result returned
in a writable parameter?

Well, sounds like its probably very different to the lisp we used 15 years
go. All we could seem to do is have lots of brackets with calls to functions
embedded..

2*(5+Speed)+Velocity

looked something like:

(+ (* 2 (5 Speed +)) Velocity)

You mean (+ 5 Speed), of course. And I guess that is just a made-up
example, because I do not recognize the physics.

How about S = 1/2at^2 + vi*t?

(defun distance (accel time initial-velocity)
(+ (* initial-velocity time)
(/ (* accel (expt time 2)) 2)))

Note that I just typed that in and may have unbalanced parens (or other
gaffes), but when writing Lisp my editor helps me with parens so much
that I never think about them (and did not after the first month of Lisp).

And one of the biggest ways the editor helps is by /automatically/
indenting expressions based on how I have nested my expressions. So if I
get careless, I hit carriage return and the autoindentation goes
someplace conspicuously whacky. But maybe the bigger win here is during
refactoring, where I can totally trash the indentation of a fat 50-line
function and re-indent the whole thing in one command.

I know VC6 handles auto-indenting nicely, too. I never tried it on a
large region of refactored code, but I imagine it handles that, too. My
point is that "lots of brackets" is not a minus for Lisp. In fact, it is
a plus because my editor also lets me select, copy, cut, and paste any
balanced chunk of code, so I now edit code, not text (if you get my drift).

As for the prefix notation, well, you /are/ used to that!:

finalStep( preCalc1( deeperCalc( x, y), deeperCalc2( y, z)));

Lisp is just being consistent in its syntax, which pays off big time in
higher-order programming (especially procedural macros).

kenny

 

[Gerry Quinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Gerry Quinn wrote:
|
| What is it about Lisp that makes novices fall in love with it? They
| don't actually *produce* anything with it, mind you, but they insist on
| telling the world how superior it is to every other language.
|
| Dude, write a good game in Lisp and that will impress us a lot more than
| a load of blather about how C++ is unsuitable for game programming. The
| thing is, we use C++ for game programming, so we know whether it is
| suitable or not. We've even seen a few games in our time that are
| written in Java, Delphi, Flash or VB. But from the Lispers, all we see
| is the same old hot air...

Please see:

for games written with Lisp,
http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml

Yes, one team wrote parts of some of their games in Lisp, and that one
example has been trumpeted to the rooftops ever since. Read their
'post-mortem' on Gamasutra and you'll find that the benefits were far
more ambiguous than you would think to listen to the Lisp boosters. To
put it briefly, it featured strongly in both the "what went right" and
"what went wrong" sections.

what is it about Lisp,
http://alu.cliki.net/RtL Highlight Film

That's more an example of what I'm saying than a refutation of it. Lots
of gushing about Lisp, but hardly a mention of any shipped projects...

- Gerry Quinn

 

[Hannah Schroeter]

Hello!

As other industries using C++ - even for highly graphical, rich-content
physics simulations - report fewer of these problems, the game programming
culture itself might be to blame.

We have had enough memory management issues (both leaks as well as
corruption by access-after-free/delete) in our company.

They still want us to use C++, w/o gc. :-(

Of course they diminish by using "smart pointers" and similar devices,
but the performance advantages of C++ diminish alongside.

[...]

The static type system locks you into a certain design, and you can't
*test* new ideas, when they come to you, without redesigning your
whole class hierarchy.

Then don't use the static type system.

You won't really recommend C/C++ programmers to cast everything to
void*?

[...]

C++ programs can not "think" of new code at run-time, and plug that
new code into themselves in compiled form. Not easily, anyway.

So, uh, use the scripting layer?

Which is usually less efficient than calling (funcall (compile nil ...))
in Lisp (or even storing the result of (compile nil ...) into some
data structure and using it over and over).

[...]

Kind regards,

Hannah.

 

[Kenny Tilton]

Hey

Recently, I researched using C++ for game programming and here is what
I found:

[snip]

What is it about Lisp that makes novices fall in love with it?

Try it and see. I came to Lisp rather late (age 44, after 17 years of
programming, the prior eight years in C at home and Vax Basic/Cobol in
tall buildings) and it was a revelation. No pointers, no manual memory
management, no syntax, interactive -- basically, all the crap was gone
and nothing but the fun of programming was left.

They

don't actually *produce* anything with it, mind you,...

You are right! This is because Lisp is usually discovered as a hobby
language, since almost no one uses it at work.

I was a kitchen-table developer looking for a better way to develop the
next generation of a line of educational software done originally in C,
so I ended up Actually Using(tm) Lisp. It scales nicely to the real
world, and as you might imagine with anything powerful, the bigger the
task the bigger the payoff.

Then a friend asked me to do a rather huge business app (clinical drug
trial management). The kind big companies spend $100m on. We produced
something vastky better than the current state of the art on $1m. Screen
shots (which give zero idea of the underlying complexity of the problem)
are here (starting after "win32 gui samples"):

http://www.tilton-technology.com/cellophane-precursor.html


but they insist on

telling the world how superior it is to every other language.

yeah, but this is as much an act of charity to fellow programmers stuck
dancing to the tune of Java and C/C++ compilers as it is an act of
obnoxiousness.

Dude, write a good game in Lisp...

He cannot write a game until I finish my groovy (+ Lisp OpenGL
constraints physics-engine) development system:

http://www.tilton-technology.com/cellophane.html

I developed the Light Panel just to help me figure out what various
OpenGL parameters actually did. 3d rocks! I have now incorporated OpenAL
as well.

kenny

 

[Phlip]

Of course they diminish by using "smart pointers" and similar devices,

You won't really recommend C/C++ programmers to cast everything to
void*?

Hmmm. Smart pointers and void pointers. Where have I heard of these before,
to give C++ dynamic typing? Hmmm...

Which is usually less efficient than calling (funcall (compile nil ...))
in Lisp (or even storing the result of (compile nil ...) into some
data structure and using it over and over).

All big applications need a scripting layer, an efficient engine layer, and
back-end layers in assembler. There is no /a-priori/ way to guess where the
cutoff between them is, or what language to use in the scripting layer.

<a beat>

;-)

 

[Hannah Schroeter]

Hello!

Hannah Schroeter wrote:

Hmmm. Smart pointers and void pointers. Where have I heard of these before,
to give C++ dynamic typing? Hmmm...

Would only work if you "reparent" everything (except most basic
types) to a class Object, so you can have shared_ptr<Object> everywhere.
(with void*, the deletion after the last reference drops might not
call the needed destructors).

Yeah. Cool.

Especially as you then have to build wrappers around any standard
library class you might use "dynamically", kinda like

class String : public std::string, public Object {
};

All big applications need a scripting layer, an efficient engine layer, and
back-end layers in assembler. There is no /a-priori/ way to guess where the
cutoff between them is, or what language to use in the scripting layer.

But... There are a few choices where the scripting layer could be
just the same as the engine implementation layer.

<a beat>

;-)

Kind regards,

Hannah.