Otaku No Zoku

Softimage XSI 4.0 is promoted as the most significant upgrade to their venerable graphics package since version 1.0.

Having used Softimage for a number of years I would agree that version 4.0 has a number of very significant feature upgrades that apply directly to game developers.

Where Softimage Stands Today

Softimage XSI has always been pitched as a very high end (with the high end commensurate price point too) 3D animation package that is mostly used for film. The tools in Maya and 3DS Max being more mature when it came to the vagaries of game development.

Perhaps it was just my personal experience but wherever I looked in the game development industry, XSI was almost nowhere to be seen outside of boutique art houses using it for high-end cut scenes.

The lack of exposure was caused mostly by the price point, but a lot had to do with Softimage completely ignoring game developers. It appears that the company is attempting to redress the balance with a more amenable pricing structure and a feature set to woo game developers.

I’ve been a Softimage user for nearly 10 years, having formally trained on it using SGI Indigo hardware, before the release of the first XSI version so it’s a package that over the years has become as comfortable to me as Microsoft Developer Studio.

I have a lot of history with this software and really know my way around it so I wasn’t expecting too much from a half-version release (I’ve been making use of v3.5 since November of 2003).

According to Softimage, XSI v4.0 is the biggest update to the application since v1.0 was unleashed on the world and I find myself mostly agreeing with that claim.

It’s very different.

Different is good (this time).

XSI v4.0 adds dozens of big new features. Far too many that can be covered in this review so I’ll concentrate on what’s important to game developers.

FEATURES FOR GAME DEVELOPERS

Let’s start with the user interface.

Massive changes.

All your layouts and panels can now be customised, and most importantly, saved! The layout is actually saved as XML which is a nice feature.

This is quite a departure from earlier versions, especially the early days where almost everything was nailed down and you couldn’t move it around.

Along with the customisation aspects XSI adds a lot of workflow features, notably the concept of media shelves. Here you store all of the items you are using in a particular scene for quick access; models, textures, scripts, shaders, etc. The concept is that you reach up on the shelf and take down what you need for a particular part of the scene.

This is one of those subtle interface changes that you never quite realised how handy it can be until you’ve used it.

There is also a scene table of contents that lists all of the shaders, scripts, objects, textures, etc, in a human — and machine — readable form so that asset lists can be tracked, parsed, and manipulated.

Reference animation & model.

The days of having to use a low-resolution stand-in object when animating dozens of highly detailed objects that bring your machine to its knees even in wireframe mode are over. You now have the option of using low-resolution reference objects in place of the actual geometry.

Finessing the workflow by naming a reference object and the actual object identically and then swapping one for the other (hoping that you got all the appropriate instances) when you wanted to do a final render is no longer the chore it was.

XSI also applies the same idea to textures, utilising low-resolution proxy images that load faster and can be manipulated quickly when you’re blocking out the movement in a scene or tweaking a pose. The technique also applies to shadows, using low-resolution stand-ins for performing rapid lighting calculations on highly detailed objects.

Vector & Raster painting.

XSI adds a vector & raster painting tool that lets you paint directly on to textures, single frame or video allowing quick touch up work without resorting to an external art package such as Adobe Photoshop. The solution is reasonably robust and feature rich, especially for frame by frame tweaking that can be a real chore in other packages, but it is no Photoshop.

Compositing has been overhauled with new tools for handling tracking & pinning along with an “Image Compare” window for side-by-side comparison of before & after images.

XGS (XSI Graphic Sequencer) is Softimage’s new programmable graphics pipeline technology allowing adept programmers to implement custom rendering solutions that execute on the GPU for full scene and per-object effects.

Rigid body dynamics using ODE.

Softimage has done a lot of licensing of other technologies with this release, notably Open Dynamics Engine (ODE), an Open Source Rigid Body Physics solution used in a number of other commercial products, though XSI is the most high-profile application to date. Check out xpand rally to see this engine being used in a commercial game.

ODE is implemented in XSI as a plug-in, so it’s possible to alter the source code, recompile, and distribute a new build to the artists within a team. I can’t say whether Softimage has made use of a vanilla build of ODE, or tweaked it for their particular application.

The particle system in 3.5 was capable, though it lacked many features that game developers deem desirable.

XSI doesn’t disappoint, finally offering attractors and repulsors to influence the flight of particles, something that Softimage refers to as goals.

The particle parameters, along with the emitters and goals are exportable and the entire particle system is exposed via an API that allows programmers to implement parts of the game engine to allow the artists to tune their particle systems for a particular implementation.

Along with the standard Mental Ray renderer that XSI is known for you now receive several other options suitable for game development, the OpenGL renderer and DirectX 9 shader support is welcome and should prove useful for artists who will be building objects to run in a game engine.

You can even apply a high-level shader language (HLSL) (tell your DirectX programmer colleague about it to give them ideas) to just a particular part of the scene.

XSI adds further polygon reduction tools that are comparable to those found in Maya 6, the adjustable parameters are what you would expect to see such as polygon count and angle limits with the ability to automatically generate multiple LOD (level-of-detail) models for use in a game engine. Each LOD can be individually tweaked though the automated features are still no magic wand so artists will still want to keep those low-polygon skills sharpened.

XSI supports the previous Windows scripting options such as VBScript, JavaScript, and Python, and has added ActivePython on the Linux platform.

PROBLEMS I RAN INTO

The feature I was most excited by when v4.0 was announced is the new Custom Display Host (CDH) that lets you embed other applications into a window within XSI.

This can be an application such as Adobe Photoshop, or a non-linear editing package, or your game engine.

By making your game engine aware of the XSI object model it is possible to send data in both directions, allowing artists to construct and place models within the game engine and then switch over to the game and fine tune the object parameters (or any other custom game parameters) that can then be sent back in to the modeller.

All this without actually leaving XSI, which makes the application useful as a level editor as well as a modeller.

CDH debuts in the current version and is still rough around the edges, I didn’t have as much time with XSI as I would have liked but this was the feature that had me sat up until 3AM most nights trying to integrate my game engine. I cannot describe it as a smooth ride though with persistence I was able to eventually get it to the engine to a point where it no longer took down XSI every time it exited.

Yes, the problems most likely existed in my game engine, not XSI, but with the problems I had I would have to say that you should allow plenty of time for integration, don’t just expect it to happen overnight.

SUMMARY

The package really does absolutely everything you could want. Softimage has gone out of their way to accommodate game developers.

The new pricing structure has brought it within the realm of many development studios as a possible alternative to the two major competitors.

VERDICT

Softimage XSI 4

Company: SoftImage

Rating

9 out of 10

