WTF apple!

Just spent a long time (as in several hours) stumbling on things that shouldn't have even been problems.

1) Multi-touch on the iPhone. The freaking canvas has to have a property set to enable multi-touch. You still get multi-touch if you don't enable it, but the data is random--which makes you think that the scale and translation you are applying to your canvas is wrong. I see no good reason for having the option of turning off multi-touch events, so whoever decided that I want my wasted hour back.

2) OpenGL errors on the iPhone. Put in some glGetErrors to trace down the few errors I was having. Oddly enough they seemed to be right around the calls that used GL_CLIP_PLANE1 (not GL_CLIP_PLANE0, just clip plane 1). Sure, that didn't seem to be a problem before, but what'evs--I can deal with it. Still some other textures that looked wrong. Turns out I inadvertently created some non-power-of-two textures (which work fine in new versions of OpenGL now-a-days). As soon as I realized this I decided to double check the clip plane problem. Sure enough, no longer a problem. Why in the hell was an error being reported on the CLIP_PLANE1 and not somewhere closer to the texture. Damn, damn, double damn.

And again

I found live ammunition on a bridge late last night. Made my day.

Still not much more luck with the lines. This rasterizes the current line, computes the signed distance from the line, extracts the level set at a specific distance, and then tries to connect the resulting polygons to the existing line. That's why the line appears to follow itself.

Slow. Downsampled they almost look like the embedded code images.

Line update

Some more lines. I have tried several different methods, and still nothing is giving me what I expect.

The code (which is a mess) because I wrote it at 3 in the morning is also embedded in the other not-so nice image (as usual).

Static is good, and static is great, but static initialization order sucks. I have had problems that could be attributed to static initialization in c++ before, but I wasn't entirely certain at the time that this was the problem. Just like an ugly memory bug, the static initialization order rears its head with meaningless memory access violations--which in my case seem to always end up deep in the stl. While porting something from linux to Mac, a simple re-ordering of the object files on the make line was enough to solve the problem. Wrapping the static variables in static functions to ensure an initialization order is clearly a better solution.

Obviously these things should become a problem and cause problems before main is even entered. I was also building the application for the iPhone and was experiencing problems with it as well. The problem was a segfault of sorts, and the stack was getting f'ed, and GDB was being almost hopeless. Of course, as I just had problems with static initialization I attributed these problems to be that beast. After several failed attempts at re-organizing the static initialization, digging through the semi-automatic resource handling code--I eventually followed the trail down the wormhole with the debugger to a buffer underflow error. Damn it! The only part of code that was different between the Linux/Mac version and the iPhone version was the loading of resources--which first have to dereferencee file names from the main application bundle. This code was different, and in the iPhone port I was using CFString and its reverse search to find the last occurrence of the '.' for file extensions. Obviously I wasn't checking to see if the return value was within bounds before computing a substring--which suprisingly wasn't being checked in the CFString substring functions. I'm certain I spent an hour looking for that. So obvious, but I was led astray by the static initialization. Cut again by Occam's---again and again and again.

Arduino

Got an arduino for x-mas and just got around to playing with it the last couple nights. Pretty damn fun. Learnt a little (pull-down and pull-up circuits).

Also started working on generating an image from a continuous line. Preliminary results and some embedded source code are linked in this page. The version is based on subdivision and post-processing.