If you have access to shaders, you can invert the drawing logic. Normally you loop through tiles and draw each one. When you're zoomed out there are a lot of tiles to draw. Zooming out is slower. Inverting the logic, you can loop through pixels and figure out which tile that pixel is on, and that tells you which sprite to draw, and then you look up a color in the sprite. This is weird but it means that no matter what zoom level, you have the same number of draw calls (just one quad), and the same amount of work to do, at least for the tiles. The objects on top of the map don't work with this trick so you'll still have to draw them separately.
To make it work you put the game map into a texture. The texture color tells you which tile to use. You also have the tile sprites in another texture. For example if you have 32x32 pixel tiles, and 16x16 of them, you can put that into a 512x512 texture. If the game map is 200x200 you can put that into a 200x200 texture, where each color is {red = 0.0 for column 0 to red = 1.0 for column 15, green = 0.0 for row 0 to 1.0 to row 15}.
If the tile to draw is in column 3, row 9, then you'd store {red = 3/15, green=9/15} as the color. The shader then looks up the tile coordinates first. It would see that it needs to look in the spritesheet at column 3 (which starts at pixel x=3*32) and row 9 (which starts at pixel y=9*32). It then calculates which pixel of the sprite it needs to draw, and looks that color up in the spritesheet.
I had tried this out a long time ago with this flash demo, and then I tried to find other people who had the same idea and found this javascript demo and a blog post about the technique. Some of the comments on that blog post suggest that it may not actually be that efficient of a shader, so if you're going to try this it's worth measuring the performance.
