Sign in to follow this  

map question for SDL side scroller

This topic is 4377 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was under the impression that the 'map' would be more of a really big BMP that you would only show portions of when the character was in that section, but the more tutorials im looking at, it seems the better way to do it is to create 'tiles' of the map, and place them on the screen accordingly in a large array of tiles. could anyone help clarify this for me. thank you.

Share this post


Link to post
Share on other sites
i suppose either would work, if you wanted to do a huge side scrolling BMP then goto http://lazyfooproductions.com/SDL_tutorials/lesson19/index.php

good tutorials...

if you wanna do a tiling one good luck because im trying to and no one can really answer my questions lol

Share this post


Link to post
Share on other sites
I would do the tiles way, but that is just me. To me, the tiles way seems like it would be faster, and better on performance, instead of loading a HUGE image as the background.



Chad.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
lol a huge bitmap wont be a problem unless your running on a intel pentium1 processor with 64 MB of ram. then you might pose a problem.

Share this post


Link to post
Share on other sites
Yep it seems the most popular way is using a bunch of small tiles, this way it makes it easier to customize the maps and re-make them...like you have a tile for trees...a tile for grass.etc.. It also helps with making background objects and foreground object (like if the player wants to walk behind something).

The standard way of doing it is greating a huge multi-dimensional array..like

const int X = 25;
conts int Y = 25;

int map[X][Y];

then everytime the player takes a step, redraw the map according to where they are

so a 5x5 map would look something similar to this


map[0][0] map[1][0] map[2][0] map[3][0] map[4][0]

map[0][1] map[1][1] map[2][1] map[3][1] map[4][1]

map[0][2] map[1][2] map[2][2] map[3][2] map[4][2]

map[0][3] map[1][3] map[2][3] map[3][3] map[4][3]

map[0][4] map[1][4] map[2][4] map[3][4] map[4][4]


where every element of the array *(map[x][y]) represents a tile.

If you already knew all the sorry for the explination, hope that helps ya out
ArchG

Share this post


Link to post
Share on other sites
theres some different philosophies about maps.

In a SDL scroller that I've been porting to plain OGL, Super Maryo Chronicles, the map is a collection of objects, no tiles, though they do behave somewhat like tiles. The difference is theres more freedom of where to put them, whereas tiles have to be placed consistently. They treat every "tile" as a sprite, and half maybe a repeating background picture behind it to make it look nicer.

I find it's a pretty good method, actually.

Next is of course the traditional tile system, with 1 or more layers of tiles drawn at certain intervals. This way is probably a bit faster in some cases, because if you have a really big object that needs to be drawn, and only a part of it is on visible on the screen, in the former method, you must draw the entire object, whereas in this you need only draw the tiles that are on or partially on the screen.

I think though, that the best method for a 2D scroller is a mix of both. That way, you can get the functionality of the right one for the right job at different parts of your program. Large images can be chopped into tiles to improve performance, but key objects in the game world can be map sprites to allow freedom of where to place them.

Share this post


Link to post
Share on other sites
Quote:

In a SDL scroller that I've been porting to plain OGL, Super Maryo Chronicles, the map is a collection of objects, no tiles, though they do behave somewhat like tiles. The difference is theres more freedom of where to put them, whereas tiles have to be placed consistently. They treat every "tile" as a sprite, and half maybe a repeating background picture behind it to make it look nicer.


I've actually been considering trying a method like this.

Is it difficult to perform collision detection between the player and the tiles? Since they're objects wouldn't you have to iterate through all of the tiles to check for collisions? Or is there some other way that collisions are checked?

Just curious because I might try to apply something like this in my current side scroller.

Share this post


Link to post
Share on other sites
You'd definitely want a tilemap over a big bitmap. It's way more flexible. All you can really do with a big bitmap is blit parts of it.

I wrote a side scroller on the showcase - I used a tile map, but its tiles actually correspond to models which are rendered using OpenGL. Some tiles are flat, but others contain a model, like a wall section or turret.

Mark

Share this post


Link to post
Share on other sites
What is done for collisions with the map sprites is,

there are different categories of sprites in their game. Massive, half massive, passive, and enemy (i think). Collision is done against massive, half massive, and enemies, and has its own collision type. you could do this for tiles too if you just treat the tiles like sprites, so it's more or less the same level of complexity. When you're doing collision testing for the map, like to see if a position is valid, just skip non-map objects when going through all the objects on screen, or an even faster way would be to put map objects in their own array, and only perform collisions through that array ( so you don't even have to skip non-map objects, just ones that are off screen).

O_O.. mind you Im still kind of struggling to organize an efficient system for this myself.... Uhh, they said not to recruit for my team in this forum... but if you want to collaborate on my 2D game engine (which relates to this of course, and you're the same level programmer that I'm looking for), you should PM me! probably be able to implement stuff from it into your own game too.

Share this post


Link to post
Share on other sites
tiles are fun and useful,
but perhaps outdated.

note the winners of the 4e4 with their awesome graphics (P<3N) had a side scroller without tiles.

also note that even though they used low resolution, on my machine with 128Mb it had problems running smoothly. (but they have plenty of other memory wasters besides the background graphics).


Iftah.

Share this post


Link to post
Share on other sites
Which brings me to somethinig else, when using textures in OpenGL for tiles, make sure they're powers of 2 or it runs SLOWWWWWWWWWWWWWWWWWWWWWWWWWWWWW. not cool :(

Share this post


Link to post
Share on other sites
I'm trying a fairly efficient map system it works as follows.



Tile-------------------------->Zone------------------>Map
(name) (loads and draws the (loads and draws Zones)
(GLuint) tiles and makes sure
(height width) there is never more
( X and Y) then one of the same
texture in list at one
time)

The zones perform a test on which tiles are on the screen and only draws those (hard to do with a huge image) and the map decides which zones are active to conserve RAM. This way you never have more then 4 active zones, the zones are linked together and sort of act like huge tiles of their own. This can give you a seamless world especially because you can have the last node on the right point to the first node on the left and BAM after you go right for a while your right back where you started =). I sappose with increasing RAM and overal storage on the computer tiles could go obsolete but im sticking with them for right now.

EDIT: I think that Tiles are not near as nessisary for side scrolling games as they are for massive games like RPG's. If you make 1 tile you can reuse it as many times as you like under a tile system but with larger images every time you want to use a picture of grass it costs more memory because it makes the picture bigger. Big pictures are good for games that are only using back gound or want to have alot of detail in their game (and are prepared to take a RAM and total storage cost hit). Otherwise tiles

Share this post


Link to post
Share on other sites
I don't think the advantage of using tiles is necessarily to save storage on large images. if there is a large image, and you want to draw it in tiles, you'll have to make different tiles for different parts of the larger image. Some console platforms are optimized to draw things in blocks of data (like a 16x16 pixel sprite on the sega genesis), and so for speed reasons, theres no other choice but to do this, but 4 16x16 pixel images is still the same ammount of space in memory as a 64x64 pixel image. tiles only REALLY optimize space when you aren't using a lot of unique large images. When you want to save memory, think about how many PIXELS are in memory, not how many pictures. :O.

Now, think about this. Using tiles, the number of Objects in memory (at least one for every tile) is much greater than if you were to use sprite objects instead. When doing collisions, you'd need to process every single tile on screen, whereas with sprite objects you may only need to process two or three for collisions. This is definitely a speed advantage.

I don't want to take sides between which is better, A) because at this point in time the problems presented are almost a none issue on current day PCs, and B) because I prefer to combine the two as I said before :X

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
lol a huge bitmap wont be a problem unless your running on a intel pentium1 processor with 64 MB of ram. then you might pose a problem.



See? My grandmother couldn't play it then. lol. She has the worst computer ever made! lol.



But yes, just do the tiles way. to me, it might even be easier. I don't know. lol. Ever since I figured out how to do tile maps, I have been in love with them. lol. It is also, and easy way to edit the leval.




Chad.

Share this post


Link to post
Share on other sites
Quote:
Now, think about this. Using tiles, the number of Objects in memory (at least one for every tile) is much greater than if you were to use sprite objects instead. When doing collisions, you'd need to process every single tile on screen, whereas with sprite objects you may only need to process two or three for collisions. This is definitely a speed advantage.


Not necessarily. If you are representing the tilemap as a multi-dimensional integer array, than it is actually faster to check collision.

Think about it, this is how you get a particular tile from an array:
tiles[y/TILE_SIZE][x/TILE_SIZE]

which means you can access a tile directly with an array, whereas with a list of sprite objects, you would have to iterate through the list checking for collisions.

Although that may really depend on how you write the collision system, I'm just stating this from my expierence using a tile system.

Share this post


Link to post
Share on other sites
I dont mean that, I'm just saying that with tiles, there will ALWAYS be more objects to process than without... Like, 16x16 or 32x32 or whatever tiles on the screen, ALL the time. for 16x16 tiles on screen, thats an extra 256 objects to cycle through every frame. They may not all require collision or nothin, and so the overall effect may be next to nothing, but on a low end machine it may be something to consider. Like I said though, the reality is that most of the problems faced with tile engines are no longer applicable to anything remotely resembling modern hardware. Games easily process way more polygons per second than in some cases the contents of an entire 16 bit game cartridge. So, the point is kind of moot unless you're really intent on targeting ancient hardware.

Share this post


Link to post
Share on other sites
Quote:
Original post by AAAP
I dont mean that, I'm just saying that with tiles, there will ALWAYS be more objects to process than without... Like, 16x16 or 32x32 or whatever tiles on the screen, ALL the time. for 16x16 tiles on screen, thats an extra 256 objects to cycle through every frame. They may not all require collision or nothin, and so the overall effect may be next to nothing, but on a low end machine it may be something to consider. Like I said though, the reality is that most of the problems faced with tile engines are no longer applicable to anything remotely resembling modern hardware. Games easily process way more polygons per second than in some cases the contents of an entire 16 bit game cartridge. So, the point is kind of moot unless you're really intent on targeting ancient hardware.


That is true. It's like I said before and you said here, it doesn't matter whether you use objects or just tiles, the speed should be fast enough.

Share this post


Link to post
Share on other sites

This topic is 4377 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this