🔒 Locked

A question about the word "rendering"

Started by Plethora Feb 21, 2013 at 4:33 PM 5 replies 1.3k views

Original Post

Feb 21, 2013 at 4:33 PM

So the specific context here involves SFML2 and sf::RenderTexture, but I think there is some generality here.

So I have a tile map and up until now I've been sending invidual draw commands for each and every tile. I've read here and other places that this is generally considered bad form and that you're much better off putting together everything on your screen to be drawn and then sending one draw command. That makes sense and I understand the reasoning behind it just fine.

My question is, can I assume that if I'm not actually drawing to the screen that I'm not actually rendering anything? Or is this completely false?

Consider this:


sf::Sprite tile1;
sf::Sprite tile2;
sf::RenderTexture builder;
sf::RenderWindow screen;

builder.Draw(tile1);
builder.Draw(tile2);

screen.Draw(builder);

I know that code is incomplete, I just wanted to get my point across.

So in this case, am I "rendering" 1 time? or 3 times? Am I accomplishing my goal of only drawing to the screen once? Or not?

The additional question is, if I'm not, how would I do it instead?

thanks for the help!

Zaoshi Kaba

Feb 21, 2013 at 4:41 PM

It is false.

Reasoning behind drawing everything in 1 draw call is CPU usage. When you draw driver has to make sure all resources are correct, perform error checking & other things which eats reasonable amount of performance.

You say you draw to "screen", but actually you draw into texture, just later on it gets sent into the screen, so the difference between your current code and in this post is that you send different texture to screen.

What you want is called instancing. You'll have to search through SFML documentation how to use it, but general idea is that you set model's buffer (in your case tile), then set 2nd buffer which is an array of positions for those tiles, then draw 100 tiles and it'll merge those buffers, allowing to draw 100 tiles with single call.

Plethora

Feb 21, 2013 at 5:01 PM

Thanks for the help, that should give me enough to figure it out. :)

Servant of the Lord

Feb 21, 2013 at 5:10 PM

So I have a tile map and up until now I've been sending invidual draw commands for each and every tile. I've read here and other places that this is generally considered bad form and that you're much better off putting together everything on your screen to be drawn and then sending one draw command. That makes sense and I understand the reasoning behind it just fine.

Usually when people are talking about that, they are referring to when drawing millions of 3D triangles or hundreds of thousands of 2D particle effects. A few thousands tiles shouldn't slow down your program much - is your program running abnormally slow?

Plethora

Feb 21, 2013 at 5:40 PM

No, not at all. The reason I brought it up is just because I'm revamping some aspects about how I draw everything already for unrelated (mostly code manageability) reasons and just thought that if there was a more "standard" way to do this that this would be a good time to learn it.

Would you say proceeding as I have been is a-ok?

Servant of the Lord

Feb 21, 2013 at 5:54 PM

You may find it actually ends up slower (or maybe not), but it might be fun to try anyway!
If you use a profiler, you can profile your code to see where the real slowdowns are. You can also use timers to measure how long the average frame takes, so you can see whether you are making progress or not.

One thing that might help when doing it, is drawing all the tiles that share the same image together in one go, so the GPU doesn't keep switching between textures.

Instead of drawing in the order they appear in the map:
[Grass.png at 0,0] * [Dirt.png at 1,0] * [Grass.png at 2,0] *[Sand.png at 3,0] * [Dirt.png at 4,0] [Dirt.png at 5,0]

* = Texture change (slightly expensive)

You reorder them to draw in groups sharing the same texture:
[Grass.png at 0,0] [Grass.png at 2,0] * [Sand.png at 3,0] * [Dirt.png at 1,0] [Dirt.png at 4,0] [Dirt.png at 5,0]

But with only a few thousand tiles, reordering them might be slower than any speed gains.

If all the tiles are actually in one reasonably-sized texture, no texture change will occur.

In my game I just draw them in whatever order, without bothering to batch them together in one draw call, and it runs fast enough so far. If it gets too slow, then I'll optimize it - but optimization isn't a priority to me if it already runs fast enough.

And re-factoring for cleaner code is always a good thing (as long as your project still moves towards it's real goal: Getting completed ).

Plethora

Feb 21, 2013 at 6:05 PM

Thanks so much for the advice. :)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.