However, a map element might actually be smaller than the viewport. The reason for this is that pixel art requires a resolution multiple of 2x, but you can't always ensure that the viewport and map area are always the same when creating a UI that will actually work on various resolutions.
The problem with this, is that a HUD is intended to be seen. If you anchor your HUD objects dynamically using EAST,WEST,NORTH,SOUTH, you either have to leave excess space at the edges:
On different resolutions, you can see that the excess space will result in that space being inconsistent as different resolutions will have slight variations in the amount of pixels that are drawn past the edges of the viewport, ranging between 0 and TILE_SIZE-1. If you don't include this excess space, parts of the HUD are cut off.
There are ways to deal with this problem:
1) You can loop over every object in the screen and reposition it based on its anchor (this is not obvious to newer, less experienced developers). (Inducing churns on a potentially large number of objects to keep something rendering consistently)
2) You can add 8 PLANE_MASTERS to the screen and then simply update those 8 objects to move the objects anchored to the side the plane belongs to. Unfortunately, this is going to cause a pretty severe rendering slowdown just to keep something still.
3) You can make sure the view is always <= the size of the view by buffering with black space:
Which... You know, no end-user ever would find acceptable.
4) Stretch to fit, and make your pixel-perfect pixel art render with an incorrect aspect ratio or rows of duplicated pixels. (A 2D game engine that can't properly render 2D games?)
Instead, the client already knows the renderable area of the map, and it already knows the size of the viewport. Why not let it interpret screen_locs with 4 more special case flags that use that information?
This would take some pretty massive headaches out of working with the engine.
