At last I ironed out the bugs in the 1.0 branch and was able to release Adrian both for Windows and Linux. You can download the Linux version or the Pre-Compiled Windows Version.
Hope you guys enjoy the game. Do report any bugs you find here.
Source code is licensed under GPLv3 and the SVN repository is located here.
Here are some screenshots from the game (scaling them reduced the quality here)
Sunday, May 10, 2009
New Model Loader
One of the sore points of the original game was that buildings attributes were handcoded. This was a very tedious effort. Also not to mention the results were not too appealing always, and the visual complexity of the objects was exceedingly little. But now by leveraging a third party Model loader, the loading of almost all formats has become a simple cake walk.
Thanks to ASSIMP, hosted at http://assimp.sourceforge.net/, we were able to load not just MD2, but even open source models like Collada etc. This has opened up a whole new array of resources for us. Also it lets us do away with the current MD2 loader which is pretty brittle. Even Skeleton animation can be included too if required.
However, Release 1.0 will be shipped without this feature.
Thanks to ASSIMP, hosted at http://assimp.sourceforge.net/, we were able to load not just MD2, but even open source models like Collada etc. This has opened up a whole new array of resources for us. Also it lets us do away with the current MD2 loader which is pretty brittle. Even Skeleton animation can be included too if required.
However, Release 1.0 will be shipped without this feature.
Friday, May 8, 2009
Showstopper resolved - Release on track!
The showstopper with the windows release has been successfully resolved. The issue turned out to be a simple bug. Basically we have a structure which has an embedded vector STL class in it. What the code was doing was to create the structure, and before assigning contents to it, was simply memsetting the entire structure to 0. While this is normal operation in any C code, in C++ this can cause very weird bugs. More technical details can be had in the bug report or in my blog.
Now I have created a 1.0 branch to release Adrian, This branch will contain some basic bug fixes. The plan is to release it this Sunday. The trunk will continue to experiment with new features meant for 2.0 like new model loaders etc.
Now I have created a 1.0 branch to release Adrian, This branch will contain some basic bug fixes. The plan is to release it this Sunday. The trunk will continue to experiment with new features meant for 2.0 like new model loaders etc.
Wednesday, May 6, 2009
What is blocking Adrian Release
Currently we have done many improvements to the old game, but unfortunately unable to release, since the windows Release configuration crashes unexpectedly. The Debug configuration runs perfectly. The Linux version is running very well too. Some thing appears rotten there.
The problem occurs in some list handling in the MD2 model loading code. So we have two options - debug it or use a more professional loader. Basically we have seen a good open source model loader based on the BSD license at http://assimp.sourceforge.net/. This will be hopefully solve the woes. But I guess it pays to debug what the problem is with the existing code too, but not by blocking the release indefinitely. Technical details are tracked in this issue report.
So that is exactly what was blocking the release. I cant wait to populate the downloads section with the first "official" Beta release version of our game!
The problem occurs in some list handling in the MD2 model loading code. So we have two options - debug it or use a more professional loader. Basically we have seen a good open source model loader based on the BSD license at http://assimp.sourceforge.net/. This will be hopefully solve the woes. But I guess it pays to debug what the problem is with the existing code too, but not by blocking the release indefinitely. Technical details are tracked in this issue report.
So that is exactly what was blocking the release. I cant wait to populate the downloads section with the first "official" Beta release version of our game!
3D Models - accidental discovery
Well, in Adrian, when we initially created it, we hard coded the building load routines. But now that we are extending it to load maps on the fly, this had got to go. But I found out that it was a very tedious thing to migrate all this information into a normal file from C code by hand.
So I did a hack, which replaced all the GL function bodies with a simple printf about what they are doing and their coordinates. This caused it to generate an output file, which sequenced the list of OpenGL commands.
For loading the building, all I did was at load time I did a glNewList and put in all the vertices, textures drawing etc into it. Now for rendering, I just call the display list. This seemed like a very nice and unique solution. Basically then I realized that what I have done is exactly what 3D modelling formats do.
You kind of understand things at a whole new level, if you come up with a solution, which turns out to be actually widely used. You would actually know the exact usage of such a solution.
Chill.
So I did a hack, which replaced all the GL function bodies with a simple printf about what they are doing and their coordinates. This caused it to generate an output file, which sequenced the list of OpenGL commands.
For loading the building, all I did was at load time I did a glNewList and put in all the vertices, textures drawing etc into it. Now for rendering, I just call the display list. This seemed like a very nice and unique solution. Basically then I realized that what I have done is exactly what 3D modelling formats do.
You kind of understand things at a whole new level, if you come up with a solution, which turns out to be actually widely used. You would actually know the exact usage of such a solution.
Chill.
Monday, April 27, 2009
Sprites - Poor man's 3D rendering
Modeling stuff like Trees, explosions in 3D is excessively complex. The number of polygons used to render them make it prohibitively expensive even for high end cards. So most games take shortcuts to create approximations, which are nearly as good, but extremely cheap. One such concept is sprites...
The basic idea behind sprite is that, no matter how much u model, the final image appears on the 2D screen. So technically you can get away with just rendering the 2D view of it. So how do you do this? simple, just draw one polygon with the 2D view of the object, and then make sure that the Polygon is *ALWAYS* facing the user. so no matter which place in the 3D world the user looks at from, he sees the same side of the polygon facing him. This gives a reasonable illusion of 3D for a very very cheap CPU and RAM cost! Obviously this works best only for objects which do not require much interaction with the user, and are mere eye candy.
Adrian now implements sprites, and litters the map with some trees here and there. Another thing is that although a tree looks complex, we just render a single rectangle. We take an image of a tree, in which parts of it not inside are made transparent (instead of some color), and saved as a TGA file (JPEGs etc do NOT support transparency). Now we map the image to the rectangle, and it gives the illusion of a tree.
For the OpenGL coders, to do this you have to enable transparency use the following code
However if 2 or more transparent objects overlap, then the results will result in the one drawn first getting hidden by the later drawn one (even IF the first object is in front of the other!). To overcome this order the objects need to be distance sorted.
If distance sorting is not an option, then my friend Vamsi suggested that you can enable Alpha Test to make sure that before overwriting the buffer, OpenGL compares the existing alpha value and if lesser does not overwrite the existing one.
The basic idea behind sprite is that, no matter how much u model, the final image appears on the 2D screen. So technically you can get away with just rendering the 2D view of it. So how do you do this? simple, just draw one polygon with the 2D view of the object, and then make sure that the Polygon is *ALWAYS* facing the user. so no matter which place in the 3D world the user looks at from, he sees the same side of the polygon facing him. This gives a reasonable illusion of 3D for a very very cheap CPU and RAM cost! Obviously this works best only for objects which do not require much interaction with the user, and are mere eye candy.
Adrian now implements sprites, and litters the map with some trees here and there. Another thing is that although a tree looks complex, we just render a single rectangle. We take an image of a tree, in which parts of it not inside are made transparent (instead of some color), and saved as a TGA file (JPEGs etc do NOT support transparency). Now we map the image to the rectangle, and it gives the illusion of a tree.
For the OpenGL coders, to do this you have to enable transparency use the following code
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
However if 2 or more transparent objects overlap, then the results will result in the one drawn first getting hidden by the later drawn one (even IF the first object is in front of the other!). To overcome this order the objects need to be distance sorted.
If distance sorting is not an option, then my friend Vamsi suggested that you can enable Alpha Test to make sure that before overwriting the buffer, OpenGL compares the existing alpha value and if lesser does not overwrite the existing one.
glEnable(GL_ALPHA_TEST);
glAlphaFunc(GL_GREATER, 0.5);
Adrian on Windows
So we do realize that there are too many developers for windows platform, who want to get their hands dirty with our code.. or so we hope they exist. Since we use SDL it was an easy ride from linux to windows. Head over to the adrian code base and get the updated files and visual studio 9 project files. Btw.. you will ofcourse need SDL_mixer, SDL, SDL_image and SDL_ttf dev libraries and runtime dlls to get the project to compile under windows as well.
Known Issues:
1) Textures of some of the enemies loaded in the game look weird.
2) Lot of warnings during compilation.
Ps: We do not have any releases yet... so you will have to use svn clients to get your hands on the game code.
Known Issues:
1) Textures of some of the enemies loaded in the game look weird.
2) Lot of warnings during compilation.
Ps: We do not have any releases yet... so you will have to use svn clients to get your hands on the game code.
Friday, April 24, 2009
Code ONLINE!
The code for Adrian Game is now licensed under GPLv3 and is available at Google Code. The hosting facility appears to be pretty good. We will be making changes to it and improving it, as well as fix existing bugs. If you know of any bugs, do send me a mail or just start a new issue in the issues tab in google code.
Adrian Resurrected!
Adrian game was initially developed by Suman Korada, V Vamsi Krishna and myself, while we were in 3rd year B.Tech at IIIT-Hyderabad in 2003. We wrote the game for a game designing contest in 7 days (and nights) flat. The initial version that you see is based off the same source code. Needless to say it was pretty impressive and we walked off with the first prize :).
After almost 6 years of no development on it (mainly since we could not afford the better graphics cards initially and later working full time), I felt like it was a good time to resurrect the project and here we are. The actual trigger for resurrecting adrian came from a guy who mailed me about the game saying he liked it. It prodded me to download the source code myself and see how it runs, and I was very impressed with our work. There were a lot of changes which we could not do for the contest since, we were operating under a severe time constraint then. But now the development can proceed at a more slower pace.
I am very excited about this new game, and hope I will have as much fun as I had last time I used it.
Subscribe to:
Posts (Atom)