It's been nearly two weeks since the last post, and longer since I had anything with substance. This is just a quick note to let you know I'm not dead!

In fact, I'm working on the little mini-game that I started on in January. I decided it was worth brushing off and doing some more work on. Here's a screenshot:

Also, Shamus Young has run into some problems using Qt as his GUI toolkit, and I'm trying to convince him to switch to my GUI. Which of course does not work yet. So I'm going to have to make some extra efforts in that direction.

There will be a full post soon with the mini-game (called "Don't Hit Me!") and something on the GUI. ]]> 2012-05-03T07:00:00-07:00 Some interesting designs have come in. http://www.sea-of-memes.com/Delay/DesignContest2.html http://www.sea-of-memes.com/Delay/DesignContest2.html Some interesting designs have come in. GUI Design Contest Results

The contest did not start well. I was just getting variations on the concept that I had supplied. The staff at 99designs suggested that I had overspecified what I wanted (I was just trying not to be vague) and told me to simplify my brief. They also extended the contest for me, free of charge. Since then, several interesting variations have come in.

The best of the initial round was from reader Florian Bösch, shown here:

Florian's UI

I'd be happy to use this for UI work, and will try to do a skin for my GUI that uses this style. For SeaOfMemes, I wanted something more in the spirit of the game. I asked people to submit concepts, not detailed designs, and suggested something that looked like a building blueprint. I like these two designs:

Eikonographer's UI

Liu Design's UI

I've also gotten some other creative designs like this one:

mmactor's UI

A Poll

I'm still looking at designs and making suggestions to the designers. What do you think? Here's a poll. Please comment on the designs shown. I still have some time on the contest to get what I want. ]]> 2012-04-27T15:00:00-07:00 I've submitted a GUI design contest to 99designs.com http://www.sea-of-memes.com/Delay/DesignContest.html http://www.sea-of-memes.com/Delay/DesignContest.html I've submitted a GUI design contest to 99designs.com GUI Design Contest

I've been working on my GUI code, and decided to use the graphic design site 99designs.com to find a concept/color scheme for the UI.

For any of you who are graphic designers and want to take a crack at it, the contest is here.

Design Brief

I am writing a video game and need a concept for the user interface graphics. I'm not looking for individual icons yet (I'll bid that work out separately), just an overall look.

The example I've provided (see "sample-concept.jpg") has some of the characteristics I'm looking for:

• It's translucent, so that players can monitor the game while they are using windows/dialogs, etc.

• It has a technical/engineering flavor, to match the game. My attempt was inspired by blueprints. It has a blue color scheme and uses an italic sans-serif font.

• I want something fairly minimal and clean, since the user's attention should be given to the game, not the UI.

On the other hand, I'm a programmer, not an artist, and I'm not attached to the particulars of the sample concept. If you have a completely different idea, please submit it.

I've made both the dialogs and controls 30% transparent. Feel free to try variations on this, as long as controls are readable over the sample backgrounds. The video game code can support any texture on the control/dialog background. Transparency can vary over the surface if you like. Textures can be an arbitrary R,G,B,A image, in other words.

Your submissions should be in the form of a PNG file with appropriate levels of transparency (see "submission.png"). Three sample background images are provided. Your UI concept should be readable over all three. You will be specifying:

• A color scheme. Specify colors of the dialog background, a disabled button, an unpressed ("up") button, a button with the mouse over it ("hover"), and a pressed ("down") button. I also need colors for text in various uses, the background and text color of a menu item, etc.

• Background textures. As mentioned, the dialog and control backgrounds can be any texture with any amount of transparency.

• A font. Please use either standard Web fonts or open source fonts (give a source URL.) My code only supports TrueType fonts. I'm using a font called "Sansation" in the example. Download from www.fontsquirrel.com/fonts/Sansation if you are interested in using it (not required.)

• Button/icon styles. I don't expect a finished icon design, but please indicate if button graphics would be heavy or light, italic, curved, etc. and the color scheme. A rough sketch on the submission image is sufficient.

In addition to the design fee, I will be happy to credit the designer and give a link to your website in my documentation.

Sample-concept.jpg

Submission.png

Background1.jpg

Background2.jpg

Background3.jpg

In the last part, I described keeping the landscape as some kind of Octree, and was trying to figure out the shape of a leaf node. I needed something that would do heightmaps, but also let me break things into cubes, and dig holes in the landscape. I was imagining some kind of discrete shape, like a collection of tetrahedra.

Fig 1: Hermite data

Reader Scott Richmond linked three papers on variations of "Dual Contouring", which I think will be the right answer. The leaf cubes will contain up to 12 points, the intersection of the desired surface with the edges of the cube. Each point also has a normal associated with it, indicating the direction of the surface. In two dimensions, it looks like Figure 1.

In the papers, this is called "Hermite" data, and the algorithms use a "quadratic error function" which is minimized to place each polygon point during a modified "Marching Cubes" algorithm. I am still working through the papers to figure out what this all means!

The surface intersections and normals are easy to generate from the procedural heightmap-based landscape. I'm not sure exactly how I'll be manipulating those when the player digs holes. And I'm not sure when I recompute the polygonal form of the surface. I don't know how expensive that will get, and whether I can do it in sections (so they can be cached), or if I have to redo the entire landscape on each change. Since the input cubes change whenever you move (cubes get smaller as you move nearer) or when you dig, this needs to be fast.

Sleepless

While I wait for a doctor's appointment and the inevitable tests, I've decided to work on some odds and ends like my old GUI and adding features to Crafty. That can be done in small bursts and don't require any math, which my tired brain just isn't capable of right now. I'll post again when I get something working. ]]> 2012-04-12T06:30:00-07:00 Still trying to get modifiable landscape to work. http://www.sea-of-memes.com/LetsCode54/LetsCode54.html http://www.sea-of-memes.com/LetsCode54/LetsCode54.html Still trying to get modifiable landscape to work. Part 54: Stuck

Fig 1: Heightmap-based landscape

Since the beginning of the project, I've been talking about putting Minecraft-style structures made of cubes on a polygonal landscape. I just can't render a large world with distant views if it's all made of cubes. They take too long to render, and are too hard to summarize in the distance. Also, I just like the look of a polygonal landscape. Figure 1 looks much better to me than anything done with cubes.

I've been doing polygonal landscapes with heightmaps. You have a grid in x and z, and each point has a height in y. Each square cell of the grid is drawn with two triangles. In Part 28 I showed how you could vary the resolution of a quad-tree, where each node contained a 32 by 32 heightmap. By using coarser grids in the distance, the demo can draw a view right out to the horizon without using too many triangles.

