It's that time of year, again. I'm not referring to the 1 year anniversary of BNov. I'm referring to that fact that we've hit the point where I'm fairly comfortable with writing a manual, then releasing.
There is, come to think of it, one tiny little thing that should be done before release, and that is to make a passable UI for selecting the starting position in network games.
So then we've hit the point where we just need to do that one thing, create a skybox (if we really want it; is it necessarily needed?), test it, lower the network bandwidth (turn down the SONAR broadcast rate), write the manual, and we're freakin' done.
We've almost made it. Let's hit the ground running. I have a couple of small projects, so we can get this done by the BEST Kickoff on September 10th.
Let's go. We got this.
Sunday, August 28, 2011
Sunday, July 31, 2011
Long delay, but I'm still here.
Okay, team. After an extended period of time slacking off at an internship down at WPEngine, I'm back and (almost) ready to slack off here.
My hope is that I'll mirror last summer, when I wrote four thousand lines of code and put in most of the ground level framework, a running simulation, in the last two weeks of summer. This summer, when school starts, the line count is going to pass 30k, and BNov will be a decent game (okay, so maybe I'm a little hopeful).
Here's what needs to be done:
My hope is that I'll mirror last summer, when I wrote four thousand lines of code and put in most of the ground level framework, a running simulation, in the last two weeks of summer. This summer, when school starts, the line count is going to pass 30k, and BNov will be a decent game (okay, so maybe I'm a little hopeful).
Here's what needs to be done:
- The network needs to be finalized and written. This is pretty big, but we have a lot of the lower level stuff. One of the big issues is that the most recent version has issues running locally.
- Models need to be made. This is also big, because it involves both graphics modelling and Python scripting - and frankly, I suck at graphics modelling.
- A closely linked objective is better AI. At the moment, things (torpedoes) might sort of hit something if you're really lucky, and you shoot a lot of them. This is also tied into number four.
- This last one is big only emotionally. The SONAR model must be set in stone, at least for some period of time. I don't think we can't decently meet any time goals if I keep on rewriting it from scratch (anyone who looks at the code will realize that there is actually 2 complete rewrites of the SONAR module, both of which are enabled and running at all stages of the game.)
- The user interface. Need I say more? We need to clarify what we expect. Speech isn't what we thought it'd be, sadly. I'm impressed, but the possibility of failure is too high for, well, controlling navies. Perhaps some sort of confirmation method would be preferable? (Some sort of Windows style "Are you sure you want to dodge the incoming torpedo?")
Tuesday, May 31, 2011
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 :)
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.
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... ;)
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... ;)
Wednesday, May 4, 2011
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 :)
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.
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.
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.
Friday, April 22, 2011
Long Time, But I Hear You... Differently
It's been a depressingly long time since I got anywhere on anything. However, as of late I redid the SONAR module. The new SONAR module (dubbed SONAR2) splits the frequency band into a hundred different bands. It also uses a more realistic propagation model, pulled from some university web site.
But, one step at a time as it may be, I still need to finish the first step. The first sound file is composed of four sines: 60Hz at 5dB, 160Hz at 8dB, 5Hz at 20dB, and 600Hz at -20dB. I pulled these waves from a spectrogram of a helicopter, and I just picked the first four strongest waves that seemed relevant to me at the time, and made up some other ones. In the original, there was a quiet spot at 5Hz. The levels of each of these waves was tweaked later, in Audacity.
One idea (on another note) I had was to run the audio data through Eureqa. Then Eureqa would figure out a set of sums of sines, which can easily converted to a series of frequencies and amplitudes. The problem with this is that it involves crunching millions of numbers in a genetic algorithm evolver - in other words, time and memory. I'm crunching away with the first sound file, my approximation, and it still hasn't gotten anywhere important. I'm using eight cores on this search, so hopefully it finds something. I'll let it run overnight, then check it again.
Another idea I had was to use a computational fluid dynamics program to calculate the fluctuations in water. I downloaded OpenFOAM and played around with it a little, but it seems a little bit low-res. I'm going to play around with it on a more powerful machine later today...
Another idea I had, crazy though it sounds, is that my estimated propeller sounds accurate. If that's true, then I'll just use that, but I don't want to sacrifice accuracy... How does it sound? It doesn't take into account things like the engine, so it should be somewhat heavy on the beat. My theory is that there is a powerful beat every time a blade passes the viewer. As such, in this example, the first audio clip would represent a 2-blade helicopter rotating at 150RPM, or a 5-blade ship rotating at 60RPM. I don't know how I would take into account things like cavitation... But one step at a time.
It includes a new waterfall diagram, which is fairly neat. According to the manual for a commercial submarine simulator, targets can be located by watching it's bearing change over time, figuring out the speed from the acoustical profile, combining the two gives distance, which can be a position and direction at a speed. Is there a cooler way to target torpedoes? Here's a screenshot of the new waterfall diagram, showing a ship as a dim thin vertical white band (the background noise is black):
Notice that the frequency profile for the ship is flat, from bottom to top. While the structure is in place for having a finite element analysis for calculating the ship noise profile, I don't actually know how to calculate the noise a propeller makes. It's harder than it sounds. I downloaded a neat little sound analyzer called Praat, which has support for all sorts of spectrograms. It hasn't led me to a solution yet, though. Below is my best attempt to imitate a two bladed helicopter in air using only sums of sines:
I know, it's not the best, but it's not all that bad. It has a mere four sine waves. Below is another audio clip that's a simple linear combination between 60Hz and 120Hz over the course of 30 seconds. To me it sounds like a propeller spinning up... Hopefully it's not just me.:
The second one demonstrates how you can (hopefully) determine speed from the spectrogram. This work is only for the propeller noise, so work will have to be done for the engines, the motors, the generators, arbitrary skin friction noise, and so on. One step at a time, I guess.
But, one step at a time as it may be, I still need to finish the first step. The first sound file is composed of four sines: 60Hz at 5dB, 160Hz at 8dB, 5Hz at 20dB, and 600Hz at -20dB. I pulled these waves from a spectrogram of a helicopter, and I just picked the first four strongest waves that seemed relevant to me at the time, and made up some other ones. In the original, there was a quiet spot at 5Hz. The levels of each of these waves was tweaked later, in Audacity.
One idea (on another note) I had was to run the audio data through Eureqa. Then Eureqa would figure out a set of sums of sines, which can easily converted to a series of frequencies and amplitudes. The problem with this is that it involves crunching millions of numbers in a genetic algorithm evolver - in other words, time and memory. I'm crunching away with the first sound file, my approximation, and it still hasn't gotten anywhere important. I'm using eight cores on this search, so hopefully it finds something. I'll let it run overnight, then check it again.
Another idea I had was to use a computational fluid dynamics program to calculate the fluctuations in water. I downloaded OpenFOAM and played around with it a little, but it seems a little bit low-res. I'm going to play around with it on a more powerful machine later today...
Another idea I had, crazy though it sounds, is that my estimated propeller sounds accurate. If that's true, then I'll just use that, but I don't want to sacrifice accuracy... How does it sound? It doesn't take into account things like the engine, so it should be somewhat heavy on the beat. My theory is that there is a powerful beat every time a blade passes the viewer. As such, in this example, the first audio clip would represent a 2-blade helicopter rotating at 150RPM, or a 5-blade ship rotating at 60RPM. I don't know how I would take into account things like cavitation... But one step at a time.
Sunday, April 3, 2011
We have a Website!
I finally put a website up! At the moment, it's still fairly hacked together. But, regardless, it's still there. Most of it I ripped from the SpeedSim website, so many thanks to them. Rest assured that the website isn't a replacement for this blog, but anything relevant to the end user will be down on the site. I need to figure out a good way to run the news... How is this normally done?
Here's a link to the website.
On a different note, I thought about licenses over the weekend, and I'm thinking that a MIT license would be good.
The sad thing is that this is really all I'm going to get done this week... *snif*
Here's a link to the website.
On a different note, I thought about licenses over the weekend, and I'm thinking that a MIT license would be good.
The sad thing is that this is really all I'm going to get done this week... *snif*
Thursday, March 31, 2011
It's Airtight Now
Alright, maybe it isn't quite airtight.
On my other computer, I started developing a moving map display. It's present in r13&14. r13 lacks some required images, but r14 includes these images. It's a little bit simplistic at the moment, as shown in the screenshot below, but you can switch back and forth to periscope view by pressing the 'L' key.
Man, I'm loving this screenshot feature! Why didn't I do it sooner?
On a related note, I'm working on a contour map generator. It's not in the repository yet, but it will be soon. I'm considering moving it into the Blue November core engine so that it'll be generated automagically at runtime, but that's a ways down the road.
As predicted, it's been a slow week, just like last week. Next week will also be slow, since I'll be at a robotics competition for half of the week. The week after will be much faster.
Stay tuned :)
SVN r15 fixed bug 3220471. That bug is the one which reported major memory leaks. These leaks have been tracked down to the Python modules, and dealt with. These memory leaks are no longer detectable.
On my other computer, I started developing a moving map display. It's present in r13&14. r13 lacks some required images, but r14 includes these images. It's a little bit simplistic at the moment, as shown in the screenshot below, but you can switch back and forth to periscope view by pressing the 'L' key.
On a related note, I'm working on a contour map generator. It's not in the repository yet, but it will be soon. I'm considering moving it into the Blue November core engine so that it'll be generated automagically at runtime, but that's a ways down the road.
As predicted, it's been a slow week, just like last week. Next week will also be slow, since I'll be at a robotics competition for half of the week. The week after will be much faster.
Stay tuned :)
Friday, March 25, 2011
All Good On X11 Crash
It's been a while since I got some good time to work on Blue November. Unfortunate, really.
But, the good news is that bug 3223835 is fixed! This means that the previous warning on running Blue November on certain systems is fixed! And it still has the new & improved graphics that I added in SVN r10!
Sadly, that's the only bug that's been fixed. It still leaks memory, so that should be fixed by next time around.
My dad forwarded me this. Apparently Cornell is doing a cool genetic algorithm algorithm finder. Is that an awkward phrase or what? But my thinking is that data could come from Blue November through Eureqa, which would reverse-engineer the physics of a specific ship so that PIDTune could use this to tune the PID loops even more accurately. I say this because while the current PIDTune works better than nothing, it still requires manual tuning afterwards. Even if Blue November doesn't end up using Eureqa, it is still Freakin' Cool!
At some point since Spring Break I started working on a contour creator. It isn't in the SVN repo, so I didn't think of it until now. But hey, here's a demo image for the moment:
At some point I want to add depth markings to this. I also want to potentially replace the periscope view with this map, overlayed with current submarine position, enemy positions, and whatever else. Perhaps there can be a key to switch between the two (or even a voice command!).
It's been a slow week, and the next little while will be slow as well, although hopefully a little bit faster than this past week. One thing I want to do at some point is something along the lines of basic website style thing, because the current site is... non-existent.
But, the good news is that bug 3223835 is fixed! This means that the previous warning on running Blue November on certain systems is fixed! And it still has the new & improved graphics that I added in SVN r10!
Sadly, that's the only bug that's been fixed. It still leaks memory, so that should be fixed by next time around.
My dad forwarded me this. Apparently Cornell is doing a cool genetic algorithm algorithm finder. Is that an awkward phrase or what? But my thinking is that data could come from Blue November through Eureqa, which would reverse-engineer the physics of a specific ship so that PIDTune could use this to tune the PID loops even more accurately. I say this because while the current PIDTune works better than nothing, it still requires manual tuning afterwards. Even if Blue November doesn't end up using Eureqa, it is still Freakin' Cool!
At some point since Spring Break I started working on a contour creator. It isn't in the SVN repo, so I didn't think of it until now. But hey, here's a demo image for the moment:
At some point I want to add depth markings to this. I also want to potentially replace the periscope view with this map, overlayed with current submarine position, enemy positions, and whatever else. Perhaps there can be a key to switch between the two (or even a voice command!).
It's been a slow week, and the next little while will be slow as well, although hopefully a little bit faster than this past week. One thing I want to do at some point is something along the lines of basic website style thing, because the current site is... non-existent.
Friday, March 18, 2011
*WARNING* X Error
Greetings:
SVN revision 10 has a fatal bug causing it (X) to crash (fatally) on certain systems. See bug 3223835 for more information. Bottom line: use only with extreme caution. I'm still working on why exactly it happens, so stay tuned. The last revision that is known to work on the broken computer (X version 1.2) is r7. My higher end computer (X version 1.4) doesn't have the problem.
On a lighter note: I noticed that I don't get E-mails when bugs are submitted, causing me to miss a memory leak bug that I should have been fixing. Instead, I decided to add lighting and blow up the program. Oh well. Live and learn. But now we have lighting!
SVN revision 10 has a fatal bug causing it (X) to crash (fatally) on certain systems. See bug 3223835 for more information. Bottom line: use only with extreme caution. I'm still working on why exactly it happens, so stay tuned. The last revision that is known to work on the broken computer (X version 1.2) is r7. My higher end computer (X version 1.4) doesn't have the problem.
On a lighter note: I noticed that I don't get E-mails when bugs are submitted, causing me to miss a memory leak bug that I should have been fixing. Instead, I decided to add lighting and blow up the program. Oh well. Live and learn. But now we have lighting!
Wednesday, March 16, 2011
Spring Break Halftime
Well, SVN r7 and r8 just went in (I just love developing on two machines simultaneously). So far this Spring Break, I've managed to add a manual (LOL), fix a large number of undocumented bugs, improve the control systems of both the submarine and the torpedo a lot, added a screenshot feature, etc, etc.
The PID tuner that I mentioned previously worked out incredibly well. It still takes some tweaking to figure out what the environment is, and the PIDTune UI could be improved, but it is infinitely better than the PIDLS (PID Learning Service) stuff. PIDLS gave us SVN r1-6, which sucks. PIDTune, however, is in r7, and it took a mere two days to write the program and tune both object's rudders. A little bit of overshoot here and there, but nothing major.
Joy to the world - We have an actual map! Well, more actual, at any rate. Here's a land mask for it (white is land, black is water):
Did I mention that I added a screenshot feature? The funny thing is that it's been there all along, but it's just been commented. It used to be that all rendering went into a series of screenshots. Now just press the 's' key, it'll save it into ./Screenshots. Here's a picture of the new and improved UI:
Notice the speed-o-meter just to the left of the pitch gauge. That's the only change.
Halfway through Spring Break!!!!!!!!!! :'(
The PID tuner that I mentioned previously worked out incredibly well. It still takes some tweaking to figure out what the environment is, and the PIDTune UI could be improved, but it is infinitely better than the PIDLS (PID Learning Service) stuff. PIDLS gave us SVN r1-6, which sucks. PIDTune, however, is in r7, and it took a mere two days to write the program and tune both object's rudders. A little bit of overshoot here and there, but nothing major.
Joy to the world - We have an actual map! Well, more actual, at any rate. Here's a land mask for it (white is land, black is water):
Did I mention that I added a screenshot feature? The funny thing is that it's been there all along, but it's just been commented. It used to be that all rendering went into a series of screenshots. Now just press the 's' key, it'll save it into ./Screenshots. Here's a picture of the new and improved UI:
Halfway through Spring Break!!!!!!!!!! :'(
Thursday, March 3, 2011
PID Loops
I've been playing around with the SF bug tracker - it really comes in handy!
Anyhoo, I think I found the cause of bug 3198106, which was starting to vex me. However, the solution is also elusive: Either we do a server side clipping of all contacts under, say, a Newton or we have the client report which ships should record contacts. Or maybe both. For instance, the testShip doesn't even have a function to deal with contacts, so no point sending the data across. But, as long as we don't crash them into each other, we should be safe ;)
Oh yes - Bullet, the physics library, does all collisions in terms of contact points. The Python files have callbacks for these contact points. For example, the torpedo uses it to acts as an explosive trigger. Bullet is running on the server, and the Python files are running on the client.
I think that 0.0.1 will be released at the end of Spring Break. When it is released, I want to have the destroyer model up and running. I also want to have MUCH BETTER PID LOOPS for every model.
Have I mentioned my bipolar view of PID loops? They are incredibly useful in ship control, so I love them. However, for some reason or another I can never get my PID loops to tune correctly, so I hate them. The average image of me trying to tune them is me sitting in front of my computer for hours (days?) on end, downing bottles of Advil along the way. I've tried to setup automatic PID loop tuners, but it didn't work too well. The one I tried is the 'PIDLS' in the torpedo.py and base/Ships/pid-trainer.py files. I'm considering empirically getting the response curves for the system and plugging that into a PID loop simulator (which are hard to find for free, so I'll have to write one), just so that I can get faster turnaround times.
Anyhoo, I think I found the cause of bug 3198106, which was starting to vex me. However, the solution is also elusive: Either we do a server side clipping of all contacts under, say, a Newton or we have the client report which ships should record contacts. Or maybe both. For instance, the testShip doesn't even have a function to deal with contacts, so no point sending the data across. But, as long as we don't crash them into each other, we should be safe ;)
Oh yes - Bullet, the physics library, does all collisions in terms of contact points. The Python files have callbacks for these contact points. For example, the torpedo uses it to acts as an explosive trigger. Bullet is running on the server, and the Python files are running on the client.
I think that 0.0.1 will be released at the end of Spring Break. When it is released, I want to have the destroyer model up and running. I also want to have MUCH BETTER PID LOOPS for every model.
Have I mentioned my bipolar view of PID loops? They are incredibly useful in ship control, so I love them. However, for some reason or another I can never get my PID loops to tune correctly, so I hate them. The average image of me trying to tune them is me sitting in front of my computer for hours (days?) on end, downing bottles of Advil along the way. I've tried to setup automatic PID loop tuners, but it didn't work too well. The one I tried is the 'PIDLS' in the torpedo.py and base/Ships/pid-trainer.py files. I'm considering empirically getting the response curves for the system and plugging that into a PID loop simulator (which are hard to find for free, so I'll have to write one), just so that I can get faster turnaround times.
Monday, February 28, 2011
SourceForge!
Well, it's out there in the wild blue wonder. The entire source code and data distribution is posted on SourceForge Here, after many problems with their servers eating my URLs (Apparently you have to sign up before you can register projects).
I had the weirdest feeling when I finally uploaded everything to SF. It felt kind of like sending a kid off to college: You know, it's finally gone and out from under my roof.
Due to security concerns, version 0.0.0 will never appear on SF, and we'll jump straight to 0.0.1.
On the more actual technical side of life, I fixed most of the bugs I mentioned in the last post. It was just a simple matter of adding a few more types of packet data. Everything works except for SONAR over the network, and maybe after we fix that we'll release 0.0.1. I already know what needs to happen, but I haven't done it yet (maybe tomorrow. I'm having to much fun firing torpedoes everywhere).
And, like usual, I'm still trying to make half-decent models. Here's a sneak peek at my latest model (No textures yet, sorry). At least it beats my last model of the submarine :)
Sorry about the lighting - I'm not very good at lighting, despite what my avatar suggests.
I had the weirdest feeling when I finally uploaded everything to SF. It felt kind of like sending a kid off to college: You know, it's finally gone and out from under my roof.
Due to security concerns, version 0.0.0 will never appear on SF, and we'll jump straight to 0.0.1.
On the more actual technical side of life, I fixed most of the bugs I mentioned in the last post. It was just a simple matter of adding a few more types of packet data. Everything works except for SONAR over the network, and maybe after we fix that we'll release 0.0.1. I already know what needs to happen, but I haven't done it yet (maybe tomorrow. I'm having to much fun firing torpedoes everywhere).
And, like usual, I'm still trying to make half-decent models. Here's a sneak peek at my latest model (No textures yet, sorry). At least it beats my last model of the submarine :)
Saturday, February 26, 2011
Woes on the hacked network protocol
As some of us, specifically me, know the entire network protocol was added as a mere afterthought after the rest of the program had been written.
This is starting to really suck.
For one, there is a bug when 0.0.0 is run as standalone. It just fails to take control of it's ships, as it waits for the server to tell the client to control a ship, but there is no server. The fix is to just run a server and client on the same machine.
Oh, and by the way, you can't connect to any server except localhost without recompiling. This will be fixed by 0.0.1.
For another, the only things transferred over the network in 0.0.0 is the engine magneto state, the ballast tank data, and the airfoil control surface controls. This means that when the launcher tries to launch the torpedo with a given forward velocity, this velocity doesn't actually take effect. This will also be fixed by 0.0.1.
For those who don't know: the server/client protocol has a concept of "control," which is assigned to different clients by the server. The different 'brains' of the ships, so to speak, are housed in python files. Only the client with "control" over a ship is allowed to run the python file that takes in environmental data (position, speed, etc.) from the server and outputs controls (airfoil deflection, engine throttle, etc.) back to the server.
I'm considering moving to SourceForge. Any thoughts?
This is starting to really suck.
For one, there is a bug when 0.0.0 is run as standalone. It just fails to take control of it's ships, as it waits for the server to tell the client to control a ship, but there is no server. The fix is to just run a server and client on the same machine.
Oh, and by the way, you can't connect to any server except localhost without recompiling. This will be fixed by 0.0.1.
For another, the only things transferred over the network in 0.0.0 is the engine magneto state, the ballast tank data, and the airfoil control surface controls. This means that when the launcher tries to launch the torpedo with a given forward velocity, this velocity doesn't actually take effect. This will also be fixed by 0.0.1.
For those who don't know: the server/client protocol has a concept of "control," which is assigned to different clients by the server. The different 'brains' of the ships, so to speak, are housed in python files. Only the client with "control" over a ship is allowed to run the python file that takes in environmental data (position, speed, etc.) from the server and outputs controls (airfoil deflection, engine throttle, etc.) back to the server.
I'm considering moving to SourceForge. Any thoughts?
Thursday, February 24, 2011
Hello!
Hello there!
Blue November is a realistic naval warfare simulator. It was first inspired to me by my Uncle, and I just took the idea and ran...
But here I am. I just released the first alpha for the project, version 0.0.0, and I'm throwin' a party! :D
Anyhoo, more to follow. Stay tuned!
Above is a picture of Blue November circa September - Things have changed a little bit. Anyone who isn't blind will note that the graphics are absolutely horrendous. My apologies, as I am not a graphics designer :,( But, regardless, at some future point I'll make life look better in general. Also, my Uncle insisted that what little I have is overboard - He wants this to be entirely realistic and have no external views whatsoever. I'm of two minds.
But I make up for it in speech technology. Commands are given almost primarily using voice commands - and the crew will respond with voice! If I may, I will endorse the PocketSphinx and Festival teams, as they are both ABSOLUTELY AWESOME!!!!! :)
I'll catch y'all later. Maybe after I have something showing some sort of better gfx :-X
Blue November is a realistic naval warfare simulator. It was first inspired to me by my Uncle, and I just took the idea and ran...
But here I am. I just released the first alpha for the project, version 0.0.0, and I'm throwin' a party! :D
Anyhoo, more to follow. Stay tuned!
Above is a picture of Blue November circa September - Things have changed a little bit. Anyone who isn't blind will note that the graphics are absolutely horrendous. My apologies, as I am not a graphics designer :,( But, regardless, at some future point I'll make life look better in general. Also, my Uncle insisted that what little I have is overboard - He wants this to be entirely realistic and have no external views whatsoever. I'm of two minds.
But I make up for it in speech technology. Commands are given almost primarily using voice commands - and the crew will respond with voice! If I may, I will endorse the PocketSphinx and Festival teams, as they are both ABSOLUTELY AWESOME!!!!! :)
I'll catch y'all later. Maybe after I have something showing some sort of better gfx :-X
Subscribe to:
Comments (Atom)