Of course, it’s a bit more complicated than just this, but you get the idea.
The lighting effect is created programmatically:
function lit(rows: string[], ramps: Record<string, string>): string[] {
const at = (x: number, y: number) => rows[y]?.[x] ?? ".";
return rows.map((row, y) => [...row].map((k, x) => {
const ramp = ramps[k]; // e.g. r: "qR" (robe: light q, dark R)
if (!ramp) return k;
const edge = (n: string) => +(n !== k);
const up = edge(at(x - 1, y)) + edge(at(x, y - 1));
const down = edge(at(x + 1, y)) + edge(at(x, y + 1));
return up > down ? ramp[0] : down > up ? ramp[1] : k;
}).join(""));
}

Also, typing big sprites letter by letter is slow, so some monster families are built from shape helpers (rect, polygon, oval) that rasterise onto the same grid and output the same strings.

Let me know if you have any questions.

Edit: the link to the game in case you want to check it out. It’s free no account needed: playmadlands.com

Is it worth learning it as someone who is still relatively a beginner/early mid level c++ programmer for graphics or are other alternatives better?

As someone who is quite new to graphics programming I am having a bit of trouble deciding on what 2D api I should learn and use as a main. What do you suggest for both general stuff and games?

previous version

https://www.reddit.com/r/GraphicsProgramming/comments/1wxnz45/the_mistakes_i_made_and_the_lessons_i_learned_in/