The problem with heightmaps is they are only vertical. If you play with Minecraft, you can see that caves are really important to the look. On the TwentyMine server, there are all kinds of interesting underground structures. So although my fallback was to just use heightmaps and let you dig vertically before building, I've wanted a better data structure.

In particular, for my asteroids, I want you to be able to carve them up and make any structure you like out of them, from a hollow habitat (Figure 2), to some bizarre nesting of levels and structures at all angles.

Fig 2: A hollow asteroid

I've been toying with different kinds of data structure for months now, trying to find one that would do what I want:

• It has to handle arbitrary 3D shapes with mountains, caves, holes, etc.

• When the player digs through a mountain or shell of an asteroid, I need to easily know when he's broken through to the other side.

• I need to be able to summarize landscape at lower resolution in the distance. For example, if you dig out a mountain, ideally I'd like to see some sign of the holes when you move far away.

• The rendering code can quickly extract a list of triangles to draw, and they should not include too many extra, obscured triangles.

• I should be able to do at least what a heightmap would do.

• It can't take a ridiculous amount of memory for the kind of landscapes I'm using.

Six-sided height maps

Fig 3: Height maps in all directions

You can start to see the problems even in this illustration. The data structure does not enforce anything about the height map values, so they might not meet up at corners, or the bottom heights might extend until they hit the opposite face, or even the sides. As you dig, I would continually have to check the intersections with the nearby faces, both horizontal and vertical.

I was also originally thinking each node in the tree is a 32 by 32 by 32 cube with a heightmap, but this won't work. It would only allow you to dig 32 by 32 meter holes in the landscape! To have arbitrary shapes, I would have to take the scale down to a single cube. If each cube had a 32 by 32 heightmap on each face, that's too much memory.

After more thought, I decided that this all really reduces to an Octree, and the only question here is what shape is in the leaf cube.

Leaf Shapes

Fig 4: Larger cubes in the distance

If you kept only a single bit per leaf cube, you'd have a Minecraft-like world, except with larger cubes in the distance. This works and satisfies all my criteria except that it looks terrible. It won't do the nice landscape in the distance that a heightmap will do.

Fig 5: 8-point
nodes
 

To implement a heightmap, the leaf cube has to handle a height at all four corners. To handle my asteroid case, it has to do this in any of the six face directions. Last week, I was thinking that I would just implement the leaf cube with 8 points that can have arbitrary positions within the cube (Figure 5.) The leaf shape is drawn just as I currently draw cubes -- with two triangles per face.

If I set the bottom corners to be at the cube points, and the top corners to follow the heightmap, I could do everything I currently do with heightmaps. When digging, I would need to push the corner points into the cube until they intersected the opposite face. At that point, the cube is empty.

Fig 6: Clipped
8-point
nodes

Unfortunately, since I'm so poor at visualizing things in three dimensions, the obvious problem had never occurred to me. The adjacent points of a heightmap landscape are not necessarily within a cube. In fact, clipped to a cube, you can get some nasty shapes (Figure 6.) To avoid this, I would have to constrain the 8 points to be within the cube, which restricts the shapes the player can build.

You might think this doesn't matter, and close up, it probably wouldn't matter much. It would just mean that as you dig, whole cubes disappear when you think there should still be a sliver. In the distance though, constraining the surface points to fit in a cube means you can't have more than a 50% slope, and the mountains of Figure 1 are impossible. It would also be impossible to draw a deep cut into a more gently sloping mountain.

Tetrahedrons?

Fig 7: Subdividing tetrahedra

Unfortunately, the tree wouldn't have a nice structure like the Octree. The tetrahedron would not be split at regular intervals -- that would just build the landscape out of fixed-sized pyramids instead of cubes. Instead, we need to split at arbitrary points along the edges.

If you imagine a large "universe"-sized tetrahedron, the landscape would be a bit of noise at the bottom. As you subdivided the top level tetrahedron, you would get all kinds of thin slices, leading to round off errors and probably some "flimmering" when you drew parts of the shape.

I also rejected this because I simply can't visualize what is going on. In the simple case of Figure 7, where you cut each edge at one point, how many child tetrahedra are there? I can't visualize what is happening in the center. I could probably look it up somewhere, but the fact that it's not obvious to my defective 3-d reasoning makes me nervous. This is not a data structure I want to work with.

Oriented cubes?

Fig 8: Oriented cubes

I have two problems with the leaf shape. One is that I'm insisting on doing everything from all six sides of the cube. That makes even a simple shape much more complex. I could solve this by orienting the cubes, so that the shape, whatever it is, always faces "up".

Figure 8 shows the 2D version. Independent of rotations, there are two cases. The box is either on the axis or on the diagonal. Picture a little heightmap or whatever inside each box, where "up" is in the direction of the arrow.

In 3D, there would be three cases -- the cube imbedded in a surface, with one face exposed, the corner with two faces exposed, and the corner with three faces exposed. I could define "up" in the corner cases as pointing along a diagonal of the cube.

Doing the cubes this way means checking that when the player deletes a cube, I also delete neighbors to make sure no cube has opposite sides exposed. That's manageable.

The other problem is the shape itself. I could just go ahead and use four heights making two triangles, and clip them to the cube. A stack of these with a steep slope is going to draw all the clipped shapes, and there is some round-off error to worry about, but it would work.

When you are digging, you might touch the middle of a sequence of these cubes, all with identical slopes. I'm not sure what happens to the middle cube in that situation, or how I adapt the neighbors.

I'd like to find some more natural shape to put in the leaf cubes, so that the landscape is built out of these shapes, and digging just removes some of the shapes. Perhaps there's a better way to do the whole thing! I'm open to suggestions. ]]> 2012-04-04T00:22:00-07:00 Feels like reinventing the wheel, but here's my solution. http://www.sea-of-memes.com/LetsCode53/LetsCode53.html http://www.sea-of-memes.com/LetsCode53/LetsCode53.html Feels like reinventing the wheel, but here's my solution. Part 53: Storing World Data

Minecraft stores its world data in a collection of files. Over the multiple versions of the program, the structure seems to have turned into a bit of a mess. The region directory contains two versions of everything -- the old mcr files and the new mca files. I think the DB is using both ZLib compression (for regions), and GZip file format (for the level.dat file.) The compressed formats don't just compress the raw data, but compress the "NBT" file format which originally stored the data in individual files.

Needless to say, I don't want anything like this to happen to my database format! I also have the problem that in Crafty at least, game developers are going to want to add their own state information. So I need a format that will support growth and extensions by other programmers.

Back in the early parts of this project, I had a version of Crafty with a file format of its own. I was storing all the 32 by 32 by 32 chunks of landscape in individual XML files. The sample world had several thousand of these chunks. I was relying on the Octree format to provide for some compression, but not doing much otherwise.

When Notch switched to the region format, it was claimed that storing multiple individual chunks in a single large region file improved performance. I have no reason to doubt this, but it is irritating. Storing data on disk is the job of the operating system. Redoing this in your own layer seems like reinventing the wheel. On the other hand, I could clearly see that copying these thousands of files, between my machines or to make backups, was extremely slow. The file system just isn't optimized around this kind of use.

So I need a format that can store large amounts of data, be used for individual files (for things like avatars) or huge collections (for regions), which can grow to hold new information, that isn't locked down to the particulars of the world (like chunk sizes), and that can be upgraded without breaking anything in old code.

It was tempting to do something XML-ish, with nested tags and so on, since that's the direction of file formats out on the net. On the other hand, I didn't want a complex format or interface, since there would inevitably be problems with it.

I also need something with decent performance, which means binary data and indexes which point directly to objects in the file, not text which you parse. I finally decided to go the other direction, and make it all brutally simple.

The Interface

There is a format signature at the very beginning of the file, which can be read without knowing anything else about the file format. This means that if a better implementation comes along, I can create a new format, signaled by a new signature, and completely change the structure of the files without changing this interface.

The interface supports a table of objects, each of which is an unformatted byte array. Each object is identified by a key, which is a variable-length string, with some reasonably large maximum length (say 512 bytes.) In addition, each object has a 64-bit version id.

This version represents changes to the object, not to the format of an object. So for example, the first version of a landscape before you modify it is version 0. Then when you add a block, that's version 1. Add another block, that's version 2, etc.

This will be used in the multiplayer game world. Your local database will be a cache for objects you've seen. When you enter the world, the client will display the versions it has on disk. At the same time, it is requesting the most recent versions from the server, with queries of the form "get chunk at 32, 64, 32. I have version 1234". If the server has a more recent version, it can send it. Otherwise, the client uses what it has.

Here is the complete interface of the ObjectStore class. I implemented this in C++, but I'll 'pseudocode' it for non-C programmers.

getFormat(string fileName) returns string formatSig
	Return the format signature on a file. The signature is the first line of a file, terminated by a newline. No other data is required for this method.
create(string fileName, string formatSig)
	Create a new object DB, with the filename and signature. It's an error if the file already exists.
open(string fileName, string formatSig)
	Open an existing object DB. It's an error if the format signature does not match.
close
	Close the DB.
writeObject(string key, int64 version, int32 length, byte array data)
	Writes the new version of an object identified by key. If an old version exists, it is deleted.
readObject(string key) returns int64 version, int32 length, byte array data
	Read the object identifed by key, returning the data and version. If the object does not exist, a null is returned.
deleteObject(string key)
	Delete the object identified by key.
indexStartPosition() returns an int32 position
	Start reading the index. A position of -1 indicates read complete.
indexNextKey(int32 position) returns string key, int64 version, int32 position
	Read the next entry in the index. The key and version of an object are returned. A position of -1 indicates read complete.

As I said, it's simple. The structure is all in the keys. For example, the Minecraft-style chunks have a major code, minor code for each brick (2 bytes total), and two lighting codes (4 bits each). You could implement this with keys like:

• "block/32,64,32/bricks" for the brick codes, writing 32 by 32 by 32 by 2 bytes of brick type data.

• "block/32,64,32/lights" for the light codes, writing 32 by 32 by 32 by 8 bits of light intensity data.

Other likely objects would include position of the players, animals, etc. No structure is imposed on the key names, but the programmer can clearly create a complex structure with this interface.

As the game code evolves, and the programmer wants to keep compatibility, he creates new key names. A version of the brick data with more brick types might be named "block/32,64,32/bigbricks". To do the conversion, the program reads the index for all objects ending in "/bricks" and upgrades them to "/bigbricks" blocks, deleting the old versions.

New data is added to the world by generating new keys. If biomes are introduced, a new key "block/32,64,32/biome" can be used. In old databases where it is not present, a new version can be generated.

Two restrictions on the DB can be seen immediately:

• There should be few enough objects per DB to conveniently scan through them all, at load time, or on demand. DB files do not contain millions of objects.

• Each object is small enough to return as a single byte array. There is no method for reading subareas of an object. I am keeping the data compressed with ZLib, so partial reads would be a nuisance to implement. Minecraft blocks are on the order of 32K bytes.

In use, a single DB could be one object (such as an avatar definition), all the attributes of a single chunk, or a region of chunks. It's left to the programmer to decide what granularity to use.

The Implementation

My first thought was that I needed to read and write objects as continuous ranges of bytes in the file, to get the best performance. I would then have to track free space and do some kind of first-fit or best-fit algorithm to allocate ranges for objects. I don't want an index at the start which would grow and require objects to be moved, so the index could be put at the end. You will be rewriting the index whenever you write new data anyway.

Several things put me off doing this kind of implementation:

• The data is going through ZLib for compression and decompression. That's liable to be the bottleneck, not disk I/O.

• Most objects will compress to a block or two, making I/O even less of an issue.

• Although performance of reads could be important, writes are done in the background, and are not performance critical.

• Even if you use continuous ranges of a file, the OS is not going to allocate continuous blocks on disk.

• The objects will slowly grow as the game is used, making fragmentation a problem. You are always going to need a slightly bigger slot than the object previously required.

• When the program eventually crashes, the code can die in the middle of an object write, corrupting the DB. I need to be able to reconstruct the objects despite partial writes.

I decided to just do something straightforward, and use a linked list of blocks, even though that guarantees I'll never read more than one block at a time. If this turns out to be an issue, I can revisit the design. File systems seem to cache an awful lot of file data in memory nowadays, so I'm not sure I'll even notice.

My impulse was to put a block header at the start of each block, but I didn't do that here. I wanted the very first bytes of the file to be the format signature, not the block zero header, so I put the header at the end of each (4K) block. The header contains the complete key of the object, version number, a block sequence number, and the next block in the chain. The last block has a next-block value of -1.

When I write an object, the code writes the new version then deletes the old version. A new index is written when there's nothing else to do. In case of a crash, odds are that at least one complete version of the object will be present. Since all blocks are tagged with the key, version and block sequence numbers, I can sequentially read the DB and rebuild the index if it has been corrupted.

The index is just another object, with two exceptions. First, it always starts in block zero. Second, when it is rewritten, it reuses the existing chain of index blocks, instead of allocating new ones. Since I am reusing block zero, it doesn't make sense to allocate new blocks for the rest of the index on a rewrite.