Price

With the release of v4.0 Softimage has addressed the price comparison issue by making the package highly competitive.

The pricing structure is divided in to three tiears with titles I particularly like:

• “Everything you need” ($1,995)
• “Everything you want” ($3,995)
• “Everything there is” ($8,995)

Softimage also offers very deep discounting for students & academics which changes regularly so is worth checking the web site for up to date information.

Pros

1. Provides a Platform Developer Kit for connecting XSI to a Microsoft XBox.
2. Better integration of workflow tools.
3. Current release offers far more to game developers than ever before.

Cons

1. The Custom Display Host feature still feels like a “v1.0” product.
2. 2D painting tools are not yet up to the level of something like DeepPaint.
3. Not as well supported by 3rd party tools & books compared to competing products.

Contact

SOFTIMAGE
3510 St Laurent Blvd.
Montreal
H2X 2V2
Canada

www.softimage.com

System Requirements

* Available for Windows 2000/XP Professional & Linux
* Pentium III or AMD K7
* 500+MB of HD space
* 1280×1024 screen resolution (dual monitors at 1920×1200 makes everything feel less cluttered)
* 256MB RAM (yeah, right. Try 1GB+ for any scene of a decent size)
* OpenGL accelerated graphics card

This review originally appeared in a 2004 issue of Game Developer Magazine.

Remember when microcomputers shipped with BASIC? And you didn’t have to resort to pages of C++ code calling obscure API functions just to draw a colour rectangle on-screen? DarkBASIC Professional is a hidden gem often overlooked by commercial game developers – a modern, structured BASIC dialect with lots of commands specifically for handling games using DirectX. Capable of turning out 2D platformers and 2D shooters as easily as it handles 3D first-person shooters (both indoor & outdoor), with DarkBASIC Professional you can create anything you would with C++/Win32/DirectX, without the steep learning curve. It’s an ideal script language for game designers and programmers in a rush to try out an idea. You get the idea up on-screen rapidly with minimum fuss, and from there take it all the way through to conclusion, i.e. burning a gold master.

Code editor & IDE

The current IDE, unlike previous versions, is a native Windows application providing an editor, compiler and integrated source-level debugger. The editor is reasonably well featured, though primitive in places and really just about capable of the task for which it’s designed, but offers little more. Don’t expect Visual Studio or SlickEdit here. It handles projects, multiple source files, assets, version numbering, and a TO DO list. The debugger offers the usual complement of features such as breakpoints, single-step and variable watches, both auto-scope and user-defined.

The BASIC compiler turns out “real machine code” and disassembling the compiled output it appears the compiler is non-optimizing, leaving the code as-is and performing a linear one-to-one conversion from BASIC to assembly, calling dynamic link libraries as required. This ability to call in to other DLL’s makes the language extensible by a programmer capable of writing dynamic link libraries in e.g. Visual BASIC, C++ or Delphi.

The compiler turns out stand-alone executables with the ability to bundle any additional DLLs and assets into a single executable file and it removes any unused portions of the DarkBASIC Professional libraries. Once the executable is generated, with or without bundled assets, it can be automatically compressed and encrypted for a smaller and more secure distributable.

DarkBASIC Professional is specifically created for manipulating the DirectX API in a simple and easy way. It handles all of the DirectX 8.1 features, providing ample facilities for 2D — using the DirectX sprite interface — and 3D graphics, plus input and audio. The package makes initialization of a full-screen or windowed DirectX application as simple as can be. By either setting the start-up options in the project explorer or issuing a BASIC command that dictates screen resolution along with windowed or exclusive mode. The project settings also control the type of executable that is created, whether it is standalone or a Windows installer.

The 2D sprite system is very capable, handling animations, movement and collision between sprites. The 3D side is an even more comprehensive command set for graphics and math, covering vectors, matrices, Catmull Rom and Hermite splines, plus all the usual trigonometry commands found in other modern BASIC dialects. The 3D graphics handle the usual rendering of polygons, loading of 3D objects from disk and creating primitives at run-time plus commands to control the individual joints on a boned object and real-time mesh deformation with direct support for a lot of popular model formats, e.g. Quake 2 & 3, HalfLife, DirectX and 3DS Max.

Glittery particle effects

Advanced texturing & rendering techniques using bump mapping, environment mapping and multitexturing give the shine to games, along with support for hardware shadows, vertex and pixel shaders and even a built-in cartoon shader. Rounding out the graphics capabilities is a general purpose particle system with specific support for the unique properties of snow and fire particles.

Camera control allows for multiple simultaneous cameras for multi-viewport rendering to either the backbuffer or a bitmap. A camera is moved around dynamically via code or the tracking feature that makes it follow another object. Pointing a camera at a specific object or point in space is trivial, especially for non-programmers unfamiliar with look-at matrices. One of the nice features I explored was the intelligent navigation, by placing invisible static collision boxes in a scene the camera will attempt to avoid entering the boxes. Scene lights are fully controllable, generated either in a level editor or dynamically at run-time, with commands for spot, point and ambient along with control of fogging distance.

Object collision detection is handled automatically, 3D uses bounding spheres, 2D sprites using rectangles. Once a collision has taken place DarkBASIC Professional can either automatically move the colliding objects apart, providing for a primitive collision resolution, or leave it up to the programmer to determine the exact outcome. The collision command set provides ray casting tests for user-determined collisions and probing.

FPS using PVS and BSP

DarkBASIC Professional renders indoor and outdoor 3D scenes equally well with PVS and BSP support and a capable terrain engine that loads BSP worlds handling the culling, texturing and collision automatically. There’s a bundled BSP compiler that’s installed with the IDE and a programmer can generate dynamic terrain from height map files at run-time.

DarkBASIC Professional is supported by several custom tools that can be purchased through the DarkBASIC Professional website. Cartography Shop, v3 to be released soon, is a full fledged 3D map & level editor that allows a designer to create levels, placing objects and entities within the level and calculating static lighting. Texture Maker is designed for creating model and game textures, wrapping them directly around a piece of 3D geometry model as you paint in 2D. Also available is 3D Canvas Pro for creating models to be used in your games, the 3D editor is far easier to get to grips with than much larger, more expensive packages. DarkBASIC Developer Network is an additional subscription based service that gives you access to developer support forums, enhanced technical support and a direct line to the DarkBASIC Professional developers.

Beyond the graphics features provision is made for input from keyboard, joystick/joypad and mouse, along with force feedback capability. There are also extensions available for free from the DarkBASIC Professional support website that interface with a VR glove and USB light gun. The language provides strong audio support; streaming CD audio, MIDI and MP3 playback for music, and WAV and other formats for the sound effects, all of which can be processed as 3D positional audio. It is also possible to capture directly from the microphone which proves useful for net play games. Video, either from an AVI/MPEG file or DVD can be mapped on to a texture in real-time and then wrapped around an object.

