I spent a lot of time working through the issues of replacing the use of PICTs (Macintosh image format) with other standardized image formats this week. As I have written before, Apple has deprecated (made obsolete) the use of most of the Quickdraw imaging and drawing APIs in the Macintosh, effective in OS X 10.4. While they're still supported, they could go away at any time; so... I had to come up with another way of translating calculator screen images (which are simple bitmap byte arrays) into something displayable on a Macintosh, and able to be moved around the network. To do this, I'm using the new Quartz 2D API in Mac OS X. I can now create images by "painting" the pixels. I also found another way ( looking at some code written by another engineer ), but that method had the bad luck of not being able to translate from a core image in Quartz to anything other than a 1-bit deep TIFF image. I needed to be able to move from calculator screens to TIFF, GIF, PNG, and JPEG. My "painting" a color image from the pixel map seems to work for this capability.

Going the other way is a bit trickier. I came up with a method of taking the bitmap data from the various image formats and parsing through them to figure a threshold value for translating a potentially color image into a black and white bitmap. I've currently set the threshold at about 38% of black vs white. So far, it looks pretty good.

I've also been working with a few other things that are new to this release. Getting the software ready for the new Intel-based Macintosh systems means I've had to go through and fix a few data structures that are passed around the system via Apple Events. Contents of the data structure have to be stored in a fixed format to deal with "endian" issues. So, enter Core Endian "flippers". I've got one written to deal with the calculator directory structure that gets passed around. From preliminary testing, it looks like its working as advertised.

Next week, I'll be getting ready to start work on another project (part-time) that needs my expertise and ability. Back to my roots in embedded work and, unfortunately, back onto a Windows-based platform for developmental tools for this project. Oh well... necessary evil I guess...

This week in Billiards.... what can I say? Monday, our 9-Ball team had a "bye", so no pool... most of our team showed up regardless, just to watch another match between two of the other teams in our division.

Wednesday was frustrating in that we had a new schedule (again), and my team was playing short, with a number of players being simply unavailable and out of town. We (the players that were there) played as well as we could, but fell short. We had fun, but were frustrated as well. Hopefully, things will improve next week and we'll get things back on track.

One of the things that has changed in OS X this year is the deprecation of nearly everything PICT in the OS. PICTs have been the basic system representation for images on the Mac since the beginning. Quickdraw (used to make PICTS) was the default drawing environment. When OS X came along, the basic internal drawing is now done with Quartz, rather than Quickdraw. This change moves the drawing environment from a bitmap oriented system, to a "paint" style system.

So, what does this mean to TI Connect? TI Connect captures calculator screen images (which are very simple "bit" images, bit on, pixel on, bit off, pixel off. Internally, these have always been converted to a PICT using offscreen drawing techniques in Quickdraw. With the advent of PICT and most Quickdraw stuff being "deprecated" in OS X 10.4 (Tiger), TI Connect is going to need a new way of doing this work in the next update.

After a little discussion, and a lot of research, I'm moving the internal stuff to use Quartz when 10.4 is detected (PICTs and Quickdraw will still be used on 10.2 and 10.3). Basically, to make a Quartz image of the calculator screen, I paint a rectangle of an appropriate size all white (or green, if colored screens are wanted), and then paint a bunch of black "pixels" (a 1 x 1 rectangle) on the canvas. The resulting image is then converted to a PNG and passed around in that format. This appears to work pretty well so far. But of course, Friday rolled around, and I came up with another issue. We've historically had the ability to send images back to the calculator as well, in calculator-native formats. This was done with, you guessed it, PICTs, as an intermediary format, and extracting the bits out by copying the image data into a one pixel-depth (black and white) image. So, with PICTs basically gone for all intents and purposes, I'll need to design a new way of doing this next week. I've already got some ideas. I'll just have to see if they work out!

I've also got to spend some time next week to get our automated build system back up and running, now that I've had the source for all my projects moved from my "personal" CVS server over to the departmental build machines and their CVS servers. Hopefully, it'll be a fairly straight-forward move. Then, I can start thinking about the new process we'll have to use for the upcoming TI Connect release (which should be a "universal" binary image). If you want to know about what this means, go over to Apple's website and read up on it!

This week at work, I spent some time going over the list of features that are still not implemented in TI Connect for OS X (I have a LOT of features I'd really *like* to implement; some will be, other's won't). I added in several "viewers" for types of data that we did not have editors already implemented for, and also reworked the auto-refresh feature of the screen capture. I didn't really like the way it worked before as it was somewhat susceptible to timing out on the capture, and then, just stopping the capture sequence.

I'm still not sure when the next update will be approved or shipped (we're talking some months here for sure), but I've got plenty of things to work on in the software; new features, modifying older features, updates and corrections, as well as dealing with the changeover to the new Intel architecture announced by Apple at the 2005 WWDC. Bottom line; I'm having fun with this stuff and still really like my job after all these years (just made 23 years at Texas Instruments this year)

9-Ball this week was fun; we lost the match, but we had fun. Excellent opponents to play against, and generally a great time.

8-Ball is the story of the week though. With the way the league is set up, the schedule for matches fluctuates and changes rather fluidly the first few weeks of the session. This session was not different than in the past in this respect. We had traveled to a new club for our week 2 match, only to have there be no opponent present. This week, with a re-shuffled schedule, I traveled there to see if the other team would be there or not. Turns out, the answer was "not", so I called the remainder of my team and let them know the news. After some time sitting there at the bar talking with a number of very nice and friendly folks, I headed back to my "home" club, Drinks, and spent the evening with some friends there, watching them play their darts match in the DDA (Dallas Darts Association) league.

The pool match? Wrote it up as another forfeit; which makes 2 now, against the same "team", in 5 weeks of play... we're off to a slow start this session for sure.

I'm currently captain of two billiards teams, playing the APA league here in Dallas. On Monday's, my team, "Who's Next?" plays 9-Ball. The team has been in a "rebuild" mode the first part of this session, basically finding the right players for the team. This week, we added a couple of new players (new to our team anyway). We won our match this week; week 4 of the Fall session; after losing the week before.

My Wednesday evening 8-Ball team; "Stirred, Not Shaken"; had a bit rougher match this week and lost the match. This coming week we travel once more to the "M & M Pouring Company" on Northwest Highway. The last time we were there, the other team was still forming, and didn't show up. This time, I'm hoping for a good match and lots of fun. We'll see...

I'm playing around with the new RapidWeaver 3.2 public beta. It looks really good and I like a number of its features over the previous 3.1 version.