[SOLVED] Rendercam - Ratio/GUI issue on mobile

Questions
#1

Hi!

I’ve been recently working on a world map system and tested it on mobile for the 1st time 1 hour ago… and looks like there are some things that can be improved.

A few info, just in case:

My World Map is a collection (displayed in a full-screen popup) composed of

  • X regions => 1 region = 1 collection
  • 1 camera (different from the main scene)
    image

Each region collection is composed of:

  • 1 tilemap
  • Y level buttons (game objects)
    => When the WM is displayed, a cloned gui node is positioned over each corresponding level object (after the world>screen pos conversion) / and will follow the game object when the camera moves.
  • Various little things that we won’t care about here. *

In Defold, everything works as it should (like in a dream):

… until I resize the popup (back to reality):

image
image1854×958 164 KB

But I usually don’t do it, which is probably why I didn’t suspect earlier what happened on mobile.

On desktop (html5), there already are 2 issues:
1/ For each level, a slight shift between the game object and the GUI node
2/ The camera doesn’t focus on the current level as it’s supposed to (not sure this is the same issue though… let’s see I’ll keep it for later)

image
image628×925 172 KB

I’ve always thought that the ratio to be slightly different in the html5 version… but it was not a real problem until now. So I didn’t care that much.

On mobile (html5), grosse katastrophe!
It looks like this:
1/ The camera seems to zoom out (why? :thinking: the main scene is ok) so the tilemap is super small
2/ The gui button are not synchronized at all with the level game objects.

IMG-3182 (1)
IMG-3182 (1)1125×2436 216 KB
:sweat_smile:

On mobile html5 again, but after forcing the landscape mode.
It looks like this:
1/ The camera is still zoomed out.
2/ But the gui button are properly positioned.

IMG-3183 (1)
IMG-3183 (1)2436×1125 194 KB

I could have described the issue with a much shorter message, but I’m not sure where the issue comes from :thinking:… so perhaps screenshots would explain better than I can.

Anyway, I’ve never been super comfortable with the ratio thing, but maybe it’s time to face my destiny… Well… well well…

@ross.grams please help :sweat_smile: or anyone who has already defeated (and tamed?) this epic monster called Ratio.

#2

I was wondering…

1/ Why is the result so different on mobile? (compared to desktop html5)

2/ And why especially for the World Map collection? (the cameras are the same for the main scene and the world map, and no “zoom out” activated in script)

3/ How to make a GUI node follow a world position “no matter what”?
=> Note: I suppose I could directly use the level game objects (as a workaround), but soon enough the problem will come back, in another context.

4/ Is there a way to easily test the game in “mobile” conditions?

#3

Check “use view area” on your camera and set the “view area” setting to match the window size in your game.project. Otherwise it will use the current window size, so if you change the window size and then add a new camera it will be different (yes, it’s a bad design on RenderCam’s part).

2 Likes
#4

This fixed the “zoom out” issue, thanks! :slight_smile:
(ok for the window resizing, now that I’m aware of the “issue” I should be able to handle it when the time comes)

But the “GUI buttons doing their own thing on mobile” issue remains.

The level buttons (GUI nodes) seem to be following “some coordinates” (in which space/view? I don’t know) instead of sticking with the game objects (that are half-transparent in the video):

I used rendercam to convert the world position (game objects) to screen position (so the GUI nodes can follow them), but maybe I missed something?

#5

Hmm. Did you try passing in the “adjust” mode of the nodes to rendercam.world_to_screen()?

1 Like
#6

It works fine with “rendercam.GUI_ADJUST_FIT”, thank you very much!

In the future, these parameters will very certainly help me fix my rendercam-related issues instead of posting :monkey:

Only 1 issue remains (probably nothing to do with rendercam but I mention it here just in case):

When I display the world map, the camera is supposed to automatically focus on the “current level” (when cameras are swapped). It works as intended in Defold but not with the html5 version (both mobile & desktop). Perhaps there is an error message in the background, but no console to display it, so… I don’t know.

Even if there is (probably) no link with rendercam, based on your experience do you see any generic/technical reason why the camera would behave differently in Defold & HTML5?

Anyway, I’ll run some tests, delay the initial camera positioning by 1 frame, add checks/safeguards etc.

Thanks again for the help with rendercam!

edit: just tested it again… The “camera focus” works when I build for “local” html5
image
but not when I create a HTML5 bundle
image

So weird…

Is there something specific to html5 bundles that could cause the issue? :thinking: @britzl @Mathias_Westerdahl

[SOLVED] HTML5 bundles => weird game object ids
#7

If you are running it on desktop, then you just need to open the browser console to see error messages (press F12 in Firefox or Chrome to open the developer tools, then make sure the “console” tab is selected). On mobile it’s a bit more of a nuisance, but you can look up how to do it.

What goes wrong exactly? It just uses the wrong position? Nothing comes to mind, I would use the console and/or some debug drawing to try to figure it out.

1 Like
#8

I did that, but there was nothing special in the console.

Yes, when I display a new map, the camera must focus on the highest level reached (within the min-max camera positions). It worked with the “local” html5 version, and not with “live” html5 bundles.

But as I thought, it was a question of “timing”… I made some dirty tests to identify the issue and delayed a specific portion of code by 1 frame, and now it works as intended in the “live” html5 version.

What I don’t understand is why it worked in a html5 context (local) and not in the other (live). Probably a super secret technical reason I’ll never know :smiling_imp:

1 Like