GraphicsTown is a set of example code written by Michael Gleicher as an example for the GraphicsTownproject (CS559 Project 3). It is also meant as a starting off point for students to do their own projects. Various TAs over the years have contributed as well.
We will assemble a FAQ as people ask questions.
A ZIP file containing the project can be found here. here. (updated 4/16/2010).
For your="Apple-converted-space">
project 3, you may either use GraphicsTown as a starting point, or you may start from scratch. (You may not use another platform such as a game engine). If you start from scratch, you must re-create the main features of GraphicsTown as described here. While figuring out how to extend GrTown will take some work, it probably isn't nearly as much work as recreating the functionality from scratch. Plus, working with someone else's (imperfect) code is good practice for the real world.Graphics town requires FLTK. Because we didn't know where you had FlTk installed, everything refers to an environment variable FLTKHOME. You should set the environment variable before running visual studio. (right click on "My Computer", pick properties, and under the "Advanced" tab is an environment variables button). On a CSL computer, you should set FLTKHOME to be "S:\fltk". On your home machine, it will probably be something like "C:\fltk".
There is one thing to be careful of: the user interface (the widgets and whatnot) are defined in the "GraphicsTownUI.fl" file. Fluid (the FlTk UI designer) turns this file into a .cxx and .H file. Do not edit those files as they will be overwritten.
To run GraphicsTown, the program must be able to find its texture files. It will search around a little for them.
There are sliders to control the time of day (which does not change by itself), the field of view of the camera, and the speedup factor (you can set it to zero to stop time, or set it higher to speed things up).
The "Fly" button puts the system into flying mode (the default). The flying interface uses the following keys:
The top chooser box (labeled "view") allows you to pick an object to "ride." When an object is chosen, you can turn on the "follow" button to follow behind the object instead. One special object to ride is the "map" camera that provides a birds-eye view of the town. When in map mode, the arrow keys move things around. (improving this interface is something you might want to do)
The lower chooser box (labeled "sights") takes you to a view of some pre-defined interesting sights in the town. The default town doesn't have too many (but then again, there isn't too much that's interesting).
There isn't too much more to do with the program other than fly around and look at things.
The default town is pretty boring - it is made of a small number of simple objects, and a few behaviors. Your job in the assignment is to create a better town.
You can think of GraphicsTown as a simple game engine. In its initialization (in Main.cpp), it makes a world, a bunch of objects, and gives those objects behaviors. Then it lets things run. Each "step" of the world (between screen redraws), all of the behaviors have an opportunity to change the objects that they effect.
The two key classes to figure out are "GrObject" (the graphics objects, the things that get drawn) and "Behavior" (the things that make GrObjects do things). There are many examples of GrObjects and Behaviors to look at and learn from.
The first place to start to understand how graphics town works is the main file (main.cpp). Here you will see where the world is built. You will replace this with something that creates your own town.
Note: GraphicsTown is really bad in terms of managing memory. It creates objects and never destroys them, relying on the fact that all memory is released when the program stops. While this is tolerable because all memory/object allocation happens at the beginning of the program, it is not good programming practice.
You do not need to fix GraphicsTown 's memory problems! Just make sure that you only allocate memory during the initialization, or if you allocate memory while the world is running, that you do release it when you're done with it.
The main thing you will do for this assignment is create new subclasses of GrObject and Behavior, and have main make instances of these to populate the world. Look in the Examples directory for some simple things to get started with.
Note: there are many useful textures in the project for you to use. You need to find some of your own, but many of these will be useful.
When you look at the graphics town code, be sure to note that the widget layout was done in the FLTK interface editor (fluid). Visual studio will automatically compile the "GraphicsTownUI.fl" file into a C++ source and header file. You should only edit the ".fl" file, and you should use fluid to do it.
You can actually do most of the work of the assignment without changing much of the existing code. You'll need to change main.cpp, and you'll need to add new files for new GrObjects and Behaviors. However, unless you want to do anything major, you probably won't need to change much else.
There are a few simple objects (like cubes) and simple behaviors (like spinning around) to look at to get started.
I made some objects to make a suburban town - lawns, trees, houses, cars, ... These objects are very simple - you will want to make nicer ones.
You shouldn't use my houses and my simple grids of houses. Do not use the "SimpleSubdivision" class in your code: do something more interesting!
The road system and driving behaviors are more complicated. The code allows for an arbitrary network of pieces of roads, and for cars to drive around randomly. Cars do stay on the right hand side of the road, but they don't stop at stop signs, or avoid other cars, or ... (see below for ideas on how to fix the road/driving model). The road/driving system is mainly there as an example of a more complex behavior. You may want to extend it to be more interesting in your town -- however, it will take a little effort to understand.
The GraphicsTown program was originally written quickly in 2000 as a sample solution. It was not necessarily designed to be the platform for student projects. An overhaul in 2005 made it better, and more recent updates have made it even better.
Working with someone else's imperfect code is an intent of the project: in the real world, you often get stuck finishing something that someone else started. This will hopefully be useful practice.
One thing that you will notice is that the code is a mix of styles. For example, some parts use linked lists, while others use the STL. In practice this comes from the history of the program (in 2000, I didn't feel the STL was appropriate). In the "real world" you often run into code that is a mix of styles because different people worked on it. (here its the same person, just at a different time).
In general, I do not suggest you put too much effort into fixing the style of my code. It actually does work pretty well. You are better off investing your time and energy into defining new objects and behaviors, and adding functionality.
GraphicsTown was "designed" to be easy (for me) to write, debug, and extend. It is not organized for efficiency. It performs well enough on modern computers. (On the circa 2000 computers it was developed on it was just OK).
In addition to making your own town (with your own objects and behaviors) there are many things that you might consider improving. If you do make some major improvements, be sure to let us know (in your README file and at the demo). If you do a good job, we might incorporate your additions into the code we give to students next year (unless its something we want them to do themselves).
Some things that come to mind: