soledad penadés

repeat 4[fd 100 rt 90]

This demo was released at Inspire, a new demoscene gathering held in a small town north of Spain, with the aim of promoting escena.org, the spanish demoscene website. There was already another promotional demo done by elerium core in 2001, but I thought it would be interesting to have a newer one to kick things off.

It is very, very calmed. I had thought at the beginning about doing something very demoscene-ish, just as the previous promo demo was, but then I found myself not wanting to redo yet again the same old school effects, and headed towards something a bit more abstract. Then I remembered about eb7m's 3400 miles below and suddenly lots of ideas came to mind!

The tech stuff

The biggest change compared to previous demos which I've coded is that I used a scripting engine instead of writing everything in C++, and recompiling every time I wanted to change a parameter. For this I've finally used Lua, after considering Ruby and Python. The nicest thing about Lua is that it is really easy to embed. If you want to embed Ruby or Python, it's a completely different (and long) story, but with Lua you just build the library (with a nice makefile which they provide already and just works™) and link to that library in your project, and that's it. You can then create as many instances of Luas as you want, and they won't interfere with each other. In my case I just use one, which loads and executes the demo script (demo.lua).

The second nicest thing with Lua is the way in which you pass parameters between C and Lua. It is very simple, with functions such as lua_tonumber, or lua_tostring; if you compare with Python for example, it is way more verbose.

In the demo script you can access several functions which I created in C and exposed (registered) to Lua. So for example, there's a function for loading a song in C and once I say to Lua: hey, there's this function in C that you can use!, you can write loadSong("filename") in the script and it will end up calling fmod through the C function.

The syntax and function naming is highly inspired by Processing's syntax, although I still want to change a few details and remove some functions which end up doing the same, so that there's only one way of doing things and it's minimalist, as Lua is.

This was also a bit of a benchmark for Lua, so instead of using the typical Vector3D, Face and Mesh C++ classes I decided to implement a reduced subset using Lua's metatables. Even normals are calculated using Lua's math library! Considering the insane amount of stuff which is going on there (I basically increased the number of things such as particles, terrain segments, etc, until the frame rate began to be a little bit jerky), I think it performs very decently. Next step would be to optimise what is sent to opengl, since currently not only everything is drawn in immediate mode but also nothing is culled at all.

Why does it look like that?

Some weeks ago, trace was joking about the lack of texturing of any kind in my demos. I said I would try to use some texturing next time, but as it happens, I thought it would be more funny to play with lights. Yes, I think it's the first time I use lights in a demo. Well, a light. Since the song's title is 3400 miles below, I thought of building something like an underwater world. A very deep one indeed, since sun rays do not even reach that depth, and so any ship which wanted to explore that area would need to use their own light - hence the light is needed for illuminating where we are looking at ;-)

I first built the ground. Initially I thought about calculating an evenly distributed matrix of points and then randomize the heights so that they formed something such as a terrain, but it looked too usual - so I broke some things here and there and that's why it looks as if the tiles are misplaced.

Then I wanted some kind of life in there. But life in very deep waters doesn't resemble the usually depicted fishes. It's more about strange entities, and so I thought of those strange spiders which are in the scene. They are simply there, waiting for something while their legs oscillate.

But it was still too plain. I went too creative and added some plankton, which actually is quite wrong (plankton isn't present at that depth). The plankton is abstracted with those little triangles which go up. In fact they shouldn't go up but down, since they are created and fall from above, but in this case they contribute towards the how odd, things are moving upwards feeling.

In the quest for making it a bit more sinister and mysterious I also added fog. I think it's the first time I use fog too! It was a black fog so that colours got even darker with the distance.

And then I began with the particles-text effect. I didn't want to load and analyze a bitmap to find out where the points were, so I remembered about those naive drawings we did with PRINT in Basic, and did this:

which is a table with strings. When loading the demo and preparing the effects, I go through each string and if there's an 'X' I store a new point in the list of particles to draw. Actually, I created several particles for each point so that the fountain of particles was a tad denser. Then in each frame they move a little bit towards their final destination. To make it more subtle too, I made the alpha dependent of the height, so that transparency decreased with height.

The problem was that everything was still too evident. Something else was needed in order to hide stuff and avoid showing everything from the beginning. So that's why I added several randomly sized but circularly distributed meshes around the center of the scene. They even look sort of kryptonitic to me!

And why is everything green? Because our ship has only got a very old green phosphorus monitor, so it can only display things in green shades. Apparently ;-)

Source release and other builds

I intend on releasing the source code soon, once I decide which functions go away and which ones do stay. It is only a few source files and it's built with C and some bits of STL so it hopefully should be quite easy to understand and follow, even if you just want to see how to connect Lua and C.

I also need to fix a couple of details, such as the universal libraries issue that I found at last minute, and changing to the data directory in non mac builds (in mac, it automatically changes to the data dir inside the Resources folder), etc. At that point new builds should be available for something else than Leopard.

I was also thinking of replacing fmod with a free alternative, but I have several problems: it seems there isn't a decent, open and easy to integrate module player library (other than fmod and bass, which doesn't work in linux), and libvorbis is quite heavy for what I want. Suggestions welcome :-)

Thanks

Of course big thanks to Pplux for his awesome explanation about how the stack in Lua works. That was all I needed to take off!

I'd also like to thank Corsario for offering his computer as compo machine, and trace for the hard work in his inspire demo - it encouraged me to finish this one on time :-)

And finally thanks to Inspire organizers for all the enthusiasm they have put into this new event. Let's hope we can release lots more of demos in subsequent Inspire editions!

I had a lot of files in one folder. It is not very practical to browse the folder that way, so I decided to create a little script which would split the files into different folders, using the first letter of the file for naming the folder, as in a, b, c, d… but using Python this time!

Download from svn (this should always be the most up to date version)

To use simply go to your favourite terminal window and type