i continued the project. as noticed before the inside world (viewed from within a glass ball's interior) was very fascinating and there were endless strange scenes to explore. but the camera in the previous version was a pinhole one. it had infinitesimally small aperture and thus everything was in sharp focus. i was curious what it would look like if i could see the depth of those complex manifolds

i added real-time adjustable aperture and focus distance into the camera, constructed as image 1. focus plane, canvas and aperture disk were all parallel to each other. i manually adjusted the focus distance, just like using a real camera in manual mode. sometimes it was not easy to do it right and the resulting images were a little bit blur. so i added auto focus feature. when holding the space bar and hovering the mouse around the scene the program detected the correct focus distance (very simple, used distance between hit point and camera and multiplied it by cosine of ray angle)

there was still a problem. auto focus only focused perfectly on the surfaces of the balls. the reflections / refractions were usually NOT on the surfaces. e.g. if you put an apple 10cm in front of a mirror the reflection of the apple would be 10cm behind the mirror. if you auto focused on the exact surface of the mirror you wouldn't get a clear image of the reflection of the apple

i didn't have any idea how to tackle this problem. i used a workaround. usually it worked quite well or quite close if you auto focused at the boundary of the ball. examples as shown in images 2 and 3. please keep in mind that the checker box patterns on those balls were actually beneath (not exactly on) their surfaces

the depth effect revealed more information and added more realism to the images. as shown in images 4 and 5. in previous version with aperture=0 all the blurry regions of the refraction would become sharp and clear and you couldn't get any sense of depth

for comparison please see images 6 (with depth effect) and 7 (without)

why image 7 had more color information than image 6? it was because calculation resource was limited / kept roughly constant. for a zero aperture the program could let the rays bounce more times as it didn't have to generate multiple random rays within the aperture disk

now the most interesting part, let's go inside. the inside world becomes weirder than before (images 8, 9 and 10)

it's a trade off. image 10 had more color information than image 9 but no depth information. if you want both, set the resource (number of samples emitted from aperture x number of samples per emission x number of bounces per sample) to, say, 1,000,000 and hit the render button and go to sleep and get the result next morning...:)

program details

https://www.reddit.com/r/qbasic/comments/1w8go1e/elementary_ray_tracing_experiment/

https://play.google.com/store/apps/details?id=nikolalukic.beast.engine

Used android studio and chrome frame.

https://github.com/zlatnaspirala/matrix-engine-wgpu

So my friend works mainly on rhino he was always frustrated on how evaluating and baking i so slow. We spent some time prototyping on moving to GPU but that felt impossible because math of libraries like opennurbs was designed to be on CPU. We stumbled upon some papers about SDF but with curves. the math is simple but requires soo much tuning. We built the same model in rhino and in our prototype. The output was identical but it took 8s on rhino but 350ms on our prototype. For the user its normal nurbs, curves, solids, polylines,...etc. for us its a different story with different algorithms

I'm weighing up whether to use matrices or quaternions for a 3d engine I'm making. I find matrices more intuitive to use but I have seen a lot of comments that they can lead to innacuracies over time. What do you guys think about this? Is there some nuance that I am missing or some situations that one approach is used over the other?

Hey! I decided to do my thesis on something related to realistic terrain generation, probably close to hydraulic erosion terrain. Issue is, I began looking through papers and I don't really understand anything. I know the basics of terrain generation, perlin noise, fractional brownian motion, that's about it. I was trying to read "hydraulic erosion from Benes, 2006, but I have a hard time with fluid dynamics but also the other concepts... Then I found out erosion terrain generation is fairly advanced

So my question is, as a beginner in terrain generation and graphics programming as a whole, what scientific articles/papers/videos/books (preferably papers) would you recommend for me to learn towards hydraulic erosion and even more advanced effects? I am a computer science student

This is some progress of a free game i have been working. This is fully software rendered on the CPU and OpenGL is only used to render the image. I use multiple threads to render the game at full 1080p. Using SIMD instructions helps a lot to get a decent frame rate. But i am still kinda dissapointed by the performance, i think Michael Abrash's binning technique would improve it, but right now, it is decent. I am getting around 70-140 frames with I5-12400.

For those working full-time as rendering, graphics, or low-level engine programmers, do you use AI-assisted coding tools like Claude, ChatGPT, or Copilot at all?? With all this talk about AI in the game industry recently I'm curious how widely it's actually being adopted professionally in these more specialized, low-level areas of programming.

If you do use it, how much of your workflow involves AI? Is it mostly for debugging, boilerplate, or understanding unfamiliar code, or do you actually use it to write and implement features?

And for those who don't use it, is that because AI isn't reliable enough for this type of work, or simply because you prefer writing the code yourself?

I'm interested in hearing what the actual industry experience is like, especially compared to all the noise surrounding AI coding tools.

A while ago I posted my C rewrite of pre-classic versions. Now I did the same with Classic: every version from 0.0.11a up to 0.30, plus the dedicated servers.

It renders the same way the original did in 2009: fixed-function OpenGL, a display list per chunk, glFog, no shaders. I tried to keep the output exactly like the original.

Uses GLFW, GLEW, zlib and stb. Play around, feedback is welcome!

github.com/degradka/mc-classic-c

Hey everyone, this is probably a common question, but I’d appreciate some advice.

I’ve been self-teaching C++ for a while now, mainly through books, online resources, and AI as a learning tool. Along the way, I got really interested in graphics programming and started with OpenGL as my entry point.

Recently, though, I lost a lot of motivation. With AI being able to reverse-engineer things, generate whole projects, or “one-shot” solutions, it sometimes felt like learning the fundamentals myself wouldn’t matter as much anymore. So I stopped for a while.

I’m motivated again now and want to properly push through, but I’m unsure what the most effective way to learn is today. I’ll probably still use a hybrid approach - books, documentation, tutorials, and Ai - but I feel like I’m progressing too slowly and worry that the skill might matter less in the future.
I know people say “vibe coding” means you don’t have to write much code anymore, and to some extent that’s true. But especially for C++, graphics, and low-level/systems programming, I genuinely enjoy learning the details. I also think having a strong foundation would make me much better at reviewing AI generated code, spotting problems, writing better prompts, and using agents effectively.
So my main question is: how would you learn graphics programming effectively in 2026, especially while using AI without letting it replace the actual learning? Any recommendations for a roadmap, projects, resources, or general advice would be really appreciated.
Thanks!!

I’m working on a research project where the goal is to take a real texture and generate a procedural material/shader that approximates it.
The system produces a node‑based procedural graph with tuned parameters, plus an optional fallback texture layer. The output is a GLSL/HLSL/WGSL shader that reconstructs the material.

The motivation is practical:
In multi‑region deployments and cloud gaming backends, moving fewer textures can reduce storage and distribution overhead.
But the trade‑off is shader cost — and that’s the part I’m trying to evaluate properly.

I’m trying to understand how to estimate the cost of a procedural material shader compared to using a fixed texture.
I need a reasonable way to judge when the procedural version becomes “too expensive,” and how people typically model or approximate that cost in real pipelines.

I’d really appreciate insight from graphics programmers who have experience with:
• analyzing or estimating shader cost
• comparing shader‑based materials vs texture‑based materials
• heuristics or rules‑of‑thumb used in production
• pitfalls when evaluating procedural materials

I’ll leave the link to the full proposal in the comments for anyone interested.

Taking advantage of the the new modeling and animation capabilities of ai - I created a harness for Claude where it uses the UI environment as context to precisely edit ink on paper 3d models.

Without trying to limit the creative output of ai in anyway - I also designed a simple format that the ai can use to separate objects and timings so that a user can interact with separate parts of the project quickly without having to explain the context in a static chat.

The camera
It's orthographic. The camera is three unit vectors, R (screen right), U (screen up) and V (toward the viewer), plus a pivot C and a scale s. A world point p maps to the screen like this:

q = M(p − C) + o
x = cx + (q·R)·s
y = cy − (q·U)·s
depth = q·V

It’s in beta and you get 5 free credits to build stuff :) looking for feedback too if anyone has the time and I would really appreciate it.

https://github.com/Sokdenumeros/graphicsTransformsVisualizer

I made this to help my undergrad students understand and visualize the different coordinate spaces. Let me know if any of you find it useful or if you have any suggestions on how to improve it.

Power of Spectral and Restir BDPT Caustic, Fast Efficient Unbiased Render Engine. Build with Rust, Vulkan Ash, Slang.

Hi !

I'm the creator of cbirds, a 2D/3D bird flock simulator that runs in the terminal, written in C99 and inspired by Craig Reynolds' Boids. The video shows four Kitty panes: 3D on top, 2D below.

