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

  • From: "Jason Clark" <jclark@xxxxxxxx>
  • To: <gameprogrammer@xxxxxxxxxxxxx>
  • Date: Fri, 1 Apr 2005 13:47:42 -0800

This weeks Gamasutra article is awesome and just saved me tons of =
research time if anyone is interested.
http://www.gamasutra.com/features/20050324/steinmeyer_02.shtml

Jason.



> -----Original Message-----
> From: gameprogrammer-bounce@xxxxxxxxxxxxx=20
> [mailto:gameprogrammer-bounce@xxxxxxxxxxxxx] On Behalf Of brianevans
> Sent: Wednesday, March 09, 2005 9:36 AM
> To: gameprogrammer@xxxxxxxxxxxxx
> Subject: [gameprogrammer] Re: Fast development over multiple=20
> platforms, which language?
>=20
>=20
>=20
> >I am not going to argue with anyone over the difference=20
> between fashion=20
> >and habit :-). How about we call it cultural inertia? We can let the=20
> >term cover every factor from fashion to habits as well as=20
> factors like=20
> >the preponderance of books and libraries.
>=20
> Well, I know it seems piddly, but to me theres a difference=20
> between people=20
> using things because it's new and trendy and cool, and people=20
> using things=20
> because they've been using it for years and it works.
>=20
> I would argue that Java is the fashionable trendy language=20
> nowadays.  Especially in the business sector.
>=20
> But I agree to your term.  We're not really interested in=20
> sociology here,=20
> after all. :)
>=20
>=20
> >Lets face it, it is much
> >easier to find a book written about doing game programming=20
> in C++ than=20
> >in about any other language. I'm not saying the other books don't=20
> >exist. They do. But a quick look at the games section at B&N=20
> shows what=20
> >we are talking about, tons of books based on C++, nearly=20
> none on Java.
> >
> >Then there is the huge number of libraries written in C and C++ that=20
> >you can "just use" in C++. To use them in Java you have to write an=20
> >interface using JNI. Every written a JNI interface? I have, it is a=20
> >pain in the @$$. So, Java by itself has created a huge barrier to=20
> >people using it for games by making it so hard to access C/C++=20
> >libraries.
>=20
> I have yet not delved into what seems like the wonderful world of JNI=20
> interfaces.  Yes, sarcasm. :)  Whenever you get something so=20
> successful and=20
> established, so driven by cultural inertia, it becomes hard=20
> to get rid of,=20
> even in the face of superior technology. Witness: Microsoft, x86, web=20
> browsers/applications and, yes, C++.  Now, I'm not yet ready=20
> to concede=20
> that Java is superior technology.  However, Java is more=20
> modern, has a lot=20
> of attractive features, and appears to have fixed a lot of=20
> performance=20
> issues whose reputation it can't quite shake loose.  In C++'s=20
> defense (or=20
> not), the language has stagnated.  Maybe the people in charge=20
> of the C++=20
> standards are to blame, I don't know.  Why they haven't integrated=20
> something like Boost into the standard when C++ desperately=20
> needs a library=20
> like Boost is beyond me.  Perhaps 'D' is the next step for C++:=20
> http://www.digitalmars.com/d/overview.html   But new=20
> languages mean doing=20
> everything over again.
>=20
> > > It was not that long ago that we had sub Ghz processors
> > > and memory was expensive, compared to now.  On Win95/98=20
> era hardware=20
> > > (100-500 Mhz machines, 64-128MB ram), the only choice that made=20
> > > sense for serious games was C/C++.  Java has just=20
> recently (2001+ at=20
> > > least ;) ) become viable for games, IMO, because the JVM's have=20
> > > gotten better, and/or the increase in hardware performance and=20
> > > available memory hides the performance hit.  I would not have=20
> > > 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=20
> trying to=20
> >do serious games in Java as early as 1996. But, that was=20
> mostly for the=20
> >server side on networked games. Even back then a Java server=20
> running on=20
> >a 100Mhz Pentium could saturate a T1.
> >
> > > I'm not talking about mobile games.  Any mobile class=20
> game will get
> > laughed
> > > out of the serious PC game arena.
> >
> >Ok, I think we need to define what you mean by "serious=20
> game" because I=20
> >take any game that generates revenue seriously. :-) What do=20
> you mean by=20
> >the phrase?
>=20
> That's a fair point.  If a game makes money, certainly it=20
> should be taken=20
> seriously.  However, the level of expectations for a phone game, when=20
> compared to a PC game, is vastly different.  It's akin to comparing a=20
> gameboy game to a gamecube one, except more exaggerated.
>=20
> But I didn't mean just any PC game that makes money.  I meant the=20
> commercial games that all the gamers get excited about, and sorry, I=20
> haven't heard a gamer rant about the greatness of bejeweled=20
> lately. :)  You=20
> know the ones that push the technological edge like Rome=20
> Total War, Doom 3=20
> and Half Life 2.  The ones that independent developers like=20
> us have no hope=20
> whatsoever of developing. :P
>=20
> The point is well taken.  I would probably be happy with=20
> writing a game=20
> that made money, but I wouldn't be satisfied.  I think I=20
> would have to=20
> write a game that I and others would want to play that did at=20
> least one=20
> thing in a fairly novel way to be truly satisfied.  Oh yes,=20
> money would be=20
> nice too. :)
>=20
>=20
> >More examples of cultural inertia.
> >
> >Yep. No question.
> >
> >Define "memory efficiency". Do you mean total memory used? Or do you=20
> >mean time spent managing memory? Or, do you mean (ok, I know=20
> you don't
> >mean) programmer time spent on memory management.
>=20
> I can tell I need to be careful here. :)  I meant memory size=20
> efficiency,=20
> but its not really just size, more along the lines of only=20
> using the memory=20
> I have to at a certain time to perform a task.    Java does=20
> have the memory=20
> size overhead of the JVM, and as you said they trade size for=20
> performance.  I did not mean programmer time spent on memory=20
> management,=20
> unless that programmer was going for a real time java app. :)
>=20
> >Yep, most programmers do not know who to program using a garbage=20
> >collector. Even in Java you can statically allocate variables, even=20
> >string buffers, so that the GC *never* gets invoked and you=20
> never get a=20
> >GC hiccup. If you must dynamically allocate memory you can do thing=20
> >like calling the GC explicitly at reasonable times to=20
> collect garbage=20
> >before it causes a GC stall. The fact that Java is noted for=20
> GC stalls=20
> >tells you something about the lousy job they have done on=20
> the storage=20
> >allocation system. :-(
>=20
> I confess I don't know all the tricks to avoid GC hiccups, I=20
> just know some=20
> exist.  Sometimes its nice to be able to explicitly allocate=20
> and deallocate=20
> memory.  That hybrid system listed in 'D' sounds intriguing,=20
> maybe optimal.=20
> I wonder why java didn't let you override.  I guess they were=20
> afraid of=20
> giving programmers a hand grenade because they might blow=20
> themselves up=20
> with it.  Sometimes you need a hand grenade though.
>=20
> >I have in fact written simple games and a real time telephone link=20
> >using Java and did not *ever* have a pause due to the GC.=20
> But, then, I=20
> >*do* know how to program using a GC.
>=20
> It's nice to know its possible. :)  I just wish you didn't=20
> have to rely on=20
> certain restrictions to do it.
>=20
>=20
> >It is interesting to look at languages like Perl and Python=20
> that both=20
> >have garbage collection and do not suffer from GC stalls (at=20
> least not=20
> >that you would notice) To the best of my knowledge those=20
> languages use=20
> >reference counting storage allocators. A lot of C++ programs=20
> also use=20
> >reference counters through a smart pointer type. Reference counting=20
> >allocators use much more of the total runtime than garbage=20
> collecting=20
> >allocators do. But, they spread it out over time so you don't notice=20
> >it.
> > >From a total run time point of view reference counting is=20
> 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=20
> byte code=20
> >and interpreted.
>=20
> I like Perl and its mutant cousin PHP.  I have yet to program=20
> in Python,=20
> but I know people swear by it.  I saw some benchmarks that=20
> had Perl an=20
> order of magnitude or two behind both C++ and Java (1000=20
> seconds vs 10=20
> seconds).    Which, if they are to be believed, shows that I=20
> was wrong=20
> about Java being interpreted class, and that Java is a lot=20
> faster than true=20
> interpreted languages.
>=20
> I would guess its a response time thing.  Most people don't=20
> care of things=20
> take a little while longer, as long as the app doesn't freeze=20
> and hang up a=20
> "out gathering twigs and memory" sign on the front window.
>=20
> >If you write Java code that dynamically allocates lots of=20
> memory and do=20
> >not control the operation of the GC you will still run into=20
> GC stalls.=20
> >The size of the memory tends to make the initial stall even=20
> longer than=20
> >before.
>=20
> Hopefully the size of the memory would allow you to avoid=20
> doing that while=20
> actually in a game, or at the least hold off until between levels.
>=20
> >This is very rare these days and any such code would be put in a=20
> >library and accessed through JNI. Which is, for example, exactly how=20
> >the SIMD blit code in SDL is accessed from Java.
>=20
> Yes, you're right.  The JNI stuff actually sounds cool, in=20
> that its cool=20
> that java can actually call C++ libs.  But its not java=20
> that's doing the=20
> low level stuff.  Then again if you're writing ASM its not=20
> really C/C++ either.
>=20
> >Ok, this statement doesn't have any meaning. It is an appeal to an=20
> >authority based on a personal opinion. An argument cannot be=20
> based on a=20
> >personal opinion of what someone else may or may not do. Unless, of=20
> >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=20
> >building spaceships and will do what ever he needs to to get=20
> the cash=20
> >he needs to build spaceships, including writing video games.=20
> Of course,=20
> >that is only my opinion.
>=20
> It's a valid opinion.  I think he's bored with programming=20
> games (arguably,=20
> game engines).  I wasn't appealing to Carmack on an authority=20
> basis, but=20
> more on a personality basis.  He's the type of programmer who=20
> will go low=20
> level, or tweak things to push the edge.  Java just isn't the=20
> language for=20
> him.  And I'm flattered, but no I'm not Carmack. :P  But I=20
> did read a book=20
> about him (Masters of Doom) and id, so I'd say I'd have some=20
> basis for=20
> knowing something about his personality.  But you're right,=20
> it doesn't mean=20
> anything more than what I think Carmack would not do, given=20
> the facts I=20
> know about him.  I do doubt that you could write Doom3 in=20
> Java right now,=20
> as it runs pretty slow as it is on current hardware.  But=20
> maybe that's just=20
> my "Java is slow" prejudice getting in the way again.
>=20
> > > Maybe you will do something that requires
> > > hand-optimized Assembly loops?
> >
> >Separate file, JNI interface. Of course, as I said before, JNI is a=20
> >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=20
> matters. =20
> > > If you were writing Quake 2 in 1997, you had to pick=20
> C/C++.  If you=20
> > > were writing Quake 2 now, maybe you could use Java.  If you were=20
> > > writing Doom 3 now,
> > I'd
> > > think you'd have to use C/C++.  But for most of the games=20
> most of us=20
> > > can make right now, it really doesn't matter, though its=20
> nice not to=20
> > > have to worry about a JVM being installed.  But then=20
> again, it would=20
> > > be nice
> > not to
> > > worry about memory leaks.  Ahhh, tradeoffs.
> >
> >Exactly!
>=20
> Finally!  More like it. Hehe.
>=20
> We probably will see a trend reversal soon.  CS students at=20
> UT these days=20
> get Java as their entry language (which really sucks as the=20
> intro level CS=20
> class they made me take, after I had already taken the entry=20
> level C++=20
> class, was HASKELL taught by a HASKELL ZEALOT!).  Anyway,=20
> they get out=20
> thinking that Java is the best language ever.  And it IS=20
> trendy, especially=20
> in the business sector.
>=20
> So maybe fashion has more to do with it than I originally=20
> thought.  Fashion=20
> gets the cultural inertia ball rolling, and habit keeps it bouncing=20
> along.  It will probably start with the Java phone games and=20
> then trickle=20
> upwards into PCs.
>=20
> >But it is so much fun!
>=20
> And educational to be sure.  But its a lot of time spent=20
> developing the=20
> tool to make your game, when you could just buy the tool and have fun=20
> modifying the tool to make your game. Most independent devs=20
> frankly won't=20
> have the time or ability to write a full featured engine that=20
> can handle=20
> complicated games.  I know I don't at the moment.
>=20
> > >
> > > Geez, I write too much.
> > >
> >
> >We both suffer from that disease :-). I think this is a good=20
> discussion=20
> >though.
>=20
> I hope so.  Tell you what though, I'm running out of steam. =20
> You got me=20
> saying that Java is not as slow as I thought it was and is a=20
> valid choice=20
> for games.  I really don't see it being used for AAA=20
> commercial cutting=20
> edge games in the short term, but it is wrong to simply write=20
> it off for=20
> every game idea since it will be a valid choice for most of them.
>=20
> So I would say I learned quite a bit. :) (phew.)
>=20
> brian.
>=20
>=20
> > > brian.
> > >
> >
> >                 Bob Pendleton
> > >
> > >
> > > ---------------------
> > > To unsubscribe go to http://gameprogrammer.com/mailinglist.html
> > >
> > >
> > >
> >
> >
> >
> >---------------------
> >To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>=20
>=20
>=20
> ---------------------
> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>=20
>=20
>=20
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.857 / Virus Database: 584 - Release Date: 2/10/2005
> =20
>=20
> --=20
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.9.0 - Release Date: 3/31/2005
> =20
>=20

--=20
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.0 - Release Date: 3/31/2005
=20


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


Other related posts: