OpenGL Point Sprites – 2 things to know…

Been playing around with OpenGL ES and most recently with Point Sprites (e.g., glDrawArrays( GL_POINTS, …) ). Today I got textures rendering onto the points (whose size > 1.0, obviously) but ran into two show-stoppers:

First, I do not see that it is possible to use a Texture Atlas with portions of a texture mapped onto Point Sprites in OpenGL ES 1.1.  You can only map the entire Texture onto the point.  Based on my reading, I can see that with a custom shader you should be able to do this in OpenGL ES 2.0, but haven’t tried that yet.

Looking around to see if I was doing something wrong I came across this from the spec and I think that’s what this is saying:

When point sprite is enabled and the GL_COORD_REPLACE_ARB state for a given texture unit is GL_TRUE, the texture coordinate set for that texture unit is (s,t,0,1) where the point sprite-overridden s and t are described in the amended Section 3.3 below. The important point is that r and q are forced to 0 and 1, respectively.

(emphasis mine).

This from:

Certainly if someone knows how to map a portion of a Texture onto a Point in openGL ES 1.1, I’d like to hear about it.

Otherwise, hopefully this’ll save someone some time.

Second, note that if you are using them for a game and you want the object they represent to be partially off-screen, you are in trouble;  Point Sprites are clipped when the point is offscreen, and the point is in the center of the point sprite.  Thus, when your object gets just slightly over half off the screen, “POOF!”, it’s completely gone.

Indie Developers: Put a link to your website in help menu!

It happens too often: I open an application because I can’t remember the company name or website address and found that there is no place in the application to get to the website. This is crazy!

This usually happens for those small applications that I don’t use often, but that I think are useful (I won’t name any names here, but if you’ve been in a MacHeist bundle you might check your application for this omission).

Put a link to the website in your about box. Put a “Visit” menu item in your Help menu or in your Application menu if you don’t have a help menu.  (ok ok, use your own domain, but you get the idea :-)).

This is a critical element of your marketing campaign. Yes, automatic checking for updates is a good thing and you need that.  But what if I’m wondering if you have any other products I might be interested in? What if I want to tell a friend about your product and want the URL to copy and paste into an email to them?

You should also include a way to report a bug or get support.  Now this might take the user to a forum (as a user I hate forums, especially if I have to “join” or “register”), or open a new email message  in the default mail application, or take me to a form on your website. Whatever it is, you need something easy and visible to the user.  This is how you are going to get ideas for future versions.  This is how you are going to impress your customers with your incredible support – the kind of impression that gets them to talk to their friends about your application and increases your sales.

ok. off my soapbox. have a nice day.

Teaching Geek std C – forgot the pain of it!

Teaching Geek std C and I’d really forgotten the pain of working in non-oop std C land.

First hurdle he hit was returning a multidimensional array from a function (the map from the () function). So he figured out from the docs that the had to return a pointer to the array but then had to learn about stack variables going away when a function returns…

I’d forgotten just how painful allocating and deallocating multidimensional arrays in std C is, especially if you actually put in the error checking and code to clean up if you fail part way through allocating all the second level array memory.

He kept telling me how much easier this would be in Python. Which made me think of Apple’s latest restriction on languages allowed on the iPhone OS. Tying yourself to old school languages can be a problem in the long haul… ObjectiveC has evolved some, however it clearly needs to keep evolving as the hardware gets faster (e.g., garbage collection) or the entire platform gets left behind. Obviously this is not an immediate issue, nor even a near term issue, but at some point it may be.

Meggy Jr. RGB from Evil Mad Scientist Labs – Good Stuff!

Geek built the Meggy Jr. RGB from the Evil Mad Scientist Laboratories store.  It was moderately challenging to solder because Geek hasn’t done a great deal of that yet – one small project, and an Arduino open source electronics prototyping platform “shield” from Adafruit Industries called the “Adafruit Proto Shield for Arduino kit – it’s on sale currently (March 4, 2010) and a really useful board if you have an Arduino NG, Diecimila, or Duemilanove model of the Arduino open source platform.

Anyway, back to the Meggy Jr. RGB!  It’s an open source LED Matrix game development kit based on the same AVR microcontroller family that is at the heart of the Arduino platform.  As a result, you can program the Meggy Jr. RGB with the Arduino software and the specifics of the Meggy Jr. RGB are made easier by a high-level library that EMSL provides.

Meggy Jr. RGB board mid-build
Meggy Jr. RGB board mid-build

The build was pretty straightforward thanks to excellent instructions included with the project, but it did take Geek a number of hours (3?) to complete the whole thing.  We took a break for lunch, but other than that he worked straight through on it and really wanted to get it done and start programming it.  Some younger kids may not have the patience to complete this big of a project.  There are some pins that are pretty close together and I had to guide Geek on how to steady his hands and how to put minimal solder onto the joints (got a few solder bridges, but we were able to clean them up ok).

Geek building the Meggy Jr. RGB
Geek building the Meggy Jr. RGB

The only criticism I have for the Meggy Jr. RGB kit is that we got the “Super Kit” version (which you want – not having handles/covers means your fingertips can (and do!) short out wires and cause it to not function properly and  the AC adaptor is a really good idea to keep endless battery use down) and had a problem with the switches and the precision of the laser cut holes in the handles/covers.   The laser cut classic handle set is cut so tightly that we had a problem with switches that were not exactly positioned hanging up on the top handle and preventing it from working properly.  The holes for the switches should be slightly larger to provide a little more “give” in the build, and the instructions should be very clear about the need to get the switches pressed down completely against the circuit board so that their relative position and orientation is perfect.  I’ve passed this on to EMSL.

Geek has had a great time programming games, and modifying some of the many (!) games you can find on the EMSL wiki.  It’s surprising just how fun of a game you can make with and 8×8 RGB LED matrix, 8 additional LEDs and sound generation ability.  The 8×8 grid are RGB LEDs and you can control their color quite easily so there is quite a bit of variation possible.

Completed Meggy Jr. RGB
Completed Meggy Jr. RGB

After modifying the enhanced version of the default starter game that he found on the wiki, he started his own – the game of “Go” which is actually quite challenging to do at this scale.  Some clever tricks and he has something interesting, though not yet complete.

In any case, if you have a capable kid who likes to solder and has some computer programming skills (basic “C” style syntax, but mostly just simple stuff), then this is quite a fun project – build it and then create games to play on it!


Completed Meggy Jr. RGB with better light. The clear covers are cool because you can see the circuitry inside.

Xcode user defaults allows some good stuff!

Thanks to @ddribin for the reminder that Xcode user defaults contains some good stuff.

Apple documentation is here.

Here are the settings I just set different from the defaults (yah, I know, I like lots of space):

defaults write XCCodeSenseFormattingOptions -dict InExpressionsSpacing " " InFunctionArgsSpacing " " InMessageSpacing " " PostColonSpacing " " MessageArgSpacing " " BlockSeparator "\n"

Not sure that’s all how I want it yet, but hopefully that’ll fix a few things I dislike (like when I select something in the help text and it’s pasted in all cramped with no white space.

Unfortunately, MessageArgSpacing doesn’t seem to be working… in Xcode v3.1.4 anyway… 😦

Reminder that the application shouldn’t be running when you’re editing user defaults.

iPad design

Geek & Dad have a coveted early-access developer iPad? How in the world did we get on that list?!

Geek & Dad only has one small app in the AppStore! Maybe Apple’s trying to motivate young programmers for that’s where they see the innovation coming from? Astounding!

Ah, not quite 🙂 :

Reality: after reading a tweet by @ravenme, dad decided to make an iPad prototype to get a sense of how users will interact with the device. Definitely helps to get a feel for it! However, the pictures above before dad realized it needs to weigh more.   Matte board and cardboard make for a very light iPad!  Dad quickly realized that he was holding it in portrait mode with one hand in a manner that was not something users were going to be doing (at least not for long.  Adding weight is clearly needed. That’s next.

Fun experiment.

Launch Services Database; 64 bit vs 32 bit on 10.5.x

Some notes on using lsregister to modify the launch services database to get the Finder to acknowledge changes you’ve made to your info.plist. Also sample info.plist entries to get your app to launch in 32 bit mode in 10.5.8 and 64 bit mode in 10.6.

Dad was working on a Mac Application and put in the entries in the info.plist so that the application would launch as 32bit in 10.5.x and 64 bit in 10.6 and later.  Unfortunately, it wasn’t doing the right thing and it took some detective work to track it down.

Turns out this application was using a slightly modified version of Chris Campbell’s SystemVersionCheck shim and it launches the real executable via execv which seems to ignore LSMinimumSystemVersionByArchitecture and code>LSArchitecturePriority and always seems to launch the first architecture in the application executable (not 100% sure on what rules it uses to decide).

What works without the system check launch thing is this:


While trying to track this down I ended up wanting to purge the entries in the Launch Services database. The lsregister tool is used to do this, and there is an applescript out there that’ll do it with a GUI and force a complete rebuild. If you want a more surgical approach, you can use commands like:

./lsregister -dump > ~/Desktop/ls_dump

to get a dump of the launch services database to figure out what’s going on. Note that ./lsregister -h provides helpful information.

I ended up using the ./lsregister -f -r -v -u {path_to_parent_folder} version of the args to unregister an old bogus entry (and -v to see what was going on). Note that you can’t get rid of an entry at a path that no longer has the file – I had to put a copy of the app into the trash, run the -u version and then quickly empty the trash in order to get rid of an entry referencing it there.

In 10.5.x this tool is in the LaunchServices.framework/Support/ folder. LaunchServices is in CoreServices.framework/Frameworks/

or (sorry about formatting)


Note that in 10.6 this tool has moved to


and may have other commands (I was working in 10.5.8).

ok. Now I can find this info again when I forget 🙂

How Times change…

When Dad starting programming for the Mac it was in MacPascal (one quarter of freshman physics lab), then in Rascal [1] (on which he later worked), then LightSpeed Pascal (which became Think Pascal), and then Think C (previously LightSpeed C), and so on. [2]

However, when we were writing a Mac application back then we just needed to know one language (Pascal or C) and maybe some 68xxx assembler for interpreting what Macsbug was telling us (if writing low level code).  We did have to learn the Macintosh Toolbox which is equivalent to the class libraries of today (e.g., Cocoa) – Dad still has 2 feet of shelf space devoted to “Inside Macintosh” books from that era that probably should be recycled already :-).

In contrast, Dad is close to finishing an iPhone app for a client that displays data from a database on a server (and some live XML data feeds from the server).  To complete this project has required:

Server Side:

PHP, SQL, XSLT (+XPath), HTML, CSS, JavaScript, XML, Python, Apache2 config files, make files, command line syntax for svn, tar, pax, and various other command line tools.

iPhone Side:

Objective-C, HTML, CSS, JavaScript, XSLT (+XPath), XML, Property Lists (yes, just a variant on XML, but need to know the differences), and shell scripts (for a Run Script in Xcode).

So, the point is, Wow! The breadth of knowledge that is required to create the software we create today is astounding compared to what it was back when this adventure started 25 years ago.

Not the new Rascal languages (rascal-lang or the Rascal DSL meta programming language), the old one (dare I say original one 🙂) which was the first (or one of the first) native IDEs that would let you program the Mac in something other than assembly language without a Lisa (see 1985 entry at old one, but it was in development before then I believe).

For the history nuts, my older-than-40-memory says my complete sequence on the Mac was roughly:  MacPascal, Rascal, Consulair C, LightSpeed Pascal,  Think Pascal, Think C, Think C++ (TCL – Think Class Libraries), MPW Objective Pascal (MacApp) & C++, Metrowerks CodeWarrior C/C++ (PowerPlant), Xcode C (Carbon) and Objective C (Cocoa) and now on the iPhone Xcode Objective C (Cocoa Touch).

Some of the relevant history is here (Dad was there from 1984-1990 and hanging out and eventually working in the “DLab” from sometime in late 1985 or early 1986 onward).  The rest is work related from 1990 onwards.

Lots of other side languages for learning, fun and contracts over the years, some on the Mac, some not:  Basic & Pascal (high school, before Mac), 68k assembler (MacAsm originally), 8051 assembler, Java, Smalltalk, Lisp, Eiffel, Visual Basic, Visual C++, whatever PocketPC required (straight C? can’t remember), and so on.   What a strange soup of names.  What’s it all mean? ha!

Make Xcode stop prompting to save files in other editors

Tired of having Xcode (3.x and later) prompt to you “Save Changes To ‘index.html’ before building?” when index.html is open in TextWrangler/BBedit and so on and has _nothing_ to do with the current iphone project you are working on? Read on for the answer!

The easy way is to just set the “For Unsaved Files” setting in the Building section of the Xcode preferences to not prompt you, but this defeats the prompt for files IN Xcode that you maybe DO want to be prompted to save.

In Xcode there was support for “external editors”. In Xcode 3.x I don’t see the UI for configuring these any longer so I’m not sure if it still exists or not. In any case, this functionality is the cause of the annoying prompts to save totally unrelated files other editors.

The list of external editors is in the file in your ~/Library/Preferences/ folder and removing that list “solves” the problem. There may be better ways to solve it, but this is the one I found that works.

The two keys are XCExternalEditorList, and PBXExternalEditorList, however in my test only the second one had to be removed to make these annoying prompts go away; in the terminal:

$ defaults delete PBXExternalEditorList

Of course Xcode shouldn’t be running when you do that or it’ll either ignore you or just rewrite them into the file.

*** Note that you probably DO want Interface Builder in the list of external editors in XCExternalEditorList (the newer key), so if you want to remove entries from that one, do them individually instead of removing the entire block of entries ***


Work-around for multiple iPhone Dev account and code signing and Xcode Organizer problems

Xcode gives errors when you have multiple iPhone developer accounts and the name on the keys for the certificate are the same. This post outlines the two areas (Xcode Organizer and code signing) where there are problems and provides work-arounds.

Update 2/2010: This is no longer a problem because apple now issues certificates with a hex hash after the name.  So if you regenerate all your certificates and profiles they can then all live in your login keychain just fine (you’ll have to delete the old ones).


Ok, maybe everyone else already knows this, but since it boggled apple dev support (the bug I wrote 6635822 and the duplicate someone else opened, 6229180 both seem to still be open) I thought I’d write about the work-around I figured out today:

First, the problems:

There are two related problems, with two related work-arounds.

Both problems arise when you have two iPhone developer accounts and the name on the keys for the certificates are the same (likely since you are required to use a person’s name and your real name when signing up with Apple, AND your name on the certificate request has to be the same as what you signed up with).