Jump to content

  • Log In with Google      Sign In   
  • Create Account


Side scrolling Tile map woes


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 dsm1891   Members   -  Reputation: 840

Like
0Likes
Like

Posted 15 August 2013 - 02:14 PM

Hello all,

 

I am having a little trouble with my side scrolling tile map, at the moment. At the moment I scroll (when I need to) by moving the map left or right (seen as tileofsetX/Y later on) when I need to. There are various culling methods to make sure I only move the ones that can be seen (mapofsetX/Y again, for later on).

 

so here is my trouble, at the moment all of tiles are pointers, fair enough right?, However, there was a slight problem with this, I would have to initialise each tile separately (Load the texture, set the sprite, etc). As the map the map can have a lot of tiles on it, initialising each tile takes a big toll on the computer - takes 10+ seconds to open a 50x50 map.  

 

I managed a work around by referencing a pre-existing tile: 

void Room::init(Graphics *g){
	roomSizeX=30;
	roomSizeY=30;
	normtile.init(g);
	othertile.init(g);
	for (UINT i = 0; i < roomSizeY; i++)
	{
		for (UINT j = 0; j < roomSizeX; j++)
		{
			if(i==0||i==roomSizeX-1||j==roomSizeY-1||j==0 || j%5==0)
			roomMap[j][i] = &othertile;
			else
			roomMap[j][i] = &normtile;
			roomMap[j][i]->setXLocation(j*64);
			roomMap[j][i]->setYLocation(i*64);
		}
	}
}

However I do need to constantly set the position of each tile. Which works however, I'm not sure how, surely I would get some flickering?

 

ingame class:

void GuiIngame::draw(){
//			 Start draw		    end draw				  Check if drawing map
	for (int i =camera.top; i <camera.bottom && i < levelMap[0][0]->getRoomSizeY(); i++)
	{
		for (int j = camera.left; j <camera.right && j < levelMap[0][0]->getRoomSizeX(); j++)
		{
			levelMap[0][0]->getTile(j,i)->setXLocation((int) ((j*(TILE_SIZE * scale))-(mapOfsetX*(TILE_SIZE * scale))-tileOfsetX) );
			levelMap[0][0]->getTile(j,i)->setYLocation((int)((i*((TILE_SIZE) * scale))-(mapOfsetY*((TILE_SIZE) * scale))-tileOfsetY));
			levelMap[0][0]->getTile(j,i)->getTileImage().draw();

		}
	}
}

However, I can not 'effectively' test for collisions with this basis, as the levelMap[0][0]->getTile(0,0)->getX/Y() Returns the last Tile's value for every tile.

 

If I made the tiles 'regular old objects' I would not be able to scroll the map, as it would just move the 'copied object - tile'.

 

Any help/advice would be appreciated.

 

Thanks



Sponsor:

#2 BeerNutts   Crossbones+   -  Reputation: 2756

Like
0Likes
Like

Posted 15 August 2013 - 03:07 PM

My guess is, the reason it takes so long to setup your map is you loading the same image for multiple tiles.  What you should do is, if the image for the tile hasn't been loaded, then load the image, otherwise, simply use a reference to the pre-loaded image.  There is no reason initializing 50x50 tileset should take 10 seconds if you're only loading data in.

 

So, to do this properly, you should have an image manager that take the image to load, and returns a pointer to the image to use;  internally, it only loads the image if it hasn't been loaded yet.

 

Good luck.


My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)

#3 markr   Crossbones+   -  Reputation: 1653

Like
0Likes
Like

Posted 15 August 2013 - 03:30 PM

I think you're possibly making the mistake of moving the world instead of the viewport.

 

There should be no reason for a tile to change its position when the viewport moves. Instead the renderer can work it out, when (and if) it comes to render the tile.

 

See http://marksverbiage.blogspot.co.uk/2012/04/move-viewport-not-world.html



#4 dsm1891   Members   -  Reputation: 840

Like
0Likes
Like

Posted 15 August 2013 - 04:49 PM

I think you're possibly making the mistake of moving the world instead of the viewport.

 

There should be no reason for a tile to change its position when the viewport moves. Instead the renderer can work it out, when (and if) it comes to render the tile.

 

See http://marksverbiage.blogspot.co.uk/2012/04/move-viewport-not-world.html

hey, thanks for the reply.

 

I gathered that you are not suppose to 'move the world'. How ever, from the book(s) I learnt /based it on, never really did that :/. At the moment, yes, I do move the world, but only the ones you are viewing. 



#5 dsm1891   Members   -  Reputation: 840

Like
0Likes
Like

Posted 15 August 2013 - 04:51 PM

My guess is, the reason it takes so long to setup your map is you loading the same image for multiple tiles.  What you should do is, if the image for the tile hasn't been loaded, then load the image, otherwise, simply use a reference to the pre-loaded image.  There is no reason initializing 50x50 tileset should take 10 seconds if you're only loading data in.

 

So, to do this properly, you should have an image manager that take the image to load, and returns a pointer to the image to use;  internally, it only loads the image if it hasn't been loaded yet.

 

Good luck.

hi,

 

Thanks for the reply. I'll have a think about this :).



#6 Endurion   Crossbones+   -  Reputation: 3402

Like
1Likes
Like

Posted 15 August 2013 - 11:54 PM

You are making the mistake of having a tile based layout but not taking advantage of that at all.

 

Tile instances for every tile are mostly overkill.

 

Can't you simply load all used images into a container and have the world consist of indices into that? (And thusly reducing the map to a 2d array of bytes or ints)

Also, tiles don't really need coordinates by themselves (unless you want tiles unlocked from the grid).

 

The tile position can easily deduced by it's array indices, as you already do with the setlocation call.


Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS