GameJolt has a contest going on with the theme, "shocking". Entries are due Friday before midnight. I'm going to try to whip up something to put my tools/skills to the test. It will force me to stop procrastinating with some things that I must do, such as using custom resource files. I'm going to create assets that I can use in Saga City, too. So it will be a robot-themed mini-game. I would like to use shaders for this, but there's no time.

I've made a few minor improvements:

I fixed the 'fly by hitting jump button rapidly' bug.
I removed the camera jerk that happens when you change the direction you're facing. In the same block of code I find the angle from the player's arm pivot (shoulder) to the reticle, and the camera's offset from the player's position (for looking around). The problem was that I used the arm pivot instead of the player's origin for the camera's offset origin. So the camera 'snaps' when you turn around because there's no smooth transition of the arm's position. If I add a turn-around animation, I could use the arm's position again. When the camera is based on the arm, the shoulder's animation position is translated to the camera, which gives it a kind of 'bounce' when running. I'm not sure if its a neat little detail, or just annoying.


Sound:

I've started the sound system, and I'm using OpenAL. I don't have time to design something better, so all sound capabilities are in a namespace. I have yet to have it check a list of loaded buffers so that nothing is loaded twice. OpenAL is designed to be like OpenGL, so I store the unsigned integer handles it generates in my object classes. It gives me a handle for each source and each buffer. When I want to play a sound, I take both the source ID and buffer ID that the object has, and make a call like: audio::Play( sourceID, bufferID ). Very simple. I'll need to update the source positions and the Listener position on each update. Each object with a source will update the position automatically in the top-level Object class (which is really only responsible for updating it's position anyway). Sound is equally as important as visual rendering so I don;t feel weird puting sound code in my basic Object class. The more sounds, the better! My namespace is really just a wrapper around OpenAL so far.
Here is the source: Audio.h Audio.cpp
If you decide to use them, download the OpenAL libraries here and be sure to get the documentation. The docs are absolutely great at explaining the elements of the library. Once you understand the elements: devices, contexts, listeners, sources, and buffers, you should see the code is straightforward.

I'm working on support for Ogg/Vorbis files using this article as a start. Its old but still seems halfway accurate. The Ogg format will be important to use for music files because they can get pretty big.

Let me say that it is a PAIN to find decent sounds to use.


Explosions:

I've implemented a simple-but-effective way to do explosions. My first was to create a circle shape, and upon any collisions with the shape, apply an outward force to the colliders. That didn't work for anyshapes already inside the circle when it's created. My next try was the most common. I would query the Box2d world for any shapes with a bounding box around the explosion point. I'd loop through those shapes and apply an outward force on each body. This works ok, but because you don't know where on the colliding body to apply the force, you must use the body's center of gravity. It works, but no offending bodies will have any spin as they fly away, which looks a little too unrealistic.

I searched on the Box2d forums to see what others where doing. One user is implementing an algorithm that uses a series of raycasts pointed outward in a radial pattern. For each cast that hits another body, you have the body and collision point to apply the force. It also gives you occlusion so explosions don't go through walls, and the basis for using particles during render. This seems impressive and perfect for my use, but he won't give away the source. So I was left to implement this technique myself or keep looking...

One of the replies to that user's technique suggested an easy and simple explosion method: simply create a bunch of circle shapes and send them outwards in every direction and destroying them after the explosion interval. It gives me the best approximation of an explosion, and lets the physics code "push" any offending objects away. Of course, it increases the time needed to compute the reactions, so a careful balance must be found in the settings to avoid a drop in frame rate when more than a couple explosions go off. Also, there is a limited number of 'contacts' allowed in Box2d, so I'll need to find a way to strictly enforce this limit.

Explosion shots and demo should be in the next post.