I’m creating (well, re-implementing in OpenFL) a game in which the scene is rendered in 3/4 perspective. For those (like myself) unfamiliar with that perspective name:
So far, I’ve gotten by with a single Tilemap and Tileset, allowing me to put down hundreds of identical images (tiles) without a performance hit. I re-sort the tilemap’s tile array whenever the camera rotates around the game area, so that objects “in front of” other objects cover each other appropriately.
However, now I’d like to manually draw some pixels (sprites) on the screen, in the middle of the tile order. Namely, I’d like a health bar to appear over creature tiles wandering in a forest, and for that health bar to be partially obstructed by tree and rock tiles appearing “in between” the player tiles and the camera.
The first solution I came up with (but have not yet implemented) is to create separate images (and tile IDs) for every fill state of the health bar, and render the health bars as tiles like everything else. That would probably work fine for this use case (just round the actual health value to the nearest 25%), but I want a more general solution for rendering arbitrary Sprites within a Tilemap’s display list. Is this desire simply impossible to achieve?
If so, how might I efficiently get the same effect as a Tilemap’s ability to draw rectangles from a larger BitmapData into a display list? I would be willing to ditch Tilemap entirely if it means I have a more elegant solution for interspersing custom-drawn sprites with pre-made bitmap resources.
P.S. If some additional context would help, I’m re-implementing a Java-based Ludum Dare game called “Breaking the Tower” in Haxe and OpenFL. The original source code can be found here. In that implementation, a
java.awt.Graphics2D object is passed to a render function implemented by every game object (in sorted order), and the object is responsible for drawing itself onto that under-construction image for every frame.
I’ve been putting my best effort into translating this code into OpenFL’s “passive rendering” strategy, in which DisplayObjects are simply added to the stage on initialization and then the objects’ display properties (position, tile ID, etc) are updated in an event-based manner.