Quote:Original post by smjones
Seems Mr. Eberly is fond of configurations...

Yes, I am. Why are you surprised? Some folks want to link in static libraries, some folks want to use dynamic libraries. I provide debug and release versions of both. Some folks want to use OpenGL on Windows (wgl), others want DirectX. Some folks use Linux, some the Mac. And some folks want GLUT. Some applications do not need a window (my engine is not all about graphics). When you start adding up what *everyone* wants, you get a large number of configurations. I try to provide what folks want.

Quote:
So one beef I have with that is that his Release notes that shipped with the source code did not mention it.

Sigh... I'll try do to better. I keep hoping folks will be less critical when they realize the amount of effort it takes one person to maintain such a large code base for multiple platforms and multiple compilers. Guess I'll have to keep hoping.

Quote:
Is there any other reason than naming why Wild Magic version 3.0 which shipped with the book I just got and version 3.2 (from web site) changed Source to Foundation?

Because "Source" sounds so boring and nondescriptive? The Source folders do contain what I consider the foundation for everything else (graphics, image processing, numerical methods, computational geometry).

Quote:Original post by hoLogramm
I also have a question concerning the Wm3Transformation - class:
Why did you decide to store the Rotations in a 3x3 Matrix and not in a Quaternion?
Is it easier to composite all the Transformations together in the end when using a Matrix?

Given the fears people have with the Dreaded Quaternions, I just stuck to using rotation matrices (like I did in NetImmerse). Maybe a later version will switch to quaternions. You still have to convert from quaternion to rotation matrix to feed the graphics APIS.

Quote:
As for the compilation question i had no troubles at all compiling on Windows. Only on linux it complained about the Reference Counter being unknown i think but i don't know exactly. I am using Suse 9.1.
I'll post here later when i got it working.

You should email the error messages to me. g++ on various Linux platforms can have strange quirks. I might be able to figure out what the error is about, even though I do not have Suse Linux to test with.

Sigh... I'll try do to better. I keep hoping folks will be less critical when they realize the amount of effort it takes one person to maintain such a large code base for multiple platforms and multiple compilers. Guess I'll have to keep hoping.

Quote:Because "Source" sounds so boring and nondescriptive? The Source folders do contain what I consider the foundation for everything else (graphics, image processing, numerical methods, computational geometry).

Works for me. I was just curious.

I don't mean to be so critical. It was a little frustrating to be stuck so early into the process. The book looks very promising. There is so much information on how to do many separate functions of a game engine but your book is the first (good one) that shows how to put *most* of it together into a single engine. I say most because it would take a set of books to include everything such as scripting, comprehensive GUI development, and such.

As far as being a lot of work, I don't doubt it. Maybe there are other people like the publisher or editors who can help bring important things up to date like web site names and release notes. Then again maybe not.

I own another popular engine that I'm a bit torqued (*grin*) about because it too is comprehesive like yours but the source code is anything but easy to follow. I'm a professional programmer and its imperative IMHO to have good source code comments and good structure to, at least, be able to maintain the blasted stuff. The documentation for that engine is mostly scattered all over kingdom come. You have to find out things from help files, articles from other users and forums. Its nice to have a single reference (book) that explains the engine.

So far I like what is found in the book and source files. Good job!

-SJ

Quote:Original post by smjones
I don't mean to be so critical. It was a little frustrating to be stuck so early into the process. The book looks very promising. There is so much information on how to do many separate functions of a game engine but your book is the first (good one) that shows how to put *most* of it together into a single engine. I say most because it would take a set of books to include everything such as scripting, comprehensive GUI development, and such.

I apologize for the frustration, but as a single-developer product, I have only a limited amount of time to spend on it, the remaining time spent on making a living. Technical book writing will not make you a fortune, and in most cases will not even make you a living. I am soon to post WM3.3 and will include the information about the Debug/Application problem.

Quote:
As far as being a lot of work, I don't doubt it. Maybe there are other people like the publisher or editors who can help bring important things up to date like web site names and release notes. Then again maybe not.

Book publishers will help a little, but not a lot. They have a budget for a book. The margins on sales are small enough that they are careful about expenditures related to the books. One way to reduce costs is to use cheap paper and bindings, but MKP has high standards and insists on good quality paper and bindings and on having books with significant content. So they are even more careful about expenditures. This is the Right Thing to do for their customers.

Quote:
I own another popular engine that I'm a bit torqued (*grin*) about because it too is comprehesive like yours but the source code is anything but easy to follow. I'm a professional programmer and its imperative IMHO to have good source code comments and good structure to, at least, be able to maintain the blasted stuff. The documentation for that engine is mostly scattered all over kingdom come. You have to find out things from help files, articles from other users and forums. Its nice to have a single reference (book) that explains the engine.

Taking the extra steps to have high quality code in all regards (structure, readability, comments, consistency, etc.) runs into the Law of Diminishing Returns. Code development invariably trades off these extra steps for timeliness in shipping. If it mainly works, ship it. Wait until customers start complaining until you fix the problems. Write extensive documentation only if your life is threatened. This is the way things work :)

Quote:
So far I like what is found in the book and source files. Good job!

Thank you for the compliment.

I can't open geometrictools.com now.
Is it down ?
Or It have been moved to another place?
Tell me, thanks!

Just checked, and www.geometrictools.com opened fine for me.

[Edited by - Will F on August 31, 2005 1:10:11 AM]

Oh, That's bad.
I'm in China, Both my friends can't open the site.
I really don't know what the hell our internet sp is doing.
what could I do?

greetings david eberly. im a fan of your work(writings, wild magic, books). i have your game physics books and i must say its very good. from ideas to complete code example. i say its worth every penny. i wish had the money to purchased all your books. maybe next year.

keep up the excellent work. and by the way, the magic software company is totally evil. you should have the trademarks, not them. we all know wildmagic as your outstanding work, and they steal it. lets just hope the company will defunct in the next few years. and all the success to david eberly. ;)