I have created a movie of the recent development code running on some really high-end machine, and uploaded it to the Video Google program. I highly recommend both the Video Google and the movie.
The movie was recorded on Linux using xvidcap.
Sunday, April 30, 2006
Music from "Dark Overlords of the Universe"
A fellow from my university has gracefully agreed to provide me with his band's music. For now, I have picked one song for the introduction GUI. It's the song "Going Agro!" ('agro' means getting angry).
Here is the band's site: http://www.darkoverlordsoftheuniverse.com/
And their logo:
Big thanks, guys!
Here is the band's site: http://www.darkoverlordsoftheuniverse.com/
And their logo:
Big thanks, guys!
Pulling GUI and Sounds
Another developer on the team has created GUI component of the project along with a new project states management - GameStates. This makes for a better approach then old way of simply following OGRE demos code. Now, GUI and the rest of the code are tied up. And more importantly the code feels a lot better, that is cleaner and easier to maintain.
Another big component that made its way is Sound. For this, I rewrote my old code for OpenAL to work with Fmod. I had some problems with OpenAL running on my Windows, so I decided to ditch it. When comparing Fmod with OpenAL, Fmod has a slightly better interface since it uses a bit of C++ as opposed C-interface of OpenAL (I prefer OOP when dealing with large project such as Ukrainian Rumble). The problem however is that Fmod still feels like a C-library. Even though it offers "Objects", they are very rudimental. For example, error handling is done by each function returning a FMOD_RESULT objects which is a enum (yes, every function does that with a few exceptions). So after each Fmod call, you need to call some method to check for errors. This is rather annoying. Exception handling would be much better, but those guys have their reasons. Nice C++ interface is not on top of their list. One way or another I made a wrapper around Fmod to give myself something I can live with. Other than the interface, Fmod seems to be a powerful system that supports all major platforms, including upcoming next-gen consoles.
Now, writing a wrapper for Fmod is a simple task compared with making sounds feel right for the game which heavily relies on physics. This means that I am dealing with a "messy" system (physics engine) that does not provide exact same results for every run. Furthermore, physics give you a range of results. For example, let's say you want to play a sound for each collision. OK. I create and assign the right classes, etc. Run the application. Here is what I get: a sound for each collision, no matter how small or big it was. Alright, a threshhold is put in place, and now collisions are filtered out. Now, I notice that those collisions don't reflect real life, for example I might get 5 collision for an object simply sliding. Another thing is that collisions vary in magnitude (big and minor ones). So, now I need to add a filter to set a correct volume of the sound. After this, we get into situation where different collisions should sound different. Think of sliding motion or simply different surfaces. Mmm...
One note about sound. Once you add one, you need all of them. This is because with no sound you don't notice that everything is silent, but once you have a single sound effect, your mind expects to hear other sounds as well.
All in all, GUI and sounds add a lot to the project. It feels more complete now.
Another big component that made its way is Sound. For this, I rewrote my old code for OpenAL to work with Fmod. I had some problems with OpenAL running on my Windows, so I decided to ditch it. When comparing Fmod with OpenAL, Fmod has a slightly better interface since it uses a bit of C++ as opposed C-interface of OpenAL (I prefer OOP when dealing with large project such as Ukrainian Rumble). The problem however is that Fmod still feels like a C-library. Even though it offers "Objects", they are very rudimental. For example, error handling is done by each function returning a FMOD_RESULT objects which is a enum (yes, every function does that with a few exceptions). So after each Fmod call, you need to call some method to check for errors. This is rather annoying. Exception handling would be much better, but those guys have their reasons. Nice C++ interface is not on top of their list. One way or another I made a wrapper around Fmod to give myself something I can live with. Other than the interface, Fmod seems to be a powerful system that supports all major platforms, including upcoming next-gen consoles.
Now, writing a wrapper for Fmod is a simple task compared with making sounds feel right for the game which heavily relies on physics. This means that I am dealing with a "messy" system (physics engine) that does not provide exact same results for every run. Furthermore, physics give you a range of results. For example, let's say you want to play a sound for each collision. OK. I create and assign the right classes, etc. Run the application. Here is what I get: a sound for each collision, no matter how small or big it was. Alright, a threshhold is put in place, and now collisions are filtered out. Now, I notice that those collisions don't reflect real life, for example I might get 5 collision for an object simply sliding. Another thing is that collisions vary in magnitude (big and minor ones). So, now I need to add a filter to set a correct volume of the sound. After this, we get into situation where different collisions should sound different. Think of sliding motion or simply different surfaces. Mmm...
One note about sound. Once you add one, you need all of them. This is because with no sound you don't notice that everything is silent, but once you have a single sound effect, your mind expects to hear other sounds as well.
All in all, GUI and sounds add a lot to the project. It feels more complete now.
Saturday, April 08, 2006
Missile Controllers are done.
After "some" work, missiles actually fly, and home in to their targets. It turned out to be much harder than I thought they'd be. Most problems came from improper math calculations. Especially hard to track were bugs that were related to local coordinate system of the objects, which caused problems for missile rotations, spin, and control thrust. This in turn caused confusion in the controllers that did not receive correct missile status, and made wrong decision how to correct them.
What this means for bug fixing, is that there were multiple layers of interactions, so a digging was necessary to identify actual problems and not their results.
Man, I imagine how much work it took to implement control for real-life air missiles.
Here are missile trying to hit each other. Yeah, missiles at the moment are trying to hit anything you click on.
What this means for bug fixing, is that there were multiple layers of interactions, so a digging was necessary to identify actual problems and not their results.
Man, I imagine how much work it took to implement control for real-life air missiles.
Here are missile trying to hit each other. Yeah, missiles at the moment are trying to hit anything you click on.
Subscribe to:
Posts (Atom)