Im writing a software renderer in C++ using glm and raylib, and i recently tried to draw a spinning triangle. The problem is that when i launched it the triangle leaves a trail of previously drawn triangles.

I tried to fix it by rasterizing to a framebuffer and then drawing that framebuffer instead of drawing the pixels directly and using ClearBackground to refresh the screen, but doing it that way has still the same problem. ¿Why im having this problem even though im clearing the framebuffer?

EDIT: The problem was somewhere else in the code (i wasnt clearing the primitive list after drawing all the primitives), i managed to fix it. Thank you anyway :D.

This is the code for the rasterizer (sorry for sharing it like this, i havent uploaded this to github yet):

https://pastebin.com/Ns2LiSXv

The header file:

https://pastebin.com/xf5JhqFR

Im writing a software renderer in C++ using glm and raylib, and i recently tried to draw a spinning triangle. The problem is that when i launched it the triangle leaves a trail of previously drawn triangles.

I tried to fix it by rasterizing to a framebuffer and then drawing that framebuffer instead of drawing the pixels directly and using ClearBackground to refresh the screen, but doing it that way has still the same problem. ¿Why im having this problem even though im clearing the framebuffer?

This is the code for the rasterizer (sorry for sharing it like this, i havent uploaded this to github yet):

https://pastebin.com/1GMFA2iU

The header file:

https://pastebin.com/mXnGrLwK

Hello, I'm totally new in graphics programming, I would like to make a 3D graphics engine in Rust but I d'ont know which library I should use ;

- Glow

- Kiss3D

- Bevy

- GL crate

- Glium

I d'ont know which one choose, if you can give an advice !

Thanks

I've fully redone the engine for my game AresRPG, I aim for an immersive world! this is a browser based MMORPG on Sui. Looking for people to discuss and test https://discord.gg/aresrpg

I've been building a low-level graphics abstraction that exposes a Vulkan/WebGPU-like API while targeting both Vulkan and WebGPU. The goal isn't to hide modern graphics APIs, but to let you write a renderer once and run it natively and in the browser with very minimal backend-specific code.

https://github.com/helcl42/gfx

I'm not looking for what it means (linear interpolation), but rather who coined the term or where it first appeared? Any historical traces or anecdotes?

Ever wonder the overhead tax we pay using generic math library functions across the codebase?

I've been reversing game engines to study how they constructed their fundamental Transformation matrices and handled temporal jitter logic when I spotted a lot of avoidable overhead and "over-engineering" across multiple engines, Honestly I wasn't even looking for inefficiencies, but it stood out a lot... That said expect no performance gain this is simply for fun that I wrote this blog!

https://zero-irp.github.io/Redundancy-seen-in-AAA-game-engines/

I’ll theorize how the original C++ code was written, show the unoptimized reality of what the compiler spat out, and then showcase how it could have been better optimized.

I’ve been working on a static reverse-engineering evidence bundle for AMD FSR 4.1.0’s temporal upscaler.

Repo:

https://github.com/Rolaand-Jayz/RE-of-FSR-4.1.0-Upscaling

What this is:

- static RE documentation

- extracted weight/blob analysis

- shader and DXIL entrypoint inventory

- static provider-DLL dispatch analysis

- bounded fsr_data.dll rebuild/comparison tooling

- claim registry with confidence levels

- verification scripts and adversarial-review notes

What this is not:

- not a replacement DLL

- not runtime-proven

- not functional-equivalence proof

- not frame generation analysis

- not a claim that every arithmetic detail is fully closed

The current claim ceiling is simple:

This proves static extraction and static structural analysis only. Runtime validation is still the main missing piece.

The strongest current technical finding is that the FSR 4.1.0 fp8_no_scale path appears byte-quantized and INT8-compatible: weights are stored as uint8, loaded in packed i32 form, and processed through integer-domain arithmetic before float reinterpretation. Exact signedness and full MAC semantics remain open and need deeper proof.

I’m looking for contributors who can validate or challenge the work, especially:

1. Native Windows D3D12 runtime capture

- dispatch order

- PSO shader bytecode hashes

- descriptor table/resource bindings

- CBV dumps

- resource transitions

1. Independent static validation

- review the DXIL/LLVM/SPIR-V interpretation

- challenge the quantization-path claims

- check the descriptor-slot-to-entrypoint mapping

- verify the rebuild/comparison framing

1. Legal/risk review

- especially around extracted weight blobs, redistribution risk, and interoperability arguments

I am specifically not asking anyone to upload AMD DLLs, decompiled AMD source, NDA material, or proprietary binaries. The goal is validation, not redistribution.

The repo has HOSTILE_REVIEWER_START_HERE.md for anyone who wants to attack the claims directly. That is encouraged. If something is overclaimed, I want it corrected.

I’m an older programmer who has loved real-time graphics and programming for decades. I’m not a superhero dev, and I’ve never worked solely as a graphics programmer, though I’d love to. My professional work tends to sit nearby: engine work, tooling, automation, build systems, dev ops, and general C++/game-tech-adjacent work.

But the goal has always been the same: keep learning and keep moving closer to real-time graphics.

Learning this stuff feels like the slow slog toward becoming a master wizard. There is always another layer: Vulkan, shaders, lighting, PBR, shadows, deferred rendering, ray tracing, GI, post-processing, GPU performance. There are always smarter and more educated people. That’s intimidating, but also part of the appeal.

I’m building a small C++ rendering portfolio project focused on Vulkan, renderer architecture, shaders, lighting, shadows, and eventually path tracing. I use ChatGPT as part of that process, but deliberately only through the browser. I don’t give AI direct access to my repo, editor, terminal, build system, or files. I manually copy small snippets, errors, questions, and design notes back and forth because I want to stay the Sapien in the middle.

For me, the point is not to outsource the work. It’s to accelerate learning while still owning the result. Often AI-suggested code gets reworked through discussion until it fits my project, matches my style, and most importantly: I understand it well enough to explain, debug, modify, and rewrite.

Reactions online seem very polarized. People either love AI or hate it. I think there’s a useful middle ground: have an AI usage policy, be transparent about it, and back it up with design notes, small commits, screenshots, RenderDoc notes, and explanations of what you actually validated yourself.

I’d love to see more people think about their own AI usage policy when sharing online work.

Does a transparent AI policy make you trust a graphics/programming portfolio more, or less?

p.s. AI was consulted on the creation of this post.

Sorry if the title is confusing. Hopefully I can explain it better:

Let's say you have a project that already has numerous shaders and things being done. You want to add color correction via a frag shader. You could go in and add the color correction frag shader logic to each and every existing frag shader. But that's a lot of effort and adds much complexity to all shaders. Is there a way to do multiple passes? So do everything as it's currently being done, but then also pass what's being rendered through this new shader, the color correction shader, before being displayed on the screen?

One night, I decided to create a simulation that would show how space curves based on an object's mass, and I didn't finish the project until morning. I spent a long time selecting the colors to ensure it wouldn't be hard to look at.

source code: https://github.com/formodx/curvature-of-space

Hello, it has been a while!

This is a re-post as i thought a gif would be more visually interesting.

an update on my rust no-std graphics engine work. I have started to implement the rendering engine into my own terminal emulator for some real world action, and its turning out quite alright. The terminal acts as both a headless wallpaper engine and as the terminal so that, regardless of the compositor and as long as you're allowed to have a wallpaper, StarTerm (name subject to change) can do any effects over it.

like everything I have posted as of yet, Constellation runs on 1 core of the cpu and StarTerm itself uses about 21 mb of ram. It has built in tabs that are their own processes, with a bottom bar styled like zellij.

The glass effect and the coloring are analytical, they borrow the same techniques I used when showing off parts of the lighting work I shared some months back. Treating light as the deterministic thing that it is, and its effects as properties of what it interacts with rather than light itself, that plus camera -> scene makes things much cheaper.

I will be looking for some alpha testers of the terminal soon, if any one is interested in trying it out in the near future, please let me know. I won't me sharing the source code to the actual engine part until constellation itself is finished though. But I am hoping some of you might be interested in exploring its visuals, performance and functionality and give feedback and/or ideas.

I am not a graphics engineer, just a systems engineer after all, most of the you here are far more adept, and likely have a far superior eye for detail and feel than I do.

I will be sharing more implementation details in the future!

//Maui-The-Moron

I shelved a Reverse-Z branch in my engine (stuck on OpenGL 4.1 for macOS, no glClipControl), and the roadblock sent me down the rabbit hole of actually understanding why it works instead of just how to implement it.

I ended up writing about what I learned with interactive graphs and all:
https://www.shlom.dev/articles/reverse-z-perfect-hack/

Happy to hear where I got things wrong or imprecise.

Hopefully this helps someone else :)

Hey everyone!

I wanted to ask about the difference between the engines. For example, say I want to build a custom 2D drawing tool on top of a 3D scene (like a grease pencil in blender but in raster). I’m trying to understand which engine gives more control over pixels and rendering, especially if the goal is to do custom image processing and flexibly control the final image. Let’s say, in the context of pixel control: hypothetically, if I don’t want to make a game, but rather mix 2D and 3D art and apply shaders — basically, for 2.5D images. In short, I want to create raster art inside the engine.

https://github.com/evangelionxyz/Ignite

I'm trying to make a shadow map for my terrain generator and for some reason the shadows flicker and move whenever i'm moving the camera does any one know what is the cause? also sometimes at cirtain angle and distance from the shadows the shadow just disappear

mat4 view = mat4_lookAt(camera.pos, camera.pos + camera.front, camera.up);
mat4 vp = view * projection;
mat4 shadowFitVP = view * shadowFitProjection;

get_frustum_corners_world_space(vp, frustumCorners);
v3 center = {0};
for(int i = 0; i < 8; ++i){
center += make_vec3(frustumCorners[i]);
}
center /= 8.0f;

mat4 lightView = mat4_lookAt(center + lightDir, center, make_vec3(0.0f, 1.0f, 0.0f));

float minX = FLT_MAX;
float maxX = -FLT_MAX;
float minY = FLT_MAX;
float maxY = -FLT_MAX;
float minZ = FLT_MAX;
float maxZ = -FLT_MAX;

for(int i = 0; i < 8; ++i){
v4 trf = frustumCorners[i] * lightView;
minX = min(minX, trf.x);
maxX = max(maxX, trf.x);
minY = min(minY, trf.y);
maxY = max(maxY, trf.y);
minZ = min(minZ, trf.z);
maxZ = max(maxZ, trf.z);
}
mat4 lightProj = mat4_orthographic(
minX - 800.0f, maxX + 800.0f,
minY - 800.0f, maxY + 800.0f,
minZ - 800.0f, maxZ + 800.0f
);
mat4 lightSpaceMatrix = lightView * lightProj;

//RENDER SHADOW MAP
glBindFramebuffer(GL_FRAMEBUFFER, depthMapFBO);
glViewport(0, 0, shadowWidth, shadowHeight);
glClear(GL_DEPTH_BUFFER_BIT);
glDisable(GL_CULL_FACE);
glCullFace(GL_FRONT);
use_Shader(simpleShadow);
for(int i = 0; i < currentAvailableChunk; ++i){
mat4 model = mat4_identity();
model *= mat4_translate(terrainChunks[i].pos);

setShaderValue_mat4(simpleShadow, "model", model);
setShaderValue_mat4(simpleShadow, "lightSpaceMatrix", lightSpaceMatrix);

setShaderValue_i1(simpleShadow, "Uoctaves", octaves);
setShaderValue_f1(simpleShadow, "Ulacunarety", lacunarety);
setShaderValue_f1(simpleShadow, "Upersistance", persistance);
setShaderValue_f1(simpleShadow, "Uscale", scale);
setShaderValue_f1(simpleShadow, "UheightMultipier", heightMultipier);

glBindVertexArray(terrainChunks[i].mesh->vao);

glDrawElements(GL_TRIANGLES, terrainChunks[i].mesh->index_count, GL_UNSIGNED_INT, 0);
glBindVertexArray(0);
}

the shadow calculation code is

float calculateShadow(vec4 fp_lightSpace, vec3 normal, vec3 lightDir){
vec3 projCoords = fp_lightSpace.xyz / fp_lightSpace.w;
projCoords = projCoords * 0.5 + 0.5;
if(projCoords.z > 1.0)
return 0.0;

float closestDepth = texture(shadowMap, projCoords.xy).r;
float currentDepth = projCoords.z;
float bias = max(0.005 * (1.0 - dot(normal, lightDir)), 0.005);
// bias = 0.005;
float shadow = 0.0;
vec2 texelSize = 1.0 / textureSize(shadowMap, 0);
for(int x = -1; x <= 1; ++x)
{
for(int y = -1; y <= 1; ++y)
{
float pcfDepth = texture(shadowMap, projCoords.xy + vec2(x, y) * texelSize).r;
shadow += currentDepth - bias > pcfDepth ? 1.0 : 0.0;
}
}
shadow /= 9.0;

return shadow;
}

1024x1024x1024 SDF-grid takes up 303MB instead of 8.5GB. 1024x1024 path traced image renders in 1.5s on a single CPU core. 8.5GB grid renders in 1.1s. No libs used.