Back to General and Gameplay Programming

libGDN project details!

CpMan · 2004-04-11T07:08:09

What is libGDN? libGDN is a community project aimed at the creation of a flexible, cross-platform, non-api specific general game development library. It's scope may include anything from skeletal animation systems, terrain engines, octree and quadtree or basically anything applicable to the game development process. How is it being released and what is the license? The project is being developed as a SourceForge project using CVS. It is being released under the LGPL. Who's developing it? Anyone who wants to. You can either become a developer on the project through SourceForge (email me or ProgrammerOne to be added to the developer list), or you can email one of us pieces of code (make sure they are fairly up to spec...we don't want to spend hours converting code to fit with the library's struture). What is the structure? There are basically two kinds of code in the library...that that is system or API dependent, i.e. code that contains Windows API function calls, or OpenGL calls, DirectX calls, and that code that is system independent. There are several aims to the structure that will be laid out. First: Minimize the amount of code that must be rewritten when moving modules to new operating systems or changing which system dependent code will be linked in. In fact, the aim is to to have NO changes whatsoever in system independent code (as if that wasn't obvious). Second: Allow the libraries parts to be taken away from the rest of the library and still work properly. Lastly: Allow code to be easily added at any time. Everything also goes under namespace gdn with POSSIBLE nested namespaces, but i'm not sure. This is not only to reduce naming conflicts, but also is used as the second parameter (I think), for BOOST_CLASS_REQUIRE (more on that later). So exactly how do we accomplish this? The whole idea is to isolate system dependant code as much as possible. Using templates, one can swap system dependent elements out of the system without too much trouble. The best way to illustrate this is with an example. The "classic" example that we have come up with is a texture manager. The advantage of this example is that it encompasses a couple layers of code, and would be very useful in many applications as a standalone entity. We need the texture manager to do several things: load bitmaps from a file, manage them internally, (won't be going into this much, as the focus is on interactions between modules) and allow output of texture information. Now you might ask yourself: How do we provide all those services while only having to write one texture manager. The answer is templates. I'll start from the ground up. First there needs to be a loading system for which textures are added to the texture manager's control. Say for instance I want to load a TGA file. This requires two things: getting the data from a file and somehow getting it into the manager. Notice that the loading portion can be split up into two pieces for maximum cross platform usage. It can be split up into a general file I/O system, which is, in many cases, system independent, and a file type (TGA), loading routine. Each of these are encapsulated in a class. The TGA file loader takes as a templated parameter type the general file I/O class this is to be used. The general file I/O class contains simple methods to read and write data from a file...that's all. That way a TGA file loader, a BMP file loader, any file input system written for a specific purpose will work on ANY system provided that the system has a file I/O system written for it. But there is a problem. How do we garuntee that a given file I/O class has the required functions at compile time? Being templated, it's not totally garunteed. For this purpose, class/function signature checking, we're use the boost_concept_check system, specifically the BOOST_CLASS_REQUIRE method. Whenever a function or class member is used in code, boost forces a compiler error if the function's signature does not match. So now that we have a basically garunteed compile time signature checking (not infallible, though...it can't check the return type ), what's next. Now we need to link the file loader, which can load in any supported I/O system, into the texture manager. The texture manager takes a texture loader as a templated class paramater. Again, the texture loader basically needs one garunteed function, a load function that returns a texture in it's most basic form, a stream of bytes and a bit of data specifying size bits per pixel, etc. So now the texture manager can store any texture type that it has a loading class for (multiple types could also be encapsulated in a single class). We could extend this flexibility even further by supporting a default templated type, much like STL, that did not require a loading class. Even further, we could create a templated function inside the manager class that took a texture loader class for types that may not be encapsulated in a single loading class. But enough about loading, what about storing, and more specifically, getting the texture data out. It sort of defeats the purpose if the texture class can only output byte data, since the developer wil have to do his own conversions. Why not extend on the original templated class idea and specify a texture type? The class would need to contain at least three things: a typedef of the type to store data in the texture manager, like LPDIRECT3DTEXTURE8, an input function, which would take a stream of byte data as the image properties, as translate it into the specified texture type, and an output that would do the opposite. Then it's simple, the manager takes a texture type class, and uses the appropriate types to store data in the specified texture format and convert it when inputting from files and outputting to the developer. And again, the use of a default templated type would make it so data is only stored as byte data. It sounds a little complex, but it's not too bad, and the flexibility and interchangability is incredible. But you might not even limit the input/output type model to things like a texture manager. Anything that outputs a mesh to be drawn, like a skeletal animation system, terrain engine, etc. could go along with this model. Basically anything that outputs specific, isolatable piece of data. And it would be easy to output in other formats too...just write another type converter and plug it in. Simple as that. Think of the flexibility. I could take such a system and plug it into virtually anything, a painting program, GDI bitmap display system, military simulator, you name it. It's all about the generalized interchangeability of the system. So I guess that about outlines the basics of the system. One of the team members is writing a basic sample at the moment, that shows the general idea. This form will get extended to the entire engine where applicable. OK that's enough on the structure. What is the code style expected? We're going to be lenient here. As long as it's readable, doesn't use hungarian notation, (please no, we had an overwhelming NO NO NO at the meeting yesterday) we're ok with it. We ask that you capitalize the first word of every variable name and function name and every word thereafter. For example: GetTexture(...), TextureName, Identification, etc. We do suggest however, that you go along with something like Apache http server code style if possible: ) What is the policy on using existing libraries/API's in code? We're going to maintain a fairly open policy on using existing libraries in code right now. The only qualifications that exist are: The library is easily accessible, the library, if platform/API specific, is only used in a code section that is platform/API specific (duh). Otherwise, I can't seem to think of any more restrictions, but things may change if it becomes a problem. What about Documentation? Documentation should be done in two places if possible (please). Internally for what the code does, and externally (in text files), for how it's to be used. Documentation will be stored in a CVS directory (more on that later). (Finally) What is the policy on variable types? Basically all we want is this: Every module, if it's using some special internal variable type, or takes it as input, or whatever, should contain methods to output and intput the variable in some way is a standard c++ type. For instance, a matrix class needs some way to output and input it as say a 4x4 matrix. This is designed so as to reduce the need for conversions between modules. **************************************************************** This is a copy of a design doc that will be posted on the SourceForge site today. If you want to submit, please email me at my sourceforge account or cppman@ufl.edu. Please give me a few days, say until the end of the weekend to get the CVS system set up and write a bit on where files go, etc. Thanks. Matt BTW....if you didn't want to read this because it's too long I don't blame you one bit.... The log of last night's meeting is in CVSROOT in the repository (i'll be putting the rest somewhere later when I figure out where). Gamedev for learning. libGDN for putting it all together. [edited by - CpMan on October 31, 2002 4:30:05 PM] [edited by - CpMan on November 4, 2002 1:43:08 AM] [edited by - CpMan on November 4, 2002 1:44:30 AM]

General and Gameplay Programming Programming

Started by CpMan October 31, 2002 03:22 PM

169 comments, last by CpMan 20 years ago

Facehat

696

January 22, 2004 04:37 PM

quote:Original post by ostamo1
is this project still alive??

It doesn''t look like it is.

----------------------------------------
"Before criticizing someone, walk a mile in their shoes.
Then, when you do criticize them, you will be a mile away and have their shoes." -- Deep Thoughts
"If you have any trouble sounding condescending, find a Unix user to show you how it''s done." - Scott Adams
FaceHat Software -- Wear the hat.

libGDN project details!

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

libGDN project details!

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines