Basic thoughts about a tile based map used with Irrlicht
Basic thoughts about a tile based map used with Irrlicht
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
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
-
- Posts: 31
- Joined: Fri Apr 21, 2006 12:00 am
- Location: Australia
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.
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.
-
- Posts: 31
- Joined: Fri Apr 21, 2006 12:00 am
- Location: Australia
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.
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.
-
- Posts: 6
- Joined: Fri Jun 23, 2006 10:48 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.
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.
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!
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!
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.
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.
-
- Posts: 31
- Joined: Fri Apr 21, 2006 12:00 am
- Location: Australia
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.
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.
if i were you, i would forget that idea _very_ quick - because its really worse
and creating/deleting nodes on the fly is
a. too slow
b. will result in lags
c. fragment memory
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:
you should experiment around a bit
see you!
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.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?
and creating/deleting nodes on the fly is
a. too slow
b. will result in lags
c. fragment memory
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.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 )
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.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.
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.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?
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:
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.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.
you should experiment around a bit
see you!
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....and creating/deleting nodes on the fly is
a. too slow
b. will result in lags
c. fragment memory
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:
So when looking at the fps in the terrain-example (more than 200), it seems a little bit faster.
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") );
}
}