Nowadays, we interact with many people and witness various adventures in real life. However, as we know, some activities also negatively affect people, so there are multiple limitations. At this point, a question arises: is there a life without these limitations? In response to this question, engineers discovered one of the most popular technologies — virtual reality.

Of course, achieving this type of reality is not an easy task. Adapting real-life objects and scenes directly to virtual life is very costly. For this reason, there are many techniques to optimize the rendering of these objects and scenes, to work more efficiently, and to offer the user a more realistic and vivid image. In this article, I will discuss the current problems in virtual reality devices, solutions to these problems with foveated rendering, and its benefits in optimizing and giving the user a better virtual reality experience.

The Challenges in VR

Rendering a highly detailed scene on the 1,830 x 2,928 display at 90fps is already a challenge. How many calculations are performed in one second can be calculated this way: 1830px × 2928px (the number of pixels across the width and length of the screen) × 90 FPS (the number of frames in one second) × 100FLOPs (floating point operations per pixel) = 48,245,760,000 FLOPs (floating point operations per second)= 48.2 GFLOPS.

And to create a true-to-life experience, we need to reduce pixel aliasing artifacts as much as possible. If you wonder, anti-aliasing is a technique used in computer graphics to smooth out jagged edges in digital images. As a result, the actual render resolution is much larger: when using multi-sampled antialiasing, we render an image at 4x the display resolution. As a result, just rendering the screen takes 192.8 GFLOPs worth of calculations per second. In addition, processes such as advanced shading, post-processing effects, distortion correction, physics and interaction calculations, and eye tracking increase these calculations even more. Can you imagine how big it is?

Although modern GPUs are very powerful, there are limited resources available to render high-quality images at 90 FPS. To avoid having to decrease the image quality, foveated rendering greatly reduces the cost of the 210-degree field of view (FOV) by only rendering the area their eye is focused on in high detail.

How it works

Foveated rendering is a device-performance optimization technique that concentrates rendering resources on the area of the display where the user looks. The content in the area immediately surrounding the user’s gaze point is rendered in high resolution. The rest of the image — the part in the user’s peripheral vision — is rendered at lower resolutions, reducing the resources needed to render a scene without any perceived degradation in user experience.

Static (Fixed) Foveated Rendering

The static approach to foveated rendering, or what some call fixed foveated rendering, assumes that the user focuses on the center of the screen (which is usually true). The illustration shows how fixed foveated rendering works in a VR headset by portioning the screen into hardcoded zones. The assumed region of user attention — indicated by the white part in the center of the screen — is rendered at 100%. The gray sections are rendered at medium resolution, and the light blue areas at low resolution, reducing the resources needed to render the full scene.

You can implement static foveated rendering on just about any device, and you will likely see some degree of resource optimization. Still, it does not always yield an optimum user experience. The level of peripheral distortion introduced by early generations of lenses provided an opportunity to reduce the resolution in areas where the image would be blurred anyway. However, as lens quality has risen, the entire field of view needs to be rendered in high resolution.

Dynamic Foveated Rendering

Dynamic foveated rendering leverages the actual region of the user’s attention to fully render a small portion of the image (illustrated by the white area), expanding outward to medium (gray) and low resolution (light blue) with no degradation of quality or user experience. To implement dynamic foveated rendering, you need accurate, low latency eye tracking that can repeatedly deliver the exact gaze point of the user in real-time.

Some benchmark tests done on dynamic foveated rendering have yielded phenomenal results. In one that ran on a Pico headset with the Unity engine, GPU shading load dropped by up to 72% with an average of about 60%. These tests revealed a drastic improvement in the stability of frame rates, which didn’t drop below 90 FPS with dynamic foveated rendering enabled. And that’s great for user experience.

Benefits

Rendering

Rendering in XR is done via multi-stage pipelines. Depending on the rendering architecture of the device, foveated rendering can deliver performance savings in specific pipeline parts, which in turn can translate to faster rendering.

