Week 4: Progress Report
A hectic week indeed with the completion and release of our first demo which was just in time for our mid-project presentation on Wedensday. The demo was a great sucess as essentialy it consisted of 12 people in the class downloading from our website, changing the ip address in the config file, and then connecting and playing on a server started on one of the back machines.
Everyone seemed delighted by the collision detection, awsome gui effects, model loading, and networking capabilities. Though we still have a long way to go, the team is very pleased that we managed to make it our first milestone with everything intact and ontime.
The rest of the week was a lot more laid back, but we still have work to do to stay on target for an early May release.
Things we accomplished:
Everyone seemed delighted by the collision detection, awsome gui effects, model loading, and networking capabilities. Though we still have a long way to go, the team is very pleased that we managed to make it our first milestone with everything intact and ontime.
The rest of the week was a lot more laid back, but we still have work to do to stay on target for an early May release.
Things we accomplished:
- Groller made sure model loading got in this week, fully textured and colored with light values. We are working with the artist to reduce polygon size of the tank and make the included textures compatible with the loader.
- Groller and Kam have created a configuration file manager which allows dynamic model loading and scaling, as well as server IP adress assaignment and client port assaignment.
- Illuminus has split the movement code for the tank from the camera class. This allows more realistic object movement and provides easier acess by other game objects such as physics and gui.
- Kam is working on adding buffered input and output which will facilitate the inclusion of a chat system. He has also made the direct input wrapper functions thier own distinct class.
- More raw code for the physics and collision class is in, but it has not been activated due to changes in the core engine and some strange compile errors when trying to acess the new quad tree code.
- Waiting on the artist to provide a clean model of the tank. Efforts to modify the existing 3ds model by programmers' chimpanzee-like brains have result in less than optimal results.
- Frustrum culling is still not in, though it is being worked on. May have to wait while Groleller works with Decompile to assimilate the existing Octree into the physics engine.
posted by illuminus at 8:50 AM
2 Comments:
I thought I would post this email from Kam, who managed to fix the perplexing compiling errors we were getting when trying to acess the octree code. I think it would be helpful to other groups out there who are undoubtedly running into similar issues:
must have spent over 2 hours to fix our recent compile errors when including octree.h (or other files).
The problem wasn't in the octree code itself, but rather the way we were including the files. The problem didn't manifest itself until now, because we didn't need a recursive include until now.
I'm a bit tired right now, but I hope what I'll say will make some sense.
What Jeff tried to do was to include Octree.h in his PHYSICS.H file. But octree.h included Model_3Ds.h, which in turn included CObjects.h, which in turn included main.h, which in turn included PHYSICS.H again. As you can see, this would be an infinite loop if it weren't for the #ifndef's inside our header files.
What happened however, is that with our #include's inside our #ifndef's (which is the way it should be, btw), we would get some unknown identifier problem. This is because physics.h (and its consequent includes) would reach the #ifndef PHYSICS_H part a second time before it even declares the physics class.
On the other hand, if we leave all our #include's outside of the #ifndef's, we run into a real infinite loop, and the compiler never finishes compiling.
So, I've studied the problem a bit more, and realized that the root of our problem lies in the fact that we're all trying to use main.h to make use of our Global objects. Since main.h is in turn including almost all class headers (in order to declare the globals), we end up running into infinite include loops.
To fix that, I removed all includes from main.h, and use class prototyping to declare the global objects. This prevented infinite include loops, but gave me some errors because a lot of us were depending on main.h's includes as well. Luckly, that was a tedious, but easy thing to solve. I went through several of the .cpp files and added the missing header includes, which is why you'll see a lot of modified files on CVS.
To prevent further problems in the future, here are the summary of things you should keep in mind:
SUMMARY:
- in header files, always put #include's inside #ifndef's
- don't put globals in a header file, and use them throughout your program ('cause that will bring the need for recursive includes, but that's now fixed for our game)
- always include only header files, which should only contain definitions, not declarations
I have fixed the ghosting issue in the networking code. Now old players get assaigned a z value of -100 which gets them off the scene and flags them as candidate slots for new players.
New players who connect will search for canditates among existing slots, and when found, will add themselves there instead, of onto the end of the list as a new player.
Post a Comment
<< Home