Just got back from Tron: Legacy. It was, well, Tron. Very pretty with a very silly back story. I enjoyed it, but more for geek factor than anything else.
There was one MAJOR letdown though, and that's that the film makers had the chance to include the most epic XKCD inside joke EVER and they totally blew it! Shame on you!
Monday, December 20, 2010
Wednesday, November 17, 2010
I'm not dead yet!
Just wanted to drop in and leave a quick note to say that I haven't abandoned the blog, and I actually have a fun little project under way! Unfortunately I don't want to talk about it much at the moment, since I feel like this is something that could actually be marketable (probably via the Apple App store/Android Market). I'm also considering submitting it in it's web-based form to the Mozilla Game On competition. But that depends on how quickly and how well I can polish it up.
In any case, it is a game and I'm developing/prototyping it using HTML 5 tech like Canvas (no WebGL this time around, sorry!), Audio tags, and WebSockets. Great fodder for blog posts, but once again I would very much like to have a more complete version before I go chatting it up. Expect some updates in the next few weeks though! Even if I'm not talking about the game itself I'll probably want to talk about my experiences with the HTML 5 stuff. (I feel a rage post about the Audio tag brewing as we speak...)
Till then!
In any case, it is a game and I'm developing/prototyping it using HTML 5 tech like Canvas (no WebGL this time around, sorry!), Audio tags, and WebSockets. Great fodder for blog posts, but once again I would very much like to have a more complete version before I go chatting it up. Expect some updates in the next few weeks though! Even if I'm not talking about the game itself I'll probably want to talk about my experiences with the HTML 5 stuff. (I feel a rage post about the Audio tag brewing as we speak...)
Till then!
Tuesday, October 19, 2010
"The Social Network" Review-ish
So I had a chance to see "The Social Network" the other day. I'll admit that it wasn't a movie that I was really intent on seeing but a Hollywood blockbuster about (of all things) a programmer/website struck me as an odd little beast, so I was somewhat intrigued.
Now that I've seen it I think that It's probably worth at least one viewing by every individual who has ever built a piece of software. That's not because I really liked the movie, though. True, I found it to be an entertaining (albeit highly fictionalized) tale, and the actors do an admirable job portraying their overblown characters. I wasn't a big fan of the way they tried to portray the whole thing as this wild "sex, drugs, and rock and roll" lifestyle, though. I'm sure that there are programmers out there who live like that, or at least want to, but that's a pretty big disconnect from most of the developers I know. To me that whole aspect of the movie felt heavy handed and overdone and as a result it was probably a one-time viewing for me. So while I thought it was a good flick it certainly wasn't my favorite. (I'd easily go see Inception 3 more times before before bothering with this one again).
Anyway, the thing that really struck me about the movie, the thing I think is important about it, is that it is the first movie that I have EVER seen that actually portrays programming/hacking/development almost completely accurately. There's a fascinating monolog at the beginning of the show in which Zuckerberg (the screen version, anyway) narrates some of the steps he's going through to collect pictures for a prank website that he's building. It's a fairly lengthy scene, and shockingly doesn't try to gloss over the technical bits. It's packed with terms like "apache server" and "wget" and "bash shell" and all sorts of authentication odds and ends, and every single one of them is used in the correct context! This type of portrayal continues throughout the movie: Every single computer screen displays real OSes, real sites, and real code running on real hardware (the OSes are even date-appropriate!) They talk about real languages and real algorithms and generally act like real programmers. What a concept!
Of course, a lot of this is just incidental stuff and most of it is done rapidly enough that audience members who don't know their Perl from their Python will simply pass it off as techno-babble and still be able to focus on the story. But for an industry that has long portrayed "hackers" as semi-mystical beings who mash random keys while staring at psychedelic screens and suddenly have access to anything the very grounded and realistic approach taken here is very surprising and refreshing. It's worth a viewing if only for that: to bear witness to the day that Hollywood recognized that programmers were real people.
One final recommendation for the show: The soundtrack is great, and makes for (ironically) great music to code by. But, hey! It's Trent Reznor! Would you honestly expect anything else?
Now that I've seen it I think that It's probably worth at least one viewing by every individual who has ever built a piece of software. That's not because I really liked the movie, though. True, I found it to be an entertaining (albeit highly fictionalized) tale, and the actors do an admirable job portraying their overblown characters. I wasn't a big fan of the way they tried to portray the whole thing as this wild "sex, drugs, and rock and roll" lifestyle, though. I'm sure that there are programmers out there who live like that, or at least want to, but that's a pretty big disconnect from most of the developers I know. To me that whole aspect of the movie felt heavy handed and overdone and as a result it was probably a one-time viewing for me. So while I thought it was a good flick it certainly wasn't my favorite. (I'd easily go see Inception 3 more times before before bothering with this one again).
Anyway, the thing that really struck me about the movie, the thing I think is important about it, is that it is the first movie that I have EVER seen that actually portrays programming/hacking/development almost completely accurately. There's a fascinating monolog at the beginning of the show in which Zuckerberg (the screen version, anyway) narrates some of the steps he's going through to collect pictures for a prank website that he's building. It's a fairly lengthy scene, and shockingly doesn't try to gloss over the technical bits. It's packed with terms like "apache server" and "wget" and "bash shell" and all sorts of authentication odds and ends, and every single one of them is used in the correct context! This type of portrayal continues throughout the movie: Every single computer screen displays real OSes, real sites, and real code running on real hardware (the OSes are even date-appropriate!) They talk about real languages and real algorithms and generally act like real programmers. What a concept!
Of course, a lot of this is just incidental stuff and most of it is done rapidly enough that audience members who don't know their Perl from their Python will simply pass it off as techno-babble and still be able to focus on the story. But for an industry that has long portrayed "hackers" as semi-mystical beings who mash random keys while staring at psychedelic screens and suddenly have access to anything the very grounded and realistic approach taken here is very surprising and refreshing. It's worth a viewing if only for that: to bear witness to the day that Hollywood recognized that programmers were real people.
One final recommendation for the show: The soundtrack is great, and makes for (ironically) great music to code by. But, hey! It's Trent Reznor! Would you honestly expect anything else?
Wednesday, September 29, 2010
Itty Bitty WebGL
File this one under "Cool but useless"
I stumbled across js1k.com yesterday and was quite amused by the concept: Use 1024 bytes or less of javascript in a minimalistic shell page to create a cool demo. The contest is over now, and browsing through the winning entries is surprising and somewhat awe inspiring. They managed to get a full Chess AI and graphics in 1k of javascript?!? Awesome! It also got me thinking: None of the demos used WebGL (primarily for compatibility reasons. The rules state that demos must work in Safari, Chrome, Firefox, and Opera), but were the standard further along, how much COULD you do with a 1k WebGL app? I decided to find out!
I stumbled across js1k.com yesterday and was quite amused by the concept: Use 1024 bytes or less of javascript in a minimalistic shell page to create a cool demo. The contest is over now, and browsing through the winning entries is surprising and somewhat awe inspiring. They managed to get a full Chess AI and graphics in 1k of javascript?!? Awesome! It also got me thinking: None of the demos used WebGL (primarily for compatibility reasons. The rules state that demos must work in Safari, Chrome, Firefox, and Opera), but were the standard further along, how much COULD you do with a 1k WebGL app? I decided to find out!
Friday, September 24, 2010
Raytracing in Javascript
So I've been pretty quiet lately, but not for lack of activity on my part. I'm in one of those funny stages right now where I've got about a thousand ideas I want to try and things I want to learn and not enough time to pull any of them off properly. So I experiment, whip up several dozen cool little proof-of-concept programs, and move on to the next idea. This kind of "brain dump into code" mode is pretty fun, but has the severe downside that none of your projects reach a point where their worth actually showing to anyone else. Recognizing that my blog has been sorely neglected as of late I determined that I would bring at least ONE of my playthings to a semi-showable state and post it, and it so happens that my raytracer was the closest to being presentable. :)
Yes, it's a browser demo (but not a WebGL one, sorry!) It's a Monte Carlo tracer, which means that the image starts out really ugly and gets better as more passes are applied. (Let it sit longer and it becomes prettier.) The image above is the result of letting it sit for 400 passes, and even then you can see a fair bit of noise. It's a very slow way of going about it, but it can produce spectacular results under the right conditions (and, you know, when you're not relying on Javascript to do it...)
Okay, so admittedly this is probably the least impressive demo I've done so far. It's your standard old boring Cornell box, and not even a really cool one at that because it lacks a refractive (glass) sphere. (More on that in a bit). There's a whole bunch of things "wrong" with it, and I may be tempted to come back and update it at some point, but the point of the thing was that I wanted to learn more about raytracing, and this little guy has served that purpose admirably.
A few fun "techy" notes: This started life as a Python port of smallpt, which I eventually gave up on when I realized that the GIL makes threading for this type of thing pretty useless. So I ported my port to Javascript (wait, aren't we moving backwards here?) mostly so I could use Web Workers, but it has a nice side effect of letting me demo it online. :)
The demo uses 4 web workers (though it's super easy to scale to more or less), each of which renders their own jittered version of the full scene. All passes are then send back to the main thread and composited into the final image. I'm actually passing the image data back and forth in an ImageData object, which means that some browsers may not support this yet. It also means that there's the potential for some pretty severe precision loss, since all of the color values are compressed into a 0-255 range, sent to the main thread, and blended with the main image, which does another 0-255 compression. It would be far better to store and composite all of the color components as floats (or doubles, but Javascript doesn't give you the option. It falls somewhere in between), and copy those values over to the image after compositing. I tried this at one point, but the Web Workers kept dying and spitting out a strange "Not enough arguments" message. This is apparently a Chrome bug, but I have no idea how to get around it.
I also eventually dropped the idea of having a refractive sphere, simply because after many MANY iterations I still end up with either a black ball or a clear ball with an ugly black ring around the edges. You can still see the material class for it in the worker script, and if anyone wants to point out where I'm being stupid be my guest!
Anyway, as unimpressive as it is I did have a lot of fun putting this together, and hopefully someone out there at least finds it mildly interesting! For now, though I'm moving on to my next project, which may or may not be any one of the following: (haven't decided yet)
Yes, it's a browser demo (but not a WebGL one, sorry!) It's a Monte Carlo tracer, which means that the image starts out really ugly and gets better as more passes are applied. (Let it sit longer and it becomes prettier.) The image above is the result of letting it sit for 400 passes, and even then you can see a fair bit of noise. It's a very slow way of going about it, but it can produce spectacular results under the right conditions (and, you know, when you're not relying on Javascript to do it...)
Okay, so admittedly this is probably the least impressive demo I've done so far. It's your standard old boring Cornell box, and not even a really cool one at that because it lacks a refractive (glass) sphere. (More on that in a bit). There's a whole bunch of things "wrong" with it, and I may be tempted to come back and update it at some point, but the point of the thing was that I wanted to learn more about raytracing, and this little guy has served that purpose admirably.
A few fun "techy" notes: This started life as a Python port of smallpt, which I eventually gave up on when I realized that the GIL makes threading for this type of thing pretty useless. So I ported my port to Javascript (wait, aren't we moving backwards here?) mostly so I could use Web Workers, but it has a nice side effect of letting me demo it online. :)
The demo uses 4 web workers (though it's super easy to scale to more or less), each of which renders their own jittered version of the full scene. All passes are then send back to the main thread and composited into the final image. I'm actually passing the image data back and forth in an ImageData object, which means that some browsers may not support this yet. It also means that there's the potential for some pretty severe precision loss, since all of the color values are compressed into a 0-255 range, sent to the main thread, and blended with the main image, which does another 0-255 compression. It would be far better to store and composite all of the color components as floats (or doubles, but Javascript doesn't give you the option. It falls somewhere in between), and copy those values over to the image after compositing. I tried this at one point, but the Web Workers kept dying and spitting out a strange "Not enough arguments" message. This is apparently a Chrome bug, but I have no idea how to get around it.
I also eventually dropped the idea of having a refractive sphere, simply because after many MANY iterations I still end up with either a black ball or a clear ball with an ugly black ring around the edges. You can still see the material class for it in the worker script, and if anyone wants to point out where I'm being stupid be my guest!
Anyway, as unimpressive as it is I did have a lot of fun putting this together, and hopefully someone out there at least finds it mildly interesting! For now, though I'm moving on to my next project, which may or may not be any one of the following: (haven't decided yet)
- A WebGL accelerated version of this demo, to compare speeds
- A SketchUp to JSON exporter for quick prototyping of WebGL scenes
- An OpenGL ES 2.0 demo on Android (very tempting)
- A WebGL Material system
- Or possible something completely different! I have a bit of an itch to do something non-graphical for a bit, just to shake things up.
I've also got a couple of blog entries I want to do about some subjects I've found interesting lately, so hopefully there won't be as long of a gap before my next post.
Sunday, August 29, 2010
Setting up an OpenGL ES 2.0 dev environment for Android (The horror!)
It is a well known phenomenon that if you give a software developer (a REAL developer) any device which contains a CPU (and even a great many that don't) you will also install in them a great and uncontrollable urge to put their own programs on the damn thing. This urge cannot be satisfied by any old "Hello World" app either, oh no. It has to be something significant. Something that uses the device in a non-trivial way. Something that makes your peers say "Woah!" (The "Woah" factor is incredibly important, ask anyone.)
As such, being a developer and recently coming to posses a shiny new smartphone I've been dying to do some code for it for a while now. Finishing up some of my WebGL stuff and keeping up with my normal work (you know, the one that actually pays me) has prevented me from acting on it so far, and I still may not get a chance to code for it for a little while, but I finally had enough time lately to sit down and actually set up the SDK and play with some of the examples.
As such, being a developer and recently coming to posses a shiny new smartphone I've been dying to do some code for it for a while now. Finishing up some of my WebGL stuff and keeping up with my normal work (you know, the one that actually pays me) has prevented me from acting on it so far, and I still may not get a chance to code for it for a little while, but I finally had enough time lately to sit down and actually set up the SDK and play with some of the examples.
Saturday, August 28, 2010
Communication across language barriers
Had a neat experience while out walking my dog today. We came across a very kindly and very lost elderly Hispanic gentleman that flagged us down to ask for help. Since the first thing out of his mouth was "I no speak-a English very good." I was concerned that I would be fairly useless with whatever problem he was having. (Two years of Jr. High Spanish and all I can say fluently is "I don't speak Spanish".) Luckily, however, he was able to point to an address scrawled on a bus schedule and indicate that he was trying to reach that location. I knew where the address was, and fortunately he wasn't more than a couple of blocks off, but I was somewhat at a loss for how to communicate directions to him outside of vague hand gestures.
Then, in a moment of fleeting intelligence, I recalled the trusty little Android phone in my pocket that I had been listening to music on. Pulling it out, in under a minute I was able to call up Google Maps, punch in the address, have it map out the directions, and show this gentleman the results. Even though the map was in English a big blue line guiding you from where you are now to where you want to be is pretty universal. After studying the map for a moment a look of understanding and relief swept over him. He thanked me several times, a sentiment that I had no problem understanding, and headed off to his destination no longer lost and much happier for it.
For my part I was left with a mix of the warm fuzzies you get from helping another human being and wonder that we live in a day and age where I can hold in my pocket a tool that can completely transcend language and cultural differences and allow me to help someone in need. I don't care who you are, that's just cool!
As a programmer it's very easy for me (and, I think, others of my profession) to loose sight of why we surround ourselves with all this technology. We can easily fall into the trap of pursuing technology for the sake of technology. (I'm certainly guilty of that.) It's worth reminding ourselves once in a while that all of these spectacular devices and innovations are really there to serve one singular purpose: To make our lives better in some little way. Whether it does that by making some task a little easier, bringing us the information we need, making us safer, or just providing a few moments of entertainment, it's all in the name of improving our day to day existence. If we keep that in mind, magical things can happen.
Then, in a moment of fleeting intelligence, I recalled the trusty little Android phone in my pocket that I had been listening to music on. Pulling it out, in under a minute I was able to call up Google Maps, punch in the address, have it map out the directions, and show this gentleman the results. Even though the map was in English a big blue line guiding you from where you are now to where you want to be is pretty universal. After studying the map for a moment a look of understanding and relief swept over him. He thanked me several times, a sentiment that I had no problem understanding, and headed off to his destination no longer lost and much happier for it.
For my part I was left with a mix of the warm fuzzies you get from helping another human being and wonder that we live in a day and age where I can hold in my pocket a tool that can completely transcend language and cultural differences and allow me to help someone in need. I don't care who you are, that's just cool!
As a programmer it's very easy for me (and, I think, others of my profession) to loose sight of why we surround ourselves with all this technology. We can easily fall into the trap of pursuing technology for the sake of technology. (I'm certainly guilty of that.) It's worth reminding ourselves once in a while that all of these spectacular devices and innovations are really there to serve one singular purpose: To make our lives better in some little way. Whether it does that by making some task a little easier, bringing us the information we need, making us safer, or just providing a few moments of entertainment, it's all in the name of improving our day to day existence. If we keep that in mind, magical things can happen.
Subscribe to:
Posts (Atom)