Overall processing savings are relative to the proportion of the rendering pipeline processing that can be foveated. In both absolute and relative terms, savings increase with increasing resolution and pixel/fragment shader or lighting complexity. They increase the gains achieved by reducing the per-pixel processing costs and tend to increase the relative processing load of the parts of the pipeline that can be foveated.

Based on Tobii testing of Qualcomm foveated rendering and NVIDIA Variable Rate Shading foveated rendering together with third party testing of Logarithmic Remapping deferred foveated rendering have all shown 60% or greater net processing cost reductions to the foveated portions of their respective rendering pipelines.

Power Savings

These processing savings can also translate to power savings. GPU power consumption typically relates to a combination of GPU frequency and GPU utilization, where foveation can only directly affect GPU utilization.

Application developers do not generally have direct control over GPU frequency, however for hardware manufacturers that do (or can expose the control), there are some potentially significant benefits to power consumption.

Increasing GPU frequency comes at an exponentially increasing cost in terms of power consumption. Reducing the frequency even slightly can produce significant power savings. The exponential nature of the power consumption and the power floor required to maintain operation does however mean that returns decrease with larger frequency reductions.

As a simplified example, an application that is only utilizing the GPU for 50% of each frame could potentially run at half the frequency, which would consume far less power.

Visual Quality

Foveated rendering can also allow for better visual quality of your application. Since fewer resources have to be spent on rendering peripheral areas, the freed capacity can be reinvested in graphical fidelity. Several scenarios are possible:

• The freed GPU time can be used for more complex lighting and shaders. Any computation that primarily works on fragments or pixels can benefit here.
• Increasing resolution is another alternative. With the trend to larger resolutions in XR, the foveated regions will benefit particularly. With fixed-resolution displays, there may not be the option to increase the final resolution. However, super-sampling (rendering at a higher resolution and then filtering and shrinking the images) directed by eye tracking can give increased detail and better anti-aliasing with the processing more effectively directed than with MSAA or non-eye-tracked super-sampling.
• Dynamic foveation improves the visual quality over static foveation. While static foveation allows for some savings, they are dictated by the optical properties of the device’s lenses. Today, the effect of static foveation is already quite visible, and with improved optics and a larger field of views, the potential savings will diminish. Dynamic eye tracking foveation, in contrast, can be almost imperceivable, hence improving the visual quality.

Foveation, by definition, introduces some artifacts in the user’s visual periphery due to the lowered rendering quality. The goal is to ensure these artifacts stay below the user’s perception threshold. Similarly to how static foveation can hide these artifacts in the device lenses’ zone of imperfection, foveated rendering can hide them in the user’s peripheral vision.

Conclusion

In conclusion, the contributions of foveated rendering to VR devices and user experience are undeniable. This type of optimizations and quality increase not only makes this experience accessible and responsive, but also offers great development in the fields of enterprise, training, medical and education. Thanks to these developments, we can come up with innovative solutions and sign a better future.

Citations

“What is foveated rendering?”, Tobii, https://www.tobii.com/blog/what-is-foveated-rendering, Accessed 1 Nov. 2024

“Foveated rendering on StarVR One”, ZeroLight, https://zerolight.com/news/foveated-rendering-on-starvr-one-2, Accessed 1 Nov. 2024

“Foveated Rendering”, Tobii, https://developer.tobii.com/xr/learn/foveation/rendering/, Accessed 2 Nov. 2024

About Me

My name is Huseyn, and I’m a 16-year-old entrepreneur and game developer who is really passionate about innovation and creating new and complex stuff. Since I was twelve years old, I have been interested in programming and have created a number of startups and projects. I currently work as the community manager at GamePons, as a young member at The New York Academy of Sciences, and as a member of TKS’s Cohort ’24. Aside from that, I enjoy working on low-level projects like graphics programming and assisting others to advance in their careers. You can get more information about me via my personal website.

Feel free to contact me if you have any questions about my article or if you would like to connect via LinkedIn or E-mail.

Introduction

Before we dive into the code, let’s take a moment to understand what Tic-Tac-Toe is and what our objectives are in building this game.

