It seems that AppGameKit likes to blend the last pixels, bit of a pain, and I'm not sure if there's a workaround other than sticking to the exact native resolution of the device.
The difference between these, and standard tile maps is that the sprites are more like real sprites. With a standard tile map, you might use a 16x16 sprite, on a 16x16 grid, and these are flat - typically the player would stand on top of these, and objects would be handled seperately. One downside with standard tiles is that when you make a wall, the player is still standing on top of it, and it can be difficult to get a good impression of depth, because the player can't go behind tiles effectively. Old games like The Chaos Engine would just have the player collide with the top of a raised area, never going behind any of the backdrop. It's fine if the world is completely flat of course.
With sprite tile maps, you have Z depth as well, so a tile can be a piece of floor, or a fence post, or a treasure chest - and the player will go behind perfectly. For instance, in that example the player could be given a calculated Z depth, then he would go behing the grass blocks, all with just the Z depth, no need for more complex techniques than that. These sprite tiles are really more like the tiles an isometric engine would use. The downside with sprite tiles, is that it can be damn tricky to draw them - takes a fair bit of planning, even to get that basic 2 block tile set done took a while, I mean that's 16 images per tile, each tile is automatically set depending on if there are tiles at the sides. I tend to use binary addition to work it out. For example, start with image 1, which is a grass block on it's own, then if theres a grass block to the north, add 1 to the image, if theres one to the east, add 2, one to the south then add 4, and one to the left, add 8. Then, the resulting image is used for that block. Making those 16 images can be time consuming, but really I think it's worth the effort... whether it's standard tiles or sprite tiles, adopting a system like that means you just plonk tile 1 where you want grass, and the binary addition stitches it together nicely.
I haven't done anything with the code, but I will probably evolve it into a standard tile map example, mainly to see if it performs better. I think that a standard version would run twice as fast, because for each sprite tile, there's a lot of space that isn't needed in most sprites - means a lot of empty texture data, it's not efficient to draw too much alpha transparent images, but it might be the easiest way to have z depth. It would probably be better to have the sprite tiles split into different images - like the dirt in that example could be a 32x32 sprite set, and the grass could be 32x64 - would save some rendering time I think. If you were looking at just a flat ground, then it would probably be significantly faster, just by not drawing that blank area of texture. I will probably wait until I get the full AppGameKit package before I do much else, want to have a go at that scanline issue as well.
Health, Ammo, and bacon and eggs!
