ID:2189366
 
Resolved
New screen_loc values are now supported. LEFT, TOP, RIGHT, and BOTTOM will align HUD objects to the map control or letterbox edges (whichever is closer). Position offsets can also now be supplied as decimals or as percentages. See screen_loc in the reference for more information on these new coordinates.
Applies to:DM Language
Status: Resolved (512.1386)

This issue has been resolved.
EAST, WEST, NORTH, and SOUTH position screen objects based on the outer edges of the viewport.

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.
++
I've given this some thought, and I think this is doable if I make some changes under the hood. Namely, the client side of the engine has to be made aware of some skin info (map size limitations, if any) before the icon list generation process happens, and it will need to be updated whenever that info changes. At the present time, the algorithms behind HUD positioning and icon list generation are skin-agnostic.

Here's an important question I have on the subject: Suppose you're zooming to 2x, and the map size means that partial pixels will appear. For instance, if your actual pixels are 300x300, scaled up to 600x600, and the map is 502x502, the map is going to stay centered which means you'll get the center 250x250 out of your original image, but you'll have half a pixel (scaled up to a whole pixel) on every edge. Should LEFT, TOP, etc. be anchored to the first pixel that's visible period, or the first whole pixel?
Should LEFT, TOP, etc. be anchored to the first pixel that's visible period, or the first whole pixel?

It makes more sense that the first pixel rendered period, regardless of complete visibility in the frame should be considered the edge.
Lummox JR resolved issue with message:
New screen_loc values are now supported. LEFT, TOP, RIGHT, and BOTTOM will align HUD objects to the map control or letterbox edges (whichever is closer). Position offsets can also now be supplied as decimals or as percentages. See screen_loc in the reference for more information on these new coordinates.