Holy Moly, Batman!

So somewhere, far back into the dark ages (I.E. a year and a half ago), I wrote a tiny little function. This wee little function was made for a small, developing program barely scratching a hundred lines of code. It's sole purpose in life was to pull together all of the little loose ends of logging and present them as a single API capable of getting a direct hit from even the most critical hacker. It would go on in life to form a bullet proof backbone to a full thirty-five thousand lines of code spread across two projects.

It's name was logAddEntry().

 I found a bug in it. This piece of code has literally gone untouched for over a year and a half, and has supported my two biggest projects since almost two years ago. It fell prey to a simple fixed-length buffer error... If the sum total of all of the arguments to the function is over 1000 bytes, then it will write over the end of the buffer. It's amazing how long some pieces of code last...

Along a different note, I've recently become frustrated with the whole speech to text system. It never seems to recognize my voice correctly - I'll be following the dummy ship, and I'll give a command to shift a couple of degrees because, well, the torpedoes are very touchy. Next thing I know, I turned ninety degrees off course and I have to redo the entire alignment. So to counteract this, I implemented a message box style system. Using this system, you can type the commands instead of having to speak them. It can be activated with the 'c' key. Then, just type what you would say, almost verbatim. It literally substitutes the text that you type for what you say, pretending that what you type came from PocketSphinx. It's useful, despite the requirement for attention to detail. There is one nice shortcut, which is that BNov will parse numbers. It comes in handy :)

Messaging System At Work

Also, I implemented a simple skybox method. SVN r28 has a simple, standard SkyBox: I.E., I rendered a large textured box. In that particular rev, and every rev since, the textures are not done well. However, I had the epiphany that 'skybox' is not how the world is... And neither is 'skysphere.' See the illustration below. However, I decided that to best capture how clouds actually look would require a 'skyplane' along with the 'skybox.' The only thing that would be on the skybox would be the sun and blue sky - If we even want that. One thing that would be nice would be having the shaders generate the sky color automatically, along with lens flare. Then, the skyplane would have the clouds. We could even have multiple layers of clouds this way.

Oh - and by the way... I've changed what I think of the SONAR model (again!). I was looking at Dangerous Waters, which is another sub game, but I'm seeing a consensus... The dangerous waters system contains three systems: Broadband, narrowband, and DEMON. Broadband is a ring graph around the ship of total noise (possibly weighted by frequency - I'm not sure) versus bearing. Narrowband also takes the form of a circular graph - It records frequency versus bearing. DEMON is a true waterfall diagram - Time scrolls upward, while the horizontal axis records frequency profiles. The cool thing is that SONAR2 is able to support this new operating paradigm without modification, so that effort wasn't wasted.

Prototype SONAR Broadband Display

On a more specific note, I found what is perhaps the best resource in all of human history. And no, it's not Wikipedia. It's an illustrated guide to Submarine design history since WWII (Link), and I will admit that it is one of the few books that I'm seriously considering purchasing. Anyhow, it has many pages on the whole broadband/narrowband/DEMON concept. Okay, maybe just the DEMON stuff. It essentially lays out what the sound profiles of ships are (Oh - Another great resource is Here, but it's about Dangerous Waters). The thinking is that the water flowing over the ship is modulated by the spinning propellors, and so you end up with distinct lines whenever the propellor rotates one nth revolution. That means that, say, a seven bladed propellor spinning at 300RPM (5RPS) has a strong line at 35Hz. Insofar as I can tell, the whole thing in the Video Games about how you get a number of lines equal to the number of blades has shockingly little truth value. It's apparently just a useful feature if you want to play the game - In real life, it's not that easy.

