Siddhant Madhur

The most fun project I've worked on, a custom, high-performance 3D game engine for Windows built from scratch in C++ and D3D11. My goal for building this was to produce simulation games like Civilization VI, or RollerCoaster Tycoon where there are thousands of entities being simulated per frame.

I had a great time exploring and learning the following concepts to build the engine:

• Multi-threading and shared memory to decouple rendering, processing and other tasks onto different threads, increasing FPS
• Entity component systems to handle thousands of entities in an efficient data-oriented structure
• Optimization techniques like back-face culling and object pooling.

I also read the following books to implement the engine:

• Game Engine Architecture, by Jason Gregory
• Introduction to 3D Game Programming with DirectX 11, by Frank Luna

This project provided an alternative to Plex and Jellyfin, popular self-hosted software that let users stream local media files, such as movies or family photos, over the internet to a client or website. It handled things like transcoding video to different resolutions, picking subtitles, watch history and more. My motivation for building an alternative came from Plex putting basic features like GPU acceleration and remote streaming behind a paywall.

The most interesting feature I implemented for this was the dynamic video transcoding system. Heres a brief on the feature:

• Problem: Movies are often extremely high bitrate (35-70 Mbps), but if you're watching on a phone or tablet, you don't need the 4K version, you need a version that is much smaller and could possibly even be downloaded without taking up a lot of storage.
• General Solution: Large companies like Netflix and YouTube convert video into multiple versions (such as SD, HD, Ultra-HD) ahead of time, but this creates multiple unnecessary versions of the same file which takes up extra GPU compute, and storage.
• Dynamic Transcoding: When a user requests a version, the program runs ffmpeg and creates a live-stream with the exact resolution required. Then it manages a small buffer ahead, so if the computer slows down for a second it doesn't buffer, or if the user changes resolution it hasn't wasted compute.

While this sounds easy to implement, the problem arose from tricking a player (mpv) into thinking the whole file is present while streaming, or handling moments where the user skips ahead to another moment and ffmpeg needed to be shutdown and started at the new point. Tracking all this, along with handling garbage collection was an extremely fun challenge to solve, and it taught me a lot about HLS and how large livestreaming sites like Twitch or YouTube operate!