IWF SDK Overview.pdf Last Modified : August 23rd 2006 File Size : 633,273 Bytes This course makes extensive use of the IWF file format for loading geometry, entities and other scene data. As a result we have included a high-level discussion of how the IWF SDK is utilized within the sample code framework and lab projects. Note:For further information about the file format itself, please download the full IWF SDK installer below. -------------------------------------------------------------------------------- timerTut.zip Last Modified : September 17th 2005 File Size : 246,299 Bytes Faster computers can process more game loop iterations per second than slower computers. So Pentium IV™ systems will process more frames per second than Pentium III™ systems, which will in turn process more than Pentium II™. The geForce™ 4 can finish drawing a frame faster than the geForce™ III, which is faster then the geForce™ II, and so on. Such variations in degree of hardware speed make timing game updates based on the frame rate (frames per second) an unwise choice. Certain games from the late eighties did not account for this and as a result, cannot be run on modern PCs. On a modern system, these games cannot be properly controlled since object velocities are simply too high given the rapid frame updates. Our preference is to use more scalable time units like seconds or some fraction thereof. This document discusses the various concepts involved in providing frame rate independant computations, including object motion. -------------------------------------------------------------------------------- Tutorial - Debugging with Visual C++.pdf Last Modified : August 27th 2006 File Size : 1,289,652 Bytes When writing new code or modifying existing code, debugging typically consumes a large portion of a programmer's time. In this short article, we are going to try and provide a rudimentary foundation in the use of the "debugger" tool shipped with most development suites. We will be using Visual Studio 6.0 in our examples and explanations, but you should find that the concepts translate fairly well to other development environments. -------------------------------------------------------------------------------- Giles-v1.5-Setup.exe Last Modified : August 28th 2006 File Size : 10,209,623 Bytes GILES is our in-house, proprietary level editor which we have made available to our students in order to provide a means by which they are able to create geometry for use in their applications. "GILES provides a feature-rich and user-friendly level editing environment. A combination of power and programmability, GILES is the perfect tool for your next videogame or 3d graphics project. GILES is easy to learn and easy to use and ships complete with detailed documentation." Please visit the product's home page for more information. -------------------------------------------------------------------------------- IWF200_Setup.exe Last Modified : May 30th 2006 File Size : 1,183,998 Bytes This download contains the "IWF" SDK. This is the development kit for the 'Interchangable World Format' specification used internally by GILES, and can be used to help you develop import support within your application, for the GILES native scene file format. GILES does work directly with 3D Studio .3DS (import only) and DirectX .X files (import and export) however should you not wish to employ this flexible file format. Note: The IWF file format is employed by several courses offered here, and as such it may be a good idea to download a copy of the specification for later use. -------------------------------------------------------------------------------- Pac Dude SCD.zip Last Modified : June 5th 2006 File Size : 37,570,590 Bytes The source code distribution of Pac Dude 3D. This was a demonstration project by Gary Simmons limited to a 10 day development deadline. As a result, I ran out of time to make many of the performance optmizations that I intended to make (including the consolidation of non animating tiles into a static mesh). I also limited myself to NOT using DirectInput to keep the code base as close to GP1 topics as possible. This obviously means that input is not being performed very efficiently.