Quote:Original post by evillive2
... For instance, using texture coordinates with tile sets will greatly reduce the number of texture switches increasing your performance.
This CAN be used in certain cases but one must be aware of potential issues.
Unlike our old friend the Image Blitter, mapping part of a texture onto a quad is not nearly so precise. unless you do a direct mapping of Texels to Pixels (which means the quad cannot be scaled up) you are likely to see part of your neighboring tile 'bleeding' into your drawn image, this is ususaly due to the filtering process, the only effective way to get around this is to use a 1 (or more) translucence pixel 'gutter' around all of the images in a packed tile set, which is a large large pain.
For a little bit of perspective, I found that doing a game as image-heavy as morning's wrath was enourmously hard to make performant in a 3D API, and even now it is not very performant versus a 2D api.
Quote:Original post by evillive2
The biggest problem I have with using a 3d API is the complexity of rendering to an offscreen texture. This tends to be a pain and causes performance issues if overly used (at least for me). For the most part though, you can get away with drawing 3000-5000+ textured quads with scaling, blending and rotation in less time than 2000-4000 in something like SDL without scaling, blending and rotation.
Try looking into something like PnP Bios's hxRender library (SDL/OpneGL under the hood) or HGE's game library/engine if you don't want to do the low-low level stuff yourself. Even Irrlicht has 2d functions along with a built in GUI library. Irrlicht may be overkill for anything small but who knows what your game might grow into.
Good luck
The large issues come not when you draw 5000 textured quads, the card is very happy about doing that. The issue comes when you draw 5000 textured quads with about 50 different textures. Non-grouped renderings will cause tons of texture switches, and if you happen to be using more textures than can fit on your card, prepare to drop some serious frame-rate.
my current advice would be to keep your tile images as squares, 64x64 or whatever, and utilize a view transform to put your view into isometric.
if you can guarentee that the tiles will be 64x64 (or whatever size you choose) then you can have a number of atlases (which you might have to gutter if you need to scale) these can be generated programatically or by an artist. in this way, 64x64 tiles, a single 1024x1024 image map will give you 16x16 64x64 tiles
for your needs this may be enough and each map can have it's own 'atlas' or you can use multiple atlases, that get swaped out during map changes.
just some food for thought =D