DarkBASIC Professional features two command sets that deal with network communication, one for accessing FTP sites where you can retrieve or store any data you want; this feature can be used for sending high scores to a remote server, downloading the latest patch or level pack for an established game or even automatically upgrading the game from un-registered to registered. The other command set handles multiplayer games via LAN or TCP/IP using a peer-to-peer or client/server architecture. With this system the hardest part of creating a client/server multiplayer game is presenting a meaningful user interface to allow the player to connect. I wasn’t expecting very much from this area of the package, usually network communication in many game SDK’s is bolted on an as afterthought and allows you to only send the most rudimentary of messages. DarkBASIC Professional handles the basics and more besides with provision for transmission and reception of arbitrary blocks of memory, bitmaps, audio and complete object meshes.

The manual, spiral bound so that it will lay flat on the desktop next to your keyboard, covers the BASIC command set, each section logically divided so that it deals with a specific area; 2D sprites, 3D objects, vector & matrices, memory manipulation, etc. Each BASIC command is given a brief paragraph of information and the syntax that it requires. There are a few weaknesses in the manual; they don’t supply brief examples of how to use commands, often many commands will work in conjunction and you must infer how they bolt together. Many, but not all, of the commands are covered in the on-line examples replete with source code, and the on-line help provides more comprehensive information with small code snippets. I don’t see the need for the physical manual, either they should bring it up to the level of the on-line documentation or abandon it all together. I can understand the desire to provide something more than just a CD in a box but as it stands the paper manual is little more than filler. It would be nice to see a nice thick “user guide” that covers the particular BASIC dialect in more depth. One complaint I have with the on-line help is that it uses a non-“Windows standard” help browser. Is there any reason to deviate from the capable and usable Windows help format these days?

The compiler & IDE package are actively supported by the publisher/developer with regular updates and a monthly news letter. Cost is $99.99, with no royalty fees, and access to the DarkBASIC Developer Network costs an additional $69 per year. Consult the website which frequently runs special offers. The publisher offers educational support to schools and Universities with free licenses available.

On the web you will find a large, thriving and very active semi-pro community turning out some remarkable and experimental games, screenshots of which can be found on the DarkBASIC Professional support website. Starwraith 3, a kind of cut down version of Freelancer is remarkable and a tribute to the capability of the package and programmer. DarkBASIC Professional recently hosted a Retro competition that had almost one hundred respondents, which gives some clue to the size of the community behind this package.

Monthly newsletters

Each month a newsletter is sent out to all DBDN subscribers covering the latest developments, upcoming features, interviews with prominent people from the DarkBASIC Professional community and product offers. The newsletter also presents tutorials each month, also available from the website, that cover specific aspects of developing for DarkBASIC Professional. The hosted DarkBASIC Professional forums are one of the best resources available with source code often being offered up by veteran DarkBASIC Professional programmers within a few hours of posing the question.

As of this writing the DarkBASIC company has re-branded itself as The Game Creators, with a change in the URL to http://www.thegamecreators.com/.

Patch 5 has also been released, requiring DirectX 9.0 to be installed, and adding several dozen new commands dealing with vertex and pixels shaders. If you are creating games for a user-base that is still using the previous generation of DirectX technologies you may want to avoid upgrading just yet. Released, too, is issue 8 of the DarkBASIC monthly newsletter.

Buy DarkBASIC Professional at Amazon.com now!

“Beginner’s Guide to DarkBASIC Game Programming” by Jonathan Harbour is also a valuable resource for programmers interested in this easy to learn game programming language.

VERDICT

DarkBASIC Professional

Company: The Game Creators

Price: $99.99

Rating

8 out of 10

Pros

1. Simplifies access to all aspects of DirectX
2. Allows you to quickly get an idea up and running.
3. Once the framework is in place designers can treat it just like scripting.

Cons

1. Requires CD or USB dongle to inserted in the machine at all times (this was fixed in Patch 4.1 so that now it is only every 400 compiles)
2. Can be clumsy to express some ideas due to a lack of object-oriented features.
3. Lack of professional production features could make it difficult to integrate in to a professional development environment.

Additional Information

http://www.thegamecreators.com

Bibliography

Harbour, Jonathan and Smith, Joshua (2003) “Beginners Guide to DarkBASIC Game Programming” Premier Press

Buy DarkBASIC Professional at Amazon.com now!

“Beginner’s Guide to DarkBASIC Game Programming” by Jonathan Harbour is also a valuable resource for programmers interested in this easy to learn game programming language.

This review originally appeared in the March, 2004 issue of Game Developer Magazine.

Does it do anything but driving games?” is a question that draws groans and smiles simultaneously from the Havok team, makers of their eponymous game physics middleware that recently received a major upgrade to version 2.0.

In response to what must be an all-too-frequently asked question, Havok 2.0 broadens its scope to include character physics much more prominently over earlier versions. In that sense Havok 2.0 is not an upgrade, it’s a whole new product. New demos show off this functionality to good effect over previous releases.

New and improved

In the original Havok we heard a lot about dynamic characters - rag doll - but it was more akin to having a dynamic corpse. Havok 2.0 extends what is possible, thereby losing a lot of the dead-body feel of its predecessor. I’m not an animator by any stretch but I was able to develop my own walk cycles and attach the Havok physics system and character control far easier than with earlier versions. Havok has realized that I need to dictate full control over character look and movement in the game, both player and nonplayer, because that’s what the game player wants. I don’t always require accurate physical simulation, for example when a more cinematic or fun-focused effect is desired. Havok attempts to provide this control, and while far from perfect it’s a step in the right direction. I was able to emulate parts of the standard zombie demo easily enough that as my animation walks forward I “detached” the head, allowing it to loll freely. When hitting the character with an impulse, such as simulating a shotgun blast, I switched state to playing a “knocked back” animation, detached the arms and let the physics control the flailing arm movement and torso rotation. This could have been extended to letting arms dangle limply and legs drag heavily along the ground when targeted. I was also happy to see a proper section in the Havok manual for handling characters and control, so you aren’t left floundering.