Tic-Tac-Toe is a two-player game played on a 3x3 grid. The goal of the game is to be the first to get three of your symbols (either “X” or “O”) in a row, column, or diagonal. If the entire board is filled, and no player has achieved this, the game is declared a draw.

Setting Up Zig

To get started, you’ll need to have Zig installed on your computer. You can download it from the official Zig website: ziglang.org.

The Zig Code

Now, let’s take a closer look at the Zig code that powers our Tic-Tac-Toe game. I won’t cover every detail of the code here, but I’ll provide an overview of its key components.

const std = @import("std");
const print = std.debug.print;

const Movement = struct { move: u8, place: u8 };

fn get_move(move: u8, table:[3][3]u8) !Movement {
    const stdin = std.io.getStdIn().reader();

    var movement: Movement = undefined;


    print("Player {c} -> Enter place: ", .{move});

    var buffer: [1024]u8 = undefined;

    var place:u8 = undefined;

    if(try stdin.readUntilDelimiterOrEof(buffer[0..], '\n')) |input| {
        while(input[0] < 48 or input[0] > 57){
            return try get_move(move, table);
        }
        place = input[0]-48;
    }else {
        return try get_move(move, table);
    }

    movement.move = move;
    movement.place = place;

    // Error handling
    while(movement.place < 1 or movement.place > 9){
        return try get_move(move, table);
    }
    var index = movement.place-1;
    while(table[index / 3][index % 3] == 'X' or table[index / 3][index % 3] == 'O'){
        return try get_move(move, table);
    }

    return Movement{ .move = move, .place = place };
}

fn check_win(table: [3][3]u8) !u8 {
    if ((table[0][0] == 'X' and table[0][1] == 'X' and table[0][2] == 'X') or // Horizontal: 1
        (table[1][0] == 'X' and table[1][1] == 'X' and table[1][2] == 'X') or // Horizontal: 2
        (table[2][0] == 'X' and table[2][1] == 'X' and table[2][1] == 'X') or // Horizontal: 3
        (table[0][0] == 'X' and table[1][0] == 'X' and table[2][0] == 'X') or // Vertical: 1
        (table[0][1] == 'X' and table[1][1] == 'X' and table[2][1] == 'X') or // Vertical: 2
        (table[0][2] == 'X' and table[1][2] == 'X' and table[2][2] == 'X') or // Vertical: 3
        (table[0][0] == 'X' and table[1][1] == 'X' and table[2][2] == 'X') or // Diagonal: ↘
        (table[0][2] == 'X' and table[1][1] == 'X' and table[2][0] == 'X'))   // Diagonal: ↙
    { 
        return 'X';
    }
    else if ((table[0][0] == 'O' and table[0][1] == 'O' and table[0][2] == 'O') or // Horizontal: 1
        (table[1][0] == 'O' and table[1][1] == 'O' and table[1][2] == 'O') or // Horizontal: 2
        (table[2][0] == 'O' and table[2][1] == 'O' and table[2][1] == 'O') or // Horizontal: 3
        (table[0][0] == 'O' and table[1][0] == 'O' and table[2][0] == 'O') or // Vertical: 1
        (table[0][1] == 'O' and table[1][1] == 'O' and table[2][1] == 'O') or // Vertical: 2
        (table[0][2] == 'O' and table[1][2] == 'O' and table[2][2] == 'O') or // Vertical: 3
        (table[0][0] == 'O' and table[1][1] == 'O' and table[2][2] == 'O') or // Diagonal: ↘
        (table[0][2] == 'O' and table[1][1] == 'O' and table[2][0] == 'O'))   // Diagonal: ↙
    { 
        return 'O';
    }
    else if (
        table[0][0] != ' ' and table[0][1] != ' ' and table[0][2] != ' ' and
        table[1][0] != ' ' and table[1][1] != ' ' and table[1][2] != ' ' and
        table[2][0] != ' ' and table[2][1] != ' ' and table[2][2] != ' '
    ) {
        return 1;
    }
    else {
        return 0;
    }
}

