Rendering Order

Front to back or back to front...
Ever since the first game I wrote I always drew the background first with depth test disabled and then the characters and buildings with depth test enabled ... This is exactly how we render a scene in Adrian. But we could be rendering the foregrounds first so the number of pixels touched is minimal. This has to be done with depth test enabled of course...

Fixed Pipeline Rendering

The scene composer i had in place for the rendering engine seemed to be working fine but yesterday bhanu complained that there wasnt' a way to disable the shaders and render using just the fixed pipeline. He quickly put up a flag that disables the multipass rendering in the scene composer. But unfortunately that didn't work out as expected .. and guess who is to blame.. :D yes your truely "VK" i messed up the scene->reset() part which requires that the lists of objects for each pass be cleared for each rendering (since its' just list of pointers it doesn't really take that long to work out). Any way if we have a post processing phase (in the multipass) we have a fullscreen polygon in the final pass. There was no way of adding this for everypass so i just added it once in the constructor and in the reset i was avoiding clearing the last pass and guess what happens when there is only one pass and you call reset on the scene composer? :) and thats' what happened exactly.. so i fixed that code and now the scene composer adds a full screen poly for the post processing during multi pass rendering. I should probably add a post proc enable flag to make sure i can enable/disable this but i guess that can wait. For now the fixed pipe line is fixed and is made default :) if you want the fancy glsl shaders you should be using "--enable-shaders" (without quotes) as command line argument to start with these shaders.

PS: sorry no pictures :D

Adrian Got Shadow Mapping

I've finally finished adding another feather in the HD league. Shadows are a good way of showing the object positions etc in the world. I've finally added the ShadowMapping pass to our codebase and have actually cleaned up the code a little to treat the Shaders as objects rather than just the GLuint handles. Any way It's far from perfect, the aliasing effect is pretty evident.. the depth map is pretty high res (equal to the size of the rendering buffer) but the artifacts are there because of the huge frustum size that i had to specify for the light so as to fit the whole map.

Any way It's a good start. Ill' be looking out for ways to fix this but for now I think this is a good feature to have. Finally one of the games i created.. has shadows :D

It took me a while to get the thing working.. i was stuck with various silly problems.. but im' glad i got it done. For some tech details.. here is the sequence that i use to get the shadow rendering done. (Note .. the shadow map is rendered before every frame even for the static objects (map) but that's the only solution when we don't have a proper terrain etc to do shadow mapping offline and use that.)

• Create FrameBuffer with DepthBuffer only
• Enable and Set PolygonOffset(1.0, 1.0) // generally used value.
• Render The scene you want to get a shadow of (map + hero) from lights perspective
  
• Store the light matrix.(Light_MVP)
• Disable PolygonOffset
  
• Use Vertex and Fragment shaders for setting the color based on shadow map. (depth buffer sent as texture and is the ShadowMap)
• Send the Light_MVP to shader using mat4 uniform variable. (not using the texture matrix hack, coz this is cleaner to me).

You can check out the code @code.google.com/p/adrian

Post Processing

If you have seen my prev post, you already know iv'e been hard at work creating something using the GLSL Shaders. Well iv'e been adding a Post-Processing pipeline to Adrian's graphics engine. And i'm really excited about the results iv'e achieved with it .. So without further ado.. here are the screenies..



I know the toon shader has been done a million times now.. but the special thing about this one is ... it is done as a post-process step instead of while rendering. I know it sux.. but if you can achieve one more effect during post processing its just icing on the cake .. isn't it? :D

GLSL MultiTexture CheckList

Most of the tutorials about glsl cover the GPU side of things and generally leave out the host (CPU) side of the code to your imagination.. well not exactly .. but they assume you get it right. Turns out.. its' not that straightforward afterall.. or atleast not for me. So Here is a check list you need to see for getting multi texturing (multiple uniform variables in Fragment shader) to work.

glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, tex0id); // general texture bind call we all know and love.
glActiveTexture(GL_TEXTURE1);
glBindTexture(GL_TEXTURE_2D, tex1id);

glUseProgram(program); //program is the shader program you create using glCreateProgram() call.
GLint h0 = glGetUniformLocation(program, "tex0");
GLint h1 = glGetUnifromLocation(program, "tex1");
glUnifrom1i(h0, 0); //first texture sampler
glUniform1i(h1, 1); //second texture sampler.

The code for Fragment Shader corresponding to the above cpu code is as follows

uniform sampler2D tex0;
uniform sampler2D tex1;
void main()
{
gl_FragColor = texture2D(tex0, gl_TexCoord[0].st) + texture2D(tex1, gl_TexCoord[0].st);
}

So Now the check list:

• Use glActiveTexture for each texture unit
• Use 0, 1, .. texture unit index while assigning values to uniform values.
• Call glUseProgram() before trying to set uniform values.
• Bind texture with texture id for each glActiveTexture.

I know this might look silly but iv'e seen a lot of people asking for this particular problem.. and sadly.. I struggled to get this right too... and this is a post to make sure i dont' ever have to go through that pain again...

Adrian v1.0 RELEASED!

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)

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.

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.

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!

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.

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

    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.

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.