photoing in troy::07.17.2014+02:25
I went on a photo walk with some friends from work over the weekend and ended up with about 30 decent images. They’re all up on my photo gallery.
photos, updates, random stuff::06.07.2014+19:27
I got a new camera and had started messing around with flickr again, but I realized after a few weeks of posting photos to it that I should probably find a suitable web gallery, install it here, and put my photos there. So, that’s exactly what I did. Just to get things rolling, I uploaded my existing photos pretty much raw. I’m planning on spending some time and organizing things into albums and renaming the photos. I’m also planning on re-theming the site. The software I settled on is called piwigo and it’s pretty competent, supoorting both themes and extensions (And multiple users if you’re into that).
I also decided that having a front page where I post random, meta news about the site was pretty silly, so I’ve pulled the blog to the front and retired the old front page. This means that the rss feed now has a new location.
fun with idTech4::12.04.2012+04:27
So I got bored tonight and started screwing around with a feature of the idTech4 engine where you can do oversampling of a scene that you’re taking a screenshot of. Normally, this won’t make any difference since everything stays where it is. If you set the r_lightSourceRadius cvar to something other than 0 though, it will jitter the lights randomly every frame. This makes the game look completely insane because the shadows will randomly jump around, unless you’re taking an oversampled screenshot. If you oversample (say 128 - 1024) times, you can get a really smooth result out of the shadows. In the end, it looks nothing like idTech4. I’m not sure that I like it more, but it’s rather interesting.
Optimizing my Haskell Raytracer::02.25.2012+23:35
Way back in 2010 I wrote a really crappy, proof of concept raytracer as a way of familiarizing myself more with Haskell. I picked it back up this morning because I wanted to see how much I could improve the performance of it by doing some pretty simple optimizations. I could probably improve performance further by doing actual structure changes to the program, but I’d rather fall back on algorithmic improvements before fighting with the code generator. At any rate, the final results are satisfying: a 70% decrease in running time overall.
Strictness Annotations
The first optimization I did was to put strictness annotations
on the Doubles in the vector type.
What started off as:
became:
data Vec3f = Vec3f Double Double Double
deriving(Eq,Show)
This resulted in a 19% decrease in overall run time. Nothing drastic, but
still a very significant difference.
data Vec3f = Vec3f !Double !Double !Double
deriving(Eq,Show)
Unboxed Strict Fields
The next optimization was to add the compiler flag “-funbox-strict-fields”. What this does is tell GHC to automatically add the UNPACK pragma to strict fields in data constructors. The end result, is that the Vec3f constructor is no longer storing heap pointers to Doubles and instead just storing the Doubles themselves. Unboxing the strict fields brought the total run time decrease to 35%.
Float versus Double
As most people know, Doubles are not very fast on many systems. In the past, I had seen a speed increase by using Doubles instead of Floats in this raytracer. I believe that it had something to do with GHC not using SSE for Float and only for Double. Regardless, switching from Double to Float doubled the total savings. The result was a decrease of 70% run time versus the original.
Code / Full Disclosure
You can download the code here: raytracer.zip. When run
it will generate a file called “output.ppm” containing the rendered image. It should look like this:
The above tests were done on my Acer Aspire One, which has an Intel Atom N270 1.6GHz HT and 1GB RAM.
I’m not sure what the performance differences will be for a 64-bit machine with a better
processor.
Brett Plays Old Games: Deus Ex: Invisible War::08.08.2010+03:57
This is the first in a series of posts where I play and review old games that were possibly high-profile at the time they were released but have since faded. The majority of these games will be PC games because there are a lot of old PC games that most modern gamers haven’t played, and I happen to love PC games.
Often thought of as the ugly stepchild of the original rather than the direct successor, Deus Ex: Invisible War builds upon Deus Ex in some ways while stepping backwards in others. Released in 2003 and developed by Ion Storm, the game was visually appropriate for the time. Running in a highly-modified version of the Unreal Engine 2, it sports dynamic lighting, stencil shadows, normal mapping, and projected textures. It’s reasonably stable, crashing only twice in the three of four hours that I played it. This review only covers those hours, not the whole game, but first impressions are everything, right?