Another fellow just popped his head up with a patch that fixes Unifont in the GLDK. The Unifont Project is a bitmap font that implements the entire Unicode character map. Berlin uses it as a fallback when no other fonts can be found. (Or in the case of GLDK, freetype support just plain isn't implemented yet.) This is great because it means that I don't have to fix it myself. I was planning to do that as soon as possible after landing the SDL/GL rewrite by rewriting the GLUnifont code using display lists and texfonts. It's a lot of work saved.

As for the SDL/GL rewrite, it's finally coming along. I've decided to move the Pointer out of the DrawingKit and into the Console. Also, the GLDrawingKit will never use any Drawable. Instead, it'll ask the Console to activate its the GL context mode, so that the GLDK can make whatever GL calls it wants. This is by far the cleanest solution, except that it means that the server would be running without any Drawable at all and the server tries talking to the Drawable in several places. Interestingly, most of them have to do with the mouse pointer and that's now in the Console too. The other calls to Drawables have been diked in my latest patch too. I'm no longer releasing hwaccel revisions because my latest patch doesn't actually support hwaccel yet. In fact, it even breaks SDL completely, but at least everything will work perfectly when I'm done.

I now understand why I couldn't create a SDLDrawableGL. The console tries to keep them in a STL vector of type DrawableTie<SDLDrawable>. I'm still looking for a good source of documentation on the Standard Template Library, but I now know what a vector is: an array of similarly typed objects, type-enforced at compile time. I should consider doing the same thing with my new Pointer/PointerTie setup because every time you call Console::pointer() you get a new object instead of a reference to the pointer you want. How should we handle multiple pointers? Or should we?