Basic thoughts about a tile based map used with Irrlicht

t0mmy · Post by **t0mmy** » Fri Jun 23, 2006 6:40 pm

Hi there,

first of all: I'm a big noob in creating computer games. But fortunately C++ is no problem for me. And I've read the DX9 gam programming book from David Scherfgen, maybe somone knows it.
To get into gameprogramming, i want to make a primitive rts game - a C&C:red alert1 clone or so. That's because my intention is to make a better rts next time.

So my first big problem is the map. Must be a tile based map, sure. I think a tile should be about 32x32pixels. The mapsize about 256x256 tiles (more or less). Each tile should have specified texture.
At the beginning, the map should be flat. So there will be no height differences or problems that come with it.

Now this is the point, where I need some help from people, who know the functions and possibilities of Irrlicht better than I do.
I think I need to make a derivation (hope thats the correct english word) from ISceneNode.
Has anyone of you some suggestions for me, how to start?

Thanks

P.S.: I hope my english isn't so bad

ErUs · Post by **ErUs** » Fri Jun 23, 2006 7:41 pm

you could make your own scenenode for a map tile but you could also just draw the tile texture to screen with IVideodriver::drawimage() or soemthing

Gatekeeper · Post by **Gatekeeper** » Fri Jun 23, 2006 9:06 pm

I wouldn't go as far to derive a child class from ISceneNode. I've been doing something similar, because my game only really requires flat ground.

Basically, I made a mesh that was just a cube - to me this is one tile. I then just made a scene node with the cube as the mesh for every tile I had, and placed them all next to each other.

I've found this is working well because you can (with a little bit of simple maths) find out what tile the user has clicked on by using ISceneCollisionManager::getSceneNodeFromScreenCoordinatesBB() to find the node the mouse is over and then using the node position to calculate what tile of your game map it is.

It's also good for highlighting which tiles your mouse is over, because what you do is just add a second texture to the node if the mouse is over it.

Gatekeeper · Post by **Gatekeeper** » Fri Jun 23, 2006 9:07 pm

I wouldn't go as far to derive a child class from ISceneNode. I've been doing something similar, because my game only really requires flat ground.

Basically, I made a mesh that was just a cube - to me this is one tile. I then just made a scene node with the cube as the mesh for every tile I had, and placed them all next to each other.

I've found this is working well because you can (with a little bit of simple maths) find out what tile the user has clicked on by using ISceneCollisionManager::getSceneNodeFromScreenCoordinatesBB() to find the node the mouse is over and then using the node position to calculate what tile of your game map it is.

It's also good for highlighting which tiles your mouse is over, because what you do is just add a second texture to the node if the mouse is over it.

Human Shield · Post by **Human Shield** » Fri Jun 23, 2006 10:54 pm

This is a huge coincidence, I've just downloaded Irrlicht yesterday with the aim of developing a tile based game. A duplicated cube mesh seems limited.

t0mmy · Post by **t0mmy** » Fri Jun 23, 2006 11:29 pm

So until now, there are 3 ways:
1. IVideodriver::drawimage()
2. draw a cube (mesh) for every tile
3. make derivated ISceneNode (which does the same as way 1 or 2)

I think they are all possible, but which is better and faster?
E.g. is it a problem to draw a map with a tile-size of 256x256 with mesh(e)s for every tile? Then there would be 65536 scene-nodes. Of course they would not be drawn all the time because of the culling functions.

gfxstyler · Post by **gfxstyler** » Fri Jun 23, 2006 11:57 pm

the problem:

1. iterating so many scene-nodes is damn slow
2. do culling checks for so many scene-nodes is slow, too

the solution:

a. divide the scene-nodes into patches, and put each patch in its own buffer, so you can group scene-nodes and cull them if the patch is not visible. this way you can render multiple scene-nodes at once and dont have to do that many iterations/calculations

b. put them all into one gigantic buffer and render it completely regardless if its visible or not. it would be a kinda waste of processing power, but if you would render it with vertex-buffer objects, i could imagine it to still be a lot faster than just adding 65xxxx scene-nodes and iterate/calculate them.

see you!

hellbound · Post by **hellbound** » Sat Jun 24, 2006 7:52 am

or you could always try a heightmap

Edit: BTW ... what's the problem with heightmaps in Irrlicht?
I mean as you change perspective - as you go further or closer, there are some variations in the image - polys start dissappearing and appearing (i mean 2 polys morph in one, etc )

t0mmy · Post by **t0mmy** » Sat Jun 24, 2006 8:17 am

Oh there is no problem with heightmaps - until now.

I just wanted to start with a very primitive map-type.

Loading a heightmap is sure easier than creating a tile based map.
But is it also easy to handle, when moving objects on the map, using pathfinding, ... and so on?

And is it possible to use different textures in some areas?
E.g. for having paths, different ground for the area around the players base.

