appearance flag: DRAW_CONTENTS

ID:2189151
 
Dec 20 2016, 4:09 pm
Resolved
Most atoms, and images, now support a concept called visual contents. Other atoms can be placed in a visual contents list, which means they will be drawn (after images) as if they're attached to their visual locs. This can be used for various special effects and for easing HUD development.
Applies to:DM Language
Status: Resolved (512.1386)
This issue has been resolved.
When an object is added to the list of objects that need to be drawn, its contents should be added to the list.

This should essentially treat the object as though it were a turf for the purposes of drawing.

The object's step_x and step_y, pixel_x, and pixel_y will affect where it is drawn on the map. Its layer and plane will function as though the object were an overlay/underlay. FLOAT_PLANE and FLOAT_LAYER should function as normal.

The object's screen_loc and transform should affect where the object is drawn if the parent object is being drawn from within the screen.


What this feature would allow:

  • the ability to design container-based UI elements that can be moved around the screen by changing a single object's screen_loc or transform variable.
  • Mutable overlays
  • Large, mobile "map" chunks that don't require a ton of processing
  • sensible handling of mouse_opacity on overlays.
  • visual components
  • Complex UI elements like dropdown boxes, scrollpanes, etc. done easily
  • Interactable HUD-like objects parented to movable atoms and moving around on the map.
Dec 20 2016, 8:35 pm
As another thought, I wonder if it'd be preferable to have some sort of visual_contents or live_overlays list, which would serve the same purpose. I can see a purpose for this sort of thing on player icons, for example, where you'd still want to keep the actual contents separate. It'd look something like this:
- Object's icons include (before sorting):
    - Underlays
    - Main icon
    - Overlays
    - Images
    - Visual contents
I'm a little unsure if the visual contents going after the images is best, or if image.override should be able to replace those as well. But that's a question that comes up with your idea as well.

The only major drawback I can see to my idea is that I'd have to add circular reference checking like we already have for loc/contents, so an object couldn't include itself in visual contents, directly or otherwise.
Dec 20 2016, 9:29 pm
Honestly, that's a solid point, because the contents list affects verb visibility, which is something absolutely relied upon by a number of our existing legacy games.

I suppose the real trouble with that is that it makes turfs inconsistent in that turfs draw from regular contents, while movables would draw from visual_contents.
Dec 20 2016, 10:01 pm
Turfs would draw from both. Except with visual_contents, those would be considered to be more "tied" to the original atom.

I'm gonna have to figure out how easy it is to have objects with different IDs "under" a parent, especially when KEEP_TOGETHER is taken into consideration. But I think that's a pretty approachable issue. This seems like a good candidate for the List for 512.
Dec 20 2016, 10:12 pm
If this makes it into 512, I've got ulterior motives for this one to talk to you about in 513.

This change to how the renderer works is actually a halfway point to the map and HUD overhaul.
Dec 21 2016, 9:53 am
container based UIs best UIs
+Million to this
Dec 21 2016, 12:47 pm
This is officially on the List. I think it's fairly low-hanging fruit. More so than filters even, although I'm dying to get those in.
Dec 21 2016, 3:24 pm
Oh lawd, I've wanted this forever, I can see a ton of uses for this. Thank you based Lummox (JR).
Sep 25 2017, 11:52 am
Lummox JR resolved issue with message:
Most atoms, and images, now support a concept called visual contents. Other atoms can be placed in a visual contents list, which means they will be drawn (after images) as if they're attached to their visual locs. This can be used for various special effects and for easing HUD development.