What Oxidizer does…

by David Burnett • Sunday December 2nd, 2007
Posted in Developer's Corner, Oxidizer Blog

Oxidizer is basically a Cocoa wrapper around Universal builds of the flam3 software at the heart of the Electric Sheep screen saver. When you create a random genome Oxidizer runs flam3-genome to create one. It then takes the xml file flam3-genome creates and loads the data into a Core data repository. It then re-creates the xml and runs flam3-render to render the thumbnail.

Everything else works the same way, the Gene Pool and Breeder runs flam3-genome. Rendering runs flam3-render, movies are created by flam3-animate and a little QuickTime magic.

Oxidizer did not use to work like that, before version 0.4 the flam3 code was originally incorporated into Oxidizer itself, but the changes to make flam3 multi-threaded clashed with the multi-threading in Oxidizer. Changing Oxidizer to work with external flam3 executables had a number of advantages.

  • It eliminated a big bunch off code that I had to keep in line with flam3 code and make small modifications to.
  • It also meant that all the times that the flam3 code would just exit due to bad parameters taking Oxidizer with it could be captured and the error message displayed instead.

All of which would have stabilized Oxidizer 0.4 no end if it had not triggered a few flam3 breeding issues which lead to 0.4.1 after those had been fixed in flam3.

Scott, of course, then came along and handed me a lovely flame that crashed 0.4.1. It was one of those that are real tricky to track down as mostly it would crash after a few minutes rendering, other times it would be hours, and a few times I managed to render the whole thing. In the end it was a flam3 issue caused by a quirk of the standard ‘C’ library that Apple uses. It was literally a 1 in 4,294,967,296 chance of hitting the quirk, Scott’s flame just happen to be taking millions of goes at triggering it.

That means that there is a 0.4.2 is on the horizon, once I’ve written a small Lua script to check if a flame would render in the current version of Electric Sheep. I would tell where you can get a sneak preview but that would ruin my download figures :-)

Plans for 0.5 are totally open at the moment, the only definite plan is to update to the latest flam3 code again. Idea’s I’ve played with are…

  • Adding some sort of CoreImage facility that you could apply to the images and movies.
  • Adding something like Apo’s triangle editor.
  • Building in a web browser targeting the Electric Sheep flames (If spot okays the idea)

Any way I’ve rabbited on enough, and my favourite football (the one you play with a ball and your feet) team
are on the T.V. so I’ll leave anyone reading this to write few comments back .



  1. Scott Chitwood
         December 3, 2007


    It was literally a 1 in 4,294,967,296 chance of hitting the quirk, Scott’s flame just happen to be taking millions of goes at triggering it.

    How smoking cow, that is just too whacked :^)

  2. David Burnett
         December 4, 2007

    To be fare most flames have a fair few goes at triggering it if rendered at a decent size, having a zoom of 4.3 on top is the icing on the cake adding up what I think is approximately 310,000,000,000 attempts at triggering the bug.

    I might make the effects of some of the parameters on render time the subject of a article one of these days.

Sorry, comments for this entry are closed at this time.