|
Code
I've always enjoyed programming. One of my first useful programs was called ANIMP, which stood for
Atool's Nifty Image Manipulation Program (no, I didn't know about GIMP at the time). I really liked
comic book art, and I thought it would be cool to be able to "de-colorize" comic book art. Not
desaturatation, but literally taking the color out of an image so that it looked as though it had just gone
through the comic-book process of inking. The concept was pretty simple, but I couldn't find an easy
way of doing this in Photoshop or any other image manipulation program, so I wrote my own filtering
program. It'll basically take the following input on the left and output the image on the right:
 
I took out the words in the bubbles and downsampled the images using Photoshop, but other than that,
the output is pretty much verbatim from my program. Pretty much all it does is take colors that are
within a certain "inking" threshold value (namely, very dark colors) and turn them to pure black; it
takes colors that are within a certain "penciling" threshold value and converts those colors to their
grayscale equivalents, and the rest of the colors it throws away and replaces with white. If you'd
like to see the program (compiled for MS-DOS) or its source, you can get it here.
Atool's Fractal Parser (AFP)
|
AFP was the first somewhat complex program I've ever written. Unfortunately, because I didn't
completely understand the intricacies of good programming habits, the code is quite messy and
I made very many stupid mistakes (I found this out upon inspection of the source code one year
after I wrote it). But, the program still somehow compiles under DJGPP. AFP is basically a
program I wrote for the Mathematics Department here at provided an interface to receive a polynomial
equation, parse it,
and create a fractal based on Newton's method from it. The program also supported exploration of
the Mandelbrot and Julia sets.
There were essentially two interfaces to the program: a console
part, which was somewhat akin to a Maple console session, in which the user could enter
expressions and have them evaluated, as well as define variables and use them in expressions. The second
interface was a graphical interface, which the user could access from the console interface by
typing fract (varname), where varname was the name of the variable which held the fractal equation. If varname
was not supplied, then AFP would go into Mandelbrot exploration mode; otherwise it would
attempt to make a Newton's method fractal based on the equation it was given. The program also
had the ability to load a script of commands from a file; the scripts were identical to strings
of lines that the user would type into the console, and AFP also had a command to export the
current state of the variables to a script file, so that the user could do a lot of experimentation
within AFP itself and then output their equations to a script file. You can download AFP and its
source here (instructions on how to use it are provided). To compile it, however,
you'll need DJGPP and Allegro 3.0 (or you can use the binaries that come in the .zip file), and
you'll need a Win95/98 machine that has a video card with VESA support (or SciTech Display Doctor).
To the right are some thumbnails of fractals that AFP has generated. To view the entire image,
click on a thumbnail.
|  |
 |
 |
