I was looking into something like this, but haven't bothered making an implementation in monkey, first. One of the issues that concerns me is the speed at which we'd be able to do something like this. For scrolling games, you would either have to generate the entire texture at the beginning, (including splitting the textures into sizes the GPU can digest, typically 1024x1024), or come up with a method to dynamically generate larger "tiles" as the scrolling enters the visible area. The latter is from what I can understand a classic problem for video games -- choosing a proper blit tile size to balance the generating speed vs. the speed the tiles are requested to minimize the perception of thrash and leave as many cycles open as possible for other operations.
Maybe we won't be forced to choose, though, as some people are working on hacking a triangle-drawing routine into mojo so that we can have "real" stitched textures, which could get around the seams-in-tilemaps problem. As it stands, blitting larger tiles in advance has the additional problem of dealing with animations, and you can see where this might start to become problematic.
One last thing -- for nDrawExts2, I determined that from the CPU on my Nexus S, a 256x256 texture would take about 50ms to generate the blit image. That's the read speed, 3 frames; I didn't actually test the write speed, but it means you'd basically have to cache as much source tile data as possible, and you'd be caching it raw into RAM, not VRAM, severely decreasing the amount of heap space you'd be allowed to play with. These may not be concerns on the Desktop, but I'm guessing your question stems from efficiency on mobile. Unfortunately, it seems that the hardware on modern devices just aren't made for the same techniques as older ones were. There are no helpers for fast tile-based blitting, no special tile memory; everything's about blitting textures now. So this technique of manually baking tiles far ahead of the visible area may in the end be mostly obsolete.
|