You may not have heard this, but Havok does driving games! There is obvious new functionality in the vehicular component of the SDK, but the important part for me was how easy it is to create vehicles now. The original Havok Vehicle SDK provided a lot of black-box functionality that was poorly documented and nonintuitive. With earlier releases, I spent a lot of time spinning my wheels, literally, trying to figure out how to balance all the forces. Havok now assumes that you don’t inherently know what anti-roll bars are for, how to tune the suspension based on terrain and vehicle type, and how to calculate friction circles for cornering. Havok details specifically how their Vehicle SDK black box works and assumptions made, removing a lot of past guesswork from the equation.

Another thing that changed was automatic construction of object groups. Havok 2.0 introduces “Islands” so that you no longer have to take an educated guess as to which group in which to place your object so that the collision system is optimal. Islands are automatically constructed at run time, containing small groups of objects based on the simulation criteria. I had a previously existing prototype inside of which was a spiral of dominos that could be knocked over. Originally, I placed all of the dominos in their own group, which was fine, so long as the player didn’t attempt to knock over multiple dominos at once, causing multiple cascades, as that would slow down the simulation. Havok 2.0 took care of the grouping for me; once a few dominos came to rest, they formed their own “simulation island” and became quickly deactivated. This relieves a huge burden from me having to take what was, at best, an educated guess as to which group objects should be placed in. I also no longer need to verify that someone else has placed objects in the wrong group.

Other Platforms

I’ve only been able to work with Havok 2.0 on VC++ 6.0 running under Windows XP. Circumstance did not permit me to compile on Sony and Nintendo dev kits, so my only experience with Havok 2.0 on those platforms is playing with the interactive demos at GDC. From what I was able to glean from their new Visual Debugger, a module similar to the real-time VTune, the frame rates on complex scenes, such as the zombie demo with a dozen animating rag dolls, and character control were rock steady. CPU and memory usage never spiked above 50 percent, usually hovering around 20 percent, and when it did climb it was only for one or two frames when multiple characters attempted to interpenetrate. This was a pleasant surprise, as in the past with Havok 1.7 I could bring my 3GHz, 512MB, 64MB Radeon 9000 to its knees with a half-dozen rag dolls. Looking through the documentation and API headers reveals that Havok has gone to great lengths to ensure that each platform is properly targeted, the PS2 build making good use of the scratchpad and vector units.

How useful Havok’s Visual Debugger will prove is questionable. It certainly gives you insight into the work being performed by the physics engine, but I’d like to see more hooks to allow integration into standard profiling tools such as VTune and ProDG’s tools for Gamecube and PS2. I’ve worked on projects where the team has provided a profiling solution, and my experience with the Havok VD suggests that it does not provide the hooks that will be needed.

Support

Unlike a few middleware companies I have dealt with, Havok is going to great lengths to ensure that the people providing tech support for the licensees are qualified to do so, ex-game and physics programmers to a man. They’re tech support is second to none. From prior experience with the 1.8 SDK on a real project, technical queries submitted late in the afternoon would elicit a response by the time I returned to my desk the next day. Still, Havok seems to understand that as a middleware provider, customers’ project deadlines don’t wait for them. Pertinent questions that would apply to other developers are often placed in the FAQ - even if they are only asked once - along with useful code snippets; even small features are quickly rolled back into the main Havok code base. I saw just how quickly this happens when attempting to create a vehicle that behaves as the Warthog in Halo, with all four wheels steerable. Within 18 hours I had my answer, and a day later it was a FAQ and code snippet on how to modify the Vehicle SDK. Havok supplies 95 percent of the source code once you move beyond evaluation, and that can save a lot of time when you are hunting down an elusive bug or attempting to optimize your game. Havok is quite happy to let you look inside their physics black box as much as you like.

Documentation

I’m of two minds concerning the way that Havok is pursuing documentation. The learning curve for the Havok SDK can be steep, and one reason is that they rely more on demos than documentation to illustrate a point. That causes two learning bottlenecks: First, you have to spelunk through many, many source files looking for the demo or snippet of code that you think you need (the “I’ll know it when I see it” approach). Second, because the Havok demos are built around a common framework of code, the body of which pulls in every feature that Havok provides, it requires more support functionality. You have to build up a mental roadmap of that in your head, learning what’s important and what’s immaterial to the particular demo before you can delve in to the small piece of code that you really should be concentrating on. The demos are good starting points, but better documentation that shows the bare minimum you need and why you need to do the particular steps, would make the job easier.

Terms

Licensing terms vary based on numerous factors such as the number of titles and platforms involved, and there are numerous support options from which to choose. One thing that is consistent is that license fees are one-time-only, with no royalties involved.

Each project is different, and a physics simulation, like Internet traffic to a server, changes moment to moment, making it difficult to provide hard data that you could form a judgment around. My test rig was 3GHz, 512MB DDR 2100, 64MB Radeon 9000-equipped notebook computer running Windows XP and DirectX 9.0. I assembled two demos for this review.

The first test project consisted of approximately 150 objects in close proximity, 10 of which were considered complex; small-scale versions of the St. Louis Arch that were pinned, i.e. infinite mass and immovable. The rest of the objects were mostly simple geometric shapes (boxes, wedges, and spheres) that the player could interact with in varied fashion. There were also a half dozen rag dolls consisting of 15 bones each; a rag doll was connected to its immediate neighbor via 2D dashpots, forming a loosely coupled chain. The player was represented as a single, two-wheeled vehicle that rode as a child’s tricycle, constructed from one large wheel at the front, and a single small wheel positioned just slightly behind for stability. Due to the small distance between the wheels, the vehicle possessed a very small turning circle, enabling the player to negotiate the tight environment.

The second demo - a simultaneous blending of animation and physics - consisted of two dozen rag dolls animating a walk cycle that the player could shoot at with the mouse. The quoted memory footprint covers the entire demo,including graphics.

The Physics Testbed
	Peak Frame Rate	Average Frame Rate	Peak Memory Usage	Average Memory Usage
Demo 1: Large 150-Object Scene	120	80	10.1MB	9.4MB
Demo 2: Animation and Physics	174	98	2.9MB	2.7MB

 

 

VERDICT

 

Havok 2: All Rag-Dolled Up

Havok
San Francisco, CA
415.543.4620
Dublin, Ireland
+353 (1) 677.8705

Rating

9 out of 10

Pros

1. Flexible licensing.
2. Very responsive, technically savvy support and sales people.
3. The development team is Irish.

Cons

1. Character control isn’t perfect.
2. Poor documentation for such a deep product.
3. Visual Debugger needs better integration with other tools.

 

SIDEBAR

Your Mileage May Vary: Havok 2 Users Weigh In

“We’ve had a positive experience with Havok, although because we’re about halfway through our current game life cycle, we still have issues that we need to resolve. If we are happy with Havok at the end of the game, I can certainly see us using it again, as much of the hard work of learning the API will already be done. The documentation could be better, though; a real boon would be to have more code examples in the docs themselves, rather than having to track down the usage inside a demo.”

