Skip to content

Terrain texturing

The beginings of the terrain system are coming together, and that’s good because this needs to be DONE.  SOON.

Way too much time was spent fretting about the best way to create a direct X 10 texture array.  The design shuffled back and forth between using GDI+ as an image loader, to using libjpeg/png, to trying to figure out DX10′s native methods.  In the end, the method that was settled on should be fairly robust, if a bit roundabout.  The individual image files are loaded using D3DX10CreateTextureFromFile(), and the resulting Texture2D objects are copied into the texture array using CopySubresourceRegion().  There is some extra copying going on, but we won’t have to worry about image formats, or converting between different channels/bit depths.  The only problem with it now is how to handle mipmaps, which should just be calling CopySubresourceRegion() with the right parameters, or once per mip.

The whole point to this ordeal is to make layering terrain textures easy: textures themselves would go into one array, while texture masks into another.  In the terrain vertex shader, per-vertex texture weights will be calculated using the masks.  The final blend will be taken care of by the pixel shader.

terrain

Tagged , ,
2009 04 06 drew Tank Frenzy Comments (0) Permalink

Army Ants Download

As promised, a download of Army Ants is now available.

Please go download it, play it, and then come back here and let us know what you think.

 

Edit: the Army Ants site is now live.

2009 04 03 Matthew Army Ants Comments (0) Permalink

Lua Console & Army Ants

We were at GDC last week, so not much to say about development there. I did talk to a bunch of companies, a few of which asked if Tank Frenzy was playable yet. Not quite yet. Many people did play Army Ants however, which was being demoed. Developers from Blizzard, Square-Enix,and  Insomniac played it. It seemed to get a pretty good response, although everyone agreed the controls are bad. Since getting back, I have been working on the controls and fixing a few bugs and polishing small things. We should have a playable demo by the end of the day, and hopefully a shorter video that we can post (current one is 15 minutes). The more I test (play) Army Ants, the more impressed I am with it. It never gets old. And yes, my opinion is biased. Check back for said video and demo.

In terms of Tank Frenzy development, I started working on Lua integration and so far have a working Lua console that can be used to change stuff like resolution, full screen. More functionality will be added as I wrap various systems.

2009 04 03 Matthew Army Ants
Tank Frenzy Comments (0) Permalink

Particles (Part 2)

For the early part of this week I was working on getting units working.  Since I needed to wait for some geometry and material systems to be improved upon I headed back towards working on my particle system.  One thing I have realized in working on the system this time is that I could work on this one feature for the rest of the quarter adding new functionality and making performance tweaks to get the most out of the system without killing our games performance.

During a tech test we realized as the framerate decreased, due to an increased amount of systems, the particle systems significantly thinned out.  At first I believed this to be an issue with the performance of my individual particle systems.  Each system based on my current vertex structures can only add 78 particles per frame.  This is due to how the geometry shader works, all0wing only 1024 bytes of new information added per iteration.  

After digging into the code a while longer I realized the thinning was not due to the performance of a single system but the random number generation method I was using.  Since the GPU cannot generate its own random numbers I need to preload a texture with random vector values.  Originally I was indexing the array purely based on the current game time.  This means that every particle generated during a frame for a system recieved the exact same random values.  All of my particles per frame were overlapping one another.  I resolved this issue by adding an offset per particle based on how many I was emitting that frame and the count of particles emitted for the frame (counter / emitAmount).

healthyparticlessickparticles

Although I have fixed this one issue I am still a little disappointed with my systems performance.  One consideration is to take my initial geometry shader and stream out to two different buffers.  The first buffer which rebuilds information for the actual particle system (adding and removing particles) and the second for a combined draw buffer.  The idea is to minimize draw calls by feeding draw information for all of the particle systems to a single buffer.  So far after testing doing a simple dual stream out operation based on different passes this seems like an inefficient method.  I recieved 1/2 the FPS during the dual stream out as opposed to only a single stream out.  I will attempt to build the fully functional system in order to get a true measure of performance.

2009 03 20 nick Tank Frenzy Comments (0) Permalink

Textured Tank

 

First render of a textured model (Phong lighting)

First render of a textured model (Phong lighting)

Doesn’t it look nice and shiny?

2009 03 17 Matthew Tank Frenzy Comments (0) Permalink

Log system

The debugging log system is now set up and running.  It’s use should be fairly simple:

To initialize:

// Optionally initialize the external console window, using settings from Lua
Logger::InitLogWindow( LuaSettings(mc->GetLuaState(), "Scripts/WindowSettings.lua", "console") );
// Optionally set the filename for logging to a file
Logger::SetLogFile( std::string("TankFrenzy.log") );
// Set the log sensitivity
Logger::Level = LOG_TRACE;
// Set destinations for logging
Logger::SetDestination( Logger::FILE | Logger::DEBUGGER | Logger::WINDOW );

Using the log system is similar to using any c++ output stream:

TRACE_LOG << "notes and general messages" << endl;
WARNING_LOG << "Configuration error or performance hit" << endl;
ERROR_LOG << "Error in a subsystem, limping along" << endl;
CRITICAL_LOG << "Program Crashing!" << endl;
PANIC_LOG << "We're all gonna die!" << endl;
logwindow
2009 03 17 drew Tank Frenzy Comments (0) Permalink

Terrain rendering demo

Since we’re using Grome as a terrain/level editor for Tank Frenzy, we need a terrain renderer that is both efficient and nice looking.  Granted, this demo isn’t much to look at, but it does incorporate some of the optimizations that we planned for in the game technical design.

 

terrain demo render

terrain demo render

 The terrain vertices are indexed in a spiral pattern, so that changing the size of the rendered terrain is as simple as changing the number of rendered vertices.  All of the texturing and vertex heights are done in the vertex shader, and it demonstrates both horizontal and vertical texturing.  Vertical texturing gives the illusion of a volumetric texture by projecting it sideways onto the terrain.  Better texture scales will be needed, as well as support for more textures and better blending.

2009 03 17 drew Tank Frenzy Comments (0) Permalink

First Mesh Render

 

First tank render using Phong lighting

First tank render using Phong lighting

2009 03 16 Matthew Tank Frenzy Comments (0) Permalink

GUI System Implementation

I have spent my first week of development working on the GUI system, as is described in our development schedule. I have had some success, some failure, and then some lack of motivation to tackle certain elements of it that I know I should be tackling.

The parenting system of the GUI is what has got me a bit fuzzy at the moment. Everything regarding parenting works except for setting the origin of a parent and having it act appropriately with the child elements. If an object’s origin is set to the left and is scaled, it should from its origin out. Children elements should always be centered within its parents, which means if a parent scale changes it should be in the middle of this scale. It should not inherit this origin itself, however.

The propogation of matricies does not solve this problem the way I had hoped it would. The cure was to reset the parents “position” after the origin change has occured. This does not help in scaling, however.

One solution is to advance the node hierarchy one more level, which I am trying to avoid for performance issues.
I am moving on from this problem at the moment in order to finish my other responsibilities. I do, however, need to fix this problem ASAP!

2009 03 16 colin Tank Frenzy Comments (0) Permalink

Owned Lua or Me

The past few days I have been fighting with Lua to in attempts to create a class file that will allow our group to easily load, and save Lua files as configuration / property / settings files. I have found a few good sites on the way that talk about this kind of thing but, the way I wanted to return the data Lua wasn’t having it. What I intended to do was have Lua format the results of the file in such a way that I could store them in a data structure in c++ and I could then use that structure to store the values from lua, and write out new values to a Lua file if needed.
An example configuration file would look like the one below. This file can be read into my class to provide easy access to the values on the c++ side. To access the values it is something like

foo->GetString(“window.Name”); or foo->GetInt(“window.x”);

--Example
Window = {
	X = 0,
	Y = 0,
	Width = 640,
	Height = 480,
	Name =  “My game”,
	FullScreen = false
}

The main thing I wanted to do was have Lua build a table and format the table as follows

tableValues = {
	“window.x”,
	“window.y”,
	“window.width”,
	“window.height”
	“window.name”
	“window.FullScreen”
}
--To get this format is simple, just pass the table name and table to this function
tempValues = {}
tempTableNames = {strTableName}
tempTables = {tblTable}
for i,n in pairs(tempTables) do
	for j,m in pairs(n) do
		if(type(m) == "table") then
			table.insert(tempTableNames,string.format("%s.%s",tempTableNames[i],j))
			table.insert(tempTables,m)
		else
			table.insert(tempValues,string.format("%s.%s",tempTableNames[i],j))
		end
	end
end

The problem was getting that tableValues array back to the c++ side. When viewing the tableValues on the stack the datatype of tableValues was of usertype and the stack would not return a pointer to the data so I could access its raw memory. What I ended up doing was querying lua for each index in the tableValues and getting the string back that way. I am not sure if this is a hack way to do it or not but its one of the only ways that worked for me. So I will let you decide if Lua got the best of me, or I got the best of it.

2009 03 16 unknown201 Tank Frenzy Comments (0) Permalink