The free block list is written after the index, and updated when the index is. In addition, blocks are zero'd when they are freed (when an object is deleted.) This is unnecessary, since the free list could be computed from all the blocks not used in objects, if the DB had to be reconstructed.

It's a bit of extra work, rewriting all the deleted blocks, so if it turns out to be performance critical, I might stop doing it. But as I noted above, writes are done in the background and are not going to be performance critical. For debugging, I wanted the deleted blocks to be empty.

Current Status

I've implemented a first pass on this, and done a trivial amount of testing. Next I'll probably add some code to McrView to export into this format. Crafty and SeaOfMemes will import these files and use them to store modified world data.

I'm still working on the new code for modifiable landscape. Hopefully, that will be done for the next part.

Terrain

]]> 2012-03-27T11:00:00-07:00 Another decision I'll have to make one of these days. http://www.sea-of-memes.com/LetsCode52/LetsCode52.html http://www.sea-of-memes.com/LetsCode52/LetsCode52.html Another decision I'll have to make one of these days. Part 52: Scripting Languages

I'm currently working on two separate topics -- a new version of Crafty, and a new landscape algorithm. I've been switching back and forth and neither is ready for release. So here's another filler part, on scripting languages.

Rube Goldberg: Didn't he design C++?

The goal of Crafty is to be a framework for development of block-world games. I could just let people program their games in C++ and call into the framework. However, there will be plenty of casual game designers who would like something less formidable than C++. A scripting language would be nice, and there are several open-source alternatives.

Here are my criteria:

• Familiarity. I want a language that a reasonable number of programmers will know, that's well documented, and has a decent-sized community online. I don't want to be in the business of writing tutorials or debugging scripts for people.

• Integration. I need to integrate the scripting language into the framework. I need to manage its use of resources (trivial loops in the script should not freeze the game), and easily call into my framework from the scripts.

• Development Environment. For a first version, it would be acceptable to have a separate tool that compiles scripts. When an error occurs (or the script "prints" an output), the message could appear on an in-game console window.

  As games get more complex, I don't think this will be enough. Ideally, I'd like an in-game development environment, where you could create your castle, create an instance of a dragon, open a window and attach a script to the "someone approaches" event handler for the dragon, and then debug the script. This is a significant piece of work with most of the languages I've looked at.

Some Open Source Languages

I've been looking around the net for various open source language implementations. Here's what I have so far:

Lua

Lua is a small interpreter which claims to be "the leading scripting language in games", and to have been used in World of Warcraft. I haven't played with it at all yet, but it sounds like it would do the job. Code looks like this:

 -- add all elements of array `a'
function add (a)
  local sum = 0
  for i,v in ipairs(a) do
    sum = sum + v
  end
  return sum
end

Skimming the documentation, it actually has more language concepts than I would have put into a scripting language. The biggest downside is that I would have to learn it. :-)

JavaScript

The Google V8 JavaScript interpreter is open source and has a just-in-time compiler for Intel machines. This is probably the best known of the languages I could pick, given the number of casual web programmers out there. Code looks like this:

var i;
for (i = 0; i < 5; i++)
{
  document.write("The number is " + i);
  document.write("<br/>");
}

I have a certain amount of prejudice against this language. I implemented a compiler for it as part of a project back in 1997. This was before the formal spec was available, and the language was a bit different under each web browser. I got very frustrated by the sloppiness of most of the implementations. I think at one point I had a test case that crashed every browser I tried! I also think the language itself is a bit loose.

Since this is a JIT interpreter (compiles to machine language), I guess I would be stuck if I tried to port the framework to the iPad, but I'm not sure Apple is allowing interpreters inside apps anyway.

Smalltalk

The last time I used Smalltalk was in 1992, at a company doing pen-based computers. There's an open source implementation called Squeak. One advantage is that I think Smalltalk systems normally implement an IDE in Smalltalk as part of the language. So I would get "in-world" development tools, including a debugger, with the language. Code looks like this:

n := 1.
[ n < 1000 ] whileTrue: [ n := n*2 ].

I liked the language for the generality of it, and the small number of concepts. Although it was intended to be easy to learn, I'm not sure that it really is. Some of the block and class concepts can get a bit subtle. Perhaps it's just coming from a C++ background that made it all feel strange.

Although the language is very well known to computer science students, I'm not sure many casual web programmers have even heard of it, let alone know how to write it.

Java

Does anyone know what the situation is with an open source Java implementation? Google pulls up some projects, but also comments about Oracle suing Google over Android. Apparently there are patents, but I'm not sure what they cover (language, or some VM internals?) Code looks like this:

int sum = 0;
for (int i = 0; i < 5; i++)
{
  sum += i; 
}

If you include all the standard class libraries, Java would make an excessively huge scripting language. I'm also not sure how hard it would be to integrate into the rest of my framework. I need to call from C++ into Java, then back out to the framework. Calling the compiler and a debugger from in-world also seems like a challenge.

Python

Python is another popular programming language that I don't know. Code looks like:

def fib(n):    # write Fibonacci series up to n
    """Print a Fibonacci series up to n."""
    a, b = 0, 1
    while a < n:
        print(a, end=' ')
        a, b = b, a+b
    print()

Personally, I hate using indent level to define blocks. It looks really unnatural to me after 40 years of languages with block delimiters. I wouldn't let that stop me if this was my choice of language though.

More of a problem is the language itself. I'm a minimalist when it comes to languages, and paging through the tutorials, Python seems huge. There are a lot of different concepts, a lot of syntax, and a huge standard library. I'm not thrilled.

My Own Java

On various projects in the past, I've written compilers/interpreters for Pascal, JavaScript and Java. I can't really justify designing and implementing a "real" programming language for this project, even though I'd like to. :-)

However, I have my own implementation of Java, written as part of an earlier attempt at this project in 2005. It doesn't handle 100% of the syntax (and there have been changes to Java since then), almost no standard classes are implemented, and it's slow, but it would do as a scripting language.

The language is well documented and many programmers know it. Plus the expression syntax of Java is almost identical to both C++ and JavaScript. On the other hand, a restricted implementation of Java that doesn't have most of the class library might just be annoying to Java programmers.

I mostly want scripts for simple things like event handlers on creatures ("something is near you, so attack it.") For some of the languages above, I'd have to write (or at least integrate) some kind of editor and debugger into the world anyway. Working with my own code could save me a lot of time.

A Poll

As I see it now, Lua or my own Java will be the easiest to integrate into the framework. V8 JavaScript might not be too bad, and I have no idea about Python. Integrating a real Java into the framework looks hard, but I don't even know which codebase I'd be using for a real Java VM. If someone knows of a Java being used as a scripting language, let me know.

Both real Java and Python strike me as bigger pieces of code than I really want to deal with at this point, but I could still be convinced. Smalltalk is the only choice that will give me an in-game development environment out of the box. All the other choices require me to hook in debuggers and my own class editors, etc.

Here's a poll. Scripting is not something I will get to anytime soon, but I'd like to know what you think. Choose all languages you think are acceptable. Please leave comments if you want to argue for your choice, or know answers to any of my questions! ]]> 2012-03-20T18:30:00-07:00 Esperanto is the future! http://www.sea-of-memes.com/LetsCode51/LetsCode51.html http://www.sea-of-memes.com/LetsCode51/LetsCode51.html Esperanto is the future! Part 51: Internationalization

The demos and source on the download page have been updated, along with the GitHub projects. There are a few minor bug fixes, but no new function. The important change is I brought the OpenGL 2.1 code up to date. If you had troubles running the demos at all on your machine (especially Mac Leopard users), try again. The SaucerMovie demo still doesn't work under Leopard (it does under Lion). I'll look at it later.

My current goal is to get all my dead code cleaned up and released as demos. To that end, I've been working on a new version of Crafty, trying to integrate in some of the features that were in previous parts but never released. That's not done yet though, so here's a post about the endlessly frustrating topic of internationalization.

In retrospect, this was a stupid goal to take on at this point in the project. I have pieces of code in various states of unfinished lying all over the place. The last thing I needed was another piece of code to work on. I hope it pays off in the end.

A False Start

I wanted the framework to use Unicode -- internally when managing strings, for text typed by the user in input controls, text displayed on the screen, error messages and in the various option and other input files. Someone working in a language other than English should definitely be able to use the demos, and work on the code.

Fortunately, Windows, Linux and Mac all support UTF-8 encoded files. This is an extension of standard ASCII that allows 32-bit Unicode characters to be specified with multi-byte sequences. If you only use ASCII characters, the file is straight ASCII. If you use Unicode, the non-English characters are signalled with escape sequences.

Even better, Visual C++ under Windows, GEdit under Ubuntu Linux, and XCode on the Mac all allow you to use Unicode characters in source code, for both comments and variable names.

That's the good news.

Unfortunately, the shader compilers don't seem to allow UTF-8 variable names, which must be a nuisance for non-English speaking programmers. I suppose I could do some translation to get around this when I load the shaders in my framework.

I develop everything under Windows, then port it to Linux, and then to Mac OS. Under Windows, they clearly want you to switch from 1-byte ASCII to wide characters and do everything that way. The Visual C++ environment defaults to the Unicode character set, and that option makes all the system calls take wide strings. So I started to convert my code to use wide strings everywhere.

The nice part of doing the conversion that way is that very little code changes. If you were referencing str[i] before to get a letter of the string, you can still do that. You just have to change every string you use from normal to wide characters, and make sure you assign everything to the correct types. The only problems I ran into were the few cases where I assume a character is a single byte. This happens when I use memory moves instead of string copy operations, or allocate memory in bytes instead of characters. There were only a few places like that in the code, so it all went smoothly.

OpenGL takes strings in a few places, and won't take wide strings, so those all had to be converted, which is a nuisance. Files in UTF-8 have to be converted to wide characters on input, and wide strings have to be converted to UTF-8 on output, but Windows actually has options on file I/O to do all this for you. I had the demos running again in a few days.

Then I started converting it for Linux and Mac, and realized this was all wrong. I really hadn't done my homework before I started.

Systems Programmers and Their Little Jokes

The first false note came when I noticed that Unicode is a 32 bit standard, and Windows wide characters are only 16 bits. Under Linux and Mac, wide characters are 32 bits. So I could have a situation where a Linux chat program generated a Unicode character that the Windows version could not read.

The Unicode documentation calls the 16-bit tables the "Basic Multilingual Plane", and suggests that only rare characters would fall outside that range. On the other hand, Wikipedia states that there are Chinese dictionaries with 100,000 characters, which would not fit in 16 bits. I have no idea how many of these are used in practice, or how many national variations there are. 16 bits suddenly seemed a bit cramped.

Things got more interesting when I played with the three compilers. On Windows, if you write a Unicode string "sigma(σ)", the UTF-8 source file will hold the sigma character, but Visual C++ will complain it's an invalid string. Under Linux, it will compile to a UTF-8 string, with two bytes for the sigma character. The same on the Mac.

If you specify a wide string, L"sigma(σ)", Visual C++ now likes it, and produces 16-bit characters for the entire string. Linux gcc also likes it, and produces 32-bit characters. Mac XCode likes the string, but seems to produce UTF-8 characters padded into a 32-bit frame. This is so stupid and useless I had to check it twice.

All three systems have wide versions of the simple string routines like strlen, which takes the length of a string. I think I could have found wide variations of all the C library routines I use. Text files would have had to be handled differently, since _wfopen on Windows takes a wide string for a file name, and fopen on Linux/Mac wants a UTF-8 string. Windows also wants to write a "Byte Order Mark" at the head of text files, which Linux and Mac do not.

I was dithering over whether to use the wchar_t type, which is 16 bits on Windows and 32 bits everywhere else, or just use UTF-8 strings on all three platforms. UTF-8 seemed better supported in file form, but some of the pages I ran across on the net made it sound like 32-bit characters in your code was the "real" way to do internationalization. What finally decided me was the issue of "combining characters."

Combining Characters

Despite having 32 bits for characters, Unicode does not define every possible character. You can still combine accent marks, subscripts and superscripts, bars and arrows and underscores (as in mathematical notation) with other characters. This combined character takes a single position when drawing the string, or when moving the cursor in an input field.

That means that even if I used 32-bit characters internally, I still would not have one code per "letter" in the string. A single letter would have to be represented as a list of glyphs, all drawn on top of one another.

If I can't loop through a string with str[i], I don't see the point of using wide characters. Grumbling, I recoded my framework to use UTF-8 everywhere, and added methods to my mgString class to iterate through multi-byte characters, returning all the codes that make up a single "letter" in the string. I actually had to convert the framework back to single-byte characters, since I had been doing work on all the apps after the first conversion. Sigh.

But Wait, There's More!

Some characters like "é" exist both as single characters in Unicode, and as combining sequences (the accent plus the "e".) On input, you'd see the sequence of two characters. You'd have to know that these can be combined and you have to do the conversion by looking the string up in a table somewhere. I would need to find this list in some digital form (not a document) that I can convert into a hash table for my string code.

When you combine characters, you have to normalize the order, so that "accent+char" is equal to "char+accent", even for the combinations that are not represented as single codes. There's also a sort order for strings, which is different for each language. And rules for converting to lowercase, which I do on things like options, so that they are not case sensitive.

Implementing all this is a project in itself, but it's been done. I downloaded the International Components for Unicode (ICU) library which supposedly does everything. I thought of making this one of the libraries in my project, but it's huge. I haven't decided what to do. I might still incorporate it as a DLL, or just use it to generate some tables for me to include in my code.

That's not the end of the work though. In addition to handling combining characters, sorting, etc., I have the problem of input methods. I can take non-English keys and combine them with the right tables. I can also take numeric codes for Unicode characters if you only need an occasional character.

With a bit more work, I could have pop-up dialogs you can pick characters from, equivalent to the keymap applications on Windows, Linux and Mac. I could allow cut and paste from those apps, but in a full-screen game, that would be a nuisance.

For the Asian languages which don't have every character on a key, I would need some kind of input support. YouTube pulls up videos that show people typing phonetic sequences and then picking from a choice of characters. I have no way to write that code, and I don't know where to find it.

In addition to input, I also have output problems. I'm not sure where to draw accent marks and other combined characters when there are multiple characters in a cell. I don't know if there's even enough information to do this with FreeType.

Error Messages

UI dialogs and help text can be translated into different languages. With a language option in the code, I could display the correct version without any trouble. Error messages are a special case however. They have variable information.

In English, I want to say something like "Option 'textFont' cannot be 'Comic Sans'." In a different language, the two variables here ('textFont' and 'Comic Sans') could be presented in a different order. To handle this case, I defined a little XML file that holds all my error messages. An entry looks like:

<errorMsg id="xmlNoOpenTag">
  <var name="filename"/>, 
  line <var name="line"/>, 
  col <var name="col"/>: 
  Closing tag "<var name="tagName"/>", 
  open tag is "<var name="topTag"/>".
</errorMsg>

This would result in a message like:

options.xml, line 22, col 2: Closing tag "opt", open tag is "options".

In my code, where I used to just throw an exception with the English-language error message, now I throw an ErrorMsg object with the "xmlNoOpenTag" message code, and the variables listed as arguments. This is looked up in the error table and formatted for the user.

Still To Do

The current version of the framework has some UTF-8 support, but there's a lot more to do:

• Recognize combining character sequences, normalize them and convert the ones with single-code equivalents.

• Draw combined characters correctly.

• Add a numeric Unicode input method. Annoyingly, there are at least three conventions in use on the different systems.

• Add some kind of pop-up character palette.

• Add input helpers for Asian languages, if I can find library code to do this.

This is not next on my list (I'm sick of it!) but I would like to do it eventually. Some of it is easy. Unfortunately, I don't even know how much of this is really required. I've looked at sources around the net, but I'm not sure how much language support there is in most general-purpose apps, or in games. Do other MMOs (World of Warcraft?) have Chinese language input helpers?

Readers, let me know!

Esperanto is the future!

]]> 2012-03-10T10:00:00-08:00 The demos are all up to date, and the source has been released again. http://www.sea-of-memes.com/LetsCode50/LetsCode50.html http://www.sea-of-memes.com/LetsCode50/LetsCode50.html The demos are all up to date, and the source has been released again. Part 50: Spring Cleaning

Looking at all the pieces of code spread over my disk, and the months of time which have passed since the last update of the source code on GitHub, I realized it's time for some spring cleaning. I've also added a new download page to the site and changed the front page.

You can download all the demos in one big zip here:

For Windows, download Part 50 Demos - Windows.
For Linux, download Part 50 Demos - Linux.
For Mac, download Part 50 Demos - Mac.

You can download all the source code here: Part 50 Demos - Source.

Or get all the source from GitHub:

https://github.com/mgoodfel/mgFramework
https://github.com/mgoodfel/SeaOfMemes
https://github.com/mgoodfel/Crafty
https://github.com/mgoodfel/McrView

Changes

There are numerous small changes to the framework and demos. For UI, you can get help on all the demos with F1. The demos now start with an arrow cursor and you end the app by just closing the window. ESC toggles to a cross cursor which works shooter-style causing the mouse to turn the eye.

I've rebuilt the 2D text using the FreeType library, so we now have text on all three platforms. Yay! This may cause some problems:

• I rely on the operating system to tell me the dots per inch of the display. This can be wrong. If the text is the wrong size, edit the options.xml file for the demo and change the dpi option. Zero is the default and means trust the OS. Reasonable values are around 100. Higher numbers will get you larger text.

• Each operating system puts the fonts in a different directory, and spells them differently. On Windows, we look in c:\Windows\Fonts for georgiaz.ttf, and on the Mac we look in /Library/Fonts for Georgia Bold Italic.ttf. And so on. There's now a new file docs/fonts/fonts.xml which gives the framework font names to try. Rather than hardcode these for each platform, it just looks for all of them until it finds a font.

  If for some reason, your system is not finding any fonts, the app will put up an error dialog, or just crash (I don't have error dialogs working on Linux.) Send me the errors.txt file, or look there yourself to see if it's looking for the wrong font name on your system, or looking in the wrong place.

• I'm not caching any of the character bitmaps produced by FreeType, so text is quite a bit slower than it was. I'll fix that soon. None of the demos use much text, so you shouldn't notice it.

The other big change in the framework is the internationalization code. I'll write a separate part on that. It still needs work.

Statistics

Readers have also asked me to update the statistics on how much code there is in the project. That's a bit of a problem. There's a lot of code duplicated in the framework -- between OpenGL 2.1 and OpenGL 3.3, and between the Linux initialization and the Mac initialization, etc. The demos have variations on the same code for their UI. It's a judgement call what to count.

When I last counted all the code (part 19), I was picking and choosing parts of each platform, based on how different I thought they were. I neglected to make a list of which files I counted! To get comparable counts from then to now, I've redone the Part 19 counts to just include OpenGL 3.3 on Windows, and nothing else. I've done the same for the Part 50 source. This is just lines of c/c++ source, with no include files and no shaders.

	Part 19	Part 50
Framework lines	7,402	9,405
Utilities lines	6,738	10,986
Application lines	8,631	41,421
Total	22,771	61,812
Coding hours	464.7	1,225.1
Writeup hours	90.2	243.3

Counted this way, the 3D framework hasn't grown much. Some function has actually moved out of the framework into the "Utilities" category -- all the covering classes for threads, events and timers moved, for example. The biggest growth has been in application code.

I've eliminated duplicate code in Crafty, McrView and SeaOfMemes, as well as duplicate classes in the little framework demos. I'm also not including any of the utilities I've written like the Collada importer, or side projects like ray tracing. So this is an underestimate of the project size at this point.

I don't plan to update the source totals very often, since it's kind of a nuisance. I have to combine the source from all the parts of the project, then eliminate any shared code and any library code. I'll do it again when I have some kind of significant milestone.

Next, let me run through each part of the project and give you the status.

SeaOfMemes

The demo shows the planet, moon and ring. You can sort of land on them by approaching until the range text turns red, then hitting "L". That should rotate the eye space until you are in the coordinate system of the object you land on. It doesn't quite work right. Hit "L" again to transition back to space.

The options file controls the rate of motion of all the system objects. You can change the rotation speeds if you like. The "DayLen" options at the end are in seconds. Don't use zero.

There's dead code in the project for asteroids and generation ships, etc. I'll get to work on cleaning that up soon. For now, this is the same as the Part 41 video.

To download SeaOfMemes alone, go to Download SeaOfMemes. Here's a video.

Crafty

I've thrown out the old Octree-based version and replaced it with the latest code from McrView. I'm generating the landscape procedurally and converting it into cubes as you move. There's no editing function yet. That will be the next item on this part of the project.

To download Crafty alone, go to Download Crafty.

McrView

There is nothing new in McrView since Part 37. I'll put putting an export dialog into this next.

I might also add code to read the location of your avatar from the Minecraft files. That's kept in a completely different table than the world data, and so I ignored it. Some of the worlds I download from the net have the buildings far away from the (0,0,0) position however, and I can't actually find the good stuff!

A map view would also be nice. So would a way to view nether areas.

Of course, as I was testing this, I happened to fire up the real Minecraft, and noticed they've changed the file format (again!) So now I have to add code to handle the new database. Sigh.

To download McrView alone, go to Download McrView. Here's a video.

Framework

TestCube	Trees
Landscape	SaucerMovie

There are now four framework demos -- TestCube, Trees, Landscape and SaucerMovie. To download these, go to Download Framework.

That's all for this week. ]]> 2012-03-01T05:55:00-08:00 Now with demos. http://www.sea-of-memes.com/LetsCode49/LetsCode49Update.html http://www.sea-of-memes.com/LetsCode49/LetsCode49Update.html Now with demos. Part 49 Update

Sorry about the two week delay. I lost another week to health problems, and I had family visiting for a few days. I was planning on a more ambitious Part 50, but it was taking too long. So here is the Saucer Movie demo for the three platforms.

The Linux Port

I had used the OpenAL audio package because it ran on all three platforms, so I expected the port to Linux to be no problem. And the library did compile and link without any issues. The SaucerMovie program ran, and I saw all my animation. But no sound!

Looking at the diagnostics, OpenAL was reporting that there were no input or output devices. When CMake builds the makefiles, it includes the drivers it thinks are supported on the system. It turns out that it doesn't add drivers unless you have the development libraries for them installed (Naturally, since it can't compile the drivers without the header files.) Googling, it looked like I wanted "Pulse Audio" and perhaps "ASLA". I installed both of those, rebuilt OpenAL and tried again.

This time I got sound, and life was great -- for 20 seconds. Then the program hung and had to be killed. Sigh. The same web page that told me I needed PulseAudio also complained that it could be unstable with OpenAL and Ubuntu, and I thought "not this again!"

I noticed however that the sound was cutting out at the same point every time -- right after the saucers stop firing and the "laser" sound is deleted. So I thought perhaps OpenAL wasn't thread safe, or that I was messing up in my background thread where I keep feeding buffers of audio to the system. After hours of walking through that code, I found nothing.

Finally, I noticed something odd -- the dead saucer was disappearing. This is the step after the sounds end, indicating the demo was getting a bit farther than I had assumed. I put in some more diagnostics, and sure enough, it was hanging at the point where it creates the huge fleet of saucers just offscreen. I thought perhaps I was creating too many sounds and overloading something. That would be a nuisance.

More tracing revealed that the whole thing was a bug in my code. When I create the fleet of saucers, I just do it brute force. It has a loop where it creates a saucer, gives it a random position, then checks to make sure that position is not on top of another saucer. That loop was never exiting -- as if it could never find a good position for the new saucer! The positioning code looks like this:

saucer->m_origin.x = -150+300*rand()/(double) RAND_MAX;

saucer->m_origin.x = -150+ (300*rand()) / (double) RAND_MAX;

Changing this to

saucer->m_origin.x = -150+ 300*(rand() / (double) RAND_MAX);

Installation Issues

I was still perplexed about what to do with the OpenAL build though. I didn't really want to tell people to install two development libraries, rebuild OpenAL and relink the app to run it! I didn't see how I could distribute my own binary version of OpenAL though, since it needs to be customized to each system it runs on.

I finally realized that OpenAL was probably an installable package under Linux, and that I should just link to the dynamic library in my code, picking up whatever version is present on the system. And sure enough, if you install "libopenal1" under Ubuntu, that all works fine. It's kind of a nuisance that it isn't installed by default though. Does anyone know what game developers for Linux are supposed to use?

On the Mac, OpenAL is their default sound support, and everything worked right out of the box. I also did a system update and discovered I now have OpenGL 3.2 on my MacBook Pro! Yay! So you might have nicer, faster graphics on your system. The graphics processor in my MacBook Pro is the same as the one in new models of the Air and Mini. Hopefully, OpenGL 3.2 works across the line now.

So I now have a sound demo on all three platforms. Let me know if you have any problems. You can play with the options if you want to change the sounds. It should play any ogg files you have lying around.

For Windows, download SaucerMovie Part 49 - Windows.

For Linux, download SaucerMovie Part 49 - Linux.

For Mac, download SaucerMovie Part 49 - Mac.

Hit "M" to start the movie animation. ]]> 2012-02-17T01:30:00-08:00 Beep! Boop! It's a video game. http://www.sea-of-memes.com/LetsCode49/LetsCode49.html http://www.sea-of-memes.com/LetsCode49/LetsCode49.html Beep! Boop! It's a video game. Part 49: Sound

I started the week working on character animation for a small model I had put together. I decided I didn't know enough to do that right, and ended up buying a book: Game Engine Architecture by Jason Gregory. It tries to cover the entire range of game engine issues, and on many topics, it's just a summary with (badly formatted) links. It does have a pretty extensive chapter on character animation. But the more I read, the more I realized it was a huge project.

I looked around for something else to do for this part, and settled on Sound. The final result of this is just some new code for the project, but to have some fun with it, I also made a short movie. Skip to that below if you get bored with the technical stuff.

Ogg and Vorbis

During my previous attempt at this project in 2005, I had worked through the spec for Windows DirectSound and written a test program. Back then, I wasn't worried about distributing a demo, so I had just used uncompressed Wav files. This time, I wanted longer pieces of music and so I needed a codec. I originally thought I'd use MP3, but some discussion on the net convinced me to use Ogg Vorbis instead. There's a reference implementation and supposedly no license issues.

Ogg turns out to be the container format, which can handle a variety of streaming content. Vorbis is the audio codec.

With the Vorbis library, there's a sample decoder that reads the Ogg file, decompresses the audio with Vorbis and writes it to a file. There's also "VorbisFile" layer that reads an Ogg file without exposing any of the underlying API. Both of these produce output buffers of arbitrary length, determined by the size of the compressed packets.

This was a problem for my DirectSound test program -- it wants me to fill a fixed size buffer. Yes, I could have coded around that, but the guts of the Vorbis file layer are really complicated, since it supports seeking to the middle of the file and re-syncing the audio. Even the simpler decoder example was a problem -- I need to understand it well enough to unwind the loop, and read more audio data when DirectSound needed it, not just run through the entire file and convert it in one pass.

I spent a couple of days reading the Ogg and Vorbis documentation and puzzling over the example code before I got my version to work. Ogg supports "pages" which contain "packets", although packets can apparently span pages as well. I also found the names of routines a bit confusing. Would you call ogg_sync_pageout, followed by ogg_stream_pagein to start a new page?

Once you work through the docs, it's really simple (simpler than their example, actually.) For reference, you structure your code like this:

• Read and process the Vorbis header packets from the file.
• Start a new page.

• Try to read a packet. If this succeeds, you are done.
• If it fails with "need more data", read a page.
• If this fails with "need more data", read more of the source file and push it to Ogg.
• Go back to the top and read a packet.

Once you have this routine, decoding the file is simple:

• Read a packet.
• Decode it with Vorbis.
• Copy wave data to your audio buffer.
• Repeat until you have filled the buffer.

OpenAL

DirectSound is Windows-only, and I wanted to support other platforms. OpenAL was recommended by a reader back early in this blog, and seemed to do everything I needed, so I went with that.

OpenAL builds with CMake, and everything I've done so far under Windows uses Visual C++ project files. I really didn't want anyone grabbing the code to have to mix different methods of building the libraries, so I rebuilt the OpenAL library with Visual C++.

That involved some messing with configuration files, and one mystery problem with initialization. I cannot figure out how the original code initializes itself when used as a static library, not a DLL. I had to fix that, by bashing it with a rock.

Unlike DirectSound, which uses Windows Events, the OpenAL API requires you to poll the various sounds to see if they need more data. When I saw that, I imagined some spin loop running in its own thread, burning CPU, but of course that's not needed here. For each sound, the example sets up three buffers -- one playing, one ready to play, and a third being loaded. By making these hold 1 second of audio each, I have plenty to time to load new data even if the polling loop only checks every half second.

Once that worked, I wrote a cover for the whole mess -- Ogg, Vorbis and OpenAL -- to just support attaching Ogg files to objects and moving them around in three dimensions. I packaged it all up as a single audio library, to go with the Jpeg lib and my multiplatform "mgFramework" library.

A Short Rant

I know this is all open source and we should be grateful for what we get, even if the documentation is a bit terse and the code a bit dense. But these guys aren't working on a hobby project. This is intended to be a reference implementation of a standard. And when that's your goal, make the damn code compile without errors!

Both Vorbis and OpenAL spit out type conversion warning messages -- "conversion from 'double' to 'float', possible loss of data" etc. The Vorbis code may have been written assuming that library functions like "cos" and "floor" return float instead of double. When I replaced them with "cosf" and "floorf", a lot of errors were fixed.

That can't be the only explanation though. There are plenty of explicit uses of the "double" type, and the code mixes float and double constants (0.5f, and 0.5) freely. It just seems a bit confused over which floating point type it's using. I assume that's due to multiple authors, but it's also trivial to fix. It's not like this is the first release!

The code also consistently rounds numbers by adding 0.5 and truncating to integer, without an "(int)" cast, and it assigns pointers without regard to type (void* to char*). That doesn't bother the compiler, although the IDE underlines them all as errors. And I suppose the code could be really, really old (before C++?), but using "new" and "this" as variable names really throws me when reading the code.

There's even less excuse for this in OpenAL. It actually defines its own type names for everything and has conversion routines. Why would you write something like this and not explicitly cast the result to shut up the compiler?

ALfloat Conv_ALfloat_ALint (ALint val) 
{
  return val * (1.0/2147483647.0); 
}

I went through the Vorbis code and fixed all the warnings, and some of these variable names. I didn't fix all the pointer assignments because they don't produce error messages (and they are everywhere.) I haven't tackled the OpenAL code yet. This is really not the sort of thing I should spend time on...

A Movie

To have some fun with all this code, I decided to make a very short movie. A search for music found the piece I was looking for in a Wikipedia topic. As with all the other background music I've used, YouTube flags it but doesn't ban the video.

Next, I needed some sound effects. I found a cheesy laser weapon sound (free!) at AudioMicro, but was stumped for the flying saucer. Google just pulled up a lot of "spaceship whoosh" sounds, not the classic 1950s saucer warble. AudioMicro had an effect that sounded OK, although I needed to edit it. Unfortunately, it wasn't free. After several failed searches for an alternative, I just paid the $9 they wanted for it.

To edit my sounds, I downloaded the Audacity open source sound editor. This has done everything I needed, although that hasn't been much so far. The resulting movie is here. Trivial as this movie is, it takes a bit of implementation. Watch it first, then read the list of steps in the construction.

The movie program is implemented as a state machine, with each state transitioning to the next once time or other conditions are satisfied.

• Look at the stars for a few seconds while the music plays.

• Create some saucers and let them pass by for a few seconds.

• Create the "broken" saucer offscreen and let it drift to a stop in view.

• Create the first "killer" saucer.

• Wait a bit, then create the second killer saucer.

• Let the first killer come to a stop, then start his attack.

• Let the second killer stop, then start his attack.

• Attacks continue until broken ship is red hot.

• End the beams and wait while the broken ship fades.

• Killers start moving again.

• Pan towards Earth.

• Play background music to end.

None of this is complicated, but the timing does take some fussing to get right, as do the camera angles, grouping of ships, etc. I found that after working on the video a bit, I lost the ability to tell if I was presenting things too quickly. I had to come back to it after a day and look at it again.

That's it for this week. I'm going to release the program that creates the movie as a demo once I get a few more things cleaned up (and get it to work on other platforms.) I'll post a notice when that's available. I'd like to see if sound works for all of you.

]]>