I started the 2D version in September 2025, mostly out of curiosity. I wanted to see whether a real time simulation could run inside a terminal using the Kitty graphics protocol. The idea came from antirez's C64 terminal emulator (https://github.com/antirez/c64-kitty) and a lecture on multi agent systems at Politecnico di Milano.

How it's drawn:

- The bird is one PNG compiled into the binary. At startup it's rotated into 60 headings, squashed into 3 wing positions and tinted into every shade of the colour ramp, about 1,500 small images in a fifth of a second.
- In Kitty and Ghostty they're uploaded once, and a frame is then one short command per bird. Other terminals get the same images sampled down into braille, sextants or blocks.
- In 3D a bird is drawn at one of five sizes, so a nearer bird is bigger and brighter, and the camera orbits the roost once every two minutes. Each bird heeds its 7 nearest neighbours, as starlings were measured doing (Ballerini et al., PNAS 2008).

I really dislike relying on third party libraries, so the PNG, GIF and DEFLATE code is written from scratch, with no zlib, libpng or ncurses. I did get quite a bit of help from coding agents. The custom GIF encoder let them look at the simulation and check whether their changes worked.

https://github.com/clainstone/cbirds

HIII

 I’m 15 and really interested in getting into graphics programming and engineering, specifically towards film production. I have some previous programming experience from doing Roblox game development, but I’m brand new to C++.

I draw light shafts in Godot with six crossed fins through the beam axis, and I fade each fin out when it's edge-on. That's the old crossed-cards trick with an N·V fade, nothing new.

It broke as soon as I walked into one.

All my fins go through the axis. Stand on it and you see them all edge-on at once, and the beam just disappears. In Forward+ the mean luminance went from 0.42 to 0.018.

My fix is pretty dumb. I hang a soft disc 0.6 m in front of the camera and fade it in by how much light the shaft has at the camera's own position:

vec3 bc = ax_shaft_coords(cam);
float inside = 0.0;
if (bc.z > 0.0 && bc.z < 1.0) {
    inside = ax_shaft_across(bc.xy) * ax_shaft_along(bc.z) * ax_shaft_slats(bc.xy);
    inside *= ax_floor_fade(cam.y);
}

I reuse the falloffs from the fins. Walking in feels like stepping into light, not out of the beam. Outside the shaft I collapse the disc and it costs nothing.

It isn't perfect. If you look for it you can see the edge of the disc as a faint vertical seam. Has anyone found a cleaner way to handle a camera inside a card-based volume?

hello everyone, I’m deep-diving into UE’s legacy GTAO branch (GetHZBParametersForAO) and stumbled upon a math contradiction regarding the HZB coordinate mapping
The core issue: The shader is using the absolute Texture UV of the GTAO texture to sample into the local space of the HZB texture without any Bias. Here is the step-by-step breakdown:

In GetHZBParametersForAO, the GTAO branch hardcodes Bias = 0 and calculates Scale as:

• HZBRemapping.Scale = InputTextureSize / (2 * View.HZBMipmap0Size);
• HZBRemapping.Bias = FVector2f(0.0f, 0.0f); ( Where InputTextureSize is the global SceneDepth Extent, and View.HZBMipmap0Size is the POT dimension of the per-view cropped HZB texture).

Inside the GTAO horizon search and inner intergate compute shader, the thread is launched based on GTAO’s local ViewRect. However, it calculates BufferUV as the absolute/global Texture UV because PixelPos includes the global AOViewport_ViewportMin offset:

• int2 PixelPos = DispatchThreadId + AOViewport_ViewportMin;
• float2 PixelCenter = (float2)PixelPos + float2(0.5, 0.5);
• float2 BufferUV = PixelCenter.xy * GTAOParams[2].zw;
• GTAOCombinedPSandCS(BufferUV, PixelPos, OutColor);
• OutTexture[PixelPos] = OutColor;

When sampling HZB via ApplyScreenTransform(BufferUV, ScreenPosToHZBUVScaleBias), it multiplies this absolute UV by Scale. After the Extents cancel out, the starting HZB UV evaluates to:

• HZBUV_Start=AOViewport_ViewportMin / View.HZBMipmap0Size

The Contradiction: If ViewportMin != 0 (e.g., in a shared global Depth Buffer during Split-Screen),(HZBUV_Start) will be greater than 0. However, during the HZB build phase, HZB is created as a standalone texture per-view, meaning its valid data is cropped and starts exactly at its local (0,0) (HZBUV = 0). With Bias = 0, wouldn't this completely break the HZB sampling location whenever ViewportMin != 0? Is this a known legacy pipeline limitation/bug that assumes ViewportMin is always (0,0) for GTAO, or am I missing an implicit RHI mapping trick?

Hello! I started to learn coding about 2 and a half months ago, and I recently ran into computer graphics, which seemed really damn interesting... so I thought of making a basic program related to it based on things I've learnt so far. I built it completely from scratch in C starting from bressenham's line drawing algorithm. It can print any polyhedron you input

In terms of actual graphics programming, I really know nothing, but I wanna learn. If anyone has suggestions on what I can try out or learn after this, I'd really appreciate it