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

CpMan

532

Author

November 29, 2002 12:09 PM

Nice idea.

I''ve had talks with Fruny about existing source code (The Code Inquisition), and I''ve compiled a list of things I need to change as soon as I get back. I think the next release of the library will occur shortly after (Sunday or Monday). Have you added your WinSock Wrapper?

Gamedev for learning.
libGDN for putting it all together.

VSEDebug Visual Studio.NET Add-In. Enhances debugging in ways never thought possible.

risingdragon3

382

November 29, 2002 06:53 PM

Which files? can''t see any changes....

-----------------------------
Gamedev for learning.
libGDN for putting it all together.

CpMan

532

Author

November 30, 2002 03:41 PM

Heh.

A list of things TO change when I get back. No changes yet besides what you have done.

Gamedev for learning.
libGDN for putting it all together.

VSEDebug Visual Studio.NET Add-In. Enhances debugging in ways never thought possible.

CpMan

532

Author

December 02, 2002 01:01 AM

I''ve posted a new release of libGDN! See the site for more details. I expect there will be a subsequent release by the end of this week or early next week, comprising the first look at the basic graphics subsystem shell with a probably DirectX Win32 interface!

Have Fun!

Gamedev for learning.
libGDN for putting it all together.

VSEDebug Visual Studio.NET Add-In. Enhances debugging in ways never thought possible.

Programmer One

747

December 02, 2002 08:15 PM

Damn...

I got thrown off by the weekend, I got this sucker all done, I am going to upload it today, and start on the client wrapper.

Damn you time!
*shakes fist at the clock*

CpMan

532

Author

December 02, 2002 11:02 PM

OK, sounds good.

Gamedev for learning.
libGDN for putting it all together.

VSEDebug Visual Studio.NET Add-In. Enhances debugging in ways never thought possible.

CpMan

532

Author

December 03, 2002 01:02 AM

Very soon now I''m going to be looking for file format loading functions or classes. Specifically, texture loading functions at this time. Email me cppman@ufl.edu.

Gamedev for learning.
libGDN for putting it all together.

VSEDebug Visual Studio.NET Add-In. Enhances debugging in ways never thought possible.

ostamo1

128

January 20, 2004 04:53 PM

is this project still alive??

Anonymous

January 21, 2004 08:36 PM

Yeah, its now called Allegro/AllegroGL.

superpig

1,826

January 22, 2004 09:12 AM

quote:Original post by Anonymous Poster
Yeah, its now called Allegro/AllegroGL.

Uh, no.

Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse

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