The documentation for Screen.priority seems wrong. It says the range is 0-255 but the values -128 to 127 work for me while anything below/above does not.
Seems like someone confused their signed integer for an unsigned one.
The documentation for Screen.priority seems wrong. It says the range is 0-255 but the values -128 to 127 work for me while anything below/above does not.
Works fine for me. Are you sure you are setting it up correctly? Can you make a simple example project that demonstrates the issue?
PlayCanvas | HTML5 Game Engine (wpw branch needs to be selected)
Launch and click Wirtschaftspark Walgau on the left followed by selecting any of the floors (OG2 for instance)
The screens that pop up are being sorted by distance and their sorting priority is logged below.
See script markerScreen.js which handles the sorting
this.entity.screen.priority = pc.math.clamp(127 - pc.math.roundUp(this.entity.getPosition().distance(this.camera.getPosition()) * 2, 1), -128, 127);
//this.entity.screen.priority = pc.math.clamp(255 - pc.math.roundUp(this.entity.getPosition().distance(this.camera.getPosition()) * 2, 1), 0, 255);
Comment out the line that works and replace it with the presumably intended version (0-255 range) below and notice how the sorting changes when trespassing 127.
Well, firstly, this is a private project, so canāt see it. Secondly, other users canāt see branches in public projects.
Can you make a blank project with just 2 screen elements? Just some colored boxes on top of each other.
My bad, I thought the project had been made publicly available again.
I will try to isolate the issue in a public project later.
1 Like
https://playcanvas.com/editor/scene/2370932
Zoom out to see the issue. The issue is when some screens are above 127 and others are below.
Hmm, there is something fishy going on indeed. @mvaligursky any ideas?
Also, the Editorās field for priority on a screen component is not allowing to set it larger than 127 for some reason. Thatās a bug, but shouldnāt be related to this (probably?). I will create an issue for that.
Edit:
no idea, not familiar with that bit of code at all ā¦ but itās likely an engine bug here
I think the solution is:
- leave Editor as is, only support values 0ā¦127
- update engine to match
problem is that top 8 bits of 32bits are used to store this, but bit 31 is a sign bit, and all goes incorrectly when this is used.
1 Like
added the change in the engine here to make sure only 0ā¦127 range is used:
Cool to see it addressed this quickly. Was anything changed beyond the documentation/clamping?
Also, are negative integers taboo? I didnāt notice anything breaking from -128 to 0. Asking because when calculating sorting order by distance having more values available is handy since floating points are unsupported.
it would break if there were both positive and negative values at the same time. So we avoid negative values.
you could add your floats to array with index, sort array, and assign indices or so, to avoid the limitation.
Was anything changed beyond the documentation/clamping?
No other changes. The values are (after release) hard clamped to 0-127 now.