fn print_table(table: [3][3]u8) !void {
    print("\n", .{});
    for (table, 0..) |row, i| {
        for (row, 0..) |item, j| {
            print(" {c} ", .{item});
            if (j != 2) {
                print("|", .{});
            }
        }
        if (i != 2) {
            print("\n------------\n", .{});
        } else {
            print("\n", .{});
        }
    }
    print("\n", .{});
}

fn print_welcome() !void{
    print("---------------------------\n", .{});
    print("Welcome to Tic-Tac-Toe Game\n", .{});
    print("---------------------------\n", .{});
}

fn print_bye(winState: u8) !void{
    print("------------------\n", .{});
    print("Game Ended! ", .{});
    if(winState == 'X') std.debug.print("X won!\n", .{})
    else if(winState == 'O') std.debug.print("O won!\n", .{})
    else std.debug.print("Draw!\n", .{});
    print("------------------\n", .{});

    print("\nPress 'Enter' to exit... ", .{});
    var buffer: [1024]u8 = undefined;
    const temp = (try std.io.getStdIn().reader().readUntilDelimiterOrEof(buffer[0..], '\n')).?;
    _ = temp;
}

pub fn main() !void {
    var table = [3][3]u8{ [3]u8{ ' ', ' ', ' ' }, [3]u8{ ' ', ' ', ' ' }, [3]u8{ ' ', ' ', ' ' } };
    var move: u8 = 'X';

    try print_welcome();

    var winState = try check_win(table);

    while (winState == 0) {
        try print_table(table);

        var movement = try get_move(move, table);

        const index = movement.place - 1;
        table[index / 3][index % 3] = move;

        move = if(move == 'X') 'O' else 'X';

        winState = try check_win(table);
    }

    try print_table(table);

    try print_bye(winState);
}

The get_move Function

The get_move function is responsible for taking player input and validating it. It ensures that the entered move is within the valid range and that the selected cell is not already occupied.

fn get_move(move: u8, table:[3][3]u8) !Movement {
    const stdin = std.io.getStdIn().reader();

    var movement: Movement = undefined;


    print("Player {c} -> Enter place: ", .{move});

    var buffer: [1024]u8 = undefined;

    var place:u8 = undefined;

    if(try stdin.readUntilDelimiterOrEof(buffer[0..], '\n')) |input| {
        while(input[0] < 48 or input[0] > 57){
            return try get_move(move, table);
        }
        place = input[0]-48;
    }else {
        return try get_move(move, table);
    }

    movement.move = move;
    movement.place = place;

    // Error handling
    while(movement.place < 1 or movement.place > 9){
        return try get_move(move, table);
    }
    var index = movement.place-1;
    while(table[index / 3][index % 3] == 'X' or table[index / 3][index % 3] == 'O'){
        return try get_move(move, table);
    }

    return Movement{ .move = move, .place = place };
}

Checking for a Win

The check_win function checks the game board to determine if a player has won or if the game has ended in a draw.