JWorld
JWorld is a MUD (Multi-User Dimension) server that my friend Erik Christensen and I wrote in Java at the
end of December 1998 as a final project for our Data Structures class. Data Structures was the
first computer programming course I had ever taken, and it helped me better organize my code, and
made me realize how many mistakes I had made when I wrote AFP. JWorld is much more organized and
more efficiently written than AFP, partially because Java is a language that easily allows for
more organized code (with its package system), but mostly because I learned a lot about
organization and writing efficient code from the data structures class.
Another reason JWorld is much more efficient and more organized than AFP was because I was working
on this project with a partner, instead of solo. Collaborating with another person was a
huge benefit, for a number of reasons:
- It became easier to organize the project as a whole. Talking to Erik about how the MUD was
to be structured facilitated the conceptualization of the structure of the MUD server. It
allowed us to divide the project into components before we started any programming, so that
we could work on different parts of the program independently; as long as we had a definite
interface planned, we could interface to parts of our program that another person was going
to write, or that we'd write at a later time. This of course had a great impact on the
organization of the program as a whole; it also motivated me to comment my code, since just
in case something went wrong, another person might have had to examine my code, in which case
the comments would be very useful. As a result of this better organization, the actual
program took about a week to plan, and very little time to implement--three days, in fact.
We were thinking of calling the program "The 3Days MUD" in lieu of this, but decided against
this since we were supposed to have been working
on it for two weeks (a requirement for the final project of our data structures class). This was
a stark contrast to most of my solo projects, which had a much longer development time frame
(AFP took about 1 1/2 to 2 weeks to write and was smaller than JWorld) because of the process of
constantly writing code, figuring out a better way to program something, and rewriting the code
to make it more efficient. Here, we would discuss the most efficient way to do something, and
then implement it, instead of having to optimize our code through hindsight.
The development time
was increased a great deal in this collaborative setting, in my opinion, because Erik and I were
able to toss around ideas and think through them extremely quickly because both of our minds
were working on them, instead of just one. If one of us thought of an idea, the other one would
come up with complications that the idea might present to the rest of the framework of the program,
and we would discuss from there. When we were programming, often one person would look over the
shoulder of the other person and catch simple mistakes that one person was making--simple mistakes
that would've caused the programmer a lot more frustration if they had to be searched out and
dealt with in the traditional way (via compiler errors or debugging). In fact, when we finally
put together all the parts of the program and ran it, there were very few bugs.
- Programming became a social activity. With past projects, programming was always a ritual
of locking myself in a room for several days (or weeks, in the case of AFP) and avoiding
social contact. When I came out of hiding, I'd always feel like an alien, as though interacting
with other people was this skill that I had to get used to again. This made programming a very
lonely and depressing activity, but programming collaboratively in JWorld changed this entirely.
Because collaborating inherently involved interacting with another person, I was almost always
talking with Erik. Often we'd take unplanned breaks by just going off about some topic
entirely unrelated to JWorld and computers. Thus, working collaboratively on this project showed
me that programming didn't have to be a solitary and antisocial activity, and that really made
me optimistically consider the field of programming as a career opportunity for the first time
(assuming it was always going to be collaborative).
JWorld was developed using the MUD Object-Oriented (MOO) system as a sort of blueprint, so much
of how JWorld works internally is similar to the MOO--it's very flexible and expandable. The
development of this flexible infrastructure was what took most of the 3 days to program; implementation
of the few commands which we were able to add before handing in the project only took 2 or 3 hours at
the end of development because the framework we developed made it incredibly easy to modify the MUD.
Wizards can introduce a new object class into the MUD by properly writing a Java .class file and
placing it in the appropriate directory; they can then create new instances of the object class
through the MUD and even call public methods of the class via the Java Reflection API. Verbs for
objects are created by writing special methods that take specific parameters. Overall, JWorld was
something we were quite happy with, and we would develop it under the GNU license if we had
enough time. You can get the JWorld source and class files here,
or view a screenshot of the server and two clients in action here.
MusicTicker
The most recent software I've written is a plug-in (DLL) for Nullsoft Winamp called MusicTicker
(woohoo, it also received a 4-star rating from Nullsoft's plug-in curator!).
You can learn all about it at the MusicTicker homepage, located at
http://www2.kenyon.edu/People/varmaa/mticker.
Addendum: Kenyon's www2 server has since been shut down and the project abandoned; however,
the original website was preserved for posterity's sake and you can view it here.
3D Visualization
|
During the summer of 1999, I was enrolled as a Summer Science Scholar
at my college. I created an extensible object-oriented raytracer in
C++, called ATrace. This renderer used a phong reflection model and
supported procedural textures, Constructive Solid Geometry (CSG),
translucensy, and depth cueing, among other features. Because of
ATrace's flexible object-oriented framework, adding new kinds of
shapes, materials, cameras, atmospheric effects, and light sources was
simply a matter of deriving an abstract base class and implementing
virtual member functions.
|  |
|
I also created a simple volume rendering (voxel) engine in C. This
engine took a two-dimensional bitmap and used it as a height field to
create a three-dimensional image which could be navigated through in
real-time.
|  |
|
My last project for Summer Science was a polygon renderer which
allowed the user to navigate through a three-dimensional polygonal
world in real-time. It was written in C and supported flat and goraud
shading of triangular or quadrilateral
polygons, texture mapping, and point and directional light sources.
The engine used a z-buffer to perform hidden surface removal;
back-facing polygons were culled and the polygons outside the viewing
volume were clipped to speed up the rendering. In the end, I also
implemented bump mapping, though it was very slow.
|  |
[ About | Code | Art |
Websites | Ideas | Narrative ]
Copyright © 1999 Atul Varma
If this is the only text you can read, you have probably just tried printing this web-page. To
print out this webpage successfully, go to the "File" menu of your browser and click on "Page Setup..." Then click
on "Black Text" under the "Page Options" category. I am sorry for this inconvenience.
|
