TWiki > Proj3team5 > DominikSlusarczyk	TWiki webs: Main | TWiki
	Proj3team5 . { Changes | Index | Search | Go }

Work History

• 5/13/04 (Thu) [1 hour]
  • Cleaned up Wiki and documentation.
  • Sent some final agenda to the group via e-mail.
  • Prepared for presentation at 2.
• 5/12/04 (Wed) [1 hour]
  • Respecting the code freeze. Met with group to finalize slides, UML diagram, and documentation tasks.
• 5/11/04 (Tue) [10 hours]
  • 11:30 PM
    • Quitting work for the night. Spent a significant time helping/observing John model the level. Several ramp bugs have been ironed out, and the BoundingBox class has been put to good use (helping determine when to switch height-maps).
  • 9:45 PM
    • Added the HoleMesh and associated infrstructure for responding to the ball rolling off the board into the hole.
  • 1:00 PM
    • Finished the mission infrstructure. Unfortunately specific-order-events cannot be supported at this time. Only random-order missions--that is, missions where all the MissionSteps must be completed but not in any specific order--can be supported with the current data structures.
    • Reverted to the single-ball data representation. Some funny collision bugs have crept in, and I'm not comfortable debugging them at this time given our deadline constraint. This means that multi-ball will unfortunately not make it into the final game. But we were so close!
• 5/10/04 (Mon) [9 hours]
  • 11:30 PM
    • Laid down most of the mission infrstructure. Missions are implemented as STL lists of MissionSteps, each of which is defined as a specific target that must be hit, and an action that the game takes (including message to be displayed, score to be added, etc.) when that target is hit before moving on to the next MissionStep.
    • Exported bounding checking into a separate BoundingBox class. This feature will now be used with missions as well as for collision detection optimization. We can probably use it to implement the launcher/ramp with a little less effort, too.
    • Fixed two remaining flipper bugs.
  • 4:40 PM
    • Implemented collision bound checking.
      • Checking only 8% as many triangles as before. Huge performance boost!
    • Verified that Materials are being correctly initialized and linked via pointers from Mesh objects.
• 5/9/04 (Sun) [5 hours]
  • 2:00 PM
    • Experimented with textures. The texture loading mechanism--from LevelLoader which figures out texture filenames to the Material::getOpenGLTextureID(...) function which registers textures with OpenGL--is now implemented. However, becuase I'm slightly confused about how to use glEnable() to render both materials and textures in the Mesh::draw() function, I have removed the texture rendering code. We need to discuss this at our next meeting.
  • 12:00 PM
    • Fixed most of the remaining sweep collision issues. The ball no longer rolls through the flipper. A pre-normalization check on ball velocity has eliminated some lingering normalization crashes.
    • Added a boundary case for "very small velocities" into the response function. This was intended to make the response realistic when the ball is just rolling onto the flipper (this is a condition that was not detected before, hence resulting in the ball-rolling-thru-flipper bug). However, the end result is that we not only compensate for the bug fix, but actually have a response that is much more natural than what we started with.
    • Fixed a minor bug in LevelLoader which copied garbage at the end of name strings.
• 5/8/04 (Sat) [6 hours]
  • 9:15 PM
    • Implemented a data path from GameManager to World to FlipperMesh which allows for driving of flipper rotations with the low-level FlipperMesh::rotateFlipper(...) function.
    • Implemented new flipper sweep collision detection discussed with Z. The new collision detection mechanism relies on some simple vector calculations, and with John's redesigned flippers, works quite robustly.
    • Problems remain with catching the ball in the flipper trough in preparation for controlled launch. The ball sometimes rolls through the flippers, and the prototype sometimes crashes.
      • Part of the crash problem is an archaic bug in the standardization code wich propagates a sign error through its calculations. John and I believe we've fixed the problem.
    • Implemented several response mechanisms. The last of these is the most robust, and has been merged into the CVS code base. The response gives us the approximate direction and magnitude of ball desired for realism.
• 5/6/04 (Thu) [1 hour]
  • 3:50 PM
    • LevelLoader now correctly assigns specialized Mesh types based on the mesh name.
      • Mesh names must now follow the following format: [3-lowercase-char-prefix]_[meshname].
        • The prefixes currently supported are: pln (plain), flp (flipper), orn (orientation), bmp (bumper).
        • Sent an e-mail discussing how to add support for other mesh types.