fn check_win(table: [3][3]u8) !u8 {
    if ((table[0][0] == 'X' and table[0][1] == 'X' and table[0][2] == 'X') or // Horizontal: 1
        (table[1][0] == 'X' and table[1][1] == 'X' and table[1][2] == 'X') or // Horizontal: 2
        (table[2][0] == 'X' and table[2][1] == 'X' and table[2][1] == 'X') or // Horizontal: 3
        (table[0][0] == 'X' and table[1][0] == 'X' and table[2][0] == 'X') or // Vertical: 1
        (table[0][1] == 'X' and table[1][1] == 'X' and table[2][1] == 'X') or // Vertical: 2
        (table[0][2] == 'X' and table[1][2] == 'X' and table[2][2] == 'X') or // Vertical: 3
        (table[0][0] == 'X' and table[1][1] == 'X' and table[2][2] == 'X') or // Diagonal: ↘
        (table[0][2] == 'X' and table[1][1] == 'X' and table[2][0] == 'X'))   // Diagonal: ↙
    { 
        return 'X';
    }
    else if ((table[0][0] == 'O' and table[0][1] == 'O' and table[0][2] == 'O') or // Horizontal: 1
        (table[1][0] == 'O' and table[1][1] == 'O' and table[1][2] == 'O') or // Horizontal: 2
        (table[2][0] == 'O' and table[2][1] == 'O' and table[2][1] == 'O') or // Horizontal: 3
        (table[0][0] == 'O' and table[1][0] == 'O' and table[2][0] == 'O') or // Vertical: 1
        (table[0][1] == 'O' and table[1][1] == 'O' and table[2][1] == 'O') or // Vertical: 2
        (table[0][2] == 'O' and table[1][2] == 'O' and table[2][2] == 'O') or // Vertical: 3
        (table[0][0] == 'O' and table[1][1] == 'O' and table[2][2] == 'O') or // Diagonal: ↘
        (table[0][2] == 'O' and table[1][1] == 'O' and table[2][0] == 'O'))   // Diagonal: ↙
    { 
        return 'O';
    }
    else if (
        table[0][0] != ' ' and table[0][1] != ' ' and table[0][2] != ' ' and
        table[1][0] != ' ' and table[1][1] != ' ' and table[1][2] != ' ' and
        table[2][0] != ' ' and table[2][1] != ' ' and table[2][2] != ' '
    ) {
        return 1;
    }
    else {
        return 0;
    }
}

Displaying the Game Board

The print_table function displays the current state of the game board. It's crucial for players to see the board and make their moves.

fn print_table(table: [3][3]u8) !void {
    print("\n", .{});
    for (table, 0..) |row, i| {
        for (row, 0..) |item, j| {
            print(" {c} ", .{item});
            if (j != 2) {
                print("|", .{});
            }
        }
        if (i != 2) {
            print("\n------------\n", .{});
        } else {
            print("\n", .{});
        }
    }
    print("\n", .{});
}

Running the Game

In the main function, the game loop is implemented. It continually takes player input, updates the board, and checks for a win or draw until the game is over.

pub fn main() !void {
    var table = [3][3]u8{ [3]u8{ ' ', ' ', ' ' }, [3]u8{ ' ', ' ', ' ' }, [3]u8{ ' ', ' ', ' ' } };
    var move: u8 = 'X';

    try print_welcome();

    var winState = try check_win(table);

    while (winState == 0) {
        try print_table(table);

        var movement = try get_move(move, table);

        const index = movement.place - 1;
        table[index / 3][index % 3] = move;

        move = if(move == 'X') 'O' else 'X';

        winState = try check_win(table);
    }

    try print_table(table);

    try print_bye(winState);
}

Conclusion

Congratulations! You’ve just created a simple yet functional Tic-Tac-Toe game in Zig. This project not only allowed you to flex your programming muscles but also provided valuable experience in handling user input, implementing game logic, and creating a fun interactive application.

Feel free to expand on this project by adding more features, such as a graphical user interface (GUI) or implementing an unbeatable AI opponent.

Happy coding!

Dunger is an open-source project I’ve been working on, designed to streamline the process of creating procedurally generated dungeons in Unity. Whether you’re developing a game, simulation, or any Unity project that requires dynamic-level design, Dunger is your go-to solution.

Key Features of Dunger:

• Procedural Dungeon Generation: Dunger streamlines the process of generating dungeons with just a few clicks. It uses procedural algorithms to create unique layouts, ensuring that players never experience the same dungeon twice.
• Unity Integration: Built exclusively for Unity, Dunger seamlessly integrates into your Unity projects. You can easily incorporate it into your game development workflow and start generating dungeons in no time.
• Configurable Parameters: Customize the dungeons to fit your specific needs. Adjust parameters like dungeon size, complexity, and room distribution to achieve the desired level of challenge and variety.
• User-Friendly Interface: Dunger provides an intuitive interface that makes it accessible to both seasoned developers and newcomers. You don’t need to be a coding expert to create captivating dungeons.
• Documentation and Support: Dunger comes with comprehensive documentation and support resources to help you get started and troubleshoot any issues you might encounter.

