Plaidophile

XCode is actually pretty easy to do things in, once you know how to do them. It's just not that easy to figure some things out.

Anyway. Silly little app which has laid the groundwork for me to actually grok OSX application development. Yay!

This little exercise has caused me to drastically rethink how I was going to port Solace to different platforms, though. Originally I was basically just going to make my own windowing toolkit which would then have to be pooted on top of other toolkits, but I've come to realize that the whole reason for me doing that (not wanting to make N*M layers for N toolkits and M rasterizers) was pretty dumb to begin with.

Aside from OpenGL and the mythical software rasterizer, all other rasterizers (e.g. PS2-EE) would be pretty specific to the single platform. Furthermore, neither OpenGL nor software rasterization need much of an interface; OpenGL just needs the windowing system to configure the OpenGL context and pass it a viewing portal size, and software rasterization just needs to be pooted an unsigned char * (or, vector<char>& or whatever) and a viewing portal size.

So um. It would make a lot more sense to just create toolkit-specific wrappers for each of the rasterizer backends, and then have the toolkit stuff deal with which rasterizers get used and how and blah blah. The thing is, I was assuming that the entire public interface should be identical for each rasterizer type, but that's not true at all. I see it as being something like this:

class Driver { // the abstract rasterizer class
public:
    /* Rasterization stuff goes here */
};

class DriverGL { // OpenGL rasterizer
public:
    Setup(int x, int y, int w, int h);
    /* Rasterization stuff goes here */
};

class DriverSoft { // Software rasterizer
public:
    Setup(vector<unsigned char>& fbuf, int x, int y, int w, int h);
    /* Rasterization stuff goes here */
};

This means that apps will have to be rewritten for each toolkit layer, but that's better than just having a single unwieldy toolkit sitting on top of each one anyway. And there can still be reusable application objects which can be reused across different platforms and so on, they just need new simple interfaces put around them (but could get much more complex ones for different toolkits as well).

In keeping with Cocoa/NeXTStep standards, the names for the Solace widgets should be fairly obvious: SolaceView as the base class (derived from NSRect), with SolaceOpenGLView and SolaceSoftwareView derived from it. Or maybe it'd be better to have SolaceOpenGLView and SolaceSoftwareView derive from their respective things (NSOpenGLView and NSWhateverAPixmapStyleDrawableIsView) and then they just follow a Solace protocol or something. I'm not sure which would be easier... I think deriving from NSRect and then containing the appropriate drawable class is cleaner, though. I really don't think it makes much difference in this case anyway, and my gut instinct is that deriving from NSRect would be easier to deal with programmatically. Though with SolaceView I'm not sure what it should do for the actual rendering... it seems like abstracts are supposed to just do nothing, but that seems wrong from a C++ perspective (where abstracts are supposed to be specifically abstract and cause the program to not compile).

But on the other hand, if you just instantiate an NSOpenGLView it's true that it doesn't really "do" anything, except that programmatically-speaking it sets up the OpenGL context and so on, and then by subclassing from that you just put the drawRect method on it. But that's anathema to how this widget is supposed to work to begin with. Like, a View object is supposed to put in the high-level application behavior, and simply use toolkit things, or something...

Wait, duh, it's a computer. There's no one right way to do things.

But I want to name my objects right. What's the correct way to think about this? I can't really think of an analog in any other problem space... This situation appears to be totally unique to the world of cross-platform 3D graphics. :)