ダニエルの冒険

I’m trying out a new template now. It’s Aeros 2.0 with my own background. To create the image, I took one of my shots of Tokyo, resized and chopped it 1680×1050 (sorry all you people with 1920px wide monitors! ), and saved to a JPEG of 100kb.

Motivations for the blurring:

• Lots of sharp lines that aren’t part of the layout/content overpower the design and make it difficult to focus on what’s important. (Yes, my writing is important.)
• Not sure how successful the effect is, but I like the idea that the city is in the background, but the reader’s vision is focussed on the content in the foreground.
• Blurring reduces JPEG compression artefacts.

As a side-note, my good friend Stefan has started a new blog, Death By Recursion. The name sums up the focus of the site: death metal and coding/security. Though there’s some speed metal I enjoy (Sex Machineguns and Dragonforce, thanks to Guitar Hero of course), I’ve never been able to put up with the death growl before getting tired of it after one track, but the security articles are really worth reading, even if you only have a passing interest: Stef has kindly written everything very accessibly (which I’m assuming has a lot to do with his Google AdSense get-rich-quick scheme).

Until now I had avoided globals in my code, which I think is a good idea in general, but when I realised how many times so many of my classes were being access through their singleton accessors, I decided enough is enough and a few regex find and replaces later my code is set up with globals instead.

I don’t know why I didn’t have the confidence to do it before, now that I look at it. I should be saving a hundred or two calls every frame, or maybe about 10,000 every second!

Goodbye, YkdGraphicsSubsystem::getSingletonPtr(), hello gGraphicsSubsystem!!

Yesterday I was having trouble with the iPod accelerometer’s response time on the PC. I found it laggy to the point that it wasn’t really usable, and then realised that since I got rid of any threading on the iPod side, the whole thing blocks while it receives the image to display on the screen (about 50kb per image).

I came up with a way of having one thread receive the image, then set a flag for the main thread to check periodically in its main loop (with an NSTimer), and then receive the next image once the flag was reset by the main thread (indicating it had been consumed and put on the screen).

Before I started hacking into that, it occurred to me that I was sending a UDP datagram to the iPod telling it that an image was on the way first, and then transmitting the image over a TCP stream. I realised how silly that was, swapped the ordering so the datagram came after the image data stream had been written to the TCP socket, and in its new role as indicating that an image had been sent (as opposed to indicating one was about to be sent), the lag disappeared! Turns out that once the data is ready to be retrieved right away, the blocking recv() call in the main thread isn’t anything to be worried about! Hurrah!