# Tile Based - "Correct way"

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

## Recommended Posts

Im making a top down view 2d tile game, i draw the entire map image to a buffered image, now when the user uses the arrow keys i simply redraw the map croping it differently. Is this the correct way of doing this is a game? I dont have any experience in game programming and i cant see into the future and see problems i might have atm. Is it ok doing wat i am currently doing, or to make things easier in the long run should i change my method to another method lyk: Giving the player a position in the map array, then redrawing the entire map and player to the buffered image and showing that. Cheers, Nick

##### Share on other sites
I don't see any problems with your way, as long as you divide a large map into chunks. Then, just don't let the, "camera" go past them and when the player goes off screen, load the new map.

##### Share on other sites
The way im currently doing it the player never actually leaves the middle of the screen, is that ok?

And also the reason i was asking the first question is because ive started thinking about collision detection, and im just wondering if the way i do it will work still? its much easier putting the user in the 2d array for the map, then u can see if they are going to walk into lyk a wall of sumtin.

##### Share on other sites
Ok, couple of points. Firstly, I'm not sure you want to be drawing the entire map as that almost defeats the purpose of using a tile-based system. The idea being that the map is broken down into managable chunks so you only need to be checking and drawing those around immediately around you (within the camera view). Bare in mind, if you know your camera location and you know how many tiles fit on the screen you can determine which tiles you should be drawing at any frame.

Secondly, you'd never need the player inside your array of tiles. When it comes to collision detection you will want to query individual tiles but that can be done without physically placing a player in with them. So let's say you wanted a collision check for the left side of your player (assuming this is a top-down view - the theory still applies to side-on though)

1. Determine the world coordinates of the players left side. This would probably be
// determine world position of players left sideplayer_location_x - player_width/2

Obviously your variable names will be different.

2. Determine which tile that point is inside.
// determine which tile players left edge is inside/overplayer_leftside/tile_width// take note: that would only determine which collumn the left side is in.// you'd need another check with the player center to detemrine the y value

3. Act appropriately. If the tile is solid, push them back to a point where they are no longer colliding.

As for the player never leaving the center of the screen that isn't a problem. Given time you could add some smoothing to the camera but for now just keep it functional. Hopefully your camera is contained within a class so you can easily update it's behaviour without too much hassle.

Anyway, that's the basic gist of the process so I hope it helps.

##### Share on other sites
The reason i and drawing the map the way i am is because i only need to draw the 2d array to the buffered image once (at program start), from then on i just draw a crop of that image to the bufferedStratergy. Is this still incorrect or not as efficient?

##### Share on other sites
If this is DirectDraw7 or GDI then prepare for counter-intuition.

Blitting one screensized subrectangle from a very large surface (many times the screen size) is usualy a lot slower than blitting many smaller rectangles stored in seperate small surfaces.

The idea here is that the very large surface cannot be (or is not in the case of GDI) stored in video memory yet the driver is designed to let the hardware perform all actions involved in the blit. Thus the entire large surface is shuttled through the agp/pci bus every time you blit even though you only wish to blit a small portion of it.

##### Share on other sites
Ok, well the main reason im drawing the complete map to buffered image then drawing a crop of that is because i think it is the easiest way to draw my bullets, it draws them to the map so that if i move it still goes to that position on the map, not that position on the screen? I draw a bullet to the map at the user x + cropX and y + crop Y, and it destination is x + cropX and y + cropY.

You get wat im saying?

EG:

FULL MAP

|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||....................C......................................................||||....................C......................................................||||............1....0..C....................0.................................||||....................C......................................................||||....................C......................................................||||C.C.C.C.C.C.C.C.C.C.C..........................0...........................||||...........................................................................||||...........................................................................||||...........................................................................||||...........................................................................||||...........................................................................|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

. Is grass
1 is the player
0 is a bullet
C is the cropped image

All bulets have been shot from the current pos of the player.
The are drawn to the entire map, only the crop is shown, this is the simplest way i could think of.

Any better way?

##### Share on other sites
Yeah, I get ya and to be quite honest it is probably rather inneficient to crop such a large image each frame. Although you have only 'drawn' it the once, as the AP points out, the clipping process is not going to be too efficient (irrespective of the API). It will be trimming down a large amount of image data which is not adviseable. Furthermore, if you wanted a larger map, that would mean a larger initial image which would further slow the cropping process.

What I would suggest is a system that only draws the tiles currently in the view of the camera. This will mean a loop of drawing a couple of dozen tiles each frame but that will actually be faster, and more flexible too.

##### Share on other sites

Any objects (i.e. bullets are renderd after the tile's have been drawn, you draw them at theur current position _minus_ the camera coordinates. This allows the objects to scroll around the screen as well as the map.

I dont like the idea of cropping a huge image. I've seen a guy do both techniques (clipping and tile-based rendering) and the clipping one runs slower generally and takes longer to load (loading/rendering a huge image takes longer than loading a couple of tiles), so all round is just slow. Stay clear of it and do a nice tile rendering loop.

Keeping the player in the middle of the screen... uhmm... the player should be able to move anywhere, i think it works out better if the player has coordinates relative to the map, then the camera is positioned in such a way that it always appears that the player is in the middle of the screen... Maybe its just the way of how i think objects exist, but i think object collsion etc will be easy as you wont have to keep adding camera coords to the player's position every time you wanna compare it agains another object in the level...

I'd check out tutorials on 2d-tile-based-rendering techniques, google it.
You should pick it up in no time!

Chris

##### Share on other sites
I agree that this is a very poor way to do this. The only time this would be a good idea was if the map was very small (only a couple screens) and you're doing multiplayer-split-screen or something. Start each frame from a blank slate and draw everything on the screen, blit, and repeat.

1. 1
Rutin
28
2. 2
3. 3
4. 4
5. 5

• 13
• 11
• 10
• 13
• 20
• ### Forum Statistics

• Total Topics
632949
• Total Posts
3009412
• ### Who's Online (See full list)

There are no registered users currently online

×