It will pick the first letter of each file, create a folder with the lowercased letter (if it doesn't exist yet) and move the file to the folder. It won't move folders! (because of the os.path.isdir check).

If there's any pythonista in the audience with ideas for improving this, feel free to leave your suggestions in the comments, thanks! :-)

Note

There wasn't any special reason for not doing it with Ruby; I simply wanted to know what the differences would be. And while the semantics aren't very different (e.g. where it says os.path.join we would use File.join in Ruby), there is a huge difference between them and it's called documentation. Python documentation is hosted in Python's website, it is reviewed (and mostly written too) by Guido van Rossum (Python's author) and it's up to date and very easy to browse and read. Whereas Ruby docs were hosted elsewhere until very recently, are a pain to browse and pretty much a dump of automatically generated docs from source, which I find very uncomfortable to use. It still feels a little bit weird to use python's indenting style but I'm really liking it. A pity there isn't a Hpricot in python :-)

If you need to use a library in a universal binary you'll need to use a universal library too.

Let's use FMOD as an example; libfmod.a is the PPC compiled version, libfmodx86.a is the intel version.

For combining both into a universal library:

In the case of FMOD they provide you the with precompiled static libraries (the .a files). But if you build libraries from source code, there's a magic compiler option called -arch which will help you in this. Unfortunately I don't have an example handy right now. I'll put it whenever I find it again, but it roughly goes on the lines of -arch i386 -arch ppc :-)

I'm not sure that naming a library with something as *-universal.a is a good idea, specially if you have code which uses -Llibraryname for linking libraries — I guess you might need to change that parameter. I am explicitly adding the libraries to the project in XCode so it's working fine for me.

Suggestions and better practices are welcome!

I often get asked for recommendations about libraries and frameworks, and I also find myself often in the middle of discussions between the opponents and the supporters of libraries and frameworks.

To be honest, those discussions/wars are pretty much stupid because nobody takes the time to understand properly what's going on, and from my point of view I just see ignorance in both sides.

There's not an absolute truth in what regards to libraries and frameworks, and I doubt there will ever be such thing. You can't proclaim yourself a "I do it all myself" man or woman because that's just plain ridiculous. Are you also programming your database server, and your web server, etc? And the people which absolutely encourage the use of ready-to-use libraries also look ridiculous to me. How are you going to deal with the situation when you need to extend feature A or change feature B, if you don't know how the library works?

At the end all gets reduced to just one advice: investigate. Get informed. Compare what options you have before making a decision. Dig into the code and find out how it is built. Is it easy to understand? Is it well documented? If you wanted to change something could you do it without having to spend a whole week on it?

I generally tend to prefer very decoupled libraries which can be easily replaced with another library or with my own code whenever I need, so in a way I use libraries as a prototype. If the library is not that decoupled, I always try to build a wrapper so if I replace the library I just have to rewrite parts of the wrapper, but my main code is left untouched.

So do whatever you want. Use a library, or do not use a library, but do not hassle people which choose a different path.

Imagine you have been in a very nice place for holidays. You took a lot of pictures and want to show them to your family and friends, but you don't feel like using services like flickr or programs like iPhoto. You just want to put them in your own server and give the url to your friends.

What can you do? Well, you could do like me and create a little script to generate an HTML file, with thumbnails and even watermarked images (just in case some creepy individual decides to use your stuff without asking first).

Requirements

This script requires a couple of gems to be installed: RMagick and builder (but if you've done some stuff with Rails you might already have them). RMagick is used for dealing with the images and builder is used for generating the XHTML. This is because I didn't want to write any html by hand, with their less than and greater than signs, attributes, etc.

Using it

1. Create a folder in your computer. For example: holidays.
2. Then you copy there the pictures you want to show to the world.
3. Open a terminal and cd to that directory. E.g.

   cd ~/Desktop/holidays

4. Execute the script! E.g.

   ruby ~/code/superminigallery.rb

5. Wait until it finishes

When it finishes you'll find there's an output folder in the holidays folder. That's where the index.html file, as well as all the thumbnails and watermarked images are. Simply upload the contents of this folder to your host and let everybody know about it!

Ok, but show me the code

The first lines act like a configuration area. You can change the output folder name, so that it is called superoutput, gallery, whatever you like (as long as it is a valid path name).

You may change the sizes of the generated pictures; these sizes are defined in the versions variable. Each pair means [width, height]. For example, the thumbnails are 300 pixels wide and 150 pixels high.

You can also configure which EXIF tags need to be retrieved. Since their names are too obscure for non-technical savvy people I decided to create this hash for storing the key (Exif tag) and the nice name to show with the value. So instead of showing DateTimeOriginal, it will simply output Taken.

There are way more tags you could show, but they can be confusing for normal people and only entertain geeks, so it's better to keep them down to a minimum.

Declare the builder object, and initialize it with the XHTML header.

Now it would be amazing to have some styling in the page so that it doesn't look so ugly. We can put an style tag inside the head, and use the text! method for adding literal text to the builder object:

(the … means there's more code but I have reduced it for clarity purposes)

Now, we need to create the output directory. I haven't bothered with outputting error messages if the directory already exists or anything. It will always try to create it:

We need to create a Magick::Draw object for watermarking the images, and define its parameters:

Basically we are saying: use Helvetica bold 64pt, painting it with white (ffffff) and some transparency (99 for alpha channel). If you don't have Helvetica installed in your system, replace it with your favourite font.

(But since 2007 is Helvetica's 50th anniversary, you should do everything possible to use Helvetica!)

Now we open the current directory (where the script was executed) and find all files with jpg and JPG extensions, and sort them. That's because sometimes the images don't get listed in alphabetical order, and us humans like to see things in sequential order. Specially because they usually are numbered incrementally, and older numbers mean older images, so IMG001 should appear before IMG100.

Read each file into a Magick::Image object:

And for each version…

… create the version filename by appending the version name to the filename, like big_IMG_1234.jpg, and the output filename, by prepending the output path to the version filename:

If the version is 'thumbnail', we'll add the image metadata to the builder object. Note how you don't need to open or close tags, but just include things in blocks or parenthesis to get the mark up done.

Resizing the image is as simple as

crop_resized returns another Image object which we store in the version variable.

Now, if we are dealing with the 'big' version, we'll add the watermark that we prepared at the beginning. That is done with

You can replace my (c) soledadpenades.com with your text, of course!

And for writing the resulting image to disk:

Very very important: do not forget to call the Garbage Collector. For some reason which I still haven't been able to elucidate, the RMagick gem leaks memory furiously. So if you forget to do a

as I did with the first version of the script, your computer will mostly hung if you make it generate a lot of thumbnails. If you look at the current processes with top or a similar tool, you'll find a ruby process eating more and more memory with each picture it processes.

And finally, we just need to output the generated XHTML to index.html:

Here's the result and here's the source code. With only 120 lines of code (excluding the license text :D), it's way easy to modify to suit your tastes.

Don't tell anyone but…

I must confess I got the inspiration for this from herotyc's jGallery. But he used a bash script and I thought there should be a way of doing the same with ruby :-)