- Mark Baker, Mucky Foot

“Even with Havok it still takes significant work to combine gameplay and physics in a way that they enhance each other rather than detract from one another. When we originally looked at physics middleware a year or so ago, Havok looked like the most complete product on all platforms.”

- Sam Baker, Paradox

“We aren’t using the newest release yet, but during development we’ve given them lots of feedback and many of those issues have been addressed in Havok 2.”

- Jay Stelly, Valve

SUMMARY

 

Final word

The star rating I assigned for Havok 2 represents my best stab at mapping my experience with a very complex product to a simple, five-point scale, which isn’t a neat fit, especially given how different real-world game production needs and environments can be.

The bottom line is that Havok is maturing. Version 2 shows great strides forward beyond Havok’s driving-game roots, especially in the realm of character-based physics, making it worthy of evaluation by developers on a wide range of projects.

This review originally appeared in the June 2003 issue of Game Developer Magazine.

— Justin Lloyd

Non-native platform or embedded systems development is never a pleasant task. It is often fraught with coercing primitive tools to do your bidding and constant frustration at the pressures of non-programmers observing the target platform as a “simple system” not as complex as Microsoft Windows or UNIX. Palm Pilot, no different to any other non-host development platform, has until the very recent past been poorly catered when it comes to development tools. Many developers are still forced to use primitive tools that have not really evolved in 25 years. I’ve been struggling with Palm Pilot development the same way I was struggling with the Acorn Atom in 1981, how to be an effective and empowered developer without writing all my own support tools. All the commercial solutions I am working with leave so much to be desired and I finally cobbled together a workable environment, piecemeal, using OSS tools and two commercial integrated development environments (IDE), task switching back and forth between them.

In the Autumn of 2002 Metrowerks, makers of the CodeWarrior series of development tools, announced version 9.0, capable of supporting the new ARM hosted Palm OS 5 and still retaining backwards compatibility with previous Palm OS versions. Their all new, all singing, all dancing IDE was the awaited update to their current product line. Reviewing a product that covers the scope of an IDE, compiler, debugger, emulator, resource tools and accompanying manuals is an interesting challenge. Unless you’re familiar with the legacy of a product of this size you can’t really appreciate the effort that goes in to upgrading it and bringing something fresh to the end user.

When I’m looking for a compiler, I’m looking for the “best” compiler. But when I’m considering an IDE, e.g. Metrowerks CodeWarrior, I’m looking at every feature and every nuance. Tools are a very personal agenda. They must work in the same way that I as a developer work, so that I never feel restricted by them. I should never have to work around them. To paraphrase a cliché, tool providers have to realize that using a screwdriver to hammer in a nail is inappropriate. Being a hardcore command line user who enjoys a properly configured makefile and build script, what I want from an IDE is being able to do everything from the keyboard, and possess the capability to script and customize every action. Microsoft Developer Studio is the only IDE to date that came close to those desirable qualities. As a complete gear head geek I’m always interested in “cool new development tools”, but also being a seasoned pragmatist I’m wary of any “silver bullets”, especially from any company that I consider to have put out substandard software, doing themselves and the development community a severe disservice.

Metrowerks’ CodeWarrior (CW), which I’ve used on-and-off since the earliest Apple Mac days, was an also-ran for the longest time, the choice of last resort and I had very few good words to say about it. I’ve suffered through numerous projects on Gameboy Advance, Gamecube, PSX and PlayStation 2 and always floundered about the CW environment. For PlayStation development it was always the tool of last resort for when the DOS-based SNSys debugger was crashing constantly, refusing to talk with the DTL-2000, or GCC was having linker palpitations. The same held true for Palm Pilot. I had CodeWarrior 8 for Palm Pilot installed for months and I would open it about once every two months for an hour or so to figure out why some piece of code was failing. My development setup was less than ideal. From the earliest days, each revision of CW I would dutifully download, look at the feature list, install the demo, and come away from the whole experience disillusioned and disappointed. “Must try harder” would be my quip when asked for a summation.

CW9 has addressed a lot of the concerns and problems I had, but there are still niggling issues with it. Development tools always come down to personal preferences, and my biggest issue is “It’s not DevStudio 6″ which really Metrowerks can do nothing about. Realizing this, I can appreciate the effort that has gone into CW9 to try and make it a tool that users will want rather than lament. Version 9 changes a lot of the underlying architecture, but leaves in place everything that is familiar to people who use it frequently on a day to day basis.

CW9 is still showing its Mac roots but slowly they are being engulfed by the real aims of Metrowerks, to fulfil the not insignificant task of creating a cross-platform host development environment (currently Apple Mac and Microsoft Windows) for an undefined number of target platforms, the list of which, when reading, feels like it would consume an entire magazine page just to iterate.

CodeWarrior 9 for Palm OS is designed around a flexible plug-in architecture.

To achieve their goal with any consistent chance Metrowerks has adopted a completely flexible, and most importantly, copiously documented, plug-in architecture. Their philosophy began appearing in earlier versions and 9.0 completes the transition. Now, almost everything in the IDE, including the compiler is a replaceable plug-in, which is how it should be. The integrated editor can also be replaced but only on the Mac version. Replacing the editor on the Windows version just calls an external editor, e.g. UltraEdit, which would appear with normal use.

Your first impression is the installer, snazzy in some respects, e.g. it understands multiple sub-folders when creating the Start Menu icons; and showing its age in other small ways, some of which I will cover. The installer may not seem to be that big a deal to most people but it’s where you begin. An audio clip plays when you insert the CD.

Be sure to select “Custom Install” if you want C and C++ files to still open in another package, e.g. Microsoft Developer Studio, otherwise your default file mappings will be usurped, and whilst CodeWarrior allows you to change the mappings after installation to either CW, or default, there is no way to remap the source file handling back to how you had it without the tedious use of Windows Explorer. During installation there are no less than six separate “click-wrap” license agreements you have to wade through, quite literally tens of thousands of words of legalese and sub-sub-clauses of the third party agreeing to the first party; who has time for this? I understand that Metrowerks needs to include these for all of the SDKs that ship with their product but I no longer felt like I was only agreeing to give up my first born, now I was giving up my whole family. You may want to have your company lawyer look over the agreements beforehand to ensure one of your developers didn’t just agree to a big corporate no-no.

The installer is gracious enough to warn you if you attempt to install CW9 over an older install and that incompatibilities may arise. At the end of installation an “automatic” updater executes, also usable at any time after installation, which actually only checks for an update, requiring you to visit the Metrowerks web site to actually download, and separately install the new update.

