April 13, 2003

OpenGL Day One

Day one of learning OpenGL:

  1. Went to NeHe, grabbed base Windows framework (I just learned Windows programming this week too ;). Thankfully, there is a glut of information about OpenGL game programming on the web. Those tutorials are helping; I think these will too, especially the one about importing .3DS files.
  2. Implemented basic engine structure for creating a tree of 3D objects whose locations are relative to each other, and too many virtual methods (I will have to change to a non-virtual setup later once I understand better what I'm doing and have fewer base-level objects). Found out OpenGL seems to require you to push out all the polygons all the time. Hopefully there is a method of doing hardware-level display lists (I have heard there is).
  3. Tested with a Polygon2D class, building a triangle and septagon and moving and rotating them. Found out that rotation and translation matrices go backwards in OpenGL; therefore, first you apply the translation and then you apply the rotation, when what you're really trying to do is rotate first and then translate. It turns out this makes it easier to slave objects to one another though (you can build the parent matrix first, save it, write your child transformation, and restore the parent matrix when you are done).
  4. Angular Velocity. Time to learn math. After much digging and frustration scrawling stuff on paper, I found this helpful site which summed a lot of it up. I was trying to work with axis/angle representation, which is what OpenGL uses, and found that combining two rotations (which is what you basically need to do when you are implementing angular velocity) is just not something anyone talks about; and the math is hard. So after more digging and paper-scrawl, I converted to the strange, non-intuitive Quaternions which at least had an algorithm for rotating a point. Finally I found this wonderful page to help me along, and got the remaining kinks worked out in a jiffy. Now my objects spin on their own happily.
  5. Object Slaving Test. Finally, time came to put together the day's work; after working out a few bugs, I now have objects that are slaved to other objects' coordinate systems, so that when you rotate object A object B automatically rotates around it, and B moves when A moves; and any rotations object B. It's like having a person (object B) sitting on a flying saucer. When the saucer moves, the person moves with it, of course; and when the saucer rotates, the person stays in the same place on the saucer but rotates relative to the world.

Today is for polyhedrons and basic collision detection.

I think the beer helped. Foster's is pretty darn good.

Posted by jkeiser at April 13, 2003 10:36 AM
Comments

Okay, I just told you what Apple wants you to look out for with window positions, but in the real world, not everyone uses the hiding feature of the Dock, and it is unrealistic to be able to predict where each user will place their Dock at any given day or how large they will have it. However, you can build a feature into your application that allows spacing for the Finder. You can give users the option of where to position their windows and what area of the screen not to cross. I know that BBEdit provides me with this feature, and I wish more developers gave me more control over my windows.

Posted by: Grace at January 25, 2004 4:01 PM

So far in these articles, I have only dipped a toe or two into Aqua's pool. I have covered basic aspects of building an Aqua-compliant application, including the building of photo-illustrative/3D application icons. Now it's time to address other components of our Mac OS X application.

Posted by: Jennette at January 25, 2004 4:01 PM

Clicking an application in the dock should always bring forward an active window. If the user clicks on an open app's icon in the Dock, the application is active and all unminimized windows come along with it. I have found a few problems with windows behaving independently of their application.

Posted by: Susanna at January 25, 2004 4:01 PM

In building your amazing Aqua application, one of the most important things to consider is the Dock. There are three things your app needs to be "Dock Compliant." Now, I write this knowing that the Dock will be going through some major changes soon, but for the most part, these should still hold true.

Posted by: Isaac at January 25, 2004 4:01 PM

But limit your animations to whatever is required to communicate the necessary information. Avoid annoying animations that discourage ease of use. Ask yourself, "What do I need to show the user, and what is the cleanest way possible to achieve that?" A good example is the Mail application for Mac OS X. Whenever a new message arrives, the Dock icon changes appearance to indicate a changed state.

Posted by: Humphrey at January 25, 2004 4:01 PM

At WWDC, I listened to Apple representatives make some excellent points about taking the time to build a 100%-compliant Aqua application, and I think all developers need to look beyond the code and listen to what the folks at Apple have to say

Posted by: Silvester at January 25, 2004 4:01 PM

For example, if you see an AIM window peeking out from behind your browser and you click on it, that window will come to the front, but the main application window will not. The Mail.app/Activity Viewer is another example. The Aqua system of layers works well in many instances, but not in all. Thank goodness that the Dock is always there to come to the rescue. I know that clicking on an application icon in the Dock will always result in not only the application coming to the front, but also any non-minimized windows associated with it. And if the application is active but no windows are open, clicking on the Dock icon should create a new window in that application.

Posted by: Magdalen at January 25, 2004 4:02 PM

In building your amazing Aqua application, one of the most important things to consider is the Dock. There are three things your app needs to be "Dock Compliant." Now, I write this knowing that the Dock will be going through some major changes soon, but for the most part, these should still hold true.

Posted by: Mable at January 25, 2004 4:02 PM

Adhere to File Locations. Make sure that when your users save documents, your application knows where to put them and also gives users flexibility.

Posted by: Jeremy at January 25, 2004 4:02 PM

Not quite as entertaining as Shrek, but Dock animation can be an important and useful function in your application. For example, Dock animation is a helpful way to indicate the status of your application.

Posted by: Edward at January 25, 2004 4:02 PM