Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (495)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
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  
  2D Sprite draw order issue (image attached)  (Read 1388 times)
0 Members and 1 Guest are viewing this topic.
Offline pixelprime

Junior Member


Medals: 3



« Posted 2013-07-23 06:56:09 »

Hey guys n' gals,

I have a query relating to the ordering of sprites in a 2D tile-based scene.

Within the 'active viewport', I have something in the region of 14 x 8 tiles visible. This tile map consists of a number of overlaid elements.

First, there's the floor tiles - which get rendered first starting from the top-left, working row-by-row until it reaches the bottom-right of the viewport.

Second, I render the wall objects using the same draw method as above.

However, when it comes to active sprites, I'm a bit flummoxed as to how I order them with the correct depth without having to make lots of unnecessary texture bind switches.

Here's a quick n' dirty visualisation of what I mean:



Sprites need to be able to overlap each other on the 'z' plane (bottom to top), but it seems like the only way to do this is to check every sprite each time I draw a tile to find out if it should be at that exact depth. With potentially many sprites visible on the screen at one time - wouldn't this be tremendously slow? I'm sure I'm thinking about this wrong.

Any advice would be most appreciated. Thanks!
Offline jonjava
« Reply #1 - Posted 2013-07-23 12:50:14 »

It's not necessarily slow. But since CPU is much more expensive than memory these days you can do optimizations in various ways (i.e, sacrifice memory for more free cpu time).

3D games use a z-buffer (also called depth-buffer) for this. This means that they store the depth of every single pixel on the screen and each time they render a pixel they check to see if that pixel is behind the one already stored in the z-buffer, and if it is they skip it, otherwise they draw the pixel on the screen and save its depth in the z-buffer.

Or you can sort the sprites based on their depth each time you render or when a sprite has moved. In tile based movement games (where sprites seems to move around but they actually only change position (depth) every they move from or to a tile and NOT while they are transitioning from one tile to another) you can have the sprites already sorted and then cherry pick remove/add (with binary search) the sprite that is changing position.

I've used all 3 of these in my games at some point and to be honest I don't think I needed the optimizations and could have just sorted all the visible sprites each render (which is probably the most cpu intensive method but easiest to implement). So I suggest you try that first and optimize later if need be or if you're unhappy of how much cpu it is hogging.

Oh and I know this is obvious but in your game it seems like the sprites lowest down have the least depth so [z = -y] (This also means you'd only need to sort the sprites when their y-value has changed and you can ignore the x-value). In 3D games they set z to the distance to the camera and in isometric games it's usually a variation of [z = -(x + y)]


PS:
Here's a post where I made a while ago about sorting lists and binary search to achive depth in the game (here I ended up using the cherry picking method): http://www.java-gaming.org/topics/sorted-list/24888/msg/212173/view.html

Offline pixelprime

Junior Member


Medals: 3



« Reply #2 - Posted 2013-07-23 19:13:39 »

Many thanks for your detailed and informative reply. I'll take a look at your other post as well, but I'm most likely going to implement a worst-case scenario first to see what the performance is like.

Thanks again!
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.

Dwinin (28 views)
2014-09-12 09:08:26

Norakomi (57 views)
2014-09-10 13:57:51

TehJavaDev (74 views)
2014-09-10 06:39:09

Tekkerue (38 views)
2014-09-09 02:24:56

mitcheeb (57 views)
2014-09-08 06:06:29

BurntPizza (45 views)
2014-09-07 01:13:42

Longarmx (28 views)
2014-09-07 01:12:14

Longarmx (34 views)
2014-09-07 01:11:22

Longarmx (34 views)
2014-09-07 01:10:19

mitcheeb (40 views)
2014-09-04 23:08:59
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!