Automatic .caf file creation

As I said in the previous post, I am currently working on adding sound effects to PewPew 2. The preferred format for sound effects with OpenAL on the iPhone is the .caf (Core Audio Format), but audio softwares usually output .wav files.

Fortunately, there's an easy way to convert one format to the other, using a built in command in OS X:

afconvert -f caff -d LEI16@44100 -c 1 in.wav out.caf

Being a programmer, I am lazy, so I started thinking about automatizing the conversion for all my .wav files using a small python script that would look like that:

for every file in the directory:

exec "afconvert -f caff -d LEI16@44100 -c 1 file.wav file.caf"

But it was not going to be efficient: every time I would want to regenerate a single .caf file, the script would regenerate all of them.

And then it hit me: makefiles are made to solve this exact problem. I tested my idea with a small makefile that looked like:

test.caf: test.wav

afconvert -f caff -d LEI16@44100 -c 1 test.wav test.caf

and it worked as expected :-)

I am sure lots of other people thought about using make for stuff other than compilation, but I am still satisfied of having found this on my own.

While I was at it, I did a small python script to generate the makefile. Everytime I create a new wav file, I simply have to run the makefile generator.

Now what's pretty cool is that you can make the makefile run automatically in xCode every time you compile your project. Even cooler is that by executing the makefile with make -j 2 (or make -j 8 for some lucky bastards), you get to exploit all the cores of your CPU for the conversion. Indeed, man make explains that the -j switch "Specifies the number of jobs (commands) to run simultaneously".

Try doing this in Windows. For me, it's clear that OS X and Linux are the best OS for programmers!

Comments

PewPew Live's look in a nutshell

Occasionally someone will asked how I obtained the PPL look. In a nutshell: Draw everything with lines, including the text and the various icons. It's a lot of work, but besides looking unique it creates a consistent appearance which is a thing that a lot of indie games struggle with. The lines are screen-space projected lines with miter joins. Draw the lines with additive rendering. This means that if a red and green line overlap, the overlap will be yellow. There are a few things not drawn with additive rendering (like the background of buttons to improve readability), but they are exceptions. Add bloom. There's lots of different bloom implementations. Nowadays I use a bloom that is similarly to the one in blender's eevee . If you see banding, use dithering. Optional: Add even more post-processing like (very slight) chromatic aberration, lens dirt, scan lines, curved monitor, and vignette. No post-processing, just lines Bloom! Ignore the missing bloom at the top All the...

A general state rollback technique for C++

I wanted to write this post for a while. It describes a C++ technique to implement rollback in the context of multiplayer games that I feel is quite interesting and useful. The tl;dr is: don't bother serializing individual objects, just rollback all the memory. Rollback-based multiplayer I've been working on a multiplayer version of PewPew, and for reasons that are outside of the scope of this post, I chose to implement multiplayer with deterministic lockstep and rollback. The basic idea behind rollback-based multiplayer is that the inputs of players are replicated to all the players. Whenever a player receives the inputs of another player, the state of the game is rolled back to the point where the input happened and fast-forwarded back to the present so that the state shown to a player takes into account the inputs of the other players. Because history is being re-computed, some events get undone. For example, it's possible a player saw themselves taking a bonus, but aft...

Ridiculously cheap depth of field effect for lines

I'm working on PewPew's sequel, for which I've revamped the graphics. Instead of drawing lines directly using OpenGL, each individual line segment is made up of two triangles whose vertexes are computed with shaders. Getting lines in 3D space to be properly displayed on a 2D screen is not trivial. In PewPew's sequel I use the screen-space projected lines, a technique very well described in the Drawing Lines is Hard post. The upside of drawing the lines yourself is that you are fully in control, which allows you to implement nice things such as joints, perspective, and even simulate depth of field. https://en.wikipedia.org/wiki/Depth_of_field Usually depth of field (DoF) in video games is implemented using a post-processing step that blurs the pixels with an intensity that is a function of the depth of the pixels. When we are rendering lines, we can approximate DoF directly when rendering the lines by having the vertex shader increase the width of lines and r...

Jfgeyelin's dev blog

Search This Blog