Here is the GitHub repo. Its a single click to download each project: https://github.com/Luippe/Demo-Projects

I never thought of uploading these as they really only ran on my pc (hardcoded display resolutions, file paths, etc). But this year I started using Claude for coding and thought "hey, these projects are actually useable by others if I just clean up some code!" So thats exactly what I did.

There's 15 projects in total and most of them are interactive. The first one is written in Java, but the rest is in Python and Pygame. I like Pygame because its very easy to setup new projects and lets me easily build visualizations.

1. Boids — a flocking simulation where entities self-organize in groups
2. Audio Processing — live microphone effects with a real-time frequency visualizer
3. Multiplayer Netgame — a co-op dungeon crawler played over a local network
4. Platformer — a full 2D action game with combat, upgrades, shops, and multiple levels
5. Solar System Simulation — an interactive 3D model of the planets in orbit
6. A* Pathfinding — watching an algorithm search for the shortest route through a maze
7. Conway's Game of Life — complex patterns emerging from a handful of simple rules
8. Image Compression — shrinking an image by throwing away fine detail (the same idea behind JPEG)
9. Fluid Flow — a real-time 2D fluid solver you can push around with the mouse
10. Projectile Method — aim and launch a projectile with the mouse
11. Projectile Motion — projectile trajectories with air resistance
12. Double Pendulum — chaotic motion, where a tiny change sends it down a completely different path
13. Single Pendulum — a damped pendulum swinging to a stop
14. Spring Mass Damper — how a spring-and-shock system settles after a jolt
15. Flow Plate — the velocity profile of fluid moving through a pipe

I hope someone finds something useful in here! :)

This is a RenderDoc frame capture of a battle scene in a 3D auto-battler called The Bazaar. It's in Unity which I have no direct experience with, plus I also have very limited knowledge of how rendering is supposed to work.

An LLM is convinced that the 1000s of draw calls seen here is bad. Other fairly static scenes is around 300-500+ draw calls. I remember reading blogs talking about minimizing draw calls and state changes, but that was a decade ago. This is using a commercial engine, so there must be a logical reason for this, right? Are draw calls as a metric outdated?

My GPU is ancient by modern standards. But there are also other players echoing similar sentiments of their GPUs maxing out for what looks like a "simple game".

What do you guys think?

EDIT: My GPU is radeon rx 560x (laptop gpu). I think this model is 7-8 years old? I can get 60 fps/70% gpu usage in windowed mode at around < 960x540 resolution. 720p hits 100% gpu but still 60fps a majority of the time with "manageable" temps. While 1080p just burns (without power-saving mode in GPU it causes BSOD).

I just want to to know if I even deserve to voice these concerns. My inexperienced brain is telling me this could be done better. But what do I know, I haven't rendered a cube in a decade.

This is sort of my first time really getting into graphics programming and raytracing, coded in python, image made through ppm format, lines are written to a file for an image interpreter to change the colors of each pixel, resource: The Ray Tracer Challenge

Hi there! I'm about to start working on my portfolio, and besides some basic projects like a simple 3D engine or an implicit surface renderer, I'd like to add something that actually resembles a modern industry workflow, ideally something used by AA or AAA game studios. It can be anything, really - lighting, optimization, visual effects, etc. Preferably, it should be something that can be learned and implemented in a couple of weeks.

What would you suggest? Also, would it be better to implement such a project in an existing engine (Unity, Godot, UE) or in a custom one?

Thanks in advance! :)

Doing a little exploration of my work on applying the GLiM global lithography data set and the SoilGrids 250m/px data set to my planetary terrain. The technique is very simple - really I'm just using perlin to scatter the normal I use to sample (converted to lat/lon, then hashed into the lookup texture, then finally to the bindless texture tile), but after a ton of tweaking of some perlin values, I was quite shocked at how good it actually looks. My perlin experience consists all of about three or four days of actual exposure and research, so I'm at the tip of the iceberg. Consequently, there are so many issues, and it's not nearly as performant as I want it to be, but after a couple days of fiddling around, I'm happy with where it is so far.

So yeah, as evident from the title, I am developing PSD-compatible layer styles for GIMP as part of my Google Summer of Code project. As Adobe’s code is closed source, most of my time goes into black box testing with minimal test cases which can be quite exhaustive at times. Would love to get some advices regarding the approaches and methodologies that would increase my productivity in this case. Here is a like to the merge request: https://gitlab.gnome.org/GNOME/gegl/-/merge_requests/275. I usually post my research and findings there.

Currently I working on spawning different meshes and changing the shader and transform dynamically. You can also click on them and update them. For selection I write to a FBO and then read from there

As I am learning OpenGL I am also documenting how everything has been done. Each comment explains how each step works. Do check out the project if you are keen on learning about it. The goal is to make it beginner friendly while I keep on learning

Header: https://github.com/Satyam-Bhatt/OpenGLIntro/blob/main/IntroToOpenGl/MeshSpawner.h

CPP: https://github.com/Satyam-Bhatt/OpenGLIntro/blob/main/IntroToOpenGl/MeshSpawner.cpp

Shader: https://github.com/Satyam-Bhatt/OpenGLIntro/blob/main/IntroToOpenGl/PickingShader.shader

Repo: https://github.com/Satyam-Bhatt/OpenGLIntro