Gatekeeper · Post by **Gatekeeper** » Sat Jun 24, 2006 8:52 am

Why not keep your tile map the way it is, and just create the nodes that the user is currently looking at?

When you move the mouse to scroll, you can just add and subtract nodes as is required (e.g. when you scroll up, add nodes to the top of the screen and delete nodes from the bottom).

It may be a bit CPU intensive (I wouldn't know until I tried it myself), but who cares if it is an RTS game? It's not like you are writing a game that needs ground breaking FPS rates.

I am fairly new to Irrlicht, but not to programming. I've found in my years of programming that I am always surprised with how much code I can run in a loop and still have the program give me good frame rates.

t0mmy · Post by **t0mmy** » Sat Jun 24, 2006 8:58 am

I think it's a good idea to create only the required nodes.
I think I'll try to do it that way.

P.S.: It's funny to see, how many german people are around here and learning to write english posts.

gfxstyler · Post by **gfxstyler** » Sat Jun 24, 2006 11:34 am

if i were you, i would forget that idea _very_ quick - because its really worse

It may be a bit CPU intensive (I wouldn't know until I tried it myself), but who cares if it is an RTS game?

you dont seem to know rts-games, do you? the ai, pathfinding and all other stuff require cpu, rts games can be very cpu-intensive, thats why you have to code as good as possible.

and creating/deleting nodes on the fly is

a. too slow
b. will result in lags
c. fragment memory

Edit: BTW ... what's the problem with heightmaps in Irrlicht?
I mean as you change perspective - as you go further or closer, there are some variations in the image - polys start dissappearing and appearing (i mean 2 polys morph in one, etc )

this is no problem, its called geomipmaps. the farther away you are with the camera, the less polys will be rendered because they are clipped. to turn that feature off, see the overrideLODDistance method in the irrlicht api documentation.

I've found in my years of programming that I am always surprised with how much code I can run in a loop and still have the program give me good frame rates.

well, define "good frame rates". it all depends on the game you´re working on, and in the case of rts, your fps can drop very quickly.

Loading a heightmap is sure easier than creating a tile based map.
But is it also easy to handle, when moving objects on the map, using pathfinding, ... and so on?

for pathfinding, you dont have to create a "real" grid, you can also use a "virtual" one and just set your nodes to the virtual grid position. i mean the grid doesn´t have to be graphically.

you can either try the methods i mentioned before, or you reduce the number of tiles (which is very high btw). pathfinding with 256x256 tiles can be very very slow.

try to use less tiles and bigger ones for the graphics, and use a virtual grid for pathfinding, which has even less tiles.

you wont really notice it, cause the pathfinding doesn´t have to be pixel-perfect.

oh, btw:

And is it possible to use different textures in some areas?
E.g. for having paths, different ground for the area around the players base.

this is possible with a colormap + detailmap. basically, you create your terrain texture with all your tiles, and then apply a detailmap to make it look good. if you make a good detailmap, it will look very high-res and you wont see any tiling/seams.

you should experiment around a bit

see you!

t0mmy · Post by **t0mmy** » Sat Jun 24, 2006 12:10 pm

and creating/deleting nodes on the fly is

a. too slow
b. will result in lags
c. fragment memory

So last chance for the tile based map: What if I don't add/delete the nodes, but moving the no more used nodes to the position, where new nodes are needed? And change the texture and some other options....

gfxstyler · Post by **gfxstyler** » Sat Jun 24, 2006 12:55 pm

i never tried it, but it sounds like it could really work, good idea!

you just need to load all tile-textures at your application startup, because when you load them while the tiles change position, you may get lags, and you dont want that.

see you!

t0mmy · Post by **t0mmy** » Sat Jun 24, 2006 3:58 pm

So here's the result:
I tried it with a 32x32x5pixel Mesh. Duplicated it 1024 times (32x32) an positioned it side by side.
The disappointing result: I didn't get more fps than 70.
And I have nothing special in the loop... looks same as the first example.

The meshs are created as following:

Code: Select all

scene::IAnimatedMesh* mesh = mSmgr->getMesh("test.x");
	for (int j=0; j<mMap->mHeight; j++)
	{
		for (int i=0; i<mMap->mWidth; i++)
		{
			mNode[i + (j*mMap->mWidth)] = mSmgr->addAnimatedMeshSceneNode( mesh );
			mNode[i + (j*mMap->mWidth)]->setPosition(core::vector3df(i*36, 0, j*36));
			mNode[i + (j*mMap->mWidth)]->setMaterialType(video::EMT_SOLID);
			mNode[i + (j*mMap->mWidth)]->setMaterialFlag(video::EMF_LIGHTING, false);
			mNode[i + (j*mMap->mWidth)]->setMaterialTexture( 0, mDriver->getTexture("ground.png") );
		}
	}

So when looking at the fps in the terrain-example (more than 200), it seems a little bit faster.