Terrible distortions just 2 screens away from origin (Android) (DEF-3946)

When I move my game object and camera just 2 screens away, about 2500 units on Y axis, the sprites start to shake and distort, at only 10 screens the distortions are ugly. See video on Android:

That is not happening on Windows, see the end of the next video, I’m 32,000 units away from origin and it run as smooth as perfect.

Additional notes:

  • The gray object above the boat is to compare with a game object without CollisionObject, this gray thing position is not child of the boat, its position is updated every frame to follow the boat. This prove to me, that’s not a problem of Box2d, but the rendering engine.
  • Physics scale is set as 0.02 as reccomended in Docs…
  • screen size is about 1280x 720
  • I’m using the engine camera and default render script with just minor modifications to draw particles on the background.
  • Phone: Samsung J5 pro with android 8.1

I had the same issue and I believe floating point precision is the reason.
See this thread: Floating point precision

Of course has to be, but that close to the origin is unacceptable.
Thanks for the link, going to check.

Happens that there is no problem on other 2 devices tested. How lucky is only on my phone.

More specs:

With distortion problems at 2,000 units:

Samsung J5 Pro SM-J530G
|OS|Android 7.0 (Nougat), upgradable to Android 8.1 (Oreo)|
|Chipset|Exynos 7870 Octa (14 nm)|
|CPU|Octa-core 1.6 GHz Cortex-A53|
|GPU|Mali-T830 MP1|

No problems even at 100,000 units, run smooth like heaven:

Samsung Galaxy S5, GPU-Adreno 330

Lenovo TAB 4 10, GPU-Adreno 306

I cannot discard my phone model, the Samsung J’s are pretty common and what a shame if make a game that I can’t play. The thread post about precision is gold, I was already aware of floating point issues and I know (I think) how to deal with them and avoid them. I’m not making an Open World or infinite runner, just small levels that can go about 10 screens far from origin. And the fact that is just in one phone makes me even more worried.

I’ll try to test on 2 more devices, and also spend some hours downloading games to my phone and test them, I had never problems with games before with this phone.

Did you already change your position to highp?

Don’t know where or how to do that, im going to check.

It’s likely to be highp, check this thread to see how to change it:

1 Like

Thank you @totebo

The fix is working but is not so fun. First time ever me editing a vertex shader. And looks like I have to change the material for every sprite of every game object one by one. Plus the materials of particles…

Judging by the amount of similar threads I have found when searching for “highp”, this should be a problem fixed by the engine, not that every time someone making many kinds of game try to move away from origin have to edit all vertex shaders…

1 Like

Not every game needs highp set so it probably won’t be changed in the builtin material as otherwise it’s a waste of resources to do so. Now you know about the possible issue so whenever you make another game where assets move away from origin you know you’ll probably need highp if you are targeting mobile devices where many of them have too low precision for anything not highp.

2 Likes

I’m not asking for setting the “highp” by default for everyone, in fact I’m not familiar with OpenGL shaders and I’m not sure if now this has a cost in performance. Maybe (if possible) having a checkbox on game.project to switch all material precision from mediump to highp. Looks like is an important issue affecting many projects.

1 Like

It would require adding a new material (or materials) to the builtins at the very least. And then having some customization option for what the default material is when creating new objects of a type.

Changing builtin stuff is discouraged because they do not want to break games which rely on those values ever.

Adding stuff to builins is discouraged because they don’t want to bloat builtins up.

It’s annoying to change over the materials, but it’s what must be done for now.

Maybe a good solution would be to include some extra materials in the template projects which are labeled highp with explanation of when to use them.

Using custom shaders is normal, better learn them sooner than later.

2 Likes

yeap… looks like I have to. :grimacing:

I can recommend my talk for a start. https://www.youtube.com/watch?v=Qkhv2UWAeA8

1 Like

I wonder though how much impact it would have on performance to change from mediump to highp? Does anyone have a link to any benchmarks?

1 Like

I think we can modify your bunnymark to test that.

1 Like

It does add up, but probably matters way more with full 3d games and not so much games made up of a bunch of quads.

I did a quick non-scientific test with @britzl bunnymark, on my conflictive phone J5.

The go.animate() mode, with 15k bunnies I got stable 15.9 FPS with highp, and 15.6 with mediump. The funny is that I repeat, back and fourth and always the highp have this little more FPS.
With 8k bunnies I got 29.8 FPS with highp and 29.7 with mediump.

2 Likes

Maybe the mediump is giving openGL a non-native data size like 16bit float, that’s why the distortion so close to origin, and at highp is giving native 32bits float (or wathever this phone has as native ). So in some cases the highp could be faster!.. <-- or I just don’t know what i’m talking about! :rofl:

1 Like

You should test with lowp too!

1 Like