[gameprogrammer] Re: Fast development over multiple platforms, which language?

  • From: Bob Pendleton <bob@xxxxxxxxxxxxx>
  • To: Gameprogrammer Mailing List <gameprogrammer@xxxxxxxxxxxxx>
  • Date: Tue, 08 Mar 2005 13:30:42 -0600

On Tue, 2005-03-08 at 12:01 -0600, brianevans wrote:
> >Cause all the game programmers learned C++ in school and when people
> >asked them what language they used they said C++ and so all the people
> >who wanted to be game programmers learned C++. Nothing to do with the
> >language, every thing to do with fashion.
> 
> 
> Hey Bob,
> 
>    I'm not sure I believe that is only because of fashion.  It may be more 
> to do with habit.  

I am not going to argue with anyone over the difference between fashion
and habit :-). How about we call it cultural inertia? We can let the
term cover every factor from fashion to habits as well as factors like
the preponderance of books and libraries. Lets face it, it is much
easier to find a book written about doing game programming in C++ than
in about any other language. I'm not saying the other books don't exist.
They do. But a quick look at the games section at B&N shows what we are
talking about, tons of books based on C++, nearly none on Java.

Then there is the huge number of libraries written in C and C++ that you
can "just use" in C++. To use them in Java you have to write an
interface using JNI. Every written a JNI interface? I have, it is a pain
in the @$$. So, Java by itself has created a huge barrier to people
using it for games by making it so hard to access C/C++ libraries. 

> It was not that long ago that we had sub Ghz processors 
> and memory was expensive, compared to now.  On Win95/98 era hardware 
> (100-500 Mhz machines, 64-128MB ram), the only choice that made sense for 
> serious games was C/C++.  Java has just recently (2001+ at least ;) ) 
> become viable for games, IMO, because the JVM's have gotten better, and/or 
> the increase in hardware performance and available memory hides the 
> performance hit.  I would not have considered it viable for any but the 
> most basic of games in 2001.

Can't disagree with you on that. 'though, I know people were trying to
do serious games in Java as early as 1996. But, that was mostly for the
server side on networked games. Even back then a Java server running on
a 100Mhz Pentium could saturate a T1.

> I'm not talking about mobile games.  Any mobile class game will get laughed 
> out of the serious PC game arena.

Ok, I think we need to define what you mean by "serious game" because I
take any game that generates revenue seriously. :-) What do you mean by
the phrase?

> 
> Anyway, that kind of history will lead to reputation and prejudice.  Its no 
> wonder people automatically think C/C++ when considering serious game 
> programming.  

More examples of cultural inertia. 

> And I think when you really get down to it, it is about control.

Yep. No question.

> 
> Correct me if I'm wrong, but given the higher degree of control over memory 
> in C/C++ it is possible to program with greater memory efficiency than 
> Java.  

Define "memory efficiency". Do you mean total memory used? Or do you
mean time spent managing memory? Or, do you mean (ok, I know you don't
mean) programmer time spent on memory management.

> It is also possible to create memory leaks, but if you only have 64 
> megs of memory to use, memory efficiency is important.  Controlling when to 
> deallocate memory is important in games (and real time apps especially) so 
> you don't get hiccups or long pauses while the garbage collector goes to 
> work.  

Yep, most programmers do not know who to program using a garbage
collector. Even in Java you can statically allocate variables, even
string buffers, so that the GC *never* gets invoked and you never get a
GC hiccup. If you must dynamically allocate memory you can do thing like
calling the GC explicitly at reasonable times to collect garbage before
it causes a GC stall. The fact that Java is noted for GC stalls tells
you something about the lousy job they have done on the storage
allocation system. :-(

I have in fact written simple games and a real time telephone link using
Java and did not *ever* have a pause due to the GC. But, then, I *do*
know how to program using a GC.

It is interesting to look at languages like Perl and Python that both
have garbage collection and do not suffer from GC stalls (at least not
that you would notice) To the best of my knowledge those languages use
reference counting storage allocators. A lot of C++ programs also use
reference counters through a smart pointer type. Reference counting
allocators use much more of the total runtime than garbage collecting
allocators do. But, they spread it out over time so you don't notice it.
>From a total run time point of view reference counting is a horrible
thing, but from a psychological point of view, it wins every time.

BTW, both Python and Perl are also compiled some version of byte code
and interpreted.

> Last time I used Java, that was a problem.  Now, with machines 
> getting a 512-1024 megs of memory, it may not be.

If you write Java code that dynamically allocates lots of memory and do
not control the operation of the GC you will still run into GC stalls.
The size of the memory tends to make the initial stall even longer than
before.

> 
> Java also will not give you the control down to the metal.  Some people who 
> really push the edge may require that.  

This is very rare these days and any such code would be put in a library
and accessed through JNI. Which is, for example, exactly how the SIMD
blit code in SDL is accessed from Java.

> I very much doubt Carmack will ever write a engine in Java.  

Ok, this statement doesn't have any meaning. It is an appeal to an
authority based on a personal opinion. An argument cannot be based on a
personal opinion of what someone else may or may not do. Unless, of
course, you are actually Carmack masquerading as Brian.

Thought I would just point that out.

BTW, my personal opinion is that Carmack wants to spend his time
building spaceships and will do what ever he needs to to get the cash he
needs to build spaceships, including writing video games. Of course,
that is only my opinion. 

> Maybe you will do something that requires 
> hand-optimized Assembly loops?  

Separate file, JNI interface. Of course, as I said before, JNI is a
PITA.

> Maybe the JVM can optimize it enough for 
> you?  Granted, most of us will probably never need that control.
> 
> If you're writing a Bejeweled clone, I doubt any of this matters.  If you 
> were writing Quake 2 in 1997, you had to pick C/C++.  If you were writing 
> Quake 2 now, maybe you could use Java.  If you were writing Doom 3 now, I'd 
> think you'd have to use C/C++.  But for most of the games most of us can 
> make right now, it really doesn't matter, though its nice not to have to 
> worry about a JVM being installed.  But then again, it would be nice not to 
> worry about memory leaks.  Ahhh, tradeoffs.

Exactly!

> 
> But, ahem, back on topic.  There's so many ENGINES out there that really 
> the discussion should be on what engine to use for rapid development rather 
> than what language to develop a engine in, or what language a particular 
> engine is written in.  Developing an engine yourself is not rapid game 
> development. :)

But it is so much fun!

> 
> Geez, I write too much.
> 

We both suffer from that disease :-). I think this is a good discussion
though. 

> brian.
> 

                Bob Pendleton
> 
> 
> ---------------------
> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
> 
> 
> 



---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html

Other related posts:

  1. Home
  2. gameprogrammer
  3. Archive
  4. 03-2005