How The Game Is Played

Some Netbeans notes

Okay,

As some of you may have noticed, I'm not a big "its Sun's thing so its gotta be better" type person.

I personally think that kind of attitude cheapens the work of the teams who really have made stellar products. Two of those I can think of off hand are our Hotspot JVM team, who did what the world said was impossible and delivered a Java that runs at C++ speeds, and our Solaris folks who continue to turn out what I honestly think is the best Unix in the world.

Netbeans, I am sorry to say, has not fallen into that category in my rankings for awhile. In the beginning, it was somewhat hard to learm to use but generally matched up or exceeded other similar IDEs on a feature by feature basis. Unfortunately, for my tastes it started falling behind badly around the JBuilder8 time frame.

I'm back to using Netbeans again, though, and although it still has some issues, I'm pleased to say that at this point I think it has some real virtues to recommend it again.

First off, its speed on my hardware at least is excellent. They've really done wonders with start-up time. I run with a lot of modules plugged in-- almost all that are available-- and still don't notice an objectionable start-up. Similarly I rarely find msyelf feeling like I'm waiting on the interface to catch up with me.

Secondly, it has a dynamite free profiler. No serious Java programmer should code without a profiler handy and up til now you had two choices: buy an excellent but expensive profiler such as OptimizeIt (now part of Borland's tool suite), or use ugly, nasty and difficult free options.

Those days are over. The Netbeans profiler is awesome. I was a big OptimizeIt fan but the profiler does nearly everything OptimizeIt did for me (and they tell me the important missing features are coming soon) and many tricks OptimizeIt couldn't do. Its best trick is that it runs the code at reasonable speeds. Yes there is some hit, but nowhere near what I was used to under OptimizeIt.

Frankly, the profiler alone is enough to make me switch. Another feature that is dynamite, however, is the collaboration feature. I do a lot of remote work. Netbeans' collaboration stuff and the free share.java.net collaboration server allow me to work comfortably with remote teammates. It really is remarkable and if you haven't tried it I highly recommend it. My only gripe is that I have to keep a seperate AIM client running to talk to my AIM equipped colleuges. If they could get AIM support into this beast it would be nigh unto the perfect remote work tool.

Now this isn't to say Netbeans doesnt still have places it can improve. The UI is still fairly obtuse. You can do almost anything I can think of at this point but where you go to do it is not always real obvious. Thank god for the searchable online help, which seems pretty complete.

The biggest issue for me though is the "computer aided engineering" support. It's still a lot more primitve then JBuilder or Eclipse. Those two come close to each other though Eclispe pulls ahead as the master here. This is really a whole set of related features that can be categorized under the general title of "syntax oriented editing."

It wold take more time then I want to take here to lay it all out, but the short hand is that Eclispe has finally gotten computer-aided code creation right. The end result is much like having a full time extreme programming partner over your shoulder 24x7. It catches your errors or omissions as you write code, and suggests and inserts corrections on the fly (even inobvious ones like fixing the spelling of a mis-typed symbol.) If the Netbeans guys really want to have the ultimate tool, they need to swollow their pride and do some coding with Eclipse just to see what it does.

In the mean-time, they've seduced me away from Eclipse with their profiler. The CAE stuff makes me more productive, but a Profiler is a necessary tool. But if they can also immitate those CAE features of Eclipse, I'll be a 100% Netbeans supporter!

Posted at 01:04AM Jul 19, 2005 by gameguy in Java  |  Comments[1]

JNWN Update

Well, guys.

Its been awhile so I thought I might update you on the latest on my pet project JNWN.

JWNW, for those of you not following it, is Java3D based Open Source OLRPG client that reads and uses data from NWN and the fantastic NWN Aurora Toolset.

I love the Aurora Tools, even though they are Windows specific. What I dont love is their sever. The server is very limited and chokes on more then about 12 players in world. It also runs scripts written in their god-awful subset of C they call NWN C. NWN C is slow, nasty and the APIs are horribly incomplete. I'd much rather write code in Java.

So I decided that I wanted to re-write the server as a Sun Game Server project But to do that I needed to be able to talk to the client. As their client protocol was closed and encrypted, this meant writing a new client. The good news is that this effort is opening up the client to all kinds of extensions that wouldn't have been possible had I used theirs.

But enough of the background, the status report.

I just got paletted textures working and put back in the resource manager code base. This is how NWN does colorable obejcts such as characters, armor and clothing. I'm now working on integrating this into my game engine so that 3D objects' colors can be changed on the fly.

Speaking of the engine itself, Ive taken a first past at integrating some collision code and simple physics from Shawn Kendall. I'm having some trouble with it but hes nicely offerred to look at my bugs for me and help me figure them out.

I started looking at shadows but Im delaying a decision there. The ways I'd really like to try to do shadows, which are GPU tricks and use very little processor, aren't possible on Java3D today because they require multi-pass rendering. Thats something that the Java3D group have on their list to start working on soon but it may be awhile til I have even a Sun internal Java3D version I can play with that will do that.

They did add limited stencil buffer support for 1.5 and I took a long look at doing stencil shadows (also called "shadow volumes"). My biggest issue here is that I'm nervous about the CPU hit. Its not bad for fixed light sources and fixed objets, but every time an object moves or changes its shape you need to recalculate the shadow volumes for it. Worse, every time a light moves you need to recalculate ALL the shadow volumes for that light.

I want to do a lot of physics stuff the original NWN didnt do, so I'm trying to do as little rendering on the CPU as possible. As such I'd really rather not go the Shadow Volume route long term and its a pretty fair chunk of code to write just to experiment with. All in all it seemed prudent to put shadows on hold for the moment and work on other things.

Thats about all the news to date. I'm using the CVS as a check-point area as well as a release system so if you download, read the notes carefully as the most current version at any time may not be fully functional.

Posted at 12:36AM Jul 19, 2005 by gameguy in Java  |