A comment from Ter13 struck me as interesting the other day, and it got me thinking along some new lines. Specifically, BYOND has the ability to intermix HUD objects and the regular map, so that you could have a HUD object with a layer of OBJ_LAYER and let it appear below a mob.
Do any games make use of this? Because if not, I'd like to change it.
Here's why: The fact that HUD objects can mix with non-HUD objects, and are not guaranteed (in topdown mode) to show up on a different plane, means that the logic handling screen objects is a lot more complex than it would otherwise need to be, especially when it comes to things like opacity. The fact that HUD objects can appear outside of normal map bounds, but map objects need to be clipped, is also an issue.
But more importantly, if HUDs were constrained so that they could not share a plane with other atoms, I think this would open the door for postprocessing lighting effects. My thinking goes like this:
1) An atom or image could be marked in such a way that it says it speaks for the entire plane, so for instance it can have a color/matrix/alpha and a blend_mode.
2) The rendering engine draws all objects onto a special surface used only for the plane.
3) The rendering engine then draws the plane itself over the main output, using the plane's blend_mode.
I don't think this is as easily done with HUDs in their current state. But it seems like a distinct possibility if I can simplify the logic a little. Offhand, I don't see any reason the webclient couldn't support this, and in software mode I think I know how I'd accomplish this, using a temporary surface very similar to the current improved scaling code.
For that matter, a lower plane might be transformable in a way that could allow for parallax backgrounds or something. I'm not saying that'd be a definite thing I aim to support, but the potential might be there.
Food for thought. Sound off, developers. Do you know any games that use HUD objects in topdown mode in a way that requires interlayering with the map, or is it pretty much a given that users always want the HUD above or below? (Note, the deprecated BACKGROUND_LAYER and EFFECTS_LAYER layer options are effectively planes, so they don't count.)
ID:1958068
 Oct 10 2015, 1:18 pm
|
|
|
Oct 10 2015, 1:28 pm
|
|
FKI
 |
I've never played a game that purposely had a HUD below the player, it was always in user error. My two cents.
|
I've seen HUDs with with stuff before the player. It's usually in character generation stuff, but that's probably poor design on their part.
| |
Never seen or wanted to use a HUD interlayering with a map.
Always had them on a layer (or several hundred) above the general map layers. | |
I used the HUD for the sky and in such in Eureka, there's alot of cool things to use it for.
I also used it to block the players view in a circle and rotated another HUD object to make it act as a flashlight. | |
Kozuma3 wrote:
I used the HUD for the sky and in such in Eureka, there's alot of cool things to use it for. Seems like that's something that can be done with planes, though, right? Is the game in danger of breaking in this case, and if so, can it simply be updated? I also used it to block the players view in a circle and rotated another HUD object to make it act as a flashlight. That also sounds like it doesn't have to interlayer, but can be done on a higher plane. | |
Why not both? Some sort of variable to toggle legacy mode or something. Which reminds me, why is plane limited to -100 to 100 and only integers? Is that gonna ever change in the foreseeable future? I doubt that I'm ever going to need it, but I was just wondering. It could be useful for people who want to use SIDE_MAP and replace layer with plane. Post-processing lighting effects, and any kind of effect that you would normally get through shaders, would be pretty useful and I say have more priority to me than legacy mode, so if both isn't possible, I personally prefer the non-legacy mode.
As a side note, many game engines progress and lose support for games made with older versions. I don't think that BYOND should limit itself just because some people are too lazy to update their code. As long as the older versions are available, and you make it known that people must update their code because something is obsolete, I say to hell with old version support (for versions that are too old and/or can be done in different ways) that gets in the way of newer, more awesome features. | |
It would be nice if we could have the HUD drawn after the map. Ideally I'd be able to do neat stuff like zoom in on the map while having the HUD unchanged. Postprocessing effects could either be applied before or after the HUD is drawn.
| |
Correct me if I'm wrong here, but what you are suggesting is not necessarily getting rid of the interleaving of the map with the HUD, but rather separating each plane into a separate renderpass?
That would mean that objects on the screen would always be drawn after all view objects on the same plane regardless of layer? One would still be able to set the plane, of objects above or below the map, or separate atoms onto planes on the map, but essentially the HUD objects would always be rendered after view objects during the same pass as though their layers didn't matter except amongst things of their own kind? | |
Ter13 wrote:
Correct me if I'm wrong here, but what you are suggesting is not necessarily getting rid of the interleaving of the map with the HUD, but rather separating each plane into a separate renderpass? I'm somewhat considering both, but getting rid of the interleaving would simplify a ton. That would mean that objects on the screen would always be drawn after all view objects on the same plane regardless of layer? That's what I think would make sense, because right now HUD objects are layered like regular map objects, except in non-topdown modes. My question is whether it's reasonable for me to change topdown mode to match how the others behave. One would still be able to set the plane, of objects above or below the map, or separate atoms onto planes on the map, but essentially the HUD objects would always be rendered after view objects during the same pass as though their layers didn't matter except amongst things of their own kind? Right. Chances are I could do my plane idea without changing HUD behavior, but changing the HUD stuff would be really sensible. | |
I want to be able to add shadows without them blending over each other.
| |
I should probably clarify something, since based on rereading SuperAntx's and Ter13's responses together I see a different interpretation.
I'm not considering--not at this time, anyway--a method of separating the HUD out so that it operates irrespective of zoom. My thinking is that HUD icons probably always belong in a different plane than map icons, even if the plane isn't set explicitly. Another place this comes up is the SEE_PIXELS flag, which isn't supported in the webclient yet (although it'd be addable now) and also isn't supported in alternative map formats modes. I have a rough idea of how I might make that work in other map formats, but HUDs complicate the crap out of this. Guaranteeing HUDs never share a plane with map objects, which is already the case in side/isometric formats, would simplify everything a great deal. | |
I'd say just go for it. If they are depending on the layer interleaving for the UI, it's probably misguided anyway.
| |
Ter13 wrote:
I'd say just go for it. If they are depending on the layer interleaving for the UI, it's probably misguided anyway. That's what my gut says, too. I think it'd be a rare game that'd do something like that, and anyway BACKGROUND_LAYER has been around for ages, and now we have plane. | |
can't you still leave it in as a empty error var or something like that when you compile with it it would say Sorry we no longer support this but instead we got this other thing.
| |
Zasif wrote:
can't you still leave it in as a empty error var or something like that when you compile with it it would say Sorry we no longer support this but instead we got this other thing. It would be impossible to detect at compile-time whether the game intended to rely on the new behavior or the old. | |
The ugly black boxes can be set to any color using the map.background property.
| |
Since that too can be done with BACKGROUND_LAYER or plane, I'm not too worried about that; I'd hope you're using at least the former in those cases.
Although opacity is kind of a funny animal. When SEE_PIXELS is enabled (topdown only), it actually draws most things on the tile but covers it with a black square. In those cases you couldn't use the background to cover it. But then, that mode also disables the black square on tiles that have a HUD object, specifically because of the interleaving problem. | |
I'm not sure I understand, are you saying you're effectively REMOVING functionality for the sake of it being easier?
Based off I'm not considering--not at this time, anyway--a method of separating the HUD out so that it operates irrespective of zoom. My thinking is that HUD icons probably always belong in a different plane than map icons, even if the plane isn't set explicitly. That's what it sounds like you're saying. Which seems ludicrous, sure it would be easier for developers but surely it's more prudent to leave the edge case (However infrequent it may be, I can think of a few uses though) and instead better enforce better programming habits. Maybe I'm misunderstanding. | |