Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I have an Array of tiles in no particular order. How would I do a isometric back to front rendering on it? Do I HAVE to order it?

share|improve this question

2 Answers 2

up vote 1 down vote accepted

From your comments it seems that you are trying to handle chunks all at once when at any 1 time at most you would only need to handle 8.

PPP
PCP
PPP

Where C is the current chunk you are on and P is pre-loaded. Now when the user moves into one of the preloaded chunks you generate/reload the chunks the player is heading towards and write the chunks that are now out of range. By using this method your have pretty much unlimited size (I use the term loosely as there is always a hard drive capacity).

This could be expanded to have a varying pre-load range or maybe pre-loading multiple chunks at once.

Here is a step-by-step example of a implementation:

  1. On game creation create chunks

    (-1,1),(0,1),(1,1)

    (-1,0),(0,0),(1,0)

    (-1,-1),(0,-1),(1,-1)

  2. as the user moves into chunk (0,1) from (0,0) we then store chunks (-1,-1), (0,-1), (1,-1) as files and then generate (-1,2),(0,2),(1,2).

this would go on and on but you get the idea you ensure you only keep a set number of chunks in memory and load/unload the others.

Hope this helps

share|improve this answer
    
Nice idea but Im not gonna load and unload files every time the player moves, will cause bad performance issues. I'll figure it out, Thanks –  Trixmix Aug 30 '12 at 23:04
1  
@Trixmix There is a well known game that uses an expanded version of this very method Minecraft, and it has 17x17x255 per chunk and doesn't show any issues there. –  AbstractChaos Aug 30 '12 at 23:24
1  
correction minecraft stores the chunks in 32x32 groups –  AbstractChaos Aug 30 '12 at 23:35
    
Ill try it thanks but what kind of data structure would I use? –  Trixmix Aug 30 '12 at 23:59
1  
well with the basic example i provided you could have a file per chunk and then name them chunk_x_y where x and y are your coords this would work with minecraft's approach to by saying region_0_0 contains 32x32 chunks (not all may be generated and present in the file but when it is written it is put here) from (0,0 to 32,32) or (-16,-16 to 16,16), so long as you parse the information in and out in a way you define it dont matter the data structure. I cant give you a possible data structure as I only know your using chunks. –  AbstractChaos Aug 31 '12 at 9:51

Depends on what your tiles are.

If they are the tiles from your map (fixed objects or terrain elements) they should already be ordered in a 2D grid. In this case, just run through your array in a defined scheme depending on the orientation of your grid.

If you refer to a bunch of random floating sprites, you will have to sort them. But it might not be that expensive; keep a sorted array of the visible sprites, and simply add or remove sprites as they become visible/invisible. Re-insert sprites that have moved, perform the re-insertion from their current position in the sorted array.

share|improve this answer
1  
Well the real deal is like this: I have chunks they are stored in a 2D array. When ever you generate a chunk it adds it like to an array list. and the chunk could be generated in 4 different directions meaning it will not always be in order. Wont sorting them will be a huge performance loss? I mean the max numbers of chunks now is 10000 getting to some thing that high would be crazy to sort an array like that... –  Trixmix Aug 30 '12 at 22:05
    
Why exactly are you trying to sort them back to front? If it's only for rendering purposes, you just have to maintain a sorted array of the visible tiles, which might not be too much. –  Yno Aug 30 '12 at 22:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.