int main()

So, it’s been a crazy quarter here at UCLA – general education really is a giant time sink. Thankfully, that’ll be done after this quarter and I’ll hopefully have more time to do inane side projects like the one I’m going to talk about today.

Everyone knows about Pong – the little game that you all played on your TI-83 in high school when you were supposed to be paying attention in math class. Along with all the other games you played on your calculator – I’m hoping to play with those later. Anyway. I’ve always had an interest in 3D graphics and how they relate to games. I did some dabbling in OpenGL last summer and it was painful to say the least. I’ve also been dabbling with Python lately, so the next obvious step was to figure out how to do graphics in Python. There a lot of libraries to do this (pygame comes to mind), but I decided to use VPython. It provides all sorts of nice little things – namely the code to construct a shape.

from visual import *
square = box( pos = (0, 0, 0), size = (3, 3, 3), color = color.green)

Nice. You can give the box a velocity by doing something like:

box.velocity = vector( 5, 0, 0 )

Then you can update the position of the box accordingly using your basic physical relationships. You know, Vf = Vi + at, and all the other stuff you learned in physics. Unless you took Physics 1A with Professor Corbin at UCLA, in which case you learned all sorts of other cool stuff and aren’t sure how you passed the class. But I digress.

I started this project just trying to learn how VPython works, and I ended up implementing a version of Pong that is playable, but slightly boring. There is no score display, end-of-game info is displayed in the console, and there is no vector math implemented. Therefore, the ball always bounces at a 45 degree angle from the wall or the paddle. This is both unrealistic and boring. I’m no mathematician, and I don’t currently have the time to implement the vector math. I’ll leave that as an exercise to the reader. If you do end up implementing it, please let me know. I’m sure I’ll get around to it eventually, I just have finals coming up in the next week so it’s low on the priority list.

Anyway. That’s what I’ve been up to lately. I’m working off and on on doing a Tetris clone, and I’ll probably eventually get to Space Invaders. Maybe not with this library though. I’ll probably pick up something else (maybe a new language). Maybe I’ll go back to OpenGL or DirectX if I’m bored enough (and in a slightly masochistic mood). For those who are interested, the code is uploaded here. Comments and edits appreciated. Thanks for reading!

So, I’ve recently converted to using VIm. Textedit irritates me to no end, and I don’t want to pay money for Textmate. I decided I would post my .vimrc file up here and talk about it a little bit. For those who just want to read the file, it’s attached at the bottom of the post. Snippets of code follow, however.

map <space> /

All you VIm users out there know how to search for text – this enables me to search with the space bar, which feels more natural and quicker than having to type a special character.

set nocompatible
set number
set columns=80
set ruler
set background=light
set wrap!
syntax enable

This turns off emulation of bugs from Vi, enables line numbers, restricts my window to 80 columns, displays some basic information about where I am on a line, tells VIm to use fonts optimized for a light background (corresponds with my terminal colors), turns off word wrap, and turns on syntax highlighting. These options are all configured for programming.

set showmatch
set ignorecase
set hlsearch
set incsearch

This is extremely useful for searching in a file. The first line highlights matching braces, which is very nice for nested statements and complex conditionals. It also makes searching case-insensitive, highlights search matches, and starts searching with the first letter that you type. If you pay close attention when searching you only ever have to type the minimum amount of letters to find what you want. I find this greatly speeds up moving through a document.

set autoindent
set smartindent
set tabstop=4
set shiftwidth=4
set expandtab

These settings tell VIm what to do with tabs and indents. The first two lines tell the program to format indents according to the file type. As long as you’re using a C type language, this works extremely well. The second two lines tell VIm to use 4 spaces when the tab key is pressed, and the final line expands all tabs into spaces. This helps remove compatibility problems between tabs and spaces.

set vb t_vb=

This just turns off those pesky beeps when you enter an invalid command. Instead, the screen flashes for an instant. Much nicer in my opinion.

set gfn=BitStream\ Vera\ Sans\ Mono:h14

This sets the default font for the editor – Monaco Size 10. My current favorite programming font on OS X. Anyway, that’s a bit of a discussion about my .vimrc. The full file is below for anyone who wants to read the whole thing or copy/paste it for their own use.

".vimrc
"Author: Eric Hertz
"Date: 10.14.2009
"
"This is a configuration file for VIm, the terminal text editor. Feel free
"to use this however you wish.
 
"Key mappings
map <space>  /
 
"Interface settings
set nocompatible
set number
set columns=80
set ruler
set background=light
set wrap!
syntax enable
 
"Search settings
set showmatch
set ignorecase
set hlsearch
set incsearch
 
"Indent settings
set autoindent
set smartindent
set tabstop=4
set shiftwidth=4
set expandtab
 
"Audio settings
set vb t_vb=
 
"Font settings
set gfn=BitStream\ Vera\ Sans\ Mono:h14

Hey all,

My name is Eric, and I’ll be one of your regular authors here on int main(). You’ve probably already read a little bit about me from the post that my friend Sam put up earlier, but I’ll start with a quick introduction and background . I’m a second year Computer Science student at the University of California, Los Angeles. I consider myself well-versed in C, C++, and Java, primarily. I also enjoy (if that’s the word) working with assembly on occasion (I’ll post a discussion of some assembly topics later on). Anyway. That’s a little bit about myself. I’d also like to state here that if any of our readers have side projects that they are working on and would like an extra set of eyes or hands, feel free to email. Now that I’ve dispensed with the introductory remarks, let’s dive right into today’s topic.

