Click coordinates on ESCBackground are not properly transformed

[jeancallisti]

Look at esc_background.gd

Clicks on the background are handled like this :

    if event is InputEventMouseButton and event.is_pressed():
        var p = get_global_mouse_position() 
        var size
        if get_texture():
            size = get_texture().get_size() 
        else:
            size = rect_size
        if Rect2(rect_position, size).has_point(p): 
                       # do the click

Let's look at the details:

               # this is the global position. It can be 640x400 if that's the game's resolution
        var p = get_global_mouse_position() 

              # this will be 320x200 no matter what if the background image is 320x200
          size = get_texture().get_size() 

              # check if the click is within the background
          if Rect2(rect_position, size).has_point(p): 

This becomes a problem if the game is applying any kind of transform to the room. The most basic scenario would be upscaling (to fake a 320x200 room in a 640x400 game)

For example if you place the ESCBackground in a Node2D with a x2 scale then it breaks this logic : size = get_texture().get_size() On screen, the background is displayed on a 640x400 area. However only the top-left 320x200 area is clickable.

The clickable area should be the effective background as it's displayed on the screen, not its internal texture size.

There are several ways to go about this : 1) Use get_local_mouseposition() instead of getglobal_mouse_position() and then transform the coordinates from room coordinates to screen coordinates. OR 2) Use a different value for the boundaries (e.g. the size of the ESCBackground's Rect. Not its texture!) OR 3) Remove the click boundaries altogether. I've always thought that the background should not be given the responsibility of discarding clicks. A click is either inside the game's world (anywhere that's not a UI overlay) or "outside" of the game's world (any UI overlay). All in-game clicks should be dispatched and it should be the listeners' job (e.g. the walkable areas) to decide if it concerns them.

========

Side note: The brute force solution is to create a 640x400 ESCBackground and then use an upscaled image in it. But it defeats all the benefits of using a powerful tool like Godot. Instead it adds a ton of work (and human mistakes) when every asset needs to be upscaled.

[jeancallisti]

I've just thought of a workaround which would work in the case when the Transform is an upscale:

(context: the background is upscaled from 320x200 to 640x400)

• Use a transparent 640x400 background image as the ESCBackground's texture. It captures the clicks in the expected area.
• Add a sub-node (TextureRect or Node2D or Sprite or anything that can contain an image) in the ESCBackground to actually display the image.

I'VE TESTED THIS WORKAROUND: IT WORKS

[StraToN]

Inputs management have been quite a big struggle for a long time. The basic idea has always been that any game element (such as items or NPCs) catch inputs to direct them to a central inputs handler. But handling inputs on the background (for walking actions and such) kind of collide with this management because of how Godot manages inputs. The ESCBackground node is the only working response we came out that kind of worked.

It is important to notice that this node is name "ESCBackground" and can show a texture, but it doesn't have to. It is more used as an inputs catcher.

[Bracket-H]

It is important to notice that this node is name "ESCBackground" and can show a texture, but it doesn't have to. It is more used as an inputs catcher.

Yeah but if no texture is used then the character goes nowhere. And if a texture is used, then the texture size is the clickable region, not whichever scale the user has set.

At least from the template thing one can download via godots manager.

[StraToN]

Hmm. That should not be the case. This node's rect_size is automatically set to screen size when the room is setup. I'll double check this.

[Bracket-H]

If one removes the ESCBackground from a room, then only the collider shape of the player allows for 'cursor action cycling' , too.

In my case, it's the capsule from the step by step example from the tutorial. In other words: If no ESCBackground is used, a grey default background is shown, and the mouse UI does not work unless its on top of the capsule.

And if the ESCBackground does not have a texture set, ~it just doesn't work for me.~ then the cursor is also only changeable with right click on the collider shape.

I tried setting the size and margin values manually, but for me, it needs a texture, and it can't even be a stretched texture. It uses the dimensions of the image without any scaling applied. At least not enlargement scaling.

[StraToN]

@Bracket-H @jeancallisti Would you please mind testing my branch here https://github.com/StraToN/escoria/tree/auto_escbackground ? I did 2 things:

• add an empty ESCBackground node if the room didn't feature one
• set its rect_size to viewport size if its texture is null Thanks a lot!

[Bracket-H]

Sorry for the long delay in replying. Is that link you provided still good? Or have things changed?

[BHSDuncan]

@Bracket-H I believe we merged in a change that no longer requires you to use ESCBackground. Maybe try pulling the latest and see if it solves anything for you. If not, be sure to let us know here.

[Bracket-H]

Thanks for the reply. I think I'm too ignorant to just 'pull the latest'. Or at least, swapping the development branch of the core plugin out for the one the "template addon" (from the addon browser) results in trouble.

Is there any documentation I can read? If not...could I get a rundown of it?

I followed the documentation with its "First steps" . Which does not involve the git version of the core files. I don't think.

[BHSDuncan]

The docs are a tad out of date, unfortunately. We were using the asset library to push alpha builds of Escoria but that turned out to be a bad idea. We're sorry for that.

If you need a rundown or a hand in pulling from GitHub, someone may be able to try to help (can't promise when) on our Discord https://discord.com/invite/jMxJjuBY5Z

But the long and short is you should be able to clone the demo-game repository, and then copy files as you need between the two (likely the "addons" folder from the cloned repo to the "addons" folder of your existing project), though you may need to disable/reenable the plugins from your Project settings.

[Bracket-H]

I'm fine with git, I just didn't know how to handle escoria (and godot lol) I'll do what you explained. Gonna clone the demo and then use its addons folder.

[Bracket-H]

It works! ...I cannot enable either 9 Verbs UI, but ...the rest eventually allowed itself to be enabled. Edit: OH, I see, it conflicts with the mouse UI, all good. All good.

[Bracket-H]

This is so cool! I'm stoked! Thanks for the work and support.

[BHSDuncan]

@jeancallisti is this issue still present in the latest version of Escoria?