Chroma key, commonly known as the “green screen” or “blue screen” effect, allows you to remove a specific color from an image or video and replace it with another background. This effect is widely used in video production to composite different elements together seamlessly.

How?

We will achieve the chroma key effect by writing a custom shader in GDScript and using a VideoStreamPlayer node to display the video content.

I think, instead of knowing what to write in shader it is important to know Why?

So, Have a look at this RGB space :

In this RGB space, each color is represented by a set of three numerical values serving as coordinates. For instance, the color green is expressed as (76, 153, 0), where these values are denoted as (R, G, B).

Our next step involves selecting a color from the editor. Afterward, we will remove all pixels that match this color. However, it’s important to note that the entire green screen won’t be entirely composed of just this exact color; there may be varying shades of green. To address this, we will consider color values close to this chosen green color in the 3D color space and set a limit on how far we can deviate from this color in space.

Scene Setup

Ensure that the scene contains a VideoStreamPlayer node to play the video and a Control node to hold the UI elements for controlling the chroma key effect.

HSlider1 is to control the pickup_range how far we can go from the chosen color.

HSlider2 is to control the fade effect to smoothly discard the pixels near the chosen colors.

Writing the Custom Shader

To implement the chroma key effect, follow these steps:

1. Select the VideoStreamPlayer node in the scene and go to its properties. Under CanvasItem > Material, create a new shader named ChromaKeyShader.gdshader

2. In the ChromaKeyShader.gdshader file, write the custom shader code as shown below:

shader_type canvas_item;

// Uniform variables for chroma key effect
uniform vec3 chroma_key_color : source_color = vec3(0.0, 1.0, 0.0);
uniform float pickup_range : hint_range(0.0, 1.0) = 0.1;
uniform float fade_amount : hint_range(0.0, 1.0) = 0.1;

void fragment() {
    // Get the color from the texture at the given UV coordinates
    vec4 color = texture(TEXTURE, UV);

    // Calculate the distance between the current color and the chroma key color
    float distance = length(color.rgb - chroma_key_color);

    // If the distance is within the pickup range, discard the pixel
    // The lesser the distance, the more likely the colors are similar
    if (distance <= pickup_range) {
        discard;
    }

    // Calculate the fade factor based on the pickup range and fade amount
    float fade_factor = smoothstep(pickup_range, pickup_range + fade_amount, distance);

    // Set the output color with the original RGB values and the calculated fade factor
    COLOR = vec4(color.rgb, fade_factor);
}

Shader Explanation:

The shader uses the distance calculation to identify pixels close to our chosen chroma key color and discards them, effectively removing the selected color. Pixels that are slightly further away from the chroma key color are faded based on the fade_factor, blending them smoothly with the surrounding colors. This process creates the desired chroma key effect, making it appear as if the background has been replaced with another image or video.

UI Controls

To allow users to manipulate the chroma key effect in real-time, I created sliders in the Control node. The Control node’s script contains the following functions:

extends Control

func _on_color_picker_button_color_changed(color):
    # Update the "chroma_key_color" shader parameter of the VideoStreamPlayer's material
    $VideoStreamPlayer.material.set("shader_parameter/chroma_key_color", color)

func _on_h_slider_value_changed(value):
    # Update the "pickup_range" shader parameter of the VideoStreamPlayer's material
    $VideoStreamPlayer.material.set("shader_parameter/pickup_range", value)

func _on_h_slider_2_value_changed(value):
    # Update the "fade_amount" shader parameter of the VideoStreamPlayer's material
    $VideoStreamPlayer.material.set("shader_parameter/fade_amount", value)

func _on_video_stream_player_finished():
    # Restart the video playback when it's finished
    $VideoStreamPlayer.play()

also make sure that the range of the sliders are appropriate, my settings are :

Also you can set steps by hint_range in the shader.

hint_range(MIN_VALUE, MAX_VALUE, STEPS)

Signal Handling

Connect the appropriate signal from the UI elements to the Control node’s script. you created in the Control node’s script to control the chroma key effect. These signal handlers will update the shader’s uniform variables in response to user input.

Connect sliders change signal to the sliders, finished signal to VideoStreamPlayer and Color changed to the ColorPicker.

Woah!

Save and run the scene to see the chroma key effect in action! With the provided UI controls, you can now adjust the chroma key color, pickup range, and fade amount in real-time, achieving the desired chroma key functionality for your video content.

How did it all start?

One day, while exploring the world of games, I got an idea in my mind — an endless game similar to some other endless arcade games. Inspired and motivated, I took action to bring this game to life. In this blog post, I will walk you through the exciting development process of this game in Godot 4.0. Join me as we dive into the player movement, level generation, collision detection, and more!

1. The Dance of the Star

To begin, I needed to tackle the player's movement mechanics. To visualize I used traditional pen and paper ideation, I visualized two primary positions for the player, one above a line and another below it.

