My "No Graphics API" blog post is live! Please repost :) www.sebastianaaltonen.com/blog/no-grap... I spend 1.5 years doing this. Full rewrite last summer and another partial rewrite last month. As Hemingway said: "First draft of everything is always shit".

"Parkour City" was one of the first bigger games in HypeHype. It looked pretty bad two years ago. With our new renderer, this game today looks pretty good. I did a minor remix: Changed the visual style preset and tweaked the sun and fog settings.

For most people, virtual texturing is a streaming tech. For me, it's always been a way for the GPU to access all texture data simultaneously -> max batching + no binding cost. VT is a surface cache for the visible pixel data set. Caches your material blending and decals -> big perf win.

My hot take is that promotion of ECS and "kernelization" were one of the most harmful ideas in game programming. They apply only selectively, and were preached like a religion by angry individuals "if you don't do it, you are incompetent, silly or lazy, and your performance will suck!"

Our tech artist did a test scene with our forthcoming virtual texturing system. This scene uses just three 256x256 PBR materials (3 textures each). Total memory consumption (ASTC4x4/BC7) = 0.56MB Total storage cost (2bpp AVIF) = 144KB www.youtube.com/watch?v=IjlE...

In our next Tiny Glade update we'll bump the light limit from 32 to 32k while keeping the cost more or less the same. The small limit has been a cop out, as we didn't quite know how to render huge numbers of (screen-space) shadow-casting lights without severe performance degradation.

3->4 shadow cascades performance (M3 Max): 3 cascades: Vertex = 0.20ms Pixel = 0.07ms 4 cascades: Vertex = 0.39ms (195%) Pixel = 0.11ms (157%) On M3 Max, a total cost of 0.5ms for good-looking shadows is a no-brainer. However, a 185% cost is too much for low- and mid-tier phones.

Here's a recording of my Tiny Glade presentation from the Graphics Programming Conference 2024: www.youtube.com/watch?v=jusW... It's an any% speedrun of our GPU-driven rendering, shadows, global illumination, water, and DoF, involving a few weird tricks.

Today, I added storage buffer support to HypeHype RHI and all the backends: WebGPU, Metal, and Vulkan. I tested changing some shaders to SSBO instead of UBO. Works on all platforms! Metal was the easiest. Buffers are just GPU pointers in Metal. There's no UBO or SSBO. Zero changes...

Added fourth shadow cascade for high-end devices. This is how it looks at medium distance (cascade 2): Left = 3 cascades Right = 4 cascades (click to enlarge, left/right arrows to toggle)

Trying the tiny MLP in more locations (left) vs the spherical 10m visibility it is "learning" from (right). The one node hidden layer can only coarsely approximate the visibility signal and only in one broad direction. Also not all probes manage to converge in a reasonable time.

Today we managed to switch our Flutter web build to use WASM. It's at least 3x faster. Our game engine was already using WASM. When combined with my recent WebGPU gfx backend and Jolt physics with WASM SIMD, our new web build feels almost like the native build now :)

“The first draft of anything is shit.” - Ernest Hemingway He was absolutely right. Every time I write a presentation I get that feeling. Takes a full rewrite + several polish passes to make anything feel good. Same is happening with my "No Graphics API" blog post...

Now that we shipped WebGPU and Android will be 100% Vulkan soon, we started designing compute shader pipeline. GPU-driven rendering, virtual shadow maps, compute stochastic lighting, etc. But this is not without issues on mobile. I worry about vertex work overlap...

I have been writing a massive blog post titled "No Graphics API" for a few months. Question to the gfx programmers: If you are using texel buffers (Buffer<T> in HLSL), why do you use them over raw buffers? SM 6.2 added 16 bit support and buffer.Load<T>(offset)? github.com/microsoft/Di...

“CPU-Limited” Games & Benchmarks medium.com/@opinali/cpu...

Just pushed my WebGPU gfx backend to production. Took 21 days to develop in total: native Dawn Mac + Windows first, then Emscripten for web. Runs really smoothly on the browser and the page load is super fast. Zero issues on Mac, Windows or Chrome. Safari Tech Preview has some flickering tris.

User-generated content (UGC) in a nutshell: Massive spam of physics objects and skinned characters. Runs at locked 60Hz well on modern phones. The problem is cheap 99€ Android phones with PowerVR GE8320 :(

Have been tuning HypeHype's custom GTAO implementation for two days: Morton sampling pattern, bilateral blur uses slope-based weight (instead of constant Z), 2x2 depth downsample passes use median (instead of max). Still work to do, but starts to look pretty good. Game: "Block City" by Blue Mint

Testing video upload. Seems to have 50MB limit...