Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (529)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Sprites and Tiles  (Read 1599 times)
0 Members and 1 Guest are viewing this topic.
Offline MrKnyaz

Junior Newbie





« Posted 2013-12-10 06:43:40 »

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 situation

We 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?
Offline bilznatch

Senior Member


Medals: 8
Projects: 2
Exp: 1 year


I'm bad, I'm bad, I'm really... really bad T_T


« Reply #1 - Posted 2013-12-10 07:41:30 »

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.
Offline MrKnyaz

Junior Newbie





« Reply #2 - Posted 2013-12-10 07:51:07 »

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?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline opiop65

JGO Kernel


Medals: 153
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #3 - Posted 2013-12-10 11:53:18 »

You can't bind both.

Can I ask why you don't just have one large spritesheet?

Offline MrKnyaz

Junior Newbie





« Reply #4 - Posted 2013-12-10 16:52:00 »

You can't bind both.

Can I ask why you don't just have one large spritesheet?

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?
Offline bilznatch

Senior Member


Medals: 8
Projects: 2
Exp: 1 year


I'm bad, I'm bad, I'm really... really bad T_T


« Reply #5 - Posted 2013-12-11 00:08:28 »

Why would you need to change the texture 10-20 times per frame?
Offline opiop65

JGO Kernel


Medals: 153
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #6 - Posted 2013-12-11 00:25:08 »

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.

Offline MrKnyaz

Junior Newbie





« Reply #7 - Posted 2013-12-11 05:06:11 »

Why would you need to change the texture 10-20 times per frame?

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.
Offline bilznatch

Senior Member


Medals: 8
Projects: 2
Exp: 1 year


I'm bad, I'm bad, I'm really... really bad T_T


« Reply #8 - Posted 2013-12-11 05:21:32 »

That's the sort of situation where you put the tree on the same spritesheet as the player. It's a single sprite, so it's easy to put on the sprite sheet.
Offline opiop65

JGO Kernel


Medals: 153
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #9 - Posted 2013-12-11 05:24:06 »

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline MrKnyaz

Junior Newbie





« Reply #10 - Posted 2013-12-11 10:58:03 »

bliznatch,
tree is an example, it may be any object, tree, rock, house, wall etc all these object belong to terrain and are on another tileset.

opiop65,
10-20 times are from characters on the screen, some characters must be behind objects, some in front. For example Townsmen game, or any other strategy game, there are may be many units.

Offline opiop65

JGO Kernel


Medals: 153
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #11 - Posted 2013-12-11 12:23:53 »

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.

Offline trollwarrior1
« Reply #12 - Posted 2013-12-11 13:47:08 »

I don't think people understand what he is asking..

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.
Offline MrKnyaz

Junior Newbie





« Reply #13 - Posted 2013-12-11 16:33:12 »

trollwarrior1
Exactly!
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!
Offline trollwarrior1
« Reply #14 - Posted 2013-12-12 12:32:11 »

trollwarrior1
Exactly!
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:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
public class RenderComponent {
   
   public int x, y, layer;
   public Texture texture;
   
   public RenderComponent(int x, int y, Texture texture, int layer) {
      this.x = x;
      this.y = y;
      this.texture = texture;
      this.layer = layer;
   }
}

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!
Offline MrKnyaz

Junior Newbie





« Reply #15 - Posted 2013-12-12 19:20:37 »

By algorithm I meant to invent it myself. Thanks for your method:)
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

ctomni231 (31 views)
2014-07-18 06:55:21

Zero Volt (27 views)
2014-07-17 23:47:54

danieldean (23 views)
2014-07-17 23:41:23

MustardPeter (24 views)
2014-07-16 23:30:00

Cero (39 views)
2014-07-16 00:42:17

Riven (41 views)
2014-07-14 18:02:53

OpenGLShaders (28 views)
2014-07-14 16:23:47

Riven (28 views)
2014-07-14 11:51:35

quew8 (25 views)
2014-07-13 13:57:52

SHC (61 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!