• 5/5/04 (Wed) [5 hours]
  • 1:00 PM
    • Flipper collisions have been implemented according to a detection algorithm discussed with z. Some problems remain, in particular with violated invariants--ocasionally the flipper still moves into the ball. I believe the problem lies in the dot-product test on endpoint vectors. Will discuss this with z at the next possible opportunity.
    • Sent an e-mail discussing progress.
    • LevelLoader now correctly assigns Materials to Meshes.
• 5/2/04 (Sun) [4 hours]
  • 11:55 PM
    • Flippers rotate correctly thanks to additional work by Ed.
    • Basic board prototype loads successfully, provding the desired tilt angle.
    • Flipper collisions remain unimplemented. Discussed impediments as well as related timestep issues in e-mail to team.
• 4/26/04 (Mon) [4 hours]
  • 11:50 PM
    • Added some flipper functionality.
      • LevelLoader now sniffs out the two flipper meshes by name: LeftFlipperMesh and RightFlipperMesh
      • This information can now be passed to World::loadLevel(). The World class is ultimately responsible for keeping track of this information. The flipper meshes are created as FlipperMesh objects.
      • The FlipperMesh class now provides a rotateFlipper function.
        • (!) The rotation lacks a back-and-forth translation to simulate rotation about the pivot.
    • E-mailed the team discussing these changes, as well as the one-flipper-one-mesh issue.
• 4/25/04 (Sun) [4 hours]
  • 8:30 PM
    • Tracked down the performance bug with John. The problem was due to careless orientation of triangles in the sample level file (of all things!). So, the bug was dumb, but as a result we carefully analyzed the collision detect/response code, thus increasing confidence in the completeness of our refactoring.
      • We should consider detecting such conditions. The finall pinball board will be dense and full of opportunities for micro-collisions. We don't want the game to freeze up because of assumptions built into the physics engine.
    • We hope to import sample flippers/pinball frame into the engine later tonight and commence work on flipper rotation.

• • 4:00 PM
    • Seamed the level loading code into our project.
      • The LevelLoader class is now used directly by the driver function. File I/O would not work with the previous design, which had the GameManager using LevelLoader.
      • We have overcome the I/O bug that has been preventing us from opening files. However, other bugs have surfaced-- notably that while we can have both controls input and file input in the same project, the keyboard/mouse controls fail to work after the program runs for more than a few seconds.
      • Cleaned up data handling in Mesh and World. We will need additional attention to make sure memory leaks are completely gone; my changes have eliminated the major leaks which were proably due to scrambling before the M1 deadline.
• 4/22/04 (Thu) [9 hours]
  • Redesigned the file format for storing levels.
    • We are now using a format very similar to MilkShape's ASCII 3D format. This format supports meshes, materials, and textures.
  • Developed a MilkShape plug-in that exports models in this format.
  • Rewrote the LevelLoader class, which now understands the new file format.
  • Added support for materials and integrated this spport with the LevelLoader, World, and GameManager. Triangles aren't fully up-to-speed yet, but the necessary modification will be trivial.
  • Experiencing nagging VS fstream bug (ifstream reports unable to open file despite hardcore work and magic). Ed and I now think this may be due to the shift to a Win32 application. Yay Microsoft. Investigation is ongoing.
• 4/18/04 (Sun) [3 hours]
  • Commenced code refactoring of reuse code from Project 2.
    • Wrote the beginnings of our abstract Mesh class.
      • Observe that all of Mesh's internal data is declared as protected. This is so that derived classes have access to that data. Our implementation of derived classes will require access to private data, and this is the best design choice to that end.
      • Also grep for "QUICK HACK," which appears in three places in the Mesh.cpp This is where I've put in quick hacks to work around assumptions in imported Project 2 code about a single ball. These assumptions should be destroyed in the current project to ease implementation of the multi-ball feature. So, we will likely want to reexamine our individual private collision functions for the possibility of passing a ball radius to the function directly.
    • Created skeletons for BumperMesh, FlipperMesh, LauncherMesh, and PlainMesh.
    • Imported the Tuple and Triangle classes (for use with certain functions moved into Mesh from Project 2's Room class).
      • Observe that Tuple is now found in Tuple.[ch]pp in the project root. This is a better naming, and since we won't have additional "client-provided" code, a client/ subdirectory is probably a pretty dumb practice to carry over from the previous project.
    • Imported global.hpp from Project 2.
      • The default ball radius, formerly defined as a global constant in Ball.hpp (which has not yet been imported), is now defined in global.hpp.

• 4/17/04 (Sat)
  • Posted the design document.
    • http://www3.hmc.edu/~dslusarczyk/3design.doc
    • Please note that use cases have not been included as I did not receive them in e-mail. I will include them in a very imminent version.