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