Installed and running, you are presented with what should seem familiar to most developers, a project window on the left, a blank area for your code window, and a comprehensive array of menus, sub-menus and option dialogues. The menu bar layout can be toggled between “Macintosh mode”, which should be familiar to users of previous versions, and “Windows mode”, making the application feel more like a host platform native.

I have several sizable Palm Pilot projects so the first thing to do was exercise the IDE and get something compiled. Developers are too proud to care about the shipped examples except to rummage for re-usable source code, seasoned developers also realize that Mickey Mouse publisher samples don’t really exercise the toolset. What’s it doing? How is it doing it? What are these options for? You want to see the compiler perform on a familiar code base and how it handles your project’s unique problems.

I’m probably Metrowerks worst nightmare when it comes to end users. I’m also their target audience. I want to reconfigure the IDE. I want to change the code editor fonts to use some miniscule 6 point custom bitmap font I’ve created. I want custom colors for all of the text. I want fast code generation. I need four targets, “Debug”, “Optimised Debug”, “Final” and “Release”. I want all compiler warnings on. I want ANSI C++ compliance off. I want my tweaked version of the Palm Pilot emulator. I don’t want to read the manual. I want… I want… I want…

Twenty minutes later I’m kind of happy and kind of disappointed. No, I haven’t read the manual, not yet, manual reading comes later. I haven’t floundered yet either. I have a familiar project, my project, 300,000+ lines of code, 160 C++ source files (not including headers); compiling, linking, and executing under the emulator. The environment can occasionally feel a little non-standard and non-Windows. Some of the dialogue boxes make me stop and do a double take due to the inverse meaning of the wording, or the fact that the button layout or captions are not what I was expecting.

After playing around now it’s time to start tweaking options. There are a lot of Motorola 68K options, and very few for the new ARM. Also, the compiler only accepts inline 68K, even though it is possible to generate ARMlets, Palm Pilot’s half-hearted and crippling attempt at exploiting the power of the ARM processor, but this can only be done at the module level, not the function level in CodeWarrior. Also, whilst being a game developer and desiring to screw every little bit of speed out of the target platform that I can is considered a “good thing”, the Palm Pilot adopts the exact opposite philosophy, optimize for size first and speed last. The CW9 compiler defaults to optimize for speed for all source modules in the project. It can be changed on a module by module basis, but you need to be aware that you’re compiler is generating large, fast chunks of code as default behavior. The compiler supports a lot of pragmas, many compatible with Microsoft’s VC++, and all pragmas are well documented so now I can turn off that annoying “performance warning” when converting a float to a Boolean in a one off initialization function that I’m unable to in GCC.

Metrowerks has finally seen fit to move away from the God-awful Constructor by shipping the eminently usable PilRC resource editor. Just as well, all of my resources were in PilRC format. Still, realizing that some developers are still using Constructor for projects currently under development, it is installed and available from the Windows Start Menu but the focus is now on PilRC. Constructor, for those that aren’t familiar with it, is a legacy application that has shipped with CW almost from the beginning and I cannot imagine using it in a production environment involving any reasonable amount of graphics or text, i.e. games development. It’s incapable of importing bitmap files directly so you have the tedious, time consuming and error-prone process of cutting and pasting from your art package in to Constructor. Imagine copying and pasting several hundred bitmaps by hand. Then doing it all over again when the artists have updated the art. Constructor also stores data in a binary format so that version control systems loathe it and you cannot have multiple artists/creative types working on the same resource file simultaneously. So out it goes! Add one to the score for the Metrowerks team for their adoption of a “Palm Pilot industry standard” tool. PilRC does everything you would expect an application resource editor to do.

The CW9 IDE allows the developer to import and export IDE configuration data, and has done so for several versions, in a well-documented manner. Are you listening Microsoft? Manipulating IDE configurations via a script for a project is a feature of which I’ve made extensive use. CW9 also stores the configuration data in easily parsed XML rather than an obscure, un-documented, ever changing binary format.

The CW9 IDE offers the usual complement of workspace features that you would expect; multiple edit windows, multiple simultaneous workspaces - useful for co-dependent projects such as a library and an application - and multiple build targets with the attendant source, library & asset/resource files for generating dependencies and the final executable. The workspace can be toggled between SDI and MDI mode ala Microsoft Visual BASIC with dock-able windows. The workspace window allows you to sort your files in the order they were added, alphabetically, by the amount of code each file generates, the amount of data it generates, whether it needs re-compiling, and lots of other sorting criteria by clicking on the header columns. A feature that is sorely lacking in a certain other IDE I use on a daily basis.

A newly created workspace has difficulty recognizing some of the de facto standard C/C++ file types such as .INL to denote an inline source file that is to be included and the IDE explicitly excludes you from adding these files with an obscure “at least one file could not be added to the selected target(s)” which is also the same error given if the file already exists in a workspace. This could cause some frustration and head scratching on very large development projects. You can fix the problem by manually adding the specific file types to the workspace options but you have to add the file type for each build target, and the custom file types are specific to each workspace. Create a new workspace for another project and you have to add those custom file types all over again. Create a new build target within that workspace — and on commercial projects there are often at least four build targets and often many more - and… Yes, you guessed it.

The compiler does seem to generate code a little slowly. And that is a double entendre. I’ve only had a week too really get into the new version and I was determined to spend the entire week immersed in it, effectively abandoning my familiar tools and environment, where possible, for CodeWarrior. Due to time and scheduling constraints I haven’t had opportunity to perform proper compiler timings other than cursory stopwatch experimentation and the results are that CodeWarrior takes longer to output the same amount of code than GCC would for the same target CPU. I have GCC configured to generate dependencies, including those for art resources, process several large makefile includes, and output detailed information from the map file, essentially doing a lot more work than what I’m demanding of CW9, and GCC is still several tens of seconds faster. My current project isn’t yet at the point where I would notice frame slow-down on an ARM CPU, and uncapping the frame sync didn’t prove anything conclusive to my satisfaction so until I have more time to actually perform proper code generation comparisons I’m keeping quiet on any hard data but from my observations the code that CW9 generates is marginally slower, and I really must emphasise “marginal” until I’ve done proper timings. Previous versions of CodeWarrior have generated outstandingly slower code than GCC.

Until CW9 it was difficult to perform many tasks via the keyboard. Every time I have to lift my hand from the keyboard to reach for the mouse and select some obscure submenu option is valuable seconds taken away from productivity, it can also ruin a train of thought. Every action I can perform with the mouse I should be able to perform with the keyboard. In the latest version almost but not quite everything can now be mapped to a key, and just as importantly, all key bindings are user-definable so it’s possible to have Microsoft Developer studio keys, BRIEF emulation, or even Atari ST C-Breeze if you’re inclined.

