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 a 2d int array which represents tiles on level like this:

0000000000000000000000
0000000000000000000000
0000000000000000000000
1111111111111111111111

I have a tileset vector, where each element has it's own tileX and tileY value(position of a tile in a tileset image), collision data etc. So, when I draw a level each time I draw a tile, I ask about them like this:

draw(tileset[currentTile]->tx, tileset[currentTile]->tY, tileWidth, tileHeight);

But, as you can see, there will be lots of the same elements when I iterate through for loop, so do I need to keep lastCollisionData variable in level class to reduce time used to access each tile separately?

share|improve this question
1  
I'm not sure what you're asking about. Are you wondering about run length encoding your tile data? Or sharing a pointer to similar tile data if said tile data takes up a lot of memory? Or something else? –  michael.bartnett Feb 20 '13 at 15:18
    
I can't use lenght encoding, because I'm not really sure data will always stay the same way. I'm just wondering if storing last value will be faster than accessing vector –  winch Feb 20 '13 at 16:29
1  
It's not clear exactly what you'd be caching, because you've not told us what 'lastCollisionData' means or what it's used for, or why caching a previous value will help. –  Kylotan Feb 20 '13 at 16:38
    
Well, every tile has it's own collision property. It's just an int. (0 - solid, 1 -walkable, for example). So instead of trying to find those values using tiles id, I can just compare id and if it was the same as now, that I don't need to search in vector –  winch Feb 20 '13 at 17:38
    
Ok, are you trying to say that each position in your level tiles does not have collision data, but that each tile type does? And that you don't want to have to look up the properties of the tile type each time? If so, then no - that's a premature optimisation. –  Kylotan Feb 20 '13 at 22:10
show 1 more comment

1 Answer 1

Depending on how many times you need to traverse the list, as well as how big it will be in the long run, using something such as run length encoding could be valuable, but you have to consider the time required to encode the tiles each time there is a change to it. This is a situation where the trade off of more time spent up front, could increase performance during actual usage. If the performance hit is insignificant though, then it may not be necessary at all.

edit run length encoding is a process for identifying multiple values of the same time within a single run. For instance, rather than representing 00000000 as so, it could be represented as 80, where 8 represents the number, and 0 the value. Of course this takes time up front to perform the encoding, and may not save you time depending on how you are using the data.

http://en.wikipedia.org/wiki/Run-length_encoding

share|improve this answer
    
Well, drawing is 60 frames per second and there are like 50-60 tiles on the screen on the moment, so I need to access elements of vector for 60 * 2 times(to get tx, ty) per frame –  winch Feb 20 '13 at 16:32
    
The amount of effort necessary to traverse the list and get position information isn't significant. I would say unless you are seeing legitimate performance issues from this specific process, it isn't worth stressing over. –  Evan Feb 20 '13 at 16:57
    
Thanks, I'm just beginning to make my game and worry about everything because there will be a lot more stuff on the screen so I won't really know what causes perfomance issues –  winch Feb 20 '13 at 17:26
1  
@winch keep measuring performance of it and you'll know how your changes effect your performance as you add them. –  Rangoric Feb 20 '13 at 21:35
add comment

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.