Runtime Texture Atlas Construction

[jstine35]

The tilemap engine relies on a fixed-function 'tilemap pipeline' which reads textures from an atlas with uniform layout (fixed size tiles). Atlas textures must be uniform to a fixed grid layout, and must be constructed with 2-pix repeating-texture padding to fix texture sampling bilinear filtering error.

For rapid development purposes it is highly advantageous to be able to specify individual png src textures and assign them into the game. Moreover, calculation of the padding area means that atlas sheets ideal from an asset designer's perspective are still not OK for our purposes.

Therefore I propose adding an Atlas builder to the engine, with the following basic image editing features:

• Define atlas parameters
  • Tile dimensions are required
  • Size should be dynamic, size hint is OK
• Cut rectangle from bitmap
• Paste into atlas at given TileID
  • Engine applies padding automatically
• Option to dump result to disk, for debugging use.

Note that I considered turning off bilinear filtering as a work-around for 2-pix padding.

• It does not look good for most environments (is OK for sprites tho)
• It doesn't completely fix the problem since GPU may still fetch 'nearest' pixel from neighboring tile depending on zoom factor and especially during any rotation effect.

[robinlavallee]

Yes ! From a gameplay designer point of view, we should make it easy to drop new images and tiles as needed in the "image" directory and have them being picked up automatically by the engine (reloading the engine is okay, but doing it on the fly is even crazier), then it would be possible to reference these new tiles by filename/UVs. Any size should work, the engine would figure out the best texture size for these.

I'm assuming internally it will try to store those images into an Atlas to limit the number of draw calls.

[jstine35]

Follow-up on the technical design of the tile engine: Multiple atlases can be used by issuing mutli-pass TileMap draws, where tiles from the current atlas are valid IDs and tiles from different atlas are nil. The cost of the draw pass should be pretty inexpensive.

In a pinch, an atlas could just as well be a single tile. This would be an OK work-around for immediate-use of added texture resources. The engine will use the slow-path of issuing separate draw calls for each non-atlas'd texture until the next engine reload. On reload, things get baked into a texture and perf is restored.

This effectively maintains gameplay perf while allowing rapid development with possible perf penalties, as it is considered acceptable criteria to have perf penalties during development cycles.