What's an ideal way to scroll the camera across a map that's larger than the screen as the player moves? For that matter, how are such top-down camera classes/functions written? I've never done one before.
Here's my current display code:
void Display::render() {
// render tiles
for (unsigned int i = 0; i < game.get_area()->get_width(); i++) {
for (unsigned int j = 0; j < game.get_area()->get_height(); j++) {
apply_surface(i*TILE_SIDE, j*TILE_SIDE,
img_list[game.get_area()->get_tile(i, j)->get_id()], NULL);
}
}
// render entities
for (unsigned int i = 0; i < game.get_ent_list_size(); i++) {
if (game.get_ent(i)) {
int x_ = game.get_ent(i)->get_x();
int y_ = game.get_ent(i)->get_y();
int id_ = game.get_ent(i)->get_id();
apply_surface(x_*TILE_SIDE, y_*TILE_SIDE,
img_list[id_], NULL);
}
}
// render texts...
}
Some ideas I had:
1. Split each map into "sectors," where a sector is defined as an area of the map that fits one screen. For example, the top-leftmost sector would be (0,0), and would span real map coordinates (0,0) to (screen_width, screen_height). When the player moves, check to see if his coordinates cross over the boundaries of one of these sectors, and if they do, update the sector variable appropriately, and then shift the camera over to the next sector.
Disadvantage: A player cannot view the map in between two sectors. This would make navigating in rooms that are cut at sector boundaries difficult and annoying.
2. Create an integer variable that is added to the lower and upper bounds of printing in the render routine (i and j). This variable is incremented/decremented appropriately whenever the player moves more than half the screen width/height into the map -- and it continues to move until he reaches a boundary of the map.
Disadvantage: Gameplay becomes choppy. Sometimes, keeping the camera still is ideal.
3. Allow the player to move the camera on his own using a separate set of keys; do not allow movement past the location of the character (or a certain buffer amount around the character; say, 3 tiles in either direction).
Disadvantage: The player may not always want to move the camera on his own; sometimes, having the computer take over is helpful.
4. Move the camera every x tiles the player moves in a certain direction. That is, say, every time the player moves ten tiles down from his original position, the screen shifts ten tiles down.
Disadvantages: None?
What have been some workable solutions in past/what generally tends to please the user? Thanks in advance!
By the way, the player moves in tile-sized movements, not smoothly.