   Platformer - map[100][1000] too much?
  Edit: in my next post you can see that I actually changed 2500 to 1000 since 2500 appeared to be a bit too big.Hello everyone! ;]Wow, I haven't been on here for so long!I've come with a rather beginner question since I'm still widely exploring the possibilities and limits for game development.Right now I'm using SDL and am working on a Platformer.My maps exist of separate arrays, map[100][100] and collission[100][100], but after creating the map editor I found that [100][100] is actually too small. It would only be about 5 screens in width. While in height it's perfect, in width it is not.So I was wondering if it would be too much to make the map [2500][100], that way the level width is 32*2500 instead of the previous 32*100. (32 being the tile size in width and height.)I know 2500 sounds a lot bigger than 100, but it seems to be more than fit for the long levels I'll be making, only if it's possible though- which is why I'm here. ;]Please let me know if this is too crazy and what I could do best.And I've read that I could've also made a tile class which holds properties like 'destroyable', 'solid'/etc, but since I'm this far into the project already- and it's gonna be a quite simple one I decided to move on with what I already had, which is an array (with the same width and height as the map) which holds the data for solid blocks. (+ the fact that I don't have THAT much experience in game development so it'd be something I'm gonna try for my next project.)---Edit:Hm, now I think about it, 2500 may actually be big, but then I'm wondering. How would a platformer pull off long levels? I'll take any information I can get.I was told 2500 would be just fine, but he's quite a..beginner himself too, so I thought I'd come ask here. ;][Edited by - Auriya on April 13, 2010 3:34:48 PM]
  It depends how much memory you can use, how do you store your tiles, etc etc. For example, if you have a 5000x5000 map, where each tile takes 2 bytes, you have almost 48MB of map data in RAM. This is a lot of tiles, but also depends how big is your tile (16x16, 64x64, etc). You need to think around those things   ;  Hey!Well, I've just checked out how big 2500 would be, and it indeed looked quite big, but after having tried out map[1000][100] it was perfect.The tile size is 32x32, so now the map will be about 32000x3200, which in the game resolution (800x640 - windowed) is a good 40 game-screens in width.Trying again.. 100*1000 being 100,000, that * 2 is 200,000 in bytes, which is a rough 200kb..?And the tiles are stored in a single surface, then the integers that represent that tile are pulled from the file map.dat which contains the whole map's integers with spaces in between each integer.This is the example test tileset I'm using right now;http://bluemelody.info/skitch/wind_tileset_testroom-20100413-230340.pngAnd the map: http://bluemelody.info/skitch/map.txt(I'm guessing that showing is the quickest and most clear way rather than trying to explain in the finest details which I'm not very good at. ;p )Anyway I'll change the title of the topic too to reflect the change.Thanks for the quick reply! ;]   ;  Just retrieve the level size from the file and allocate sufficient memory at run-time. That way, you can change the size of your levels without having to recompile. This also allows you to give each level the dimension that works best for it, without having to worry about some arbitrary upper bound.You may want to read up on C++'s standard library - std::vector would be useful here.   ;  You can make a seamless world too. Load only the tiles around the player, and load other tiles as he is moving.   ;  Maybe you should try to allocate the map memory on the heap insted, using a "new" operator.int map*;map = new int[1000*100];//access map dataint x = 22;int y = 56;DrawMap( map[y*1000 + x] );   ;  Hello!Wow, so many information, thank you very much!I will look into them and see how it goes.I will definitely read up on std::vector as I used it many times before without actually completely understanding it..The game already only draws whatever is around the player ;]Thank you for the quick replies everyone, I really I love this place, it's full of knowledge! ;D   ;  For larger maps you want to use some kind of spatial partitioning; a quadtree is perfect for 2 dimensional stuff. You start out with one large rectangle representing any dimensions you feel like (could be 1,000,000 squared if you want) but that rectangle is divided into 4 smaller rectangles. Each of those is divided into another 4 rectangles, etc, etc. This continues until you get down to a nicely sized map.With this system, you have a larger number of small maps (you choose the size, but lets say 100x100 for the sake of argument) for the "leaf nodes" of your quadtree. You then use a recursive algorithm to decide which maps to draw based on what is in view of the player at that time. If each leaf node is just a big list of squares, all with a single texture, this system can be blindingly fast on modern hardware. There are of course more sophisticated systems, but the quadtree is a good starting point.   