Repository: godot
Issue: Behavior of VERTEX.y in canvas_item Shaders changes drastically depending on whether Compatibility or Forward+ Render Engine is selected
Labels: bug,topic:rendering

### Tested versions

Godot 4.x (tested up to Godot 4.3-stable)
Godot 3.x (tested from Godot 3.5 upwards)

### System information

OS and hardware independent

### Issue description

The goal was to highlight the square tile map cell over which the mouse cursor is currently hovering with a simple shader. However, when switching the render engine from `Forward+` to `Compatibility` or vice versa, the behavior of the shader changed unexpectedly.
![Image](https://github.com/user-attachments/assets/01533d8e-aec6-429d-b56b-2856977f2fe2)
The shader is of type `canvas_item` and looks as follows:
```glsl
  // ADAPTED FROM: https://www.youtube.com/watch?v=7nTQA_6CL6M
  
  shader_type canvas_item;
  
  uniform vec2 globalMousePosition; // DESCRIPTION: Input from GDScript
  uniform vec2 tileSize; // DESCRIPTION: Input from GDScript
  
  varying flat vec2 vertexPosition;
  varying flat vec2 vertexRaw; // REMARK: Only for debugging purposes
  
  void vertex() {
  	vertexPosition = (MODEL_MATRIX * vec4(VERTEX, 0.0, 1.0)).xy; // DESCRIPTION: Take transformations into account
  	vertexRaw = VERTEX; // REMARK: Only for debugging purposes
  }
  
  void fragment() {
  	float isWithinY = step(vertexPosition.y, globalMousePosition.y) * step(globalMousePosition.y, vertexPosition.y + tileSize.y);
  	float isWithinX = step(vertexPosition.x, globalMousePosition.x) * step(globalMousePosition.x, vertexPosition.x + tileSize.x);
  	float isWithin = isWithinY * isWithinX;
  
  	vec4 textureColor = texture(TEXTURE, UV);
  	COLOR = mix(textureColor, vec4(0.7,0.0,0.0,1), 0.7*isWithin);
  
  	/* DESCRIPTION: FOR DEBUGGING PURPOSES ONLY
       // DESCRIPTION: Raw Vertex Color Data
  	COLOR = vec4(vertexRaw, 0.0, 1.0);
      // DESCRIPTION: Normalized Vertex Color data; 
      // VALUES: number of horizontal tiles per screen = 20.0, tile width = 64.0 px,
      // number of vertical tiles per screen = 8.0, tile height = 64.0 px
  	COLOR = vec4(vertexRaw/vec2(10.0*64.0, 8.0*64.0), 0.0, 1.0);
      */
  }
  ```
During the debugging, I took a look at the raw vertex color in the tile set
![Image](https://github.com/user-attachments/assets/5fce5722-df6d-4c51-b13a-afd0eaa7248b)
as well as the raw vertex color of the complete screen
![Image](https://github.com/user-attachments/assets/0f9eefd8-33a5-4e40-beee-b655f8f79889)
and the normalized vertex color of the complete screen![Image](https://github.com/user-attachments/assets/f2c60ba1-c108-4be0-a436-81f61aad193b)
It is not only limited to the `TileMapLayer` Node used for the example. It could also be reproduced for e.g. `Sprite2D`
![Image](https://github.com/user-attachments/assets/5f1600ab-ee82-4d00-b22a-370f96c7f455)

## Expected Behavior
Independent of the render engine, the result should be the same, since the documentation [documentation for `CanvasItem` shaders](https://docs.godotengine.org/en/4.3/tutorials/shaders/shader_reference/canvas_item_shader.html#vertex-built-ins) states: <br>

> Vertex data (`VERTEX`) is presented in local space (pixel coordinates, relative to the `Node2D`'s origin). If not written to, these values will not be modified and be passed through as they came. The user can disable the built-in model to world transform (world to screen and projection will still happen later)...

From this statement and the vertex color visualization, the expected behavior would be that shown by the `Forward+` render engine.

## Probable Cause
It cannot be related to the implementation of the `step()` function, since the issue also occurs when viewing the raw/normalized vertex colors. This points towards an inconsistency in handling `VERTEX.y` between the `Compatibility` and `Forward+` render engines, probably occuring during the parsing of the `GDShader` to `GLSL` and `Glslang`/`SPIR-V` respectively.

## Affected Nodes and Versions
- **Any `Node2D`** (including `Control` Nodes) which can have a `Shader Material` attached to itself
- So far, this behavior could be reproduced for **all stable versions of Godot 4.x** (including Godot 4.3 at the time of writing) and due to the nature of the issue should be **platform independent** (issue could be confirmed for/tested on `Windows`, `Linux` and `Web`).
- In Godot 3.x, the `Open GLES 3.0` shows the same behavior as `Compatibility` in Godot 4.x (tested for Godot 3.5 and newer).

### Steps to reproduce

1. Create a scene with `Godot 4.3-stable` (or any other version of Godot 4.x) with at least an object which has the above shader attached to it and forward the global mouse position to it. Alternatively: Download the example project attached to this issue (Remark: Example requires due to the usage of the `TileMapLayer` Node `Godot 4.3-stable` and newer!).
2. **Two Options:**
		- **Option 1:** Swap the render engine each time between `Compatibility` or `Forward+` and reload the project. Then run the project natively with `F5`/`F6`.
		- **Option 2:** Set the render engine to `Forward+` and run the project natively with `F5`/`F6` for testing the behavior of `Forward+`. Run a `Remote Debug` Session in a browser to test the behavior of `Compatibility` (Remark: works due to the fact that in `Godot 4.3-stable`, the web export is not Vulkan based, but no matter what the default render engine is, will utilize `Compatibility`).

### Minimal reproduction project (MRP)

To obtain the vertex color output, simply comment in/out the respective lines in the shader
[mrp_canvasItem_godot4-3_tileMapLayer.zip](https://github.com/user-attachments/files/18219469/mrp_canvasItem_godot4-3_tileMapLayer.zip)