Wednesday, December 30, 2009

It’s been a while since my last post, one reason is that I was away on a vacation, another that it’s the holiday season, and another one that I caught a bad bad cold out in the snow. Well, enough with the excuses, it’s time for some interesting programming blogging. Santa brought me a brand new Mac, so I will venture into the unknown (to me, at least) territory of Cocoa with OpenGL.

Nearly a year ago, I threw together an OpenGL demo for the iPhone. This was a bit of a hack, since I merely called my plain old C code from an Xcode template. While this works, it’s not really the right way to go about when developing for iPhone, nor the Mac.

When you say Cocoa, you say it in Objective-C. This weird dialect of C has some pretty powerful features that should probably best be left alone and kept for later. The basics, however, are exactly the same as in any other OOP language that you may have encountered before—you have a class, members, methods, a constructor, and inheritance.

When learning a new programming language I usually go through these stages:

1. read about it, get sick over the syntax, and hate it
2. don’t actually use it, and keep complaining about the syntax
3. let it rest for a while, sometimes for as long as a couple of months
4. read about it a little more
5. use it, and fall in love with it (if it’s good)

Objective-C is good stuff. Although the APIs are from a totally different world than where I come from, I cannot help but think how Objective-C could have helped me in past projects. In Objective-C, everything is automatically reference counted, effectively taking care of the most difficult problems in C (and C++, for that matter), being memory management (e.g. with string manipulation) and pointers.

Strangely enough, developing Cocoa applications is not all about writing code. A part of “the magic” is done in the Interface Builder. With this tool you do not only draw your windows, but you also visually connect class instances together by drawing lines. This works not only for predefined classes, but also for classes that you newly created yourself (!).
When you think about it, it makes perfect sense for a windowing, event-driven operating system to have this kind of development model.
The applications themselves revolve around a design pattern called “Model-View-Controller”, where a “controller” controls the data that is behind the application, and sees to it that the view is being represented to the end user. While you are not obliged to follow this paradigm, the code will be quite clean and more reusable when implemented as such.

Enough talk, let’s get to the details. For implementing demos and games, what we need is an OpenGL window that reads keyboard and mouse input. Steve Jobs has summarized this for us in a Cocoa NSOpenGLView class. There is a lot of code on the internet that does not use NSOpenGLView, so my guess is that it’s a relatively new class. It makes things so much easier, once you know how to use it.
You should subclass it and call it something like MyOpenGLView. You can drag the NSOpenGLView into a window in the Interface Builder, and rename it in the Object Inspector. In the Object Inspector, you should also specify whether you want to have a depth buffer, stencil buffer, accumulator buffer, etc. or you won’t be able to use those. There is also a tab that allows you to specify how the view resizes, when the underlying window is resized.

Writing code for NSOpenGLView is easy, but like I said, you have to know how to use the predefined methods correctly.

/*
    initialize, but do not set the matrices or the viewport here
*/
-(void)prepareOpenGL {
    glClearColor(0, 0, 0, 1);
    glClearDepth(1);

    // load textures here
    // (I wrote a texture manager class to do this)

    glEnable(...);
}

/*
    this gets called when the window is resized
*/
-(void)reshape {
    NSRect boundsInPixelUnits = [self convertRectToBase:[self bounds]];
    glViewport(0, 0, boundsInPixelUnits.size.width, boundsInPixelUnits.size.height);

    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    glFrustum(...) or glOrtho(...) or gluPerspective(...)

    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
}

/*
    draw to screen
*/
-(void)drawRect:(NSRect)rect {
    glClear(...);
    glLoadIdentity();

    // reverse the camera ... or you could put this in a camera class
    glTranslatef(-cam_x, -cam_y, -cam_z);

    // draw stuff ... maybe do this from another class
    ...

    glFlush();
    GLenum err = glGetError();
    if (err != GL_NO_ERROR)
        NSLog(@"glGetError(): %d", (int)err);
}

To get keyboard and mouse input, use the keyDown and mouseDown methods. To get these events at all, you need to “tell” MacOS that you want to receive these events:

-(BOOL)acceptsFirstResponder { return YES; }
-(BOOL)becomeFirstResponder { return YES; }
-(BOOL)resignFirstResponder { return YES; }

keyDown will not see any meta-keys. For detecting key presses of the Ctrl, Shift, Alt/Option, Command keys and such, override the method flagsChanged.
You will find that MacOS key events have a method keyCode for getting the “virtual key code”. A virtual key code is like a keyboard scan code, only with different values. There appear to be no symbolic constants for these virtual key codes, so go ahead and make some #defines yourself. Mind that key codes are usable for cursor and meta keys, but you should never use them for the other keys because of keyboard layout issues—look for the unicode character instead.

There is a mouseMoved method that does not do anything by default. To enable mouse move events, do this:

-(void)awakeFromNib {
    [[self window] setAcceptsMouseMovedEvents:YES];
}

Now, you can put all your code concerned with keyboard and mouse input directly into the MyOpenGLView class, or you can be a good application developer and create a “controller” class that acts as a controller for the OpenGL view.
Create the class MyController as subclass of NSResponder. Put all the keyboard and mouse input code in MyController.m.

Add the controller definition to the MyOpenGLView class:

IBOutlet NSResponder *controller;

In Interface Builder, instantiate the MyController class and connect MyOpenGLView’s controller outlet to it.

To enable the controller, do this in awakeFromNib in MyOpenGLView:

-(void)awakeFromNib {
    [self setNextResponder:controller];
}

-(BOOL)acceptsFirstResponder { return YES; }

/* you may comment this one out now
-(BOOL)becomeFirstResponder { return YES; }
*/

Now, MyOpenGLView will not become a first responder, but it will set its controller as the next responder. Hence, the events will be sent to the controlling object.

After the controller has modified the model (e.g. the user is moving left), the view should be updated. Therefore the controller is also connected to the view … Updating the view becomes as easy as this:

[glview setNeedsDisplay:YES];

which will trigger drawRect in the MyOpenGLView class.

Games and demos usually run at a framerate, because there is so much going on, they update the screen all the time. The easiest way of getting this done, is by running the “main loop” as a timer function.

// set up timer for running the main loop

timer = [[NSTimer scheduledTimerWithTimeInterval:1/30.0f
                                          target:self selector:@selector(mainloop)
                                        userInfo:nil
                                         repeats:YES]
[[NSRunLoop currentRunLoop] addTimer:timer
                             forMode:NSEventTrackingRunLoopMode];

The funny thing is, you do not need to call update explicitly from this mainloop/timer function. All you do is move some monsters around and call setNeedsDisplay:YES whenever needed. Cocoa takes care of the rest.

NSOpenGLView does not provide a method for switching to fullscreen. I did find example code of how to do this on Mac Dev Center, but it looks advanced so I’ll leave it at that for now. It involves creating a new OpenGL context with a special attribute NSOpenGLPFAFullScreen in the pixel format, and then calling setFullScreen. You can “share” this context, meaning that it’s not needed to reload textures, reinitialize OpenGL, etc (which is great). What strikes me as odd, is that the example code utilizes an SDL-like event processing loop—exactly the kind that Cocoa is trying to hide from us.

For learning Objective-C and Cocoa, I recommend MacResearch. Although the man is a scientist, he knows how to explain things well enough to get you started. After a few lessons, it gets pretty advanced, at which point you should stop reading and try out programming some stuff yourself.