2d and FPS

[paooolino]

Well, let's consider i'm programming a little tile-based 2D-game.

During every loop cycle, I draw tiles and their content using draw2DImage.

I see that redrawing all every cycle is heavy time-consuming. But it's quite necessary.

I lose many FPS when scrolling the entire map.

How can I manage this, or better: what's the better architecture for such a game with Irrlicht?

cheers

[d3jake]

I'm not familiar with the 2d part of Irrlicht, but could you maybe break the playing area into many sections, with logic to see which parts are visible? That or make a test to see if a given tile has changed, and then not redraw it?

[paooolino]

after a bunch of tries, I can say that OGL is extremely slow when rendering 2D.

I switched to software render and I get better results (250 FPS vs 40)

In d3d, I get 120-130 FPS.

[Halifax]

Your process is pretty inefficient.

I would recommend that you create a scene node with which you put the visible tiles in dynamically. Then draw those all in one batch with a mesh buffer. You could also put that mesh buffer in a VBO (with Irrlicht 1.5 SVN). Plus I don't know about draw2DImage(), but it may be immediate in OpenGL, and that could be the reason it makes the application slower.

And if that doesn't work to your liking/can't implement it, then I would go check out an engine built specifically for 2D.

[paooolino]

I'm not familiar with the 2d part of Irrlicht, but could you maybe break the playing area into many sections, with logic to see which parts are visible? That or make a test to see if a given tile has changed, and then not redraw it?

yeah
the problem is, when I'm scrolling the entire map..

but I can say that software render is quite reasonable

[paooolino]

Your process is pretty inefficient.

I would recommend that you create a scene node with which you put the visible tiles in dynamically. Then draw those all in one batch with a mesh buffer.

I'll give it a try thankyou

[arras]

He is doing 2D so scene node and mesh buffer is not option here. I however wonder what your problem is since I did render tiles the same way as you but I did not notice some slowdowns. I also rendered map tile by tile.

[jrm]

are you only drawing the visible tiles? I have been working on a 2D game, here and there (dormant or now), and I saw similar results, when I finally drew the visible tiles only it worked much better.

also take out or condence any extra for loops..

JRM

[Halifax]

He is doing 2D so scene node and mesh buffer is not option here. I however wonder what your problem is since I did render tiles the same way as you but I did not notice some slowdowns. I also rendered map tile by tile.

How is doing a scene node not possible? You cannot use an orthogonal matrix, assign a texture, and put the two vertices you are assigning those textures to in the mesh buffer?

I don't see why that isn't possible, that's how almost all 2D games do it, and that's basically what he is doing with the draw2DImage process.

A scene node is not restricted to 3D the last time I recalled, but maybe there is some process I am missing.

[paooolino]

I however wonder what your problem is since I did render tiles the same way as you but I did not notice some slowdowns. I also rendered map tile by tile.

Let's explain better.
I simply load a texture 512x512 bmp from which I get a rectangle that represent my tile.

In the game loop, with a couple of for statements I draw the tile with draw2Dimage. All tiles are visible.

I can move the whole map with arrow keys.

with a map of 10x10 tiles I get 20-40 FPS.

When the map is out of the viewport, the FPS increases to 80. So I can argue that Irrlicht is doing culling of non-visible tiles by itself

I can say however, my notebook has poor video card. With another machine, I probably wouldn't notice the problem.

With software render I get 200-250 FPS depending of the number of the tiles that are in the viewport.

[BlindSide]

Halifax is right, draw2DImage uses a screen aligned quad in the first place, so just batch all of the quads into a single meshbuffer, and it should run much faster. You can even do texture batching using a texture atlas, kind of like those sprite tiles. There an NVidia paper on texture atlas batching over at ftp://download.nvidia.com/developer/NVT ... epaper.pdf

[paooolino]

wow. that's a kind of advanced 2D programming

[arras]

BlindSide, Halifax >> I did not know that draw2DImage uses actually vertices to draw. I tough it uses some kind of putpixel. Anyway with 10x10 = 100 tiles per screen it probably is not the problem. Also he is already using single texture as he wrote above so he is doing "texture batching".

paooolino >> getting 80FPS while you are drawing nothing on screen is horribly low. That suggest problem is somewhere else. And your hardware can't be that bad. I am drawing maps around 20x20 tiles (each out of its own texture) on hardware which is 4 years old all right.

Also difference between OpenGL and software renderer you encounter is really strange...

[paooolino]

well, I'm using only 1 texture but
when I draw, I call draw2Dimage (and consequently the "putpixel" thing) 100 times per cycle.

I believe that batching is drawing in a buffer 100 times and then display all in just one step.

But I believed also that this feature was already present with backbuffering, or am I wrong?

for the OGL issue - I will test it on another machine and let you know

[JP]

By backbuffering i assume you mean double buffering; using 2 buffers and drawing to the back one whilst the front one is being displayed on screen.

What's been suggested here is very different to that. In fact they're not related at all.

When you do draw2DImage() it sends a draw command to the GFX card. If you call draw2DImage() 100 times then that's 100 draw commands being sent to the GFX card.

If you batch all the calls into a meshbuffer then it effectively sends those 100 images in one draw command, which is a lot quicker as multiple draw commands can suffer from stalls each time.

Hope that clears it up for you.