I feel that as a reader, I would be hesitant to read and trust someone’s opinion on things unless I knew that they actually had some experience with the things that they write about. To that end, I’d like to start this blog by talking about a program that I was a developer on – AudioGuardian. This begs a bit of background information, I’m sure. This project started as part of a competition back in February 2009. I participated in SS12 put on by ProjectPossibility, an organization aiming to make technology more accessible to the disabled community. AudioGuardian was originally named MobileSoundNotifier, and its purpose was to alert hearing-impaired users of hazards in their environment. I will append links to the project’s webpage, the project wiki, and the SVN if any of our readers would like to see some of my “production” code. I quote that because it’s definitely hacked code – this project was completed over the span of approximately 30 hours. From scratch. With that said, here’s the links to the project information:

Project Webpage
Project Wiki

The SVN is linked from the webpage in the bottom right hand corner, if any of you enterprising developers would like to take the project and work on it yourself. It is licensed under the GPL, so keep that in mind. .

I guess you can’t really fork this project without knowing a bit about how we actually designed and developed the program. Coupled with the fact that this is a CS blog and not a self-promotion blog, I will now move into a technical discussion of the program. I’m going to keep this as high-level as possible so it will appeal to all audiences. Let’s get to it.

This application is built using J2ME, which is the Java 2 Mobile Edition. It has most of the capabilities of the full Java language, but it’s missing some key features. It does not support the Swing environment, so we used the built-in J2ME graphics library to build a primitive GUI. The programming paradigm is event-driven, like the majority of Java programs. A control loop listens for commands and acts appropriately. The basic application logic should be simple to follow. But that’s all academic and really not what you’re here for. Let’s get into the problems with working with audio.

The heart of this program is an audio analyzer. It listens to the surrounding environment and throws alerts when it detects sounds deemed dangerous by either us (the programmers) or the user. Those of you with a physics background may have heard of a discrete Fourier transform before. If so, you will know that this is a complex wave analysis algorithm used to translate a signal from the time domain to the frequency domain. This was important for our application because we cannot use the time domain to perform sound matching. The only correlating factors between sound waves are amplitude and frequency, which we have to use a DFT to extract from the data stream. Sounds simple, right? Without looking at any code (you can download the code yourself and look at it, it’s too long to post here), let’s discuss the issues here.

All microphones are not created equal. Every mic has a different sensitivity and different DC offset applied to the raw data stream. This was a problem for us, since we were doing development across different laptops with different microphones. To that end, we decided to build a calibration function that listens to the ambient environment and basically filters the offset and all the outside noise. This also had the unintended side effect of increasing the accuracy of the matching function. It also built cross-compatibility, so our application will work with any microphone out there. The program also had some problems processing data streams in byte array form. The Recorder class in J2ME had a nice little habit of including the file header when it passed the data to a byte array. This then caused garbage to be passed to the graphing function, which caused some serious inaccuracy and lag time in sound recognition. To fix this, we had to strip the file header ourselves. I’ll leave it to the reader to read the code and see exactly what we did.

Other problems we encountered:

The DFT itself was not easy to write. It didn’t help that J2ME was very poorly documented and as such we could not find a standard library. We ended up borrowing an implementation of quicksort from an outside source. It was optimized for use on pairs of data, which was what we were using for matching. Writing this alone took us almost an entire day of work, and then the rest of the time was spent building a GUI and other small features into the program.

One final problem was the issue of data persistence. We wanted to be able to store settings and data across instances of the program. Sounds simple, right? Write the data to a file and restore it when you open the program? Easy enough….until you look at how mobile phones and the J2ME stores data. We ended up using something called a RecordStore, which is actually an object in Java. It has to be opened before it can be used. It is indexed in a very counterintuitive manner – not like a normal array or vector of objects. We essentially ended up taking this RecordStore object and building our own suite of methods to store and access data, because the built-in functionality was not doing what we needed it to do. This took a large amount of time as well, and took brains away from cracking the DFT. All in all, however, we managed to get everything working.

Well, that was long. Hopefully I gave you all a bit of insight into that project, and a bit of perspective on what goes on in developing a mobile phone application when you’ve never done it before. If any of you have questions or would like me to cover something more in-depth, please post a comment or drop us an email. We also appreciate email if there is any topic you’d like us to talk about in general . See you next time.

Hi there!  My name is Sam and I’ll be your host tonight…

No, really.  My friend Eric and I conceived of a place where we could talk about issues and challenges faced by today’s Computer Science students.  Accordingly, int main() is a place to do that.  Over the coming weeks, months, years (or however long we’re kept interested), we’ll be talking about this junk.

If you are interested in writing here, send us a quick email!

As for a little background: the two of us  are entering our second year as Computer Science students at UCLA who have very much enjoyed the curriculum.  I will not be taking any CS classes this quarter; Eric will be taking one.

Other contributing authors may include David Wieser, Hugo Fuentes (Senior at UC Davis), and Vyvy Dao.

Anywho, now you know.  Happy coding.