Saturday, March 19, 2011

And right there, where nobody con see him was hiding the last mini boss... The File System!

Once again my fellow dudes, apologies for disappearing for almost three weeks, I was M.I.A. working on stuff for the three classes I am taking this quarter: A.I. for games, Graphics Development and Game Engine Programming. The quarter is over, yesterday was the last day of activities at the university, and what an effort I did to finish all the assignments on time. For this week I had: Graphics Development’s homework #4 and final exam, A.I. for Games’ take-home final exam, and Game Engine’s final essay and final project (Graphics Engine). I finished all of them on time (almost all completely, only failed to finish the A.I. final) after two days in a row without sleep (not even a small nap), so now is time to relax a little bit and tell you the story behind Game Engine’s last projects.

Since my last post I owe you guys one describing my File System implementation, so here you have it. Unfortunately, this was the last system I started from the four core systems, and since I started it two days before deadline, I did not have too much time to refine and improve my first design. But I am still quite satisfied with how the implementation ended up looking like.

The core functionality of the File System was to handle reading and writing different types of data to files on Windows. In order to do this (and due to time constrains), once again we ended up using the Win32 Library (Windows.h) as our start point for the implementation.

The system’s main functionalities were covered by creating a FileHandler class which wraps the following functions from the Win32 Library: WriteFile, ReadFile and FlushFileBuffers. All these methods use HANDLEs to manipulate files, and some of them use up to five (5) parameters as input. Therefore, the idea behind this FileHandler class was to hide some of the advance features this Win32 functions have, and create a simple interface the user can use to upload/download data to disk. The FlushFileBuffers function was used in combination with WriteFile to allow the system to write as much data as possible to memory, and then proceed to download all of it in one shot (writing to disk is a very slow operation, but one that is unavoidable sometimes, so if we must to do it, we better attempt to do it altogether in one try). Here you have a brief summary of the functions prototypes and description:

  • FileHandler(filename,mode) – Class constructor (Specifies the filename and read/write mode)
  • read(buffer,size) – reads size bytes from file into the specified buffer
  • write(buffer,size) – writes size bytes from specified buffer to file
  • flush() – flushes (writes) to file all data stored so far in the buffer

Last, but certainly not least, as part of the assignment I also developed an Archiver System. Essentially this class is an advance data structure that holds different types of objects inside (it has a linked list with pointers to each one) and has the functionality to download all this data to a file in an structured way (using an archiver header and table of contents), so that you can also read it back to memory when needed. The whole porpoise of the Archiver in the gaming world is to be able to store/load from disc (hard drive or optical media) files that contain complete models (maps, characters, etc.). For example, if we are talking about a character, the file would hold data regarding vertices, normals, texture coordinates and data, sounds, animations, etc.

Well my dear followers, hope all this information is useful for you or at least interesting in some way. I will be posting tomorrow the video of my Graphics Engine‘s demo followed by a post describing its architecture and implementation. Have fun tonight!

Adios!

No comments:

Post a Comment