CW9 supports two flavors of version control, extensible through the plug-in architecture, Microsoft’s Visual SourceSafe (VSS), and Concurrent Versions System (CVS). At home I stick with the simple VSS, at work I’m usually using CVS, whichever solution you require you still don’t move completely away from the native toolset, the CW plug-in merely allows the IDE to talk to the back-end versioning system.

Palm Pilots arrive in a variety of hardware and OS configurations, and not all target platforms support all features. The usual way of developing Palm OS applications is to run your code inside of an emulator or for OS 5 in the simulator, with the appropriate ROM files for the particular machine, satisfactory for Dinky applications but the real world requires you to download to hardware regularly to track down some obscure error. Metrowerks has done its best by providing several ways to connect CW9 to the target. This is where CodeWarrior usually shows strength, the integrated source level debugger, and when I say source level that means C or C++, with native support for Dragonball xZ 68K CPU line. Metrowerks touts how strongly this new release supports Palm OS 5 and the new ARM CPUs so I was expecting to be able to debug my ARM code and ARMlets — reading the datasheets you certainly receive this impression — but I spent fruitless hours attempting to step in to an ARM assembly module without much success. On feedback from Metrowerks they state that CW9 is incapable of debugging anything ARM related which puts me back to old tried and true methods and left me with the feeling that CW9 was a half-hearted effort at a Palm Pilot development tool.

Connection can be made to a hardware device via the docking cradle utilizing RS232 serial or USB. Unfortunately it’s not possible to debug all hardware configurations, some USB Palm Pilot devices do not allow remote debugging, the list of which can be found in the CW9 documentation and on their website. This incomplete coverage posed a particular problem for me as I’m currently developing an application for the Sony NX70V and am unable to debug either my GameCon peripheral or the camera code. The only way to debug is directly on the device itself using good old-fashioned techniques of printing out relevant variable values to the screen where possible. It would be nice if Metrowerks could ship a target platform debugger too. CW9 now supports an external debugger, so if you have a familiar debugger, e.g. Insight running on top of GNU GDB, you are able to use that as an integrated part of the environment rather than having to task switch out. The CW9 native debugger supports multi-session debugging, allowing you to debug a piece of software running on two separate instances of the emulator, or the emulator and a hardware device but I didn’t avail myself of the opportunity to investigate this feature as none of my projects make use of multi-machine communications yet.

The older versions of the CodeWarrior editor have always been the product’s biggest weakness, and I would say the most used feature for all users. And unfortunately, Metrowerks disappoints once again. The code editor kind of provides most of the features I expect in a modern IDE, but in a half-hearted way. Editing functionality is so-so. Code completion - had to change the default key to something more “DevStudio friendly” that actually worked on my laptop keyboard, who has hands big enough to stretch from the Alt key to the full stop on the numeric pad? Code completion usage was clunky at best and it’s unable to tell you neither the parameters a function expects nor the members a class or structure has defined. Auto-indenting - the most basic of what you would consider auto-indenting to be in the twentieth century, and that’s the last century for people not keeping up. Syntax highlighting - not enough options for highlighting different pieces of text, it’s about twenty options short by my estimate. Brace/bracket balancing — very annoying typing delay in the default configuration and woefully inept in use and fond of losing typed text, the greatest sin of all. Open #include - this is a niggle, one of those “features” that makes you take one extra small step before completing a task, instead of placing the insertion point inside of a string enclosed in quotes or angle brackets and right click and selecting “Open file” like in every sane editor that is smart enough to figure out that it’s a #include filename, you have to actually highlight the entire filename and then right click to open, it works only if you highlight the base name file, sans extension, as long as you don’t have a file with “multiple extensions”, e.g. “foo.bar.h” Can you believe there’s no “Delete Line” capability in the text editor? It also lacks a basic one-key reformatting feature. I’ll stop now before I run out of space. Hopefully Whole Tomato, makers of VisualAssist will consider porting their plug-in to the CodeWarrior environment to round out the code editor feature set and bring it up to the classification of “usable”.

The comprehensive Palm documentation has been integrated in to the IDE, which is how online help in an IDE should work. The documentation is accessible from the code editor, highlighting an API call or structure name and pressing F1 brings up the appropriate help page. Unfortunately you actually have to highlight the word, not just merely have the insertion point somewhere within the word, and part word searches don’t work, for that you have to open the appropriate help file and search. There doesn’t appear any way to add your own documentation to the list of searchable help files either.

The Metrowerks supplied documentation covers a lot of ground, CW9 ships with several help files that are worth reading through, including the use of C & C++ compilers on embedded systems, covering the specific differences in the Metrowerks CodeWarrior compiler with pointers on optimising for size and improving compiler performance.

CW9 includes the usual wizards for generating new projects, useful for first time users to get the compiler’s default options for a shared library or basic application with simple code for processing messages, displaying a form, a menu and an about dialogue. The documentation also includes comprehensive tutorials on using the wizards and setting up projects.

The IDE contains an integrated “graphical” file diff/compare utility. It’s very nice, it also generates a text list of all the differences too, unfortunately there is no actual way to export this text and the way it works is a little unfamiliar in how it applies the differences so for file compares and diffs I’ll be sticking with WinMerge and HexEdit.

A powerful feature of CW9 is its support for Windows Scripting Host (WSH), available only on the Windows version. Using any WSH 2.0 compatible scripting language, e.g. VBScript, Perl or JavaScript, you can exert automated control over your project, the IDE, and the compiler; especially useful if you have a singular machine designated as the build monkey to generate all the various target configurations or require pre-build or post-build steps. I only exercised this feature a small amount, putting together some simple scripts to iterate over the project files and ensure the latest versions had been retrieved from VSS. Coupled with the new command line features this helps CW9 to integrate in to a professional development environment where someone is not always around to click on the mouse.

Along with the standard Palm SDKs Metrowerks ships almost all of the available Palm Pilot APIs, including Sony’s; featuring their HighRes & GameCon API, along with a trial version of Bachmann’s Print Boy shared printing library, a public version of the Palm Pilot installation package, Catapult from Beiks Software, the full version of Hands High Font Bucket and of course the obligatory Huebner’s MathLib.

With version 9 Metrowerks is attempting something different by shipping the Palm Object Library (POL), a kind of MFC for Palm Pilot without all the Microsoft messiness. POL wraps many of the Palm API calls and structures in logical C++ classes. How wise this is I cannot say, I used it a little bit but I wasn’t going to refactor my project to test out an untried API. I think the library needs more maturity and real-world usage before I would consider using it in a commercial project.

Metrowerks CodeWarrior retails for an MSRP of $399 per seat for new purchases, and $199 for people upgrading from a previous version.

After a week of using CodeWarrior I’m still not changing my one-liner. I’ve returned to using my old development environment, not because of lack of familiarity with CW but because they still have a long way to go before they come close to something I would willingly use on a day-to-day basis and most of my resistance stems from the incapable code editor.

For more information
Palm Pilot Development Kits & ROMs http://www.palm.com/
Metrowerks CodeWarrior http://www.metrowerks.com/
Bachmann PrintBoy http://www.bachmannsoftware.com/
Beiks Catapult http://www.beiks.com/
Hands High Font Bucket http://www.handshigh.com/
Rick Huebner’s MathLib http://www.radiks.net/~rhuebner/mathlib.html
Ben Combee’s Palm OS Development Site: http://www.palmoswerks.com/

After this review went to press, Ben Combee, CodeWarrior for Palm OS technical lead responded. Ben works mainly on the compilers, linker, debugger and resource tools with brief excursions in to the CW IDE code base. Ben feels that some of my criticisms were premature and I’d like to take this opportunity to let him respond.

Ben Combee: “With regards to compile speeds, I don’t think you made effective use of the precompiled header capabilities of CodeWarrior. While straight code compilation may be slower than GCC, using a precompiled header to cache symbol definitions from the Palm OS headers or even local headers can dramatically speed up build times.”

Justin Lloyd: “That is a valid point, and it’s one of the first things I checked. Even with pre-compiled headers GCC was still managing to out perform the CodeWarrior 9.0 compiler. I think this has a lot to do with the way I construct my projects and makefiles though and when it comes down to it, twenty seconds on a five minute build is neither here nor there.”

Ben Combee: “I think your criticisms of the 68K/ARM aspects of the tool didn’t accurately reflect where the Palm OS market is today. Most applications are 68K, and 68K code works very well for everything but speed-critical apps. The current API for Palm OS is 68K-based, and ARMlets only barely made it into Palm OS 5 — PalmSource originally had no plans to allow user-level ARM code to execute in that OS version. We focused on 68K development with this release both because traditionally the Palm OS tools were 68K only, and for Palm OS 5, the majority of code will still be 68K-based. There are only a limited number of ARM-based devices out there right now; any game developer wanting to target the Palm OS market really needs to do 68K first, since that’s where the majority of users are.”

Justin Lloyd: “I agree. I didn’t mean to mislead the reader in saying that CodeWarrior was deficient in that area. Reflecting on it I’m positive I was venting my own frustrations at PalmSource’s technical solution and perhaps using CodeWarrior as the platform. I retract my earlier point.”

Ben Combee: “The external debugger comment seemed odd. While the IDE supports that, there are no external debuggers that support Palm OS with CW-generated programs. As for remote debugging, the lack of support is generally the fault of the device manufacturers — we have tried to get Palm, Handspring, Sony, and other companies to support USB debugging, but it’s never been a high priority. For the record, the NX70V does support remote debugging with a serial cable, but you need to get that from a third-party, such as http://shop.brando.com.hk/.”

Justin Lloyd: “I never had the chance to investigate the external debugger IDE. Specifically that was a feature bullet on the advertising literature I was sent. Also, when the review was submitted to Metrowerks for fact checking it came back that I had forgotten to mention the external debugger feature so it was added at the last moment. Which is why it seems “tacked on” to the review. So point noted, CodeWarrior 9.0 supports an external debugger but there are no 3rd party debuggers that handle Palm OS programs generated by CodeWarrior 9.0.

With regard to the remote debugging issue I did speak with Metrowerks tech support concerning this and they offered no solution, and yes, you are right to point out that it is mainly the fault of the manufacturers not providing proper support. Within a day of Game Developer publishing the review a Metrowerks representative accosted me while I was attending Game Developer Conference and informed me I could debug on the NX70V with the use of the cable you mention.”

Ben Combee: “Did you try the product in the MDI configuration of the IDE? There were no comments on docking windows support, which I think is a pretty major IDE feature added in this release. There was also no mention of workspace support in the IDE.”

Justin Lloyd: “I think a lot of what was covered got cut in the magazine version due to space restrictions. Check through the full-length review and you’ll see I do mention the workspace.”

Ben Combee: “On the topic of POL — while this is the second release of CW with this library (POL 3.x was part of the CW for Palm OS 8 Enterprise Edition release), the library has been used by developers since early 2001 and is quite mature. I’ve personally used it for several side projects, and it has worked very well.”

Justin Lloyd: “Ironically, an announcement concerning the future of POL was released in the past few weeks that it is to be discontinued. I’m sure that any OS 5 apps will have to be updated to work on OS 6 but the burden would surely be heavier if the developer also had to migrate away from POL.”

Ben Combee: “Finally, I also wish you had looked at the online support reputation of Metrowerks with regards to this toolset. I’ve personally setup a comprehensive web resource at www.palmoswerks.com to provide communications from the dev team here at Metrowerks to developers, and some of your objections could have been addressed via articles at this site. Our team is also very active in the Palm OS developer support forums, including the newsgroups from www.falch.net and the mailing lists hosted by palmos.com

Thanks for your time, and I do appreciate the review, even with my criticisms of it. If you still have the product, be sure to look in the Extras folder of the CD for some videos that were shot here at MW using the NX70V’s camera.”

Justin Lloyd: “Thank you very much for the feedback Ben, the criticisms are welcomed. I think that when Metrowerks brings its editor up to date that the CodeWarrior IDE will offer the best all round solution for cross-platform and embedded platform development.”

VERDICT

 

Metrowerks CodeWarrior 9 for Palm OS

Company: Metrowerks
Price: $399 for new users, $199 for upgrades
System Requirements: Intel Pentium or AMD K6 equivalent and 64MB of main memory. Window6s 98/Me/2000/XP or NT 4.0 with SP6, CD-ROM drive for installation, and 380MB of free hard drive space.

Rating

6 out of 10

Pros

1. Familiar environment when you move to other target platforms.
2. Large amolunts of documentation including a well-documented plug-in architecture.
3. Source level debugger supporting C, C++, 68K and ARM.

Cons

1. Incredibly primitive code editor.
2. More support for 68K than ARM.
3. Did I mention the incredibly primitive code editor.

This review originally appeared in the March, 2003 Game Developer Magazine and also on Gamasutra.

— Justin Lloyd