ID:2130752
 
Not a bug
BYOND Version:Version 511.1352
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 52.0.2743.116
Applies to:Webclient
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:

HUD objects seem to render differently on each client.

The layers must be the same value in order for this to occur.

screen location also seems to influence whether or not this occurs.


Code Snippet (if applicable) to Reproduce Problem:
//Hud object b is supposed to appear over object a

obj
hud_obj
icon='HUD.dmi'
a
icon_state="a"
b
screen_loc="2,1:-24"
icon_state="b"

mob
proc
make_toolbar()
for(x=0,x<8,x++)
var/obj/O=new/obj/hud_obj/a()
O.screen_loc="[x],0"
client.screen+=O
var/obj/OOO=new/obj/hud_obj/b()
client.screen+=OOO
mob
New()
..()
spawn(0)make_toolbar()


Expected Results:
Identical screen object rendering
Actual Results:
The screen objects render differently on each client


Workarounds:

Problem doesn't occur if you set the layer of the overlapping object as higher than the object beneath it.




This code shows the same problem but with only two objects.
obj
hud_obj
icon='HUD.dmi'
a
layer=1
icon_state="a"
screen_loc="2,0"
b
layer=1
screen_loc="2,1:-24"
icon_state="b"

mob
proc
only_two()
var/obj/O=new/obj/hud_obj/a()
client.screen+=O
var/obj/OOO=new/obj/hud_obj/b()
client.screen+=OOO
mob
New()
..()
spawn(0)only_two()
Mind you, trying to display two objects with the same layer on top of each other results in an undefined order. Although I'd prefer the webclient to keep the same order as DS, when you make the layer the same you lose all guarantees; you can't even be sure it will be the same from version to version.
In response to Lummox JR
Yes, you should define your layers, this isn't production code or something that SHOULD be used in a game.

But I am saying I'm getting different results with the same code.
Technically, you could get different results with the same code by simply rebooting your game enough times. Like Lummox said, when you have two things on the same layer you're basically leaving it to a crapshoot to see which comes first.

There's no bug here, the webclient is actually doing the same thing as DS here, just not in the exact same order. It could, if you gave it enough tries.
I'm not sure rebooting would be enough to cause a change. The layering is consistent, in that ties should always be broken in the same way in any given version; it's merely undefined.
In response to Nadrew
Technically, you could get different results with the same code by simply rebooting your game enough times.

I'm getting consistent behavior from this code. The DS and WC always render the same way as shown in the screenshot. if anything is clear to me, it's that WC and DS are definitely doing something different.
Orange, its called undefined behavior.

The point is that there is no right way to how it should work, and from version to version, how things of the same layer layer up changes.

in fact, here's a fun quirk: if you put two objects of the same layer on a turf, and move around, and what object is above what will be randomly different depending on the angle you are looking at the tile from.
In response to MrStonedOne
I mean, typically I expect an engine to do the same thing on every supported platform.

imo no matter how the layers are rendered from version to version, they should be rendered the same way on each client.

If Lummox doesn't want to do anything about it, that's fine - it doesn't really bug me since this is mostly an annoyance.
In response to Orange55
Orange55 wrote:
I mean, typically I expect an engine to do the same thing on every supported platform.

imo no matter how the layers are rendered from version to version, they should be rendered the same way on each client.

https://en.wikipedia.org/wiki/Undefined_behavior

The behavior of some programming languages [...] is undefined in some cases. [...] An implementation is allowed to assume that such operations never occur in standard-conforming program code; the implementation will be considered correct whatever it does in such cases, analogous to don't-care terms in digital logic.

It doesn't matter that DS and the webclient do different things; undefined means undefined, it's not at all guaranteed to be consistent across implementations, across versions, even across runs of the same version.
It's not undefined behaviour. In DS, when you have two screen objects on the same layer, it becomes based on order of addition to client.screen. This occurs consistently, giving the same result every time.

In the webclient, it seems to reverse this layering, which is just weird and unintuitive. You get this result every time. It doesn't just randomly juggle the objects between layers.
This version, sure. Next version that order might change, and the version after that.
This has been the case in DS for as long as I can remember, and it makes sense tbh. The order of addition to client.screen intuitively implies a drawing order in the absence of explicitly defined layers. Can't see why that should suddenly change.
Because it's undefined behavior, by nature it can suddenly change, that's why you should never ever rely on it. That's the whole point being made here.
In this case we have behavior that occurs consistently, with zero unpredictably. It's been occurring for many versions, with no foreseeable reason for change, and it makes sense. It's not some weird unreliable exploit. I can't see how you'd classify that as undefined.

If anything, it seems more appropriate to call it a minor inconsistency between the webclient and DS.

I did some tests. Turns out it's not a complete reversal. Here are some screencaps to demonstrate:

DS
https://streamable.com/kg51

Webclient
https://streamable.com/5zy7

In the webclient, it seems objects with larger icon sizes get layer priority over others added at the same time/during the same proc. Otherwise, it's again based on order of addition to client.screen. Note this is how it looks every time. It doesn't change between reboots, doesn't change layers at random. Just a weird difference from DS.
Again, because it's consistent now, doesn't mean it always will be. That's the point, you don't seem to get that, it can change and should never be relied on. Period.

The fact is, the code doesn't define how two objects of the same layer should be handled, that means that there's a million different things that could end up altering it, from a minor change to the rendering code to a simple variable change.
In response to Nadrew
Nadrew wrote:
The fact is, the code doesn't define how two objects of the same layer should be handled

Except it does, as you can see in the DS screencap. This just wasn't carried over into the webclient. Every object shown is on the same layer, only added at different times.
It doesn't, the fact that it happens that way is just a result of the current setup, which could change it at any time. The whole point of calling it 'undefined' code is literally 'there's nothing in the code defining what to do in that situation specifically'.

If you want to argue about it, fine, but Lummox has already proven you wrong, so have fun with that.

Just because it's consistent now, doesn't mean it will remain so.
Nadrew resolved issue (Not a bug)
In response to Nadrew
Nadrew wrote:
The whole point of calling it 'undefined' code is literally 'there's nothing in the code defining what to do in that situation specifically'.

Sure, I guess this is just happening magically. Nothing to do with any definition via code.
It's caused by a combination of factors, none of which are specifically there to determine the layering order. Factors that can at any time change.
Page: 1 2