Why Choose Dunger:

Dunger simplifies the process of adding randomized dungeons to your Unity games or applications. Whether you’re developing a roguelike adventure, a dungeon crawler, or any game that benefits from procedural level design, Dunger can save you time and effort while enhancing the player experience.

With Dunger, you can harness the power of procedural generation in Unity to keep your players engaged with fresh and unpredictable dungeons, making your project stand out in the world of game development.

Get started with Dunger in Unity today and bring dynamic dungeon exploration to your game world!

Built With

Dunger is powered by the Unity game engine, harnessing its versatile capabilities for seamless integration and exceptional performance. The project leverages Unity’s robust tools and resources to provide a user-friendly environment for generating random dungeons. With Dunger, you can take advantage of Unity’s powerful features to create dynamic and engaging game worlds filled with procedurally generated dungeons.

Getting Started

This is an example of how you may give instructions on setting up your project locally. To get a local copy up and running follow these simple example steps.

Prerequisites

Before installing Dunger, ensure that you have the following prerequisites in place:

• Unity: Dunger is specifically designed for the Unity game engine. Make sure you have Unity installed on your development machine. You can download Unity from the official Unity website.
• GitHub Access: If you plan to clone Dunger from GitHub, you’ll need a GitHub account and a Git client installed on your machine for version control.
• Existing Unity Project: If you’re integrating Dunger into an existing Unity project, ensure that your project is set up and compatible with the Unity version specified in Dunger’s documentation.

Having these prerequisites in order will help you smoothly install and work with Dunger in your Unity environment.

Installation

Dunger offers a hassle-free installation process, providing two convenient options:

Cloning from GitHub:

To start a new project with Dunger, simply clone the Dunger repository from GitHub to your local machine. You can then open the project directly in Unity, making it easy to get started with dungeon generation right away.

1. Clone the repo

git clone https://github.com/coderloff/dunger

2. Open the cloned project using Unity Hub

Importing as a Unity Package:

If you already have an existing Unity project and want to integrate Dunger, you can import it as a Unity package. This allows you to seamlessly add Dunger’s dungeon generation capabilities to your ongoing project, enhancing its gameplay with dynamic dungeons.

1. Download unitypackage by clicking here
2. Open your Unity project
3. Double-click on the downloaded package
4. Click install in Unity

Usage

Using Dunger to generate random dungeons in your Unity project is a straightforward process. Here’s a quick guide:

1. New Project Setup: If you’re starting a new project, clone Dunger from GitHub and open it in Unity. Dunger will be ready to use, and you can begin customizing and generating dungeons right away.
2. Existing Project Integration: If you have an existing Unity project, import Dunger as a Unity package. Once integrated, you can access Dunger’s functionality through Unity’s user-friendly interface.
3. Customization: Customize your dungeons by adjusting parameters such as size, complexity, and room distribution to achieve the desired level of challenge and variety.
4. Script Integration: For advanced users, Dunger offers script-based integration, allowing you to control dungeon generation programmatically. Use this option to create unique and dynamic gameplay experiences.

Contributing

We welcome contributions from the community to help Dunger thrive. Here’s how you can get involved:

1. Filing Issues: If you encounter bugs or have suggestions for improvements, please open an issue on our GitHub repository. Be sure to provide details and context to help us understand the issue.
2. Pull Requests: We appreciate pull requests for bug fixes, feature enhancements, or new additions. Make sure your contributions align with our project’s goals and coding standards.
3. Documentation: Improving our documentation is a valuable way to contribute. If you find areas that need clarification or want to add examples, your help is greatly appreciated.
4. Community Support: Join discussions, answer questions, and share your knowledge on our community forums. Your expertise can be a valuable resource for fellow Dunger users.
5. Spread the Word: Help us grow the Dunger community by sharing your experiences with others. Tweet about your projects, write blog posts or create tutorials featuring Dunger.