Hi everybody!Many tutorials say that we must not bind textures too often, that's why we have all these spritesheets and tilesets. Suppose I have a tileset with water, grass, trees, houses etc. And spritesheet with players.I have a question about rendering.Firstly I draw water layer, then ground, and then objects(trees, rocks houses). I'm very new to this, I suppose players must be on the same layer with objects to interact with them, am I right?Look at the situationWe have many trees, rocks and players on different positions, so while rendering we have to rebind textures(tileset and spritesheet with characters) every time depending on what I'm rendering now(tree or player), because like on the picture while player on this position tree must be behind him and rock in front of him. Is there any good practices to do this task optimally?

You can render in whatever order you want, but from what it looks like, you would want to sort your renders by y value, so that the player can be rendered before the rock if it's below it. Otherwise the player will be partially behind the rock, despite being meant to be in front of it. Also, I don't understand what you mean by interact, any environmental interactions should be handled through collision, which you'd have to write yourself, rendering only puts things on the screen.

That said, things will be drawn to the screen in the order that they are rendered, so if you say, draw the ground after the player, the player will be invisible, because the ground will be in front of him, so you want to render your top most elements last, such as GUI. In your case, I would look into setting up an array of sprites to hold which texture they each need to render from, so that you can sort them all by their y position, then render them with their proper textures, in an order that works.

You can render in whatever order you want, but from what it looks like, you would want to sort your renders by y value, so that the player can be rendered before the rock if it's below it. Otherwise the player will be partially behind the rock, despite being meant to be in front of it. Also, I don't understand what you mean by interact, any environmental interactions should be handled through collision, which you'd have to write yourself, rendering only puts things on the screen.

That said, things will be drawn to the screen in the order that they are rendered, so if you say, draw the ground after the player, the player will be invisible, because the ground will be in front of him, so you want to render your top most elements last, such as GUI. In your case, I would look into setting up an array of sprites to hold which texture they each need to render from, so that you can sort them all by their y position, then render them with their proper textures, in an order that works.

Thanks for the reply. I know about rendering order. You misunderstood me.Trees rocks etc belong to one big texture, and players belong to another. Seems like I must bind texture with rocks trees etc to draw tree, then I have to bind spritesheet to draw player and then again I have to bind first texture do draw rock. Seems like not very optimal.

May be I should bind both textures and use different shaders to draw player and trees with rocks?

But if each spritesheet is big. For example one for environment, others for characters, one spritesheet for each different character with all angles of view and animation on it.Just wanted to ask is it ok to change texture 10-20 times per frame?

At most you should be switching spritesheets twice per frame; one for terrain textures and the other for players and mobs. Maybe another for weapons. But really unless you have a large number of textures you should just pop them all into one sheet. There's no point in wasting resources for the sake of organization.

While rendering terrain if there is a tree that must be in front of mob or player, I must switch texture to draw player and then switch again to that tree(so player will be behind it), If I don't the player will be standing on a tree. In worst cases I suppose I'll need to do this 10-20 times.

You should at most be switching textures twice per frame, once for the tree and once for the player. Where are you getting 10 - 20 times from?? Like I said, put all your textures in the same sheet to reduce texture switch calls. But really, it should not matter unless your spritesheets are huge.

That's even worse to have rocks and little terrain features on a separate spritesheet.

I'll say it for the third and final time, put everything on one big sheet because its silly to not to. That's the only advice qnyone can give you because that's the only thing you can do in this situation besides not doing it.

Imagine this situation:-you draw background terrain from spritesheet1-you draw player from player spritesheet2-you now need to draw some more stuff on top of player from spritesheet1-you now need to draw something from spritesheet2

I still don't think 10-20 textures changes would make your game slow.. Think about other games. Take league of legends for example - 10 champions. Each champion has his own texture. That is 10 texture changes per frame AT LEAST. Than every skill and effect has it own texture as well. There might be 50 or something like that effects on the screen at the same time. Unless you put stuff into 1 giant spritesheet while loading everything, you will have to do at least 100 texture change / frame. I still don't think that would cause any performance problems. Remember - OpenGL is a state machine. It is supposed to be changed a lot. It is the "performance is the key" people who talk a lot about how you should be using it while they never actually done anything bigger than a simple test level.

trollwarrior1Exactly!Thanks for your answer.One texture for all terrain and one for characters.Anyway, it may be tricky but I think it is possible to code algorithm to render terrain with gaps for characters, then render all characters and then finish rendering terrain, only with two texture swaps.But as you said may be it is even not necessary. If I meet performance issues then I'll think about optimization.

trollwarrior1Exactly!Thanks for your answer.One texture for all terrain and one for characters.Anyway, it may be tricky but I think it is possible to code algorithm to render terrain with gaps for characters, then render all characters and then finish rendering terrain, only with two texture swaps.But as you said may be it is even not necessary. If I meet performance issues then I'll think about optimization.

Guys thanks for answers!

There isn't any algorithm really. I can describe the way I did it.

-I have a screen class, which has render function, such as render(int x, int y, Texture texture, int layer);-When I want to render something (player, tree, wall, tile - anything) I call that method in my screen class.-In my screen class I have a list of render components or something. It is basically a class which has data of stuff I want to render. For example, following the method I wrote render(int x, int y, Texture texture, int layer);my render component class would be something like this:

When I call the render method in my screen class, I add a new component to my list.-At the end of the frame, you would sort that list by "layer" value. For example, layer 8 would be the furthest layer, which would mean you need to put components with layer 8 to the front of the list, which would mean they are being rendered first, and appear in the background.-Once you sorted your list, just go through it and actually render everything that it has.-Clear the list and you're set for the next frame!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org