Calculating Player Positions
To make it responsive for future and different devices, I made two positions :

#above point
startPosition = (x, screenHeight/4)

#below point
targetPosition = (x, 3*(screenHeight/4))

Movement Pattern
The player will move between these two points. so when the player will move to startPosition to targetPosition then next time the previous startPosition is the targetPosition these time and previous targetPosition is now startPosition to make these functionality i made a function to toggle between these two positions:

func toggle_movement():
  var temp = startPosition
  startPosition = targetPosition
  targetPosition = temp

Finally the movement
To make player move i used a Vector2 offset that will add up to the position of player and make the player reach to the targetPosition from startPosition. I made this movement to trigger with a key on pressing the key i make the moveDistance = targetPosition-startPosition which is also equal to the screenHeight/2. and i’m moving player till the distance get 0.

func _physics_process():
  if (moveDistance > 0):
    position += offset
    moveDistance -= offset

but again there is thing that my offset should also invert after a movement because in one movement I have to go from up to down so +offset and when go from down to up -offset.

Invert Offset
To implement this I made an extra statement in toggle_movement() function to multiply the offset every time we toggle movement.

func toggle_movement():
  offset*=Vector2(1, -1)

  #also can do it like this
  offset.y *= (-1)

2. Endless Level Generation

Creating an endless level was another crucial aspect of the game. I wanted to generate random lines and obstacles for a better gameplay experience.
As the Godot is and open source engine and v4.0 is newer there is no specific tutorial for different things you wanna do. But there is an approach maximum people follow which is repeating blocks.

Repeating blocks approach
If I were to use this approach, I could create a level within a node and repeat that node alongside the previous one. However, in doing so, I would encounter a challenge — repeating the same pattern and difficulty over and over again. so for generating more random level, I got an idea.

Grid-based(TileMap) approach
I was sitting in my college lectures and getting bored so I picked up my game and started ideating the things, How to? and my lecture was more productive than ever before, haha kidding, not kidding.
I decided to use a grid-based approach. Each cell in the grid represented a tile, allowing for flexible level generation.

In TileMap we can set a tile to any cell we want by using the coordinates, just like a 2d grid. So I calculated an y_index from the screenHeight which lies in between the screen, approximately if not exact.

Then I just need to place my tiles at (x, y_index). now what is x? and what it should be? So the x is the x axis of the tile that is about to be generated I named this next_tile_position and after generating a tile I increased it.

Placing line and obstacles
Now I figured out how and where the tiles to be placed, but which tile? I have two tiles one is my “Line” tile and another is “Obstacle”. So my logic was that i can generate the lines consecutively but obstacles to be alternatively.

So I thought why not place some random lines first and then place an obstacle? So I took a random value range (1,5) and generated the lines and then I generated an obstacle tile.

var value = randi_range(1,5)
for i in range(value):
    set_cell(next_tile_position, lineTileIndex)
    next_tile_position.x += 1
set_cell(next_tile_position, obstacleTileIndex)
next_tile_position += 1

This is a pseudo code for the generation of cells.
here the lineTileIndex and the obstacleTileIndex are the index of the tiles in TileSet. If you want to know more about it, follow here.

Dynamic Tile Management
To ensure optimal performance, I implemented dynamic tile management. I’m generating the tiles that are next to the screen and deleting assed tiles from the grid, reducing memory consumption.

To do this I simply maintained a prev_tile_position as well and erased that cell with the erase_cell() method.

used a simple approach to check whether the next_tile_position is in the screen or out and whether the prev_tile_position is in the screen or out of the screen and performed accordingly.

if next_tile_position.x < (playerPosition.x + screenWidth):
  generate_tiles()

if prev_tile_position.x < playerPosition.x - 2*tile_size.x:
  remove_cells()

3. Collision and the Fateful Encounter

As the game gained shape and form, I wanted to add behavior to the player and tiles. Collision detection emerged as a vital component, an encounter between the player and the obstacles.

Now the problem here is that maybe Godot does not provide any inbuilt functionality for the tiles as the area_entered() thing, which will emit a signal and the game will know that I collided with an obstacle or line. It’s completely fair because these tiles are used to generate static levels but I used it in another way.

So now I cracked all of the things and created all but now what? So again I thought of an idea that calculates the cell coordinates by the player’s position and then matches it with any of the tiles. But I just knew that there is a function to get the coordinates of the physics body when it collides with the tile.

If the player collides with any of the tiles, I will check whether it is the line or the obstacle. and we can check this by simply comparing the indexes of both tiles.

var playerCell= cell(playerPosition)
var tileI = get_cell_id(playerCell)
  if tileI == LineTileIndex:
    Game over
  if tileI == obstacleTileIndex:
    Destory obstacle and increase score

Thanks a lot for taking the time to read.
Here is the game:

by the way here are my secret notes to make a game like this.