The user interface was revamped, again. I decided that I had too little real estate, so I split the old window into it's constituent parts. Then, I put each part in it's own 'display.' You can switch between the different states by pressing the associated number on the top of the keyboard (numpad doesn't work anywhere, FYI). '1' is the periscope (full window!), '2' is the map view (ditto!), '3' is the assortment of dials and readouts (engine, heading, depth, etc.) and '4' is the new prototype broadband display (screenshot above). Quick note: The broadband display takes ~10s to warm up after starting BNov, and updates every 5s thereafter.

At some point in the near future, I'm going to start porting BNov to Windows. The public profile is growing, person by person, and I feel bad not having anything to show for those poor souls... Porting shouldn't be very hard, except for a few key libraries. Bullet should actually be easier than it is on Linux, as there are precompiled Bullet libraries. The two I'm worried about are OpenGL and GStreamer. I've had bad experiences with OpenGL and windows, I.E. I end up having to run as old as 1.1, which is a full major rev before what BNov requires. GStreamer, however, is more or less Linux-specific, as it is built on the GObject library. It'll compile under MinGW, according to the website, but it's still work. For this it might be worth porting to the Windows API. WAPI has a built in speech decoder, and Festival works on Windows, so that shouldn't be an issue. The built-in nature of this means that it's not only tuned, but somebody somewhere gets paid sums of money to make this work well, and it works off of trained data, so it'll be a lot more accurate.

Is it just me, or are these posts getting longer? It's starting to get to the point where stuff that I write is obsolete by the time the post is published. For instance, this particular post started eight or nine revisions ago... ;)

Fourier

Time has been progressing.

Slowly.

Anyone who watches the BN SourceForge page (Now known as 'BNSF') will have noticed that Sunday night I posted four different feature requests. I realized that the school year is running out... So I decided that I need to dedicate more time to this project, since school is... school :) I'll start implementing these features after I finish the Fourier transform stuff (see below). Then, in two or three weeks time the Game Testing Team (you know who you are) will host a LAN party, and we'll nail down as many bugs and interface problems as possible. Then, we'll fix all of the bugs. Repeat.

I have new found knowledge of the Fourier transform system. One fact is that you should never, ever try to make your own library: mine still doesn't work. Now I'm using the FFTW library, which works well... but has some idiosyncrasies of its own.  My new knowledge of the DFT is that of the windowing function and bin leakage. But, I have decided that I DON'T CARE. On board an actual ship, there will still be bin leakage in the SONAR detection, so I can just include the bin leakage as part of the acoustic profile of each component. This has the drawback that propagation loss will be messed up, as higher frequency leakage will propagate as if it were actually traversing the ocean. Oh, well, I guess it'll be fixed at some point :)

Acoustic Leakage Pipeline

When I last posted, I had setup a eureqa system to hunt down the component frequencies of a particular audio file. Turns out that this has some downsides... Eureqa is a great program, but it was not intended for acoustical analysis. I killed the job after eight days and 1,500 core hours. We found two waveforms. I know that there's more.

But this leads me to a new conclusion. What if we had a program that would perform an optimized GA for acoustical analysis? We could implement it by taking the DFT of a waveform, and marking the peaks. Then, we just start adding the tallest peaks as single sinusoids, and recalculate the DFT each time we add a new wave. Then, we get the effect of the bin leakage in terms of the waves, so that when the final sum of sines is read by a computer and spectroanalyzed, it shows the proper spectrograph. I'll implement this when I get some time on my hands, but for now I'll just hand-generate a waveform for the propeller. I might also switch the bin system to be logarithmic, because at the moment the system is linear: there's a 10-110Hz bin, and a 19000-19100Hz bin. Doesn't quite work as well as I had hoped...

On the subject of acoustics, I had an epiphany with how to take into account thermoclines. What we will do is assume that all thermoclines occur in transitions between solid blocks of water-temperature-areas. We'll just say that at, say, 100m, the water changes suddenly to some different temperature. We can calculate how to measure the speed of sound in water for the two areas. Then, we can just use Snell's law to figure out the amount that it refracts. We can just setup a triangle... and we have the new distance in each medium, which can be passed to the propagation function to calculate the overall propagation.

Path of Acoustical waves through the thermocline

Oh, and speaking of the Game Testing Team: the default BN scenario, the one that loads by default (you can change it with the '--scenario=' flag), now includes a really dumb target. It should be visible on SONAR, as well as visually, from load time.