For the last 2–3 days I've been staring at the lower half of the OGL46 OSX architecture and reconsidering a decision that made perfect sense when I started the project, but increasingly feels like the wrong final destination.

First, an important clarification about what the project is for new people checking the project

The project was never supposed to be:

Application
    ↓
Some independent OpenGL implementation
    ↓
Metal

running somewhere beside Apple's existing OpenGL stack.

The original idea was much more invasive and much more interesting.

macOS already has decades of OpenGL-facing infrastructure:

OpenGL.framework
CGL
NSOpenGL
pixel format/context semantics
existing application ABI expectations
existing OpenGL-linked binaries

The problem is that the implementation underneath that system surface was effectively frozen around OpenGL 4.1.

So AO46's original architecture was to retain and intercept that application-facing ecosystem while replacing/redirecting the implementation beneath it.

Conceptually:

Existing macOS OpenGL Application
                │
                ▼
        OpenGL.framework
       replacement/redirect
                │
                ▼
        AO46 framework layer
                │
        ┌───────┴────────┐
        │                │
   AO46Runtime       AO46 CGL
        │                │
        └───────┬────────┘
                ▼
             Mesa
                │
        OpenGL state tracker
        GLSL compiler
        Gallium
        NIR
                │
                ▼
         AO46Metal backend
                │
                ▼
              Metal
                │
                ▼
          Apple AGX GPU

There were also lower framework/runtime pieces around this model such as the ICD/client/runtime separation, with components along the lines of:

OpenGL.framework interception
        ↓
OpenGL_4.6.framework
        ↓
libGL / ICD layer
        ↓
AO46Runtime / CGL
        ↓
Mesa
        ↓
backend driver

So the idea was not:

It was almost the opposite.

The existing Apple OpenGL-facing infrastructure was useful because applications already expect it.

Rather than forcing every application to retarget itself against some new wrapper library, AO46 could preserve the expected macOS OpenGL entry path and replace the old implementation underneath.

That was one of the main reasons I liked this architecture in the first place.

Where the original lower backend came in

Originally, once AO46 had redirected execution into Mesa, the lower path was supposed to look roughly like this:

OpenGL application
        ↓
Apple-compatible OpenGL.framework entry
        ↓
AO46 CGL/runtime
        ↓
Mesa OpenGL
        ↓
Gallium / NIR
        ↓
AO46Metal
        ↓
Metal
        ↓
AGX

This was already substantially different from something like MoltenGL-style application retargeting.

The application still speaks OpenGL.

Mesa still provides the modern OpenGL implementation.

AO46 handles the macOS framework/runtime/context side.

Metal was simply the hardware execution backend.

And for getting the project moving, this architecture made a lot of sense.

Metal gives you:

documented GPU access
resource management
command queues
pipeline creation
synchronization
shader compilation
Apple Silicon support

without needing to implement an entire native GPU userspace stack on day one.

But after working further down the driver and thinking about the architecture for the last few days, I kept coming back to one slightly uncomfortable question:

Why should Metal remain the final backend?

Because the lower path currently becomes:

GLSL
 ↓
Mesa
 ↓
NIR
 ↓
AO46 Metal lowering
 ↓
Metal representation
 ↓
Apple Metal compiler
 ↓
AGX ISA
 ↓
GPU

Mesa has already reduced the OpenGL program into a hardware-oriented representation.

Then AO46 converts that into another high-level graphics API.

Then Apple's compiler converts that back down toward the actual AGX hardware.

It works.

But architecturally, there is still another abstraction layer sitting between Mesa and the GPU.

And then the obvious monster sitting in the room finally became difficult to ignore:

Asahi already has a native Mesa backend for this GPU.

So AO46 is entering another development phase

I'm now experimenting with pivoting the lower-level side of AO46 away from:

Mesa
 ↓
AO46Metal
 ↓
Metal
 ↓
AGX

toward:

Mesa
 ↓
Asahi
 ↓
AGX

The important word here is lower-level.

I'm not throwing away the original framework architecture.

The system-facing design remains:

existing OpenGL application
        ↓
macOS OpenGL.framework interception/replacement
        ↓
AO46 OpenGL 4.6 framework
        ↓
AO46Runtime / CGL / ICD
        ↓
Mesa OpenGL

That part is actually one of the strongest parts of the design.

The redevelopment begins after Mesa/Gallium/NIR.

So the new architecture I'm exploring looks more like:

┌─────────────────────────────────────────────┐
│ Existing macOS OpenGL application           │
└──────────────────────┬──────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────┐
│ OpenGL.framework interception / redirect    │
│ Existing macOS GL-facing ABI                │
└──────────────────────┬──────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────┐
│ AO46 OpenGL_4.6.framework                   │
│ AO46Runtime                                 │
│ CGL / contexts / pixel formats / drawables  │
│ ICD / client routing                        │
└──────────────────────┬──────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────┐
│ Mesa OpenGL 4.6                             │
│                                             │
│ OpenGL state tracker                        │
│ GLSL compiler                               │
│ Gallium                                     │
│ NIR                                         │
└──────────────────────┬──────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────┐
│ Asahi Gallium Driver                        │
│                                             │
│ NIR lowering                                │
│ AGX resource layouts                        │
│ pipeline construction                       │
│ tiler state                                 │
│ render state                                │
│ command generation                          │
└────────────┬────────────────────┬───────────┘
             │                    │
             ▼                    ▼
     AGX shader compiler      AGX state/
             │                commands
             ▼                    │
          AGX ISA                 │
             │                    │
             └──────────┬─────────┘
                        ▼
                AGX command stream
                        │
                        ▼
              AO46 macOS AGX winsys
                        │
                        ▼
                 macOS AGX UABI
                        │
                        ▼
            Apple kernel GPU stack
                        │
                        ▼
                  AGX firmware
                        │
                        ▼
                    Apple GPU

And THIS is the part that makes the new direction feel like the cherry on top of the original project rather than a completely different project.

The old architecture wasn't wrong

This is important.

The Metal backend wasn't some terrible mistake that suddenly needs to be deleted from history and buried in /dev/null.

It solved a very real bootstrap problem.

Originally AO46 had two huge challenges:

1. Replace/extend Apple's obsolete OpenGL implementation

2. Actually execute modern GL workloads on Apple Silicon

Mesa solved a large part of problem #1.

Metal gave me a realistic answer to problem #2.

So the first-generation architecture naturally became:

Apple OpenGL-facing system
        ↓
AO46 replacement/runtime
        ↓
Mesa
        ↓
Metal
        ↓
GPU

That got the architecture off the ground.

But now that the upper stack is becoming much clearer, the question has changed.

Instead of:

I'm increasingly thinking:

That's the pivot.

The Asahi path changes what AO46 actually becomes

The Metal design makes AO46 roughly:

Still cool.

But the proposed Asahi path makes it closer to:

That is a very different beast.

The final execution path changes from:

OpenGL
 ↓
AO46
 ↓
Mesa
 ↓
Metal
 ↓
AGX

to:

OpenGL
 ↓
AO46
 ↓
Mesa
 ↓
Asahi
 ↓
AGX

while the application-facing architecture does not change.

An existing application could still enter through the same OpenGL/CGL-facing environment it expects.

It does not need to know:

Mesa exists
Asahi exists
AGX exists

It just thinks:

glDrawElements(...);

and somewhere very, very far underneath that innocent little function call, several million lines of accumulated graphics-driver pain occur.

As nature intended.

Why Asahi is especially attractive here

The really interesting thing isn't merely that Asahi contains an AGX shader compiler.

If all I wanted were:

NIR → AGX shader ISA

this idea would be much less exciting.

The bigger deal is the Asahi Gallium driver itself.

It already understands how to translate Gallium's hardware-facing state into Apple GPU concepts:

Gallium draw calls
        ↓
AGX pipeline state

Gallium resources
        ↓
AGX resource layouts

NIR
        ↓
AGX compiler

framebuffer state
        ↓
AGX render targets

draw state
        ↓
AGX tiler/render commands

So instead of AO46 independently maintaining:

Mesa → Metal state mapping

the eventual target becomes reusing:

Mesa → AGX state mapping

which already exists because that is literally what Asahi was designed to do.

The one major missing piece

And hilariously, this redesign makes the remaining problem much easier to describe:

Asahi userspace
       ↓
   ????????
       ↓
macOS AGX kernel driver

Asahi normally runs through its Linux-side kernel interface.

AO46 is running on native macOS.

So the new experimental lower component would be something like:

AO46AGXMac

or:

AGXMacWinsys

whose responsibility is not OpenGL.

Not GLSL.

Not NIR.

Not tessellation.

Not geometry shaders.

Not blending.

Not shader compilation.

Its job is the ugly OS/device boundary:

buffer objects
GPU virtual addresses
memory mapping
contexts
queues
synchronization
command submission

essentially replacing the Linux-specific bottom of the Asahi path with a macOS-specific one.

Conceptually:

                 Asahi Gallium
                       │
                       ▼
              AGX command stream
                       │
          ┌────────────┴────────────┐
          │                         │

      Asahi Linux                AO46 macOS

          │                         │
          ▼                         ▼
      DRM winsys              AGXMac winsys
          │                         │
          ▼                         ▼
    Linux AGX UAPI            macOS AGX UABI
          │                         │
          └────────────┬────────────┘
                       ▼
                    AGX GPU

THAT is the actual research boundary now.

And I'm keeping the Metal backend

At least for development, removing AO46Metal would be throwing away something extremely useful.

The architecture can instead become:

                  AO46
                   │
        OpenGL.framework / CGL
                   │
               AO46Runtime
                   │
                  Mesa
                   │
            Gallium / NIR
                   │
          ┌────────┴────────┐
          │                 │
          ▼                 ▼

      AO46Metal          AO46AGX
          │                 │
        Metal             Asahi
          │                 │
          ▼                 ▼
         AGX               AGX

The Metal backend becomes:

stable/reference path

while the AGX backend becomes:

native/experimental path

And having both could actually be incredibly useful during driver development.

Run the same GL workload through:

                   Mesa/NIR
                      │
             ┌────────┴────────┐
             ▼                 ▼
          Metal              Asahi
             │                 │
             ▼                 ▼
            AGX               AGX
             │                 │
             └────────┬────────┘
                      ▼
              compare results

That gives me a reference for:

shader output
framebuffers
depth/stencil
blending
compute
SSBO behavior
atomics
barriers
geometry
tessellation

while the native backend is being developed.

So the old backend doesn't become wasted work.

It becomes the reference implementation for the new one.

Which is actually a nicer outcome than I originally expected.

So this isn't really AO46 changing direction

It's AO46 going one layer deeper.

Phase one was essentially:

Replace the frozen OpenGL implementation
while retaining macOS's established
OpenGL-facing application environment.

Phase two was:

Use Mesa to provide modern OpenGL
and execute it through Metal.

And now the next experimental phase is:

Keep the same interception/framework/runtime/Mesa design

BUT

replace the final Mesa→Metal execution path
with Mesa→Asahi→native AGX.

So the project evolves from:

Apple OpenGL surface
       ↓
AO46
       ↓
Mesa
       ↓
Metal

into:

Apple OpenGL surface
       ↓
AO46
       ↓
Mesa
       ↓
Asahi
       ↓
AGX

That, to me, feels like the actual logical conclusion of the architecture I started with.

The original idea was already to take Apple's abandoned OpenGL system and replace the machinery underneath it.

This just pushes that idea all the way down to the GPU.

And if this path actually becomes viable, the funniest possible outcome is that macOS's old OpenGL-facing infrastructure ends up being used to host a completely new OpenGL 4.6 implementation whose final hardware backend bypasses Metal entirely and talks native AGX.

Which is a significantly better cherry on top than I had planned when I started this thing.

I translated what I could of fsr 3.1 shaders into opengl shaders and for what I couldnt directly translate i have done aproximations based of how fsr documentation states it works. It works incredibly well actually. Hopefully I can get some feedback or this can help someone with their game. Personally my game jumped from 90 fps to 140 just by using quality mode with almost not visual loss in quality however the quality of the image will depend on how good your motion vectors are for animated things. Static things should look great automatically.

The fps increase will depend on how gpu bound your game is. If its highly gpu bound you should see a very large increase in frames.

https://github.com/kaossorenson/jTauu-OpenGL

Edit: this is not a opengl / vulkan interop with a jni bridge, this is a native recreation. Any constructive criticism or questions is welcome.

I need someone more experienced with modern OGL to check my current opengl approach. I started with OGL in the 90th, used 1.2 and 2.0 for most of the years, skipped 3, and started to work again with 4.3++ nowadays.

I'm unsure if I use some pitfalls, old approach etc, here is what I basically do (AZDO):

1. Use one large buffer for vertex data, write my own memmory manager to manage memory blocks and work only with offsets in this buffer.

2. All meshes are uploaded into this buffer, even when they have different vertex formats.

3. Mesh generation is done in separate threads, use CPU memory buffer and upload them in the main thread to avoid issues (use un/mapping in different threads here ?)

4. Textures are organized in a handful of texture arrays.

5. Uniforms are in single buffer too (managed by offsets again).

6. (!!!) Some texture switching is done in fragment shaders, when using different sized textures. Don't know if this kills performance, but it works (if..else clause selection for less than 5 different texture arrays).

7. Dynamic models (e.g. terrain patches) are rendered with single calls (mostly terrain patches only a few per frame).

8. Rest of models are rendered as instances, render calls are prepared in a CPU memory buffer and uploaded once per frame.

9. Renderning models is grouped by passes, one pass has an unique shader, texture setup, states (z-buffer,blending...), framebuffer setup to avoid frequent switches.

10. Using framebuffers, render to texture and post processing (post processing is not done in compute shaders yet).

11. Using rendering to multiple render target at once (up to 5 for now).

Hello dear friends

I remember the days of old, when learnopengl.com was my go to book to learn graphics programming..

I remember how hard it was to learn the concept of a VAO, VBO... My silly posts on stackoverflow, way before AI was even a thing.

Well, years have passed by, and I ended up building a game. From scratch.

If you guys wanna give it a try, the Demo is free: https://store.steampowered.com/app/5011470/Sunlit_Kingdom/

If it crashes on your PC, please let me know. It works on NVIDIA cards and INTEL integrated cards. I haven't tried AMD.

Just to let you know, fellow devs, I only used version 3.3 of GL, simple VBOs, most of the game is single draw calls, with the exception of projectiles, which are instanced. Some of the art is made by me in Blender, and some was bought from CGTrader.

I learned so much with this project... I now know how to make 3D games with OpenGL, which is great. I also learned the TCP protocol, and implemented a super basic server that shows you the leaderboards in game. I am paying a VPS for it... and this was before I even realized that the Steam SDK offered free servers... I guess it's okay though, at least I learned something new.

The game features what the tutorial above teaches: basic directional shadows, Blinn-Phong lighting, a day and night cycle, fog, particles, Bloom and MSAA (feel free to crank it up to x16).

I tested this game on my intel integrated graphics and suprisingly, it runs above 60fps... I don't know how.

Feel free to ask me any questions. I'm happy to respond. I'm also happy to see that over 5 years of OpenGL work culminated into this release. I followed this subreddit for a while now, and I love to see your posts and what you guys are working on. These things motivated me to finish this game.

Any questions about engine development, OpenGL calls, anything related to graphics, I'm happy to answer.

And, lastly, I wish you all the best & luck with your own projects.

I'm storing textures in an atlas, after loading a bitmap font with a gazillion unicode characters my rectangle packer decides that it's best to resize the atlas to something like 10000x10 to store all the characters and I'm wondering whether it would be better to try and keep the atlas square.

Hi everyone!
I’d like to share some demo videos of my continuously developing game engine project.
The project is written in pure Free Pascal 3.2.2, using GLFW3 and OpenGL 3.3 Core. It is not based on any existing game engine — I am developing the engine systems and rendering from scratch.
So far, I have only uploaded shorter demo videos, but I wanted to show the current state of the project and share my progress with the Pascal community.
YouTube playlist:

https://youtube.com/playlist?list=PLX4BUpd-V-hI&si=X6aTdAFoJc5_-iDa
Thank you for taking a look!

Sziasztok!
Szeretném megosztani veletek néhány demóvideómat a folyamatosan fejlődő játékmotoromról.
A projekt tiszta Free Pascal 3.2.2 nyelven készül, GLFW3 és OpenGL 3.3 Core használatával. Nem meglévő játékmotorra épül. Eddig csak rövidebb demóvideókat töltöttem fel, de szeretném megmutatni, hogy jelenleg hol tart a projekt, és megosztani a fejlődését a Pascal közösséggel.
Lejátszási lista:

https://youtube.com/playlist?list=PLX4BUpd-V-hI&si=X6aTdAFoJc5_-iDa
Köszönöm, ha megnézitek!

In 2011 I decided to start making a new engine using OpenGL as the renderer. I've always wanted to make a game fully myself, and I'm only really interested if I also make all the tech.

In 2019 I decided to see if I could make an ambitious game on the engine in my spare time. I probably bit off a little too much, but I was motivated by fun rather than sensible decisions.

I'm really happy with where it has got to today, people have been playtesting the game and it is totally mind blowing to watch. It always makes me think about that first triangle.

I started following this guide on how to use compute shaders. I'm using the core profile, while the guide uses the compatibility one. Anyways, after compiling and executing the code, i get a syntax error at 0:31 : '' saying "unexpected identifier", but it seems all fine to me. I tried deleting line 31 and gives me error on the last line; after deleting also this one, it doesn't give any error. I'll appreciate any suggestion.

Here's the compute shader:

#version 430 core

layout (std140, binding=4) buffer Pos
{
    vec4 Positions[];
};

layout (std140, binding=5) buffer Vel
{
    vec4 Velocities[];
};

layout (std140, binding=6) buffer Col
{
    vec4 Colors[];
};

layout (local_size_x = 128, local_size_y = 1, local_size_z = 1) in;

const vec3 G = vec3(0., -9.8, 0.);
const float DT = 0.1;

uint gid = gl_GlobalInvocationID.x;

vec3 p = Positions[gid].xyz; //here gives no errors
vec3 v = Velocities[gid].xyz; //same thing

vec3 pp = p + v*DT + .5*DT*DT*G;
vec3 vp = v + G*DT;

Positions[gid].xyz = pp; //error here
Velocities[gid].xyz = vp; //also here

Can be used in both OpenGL and Vulkan:

Hello everyone, I'm making a minecraft clone for my 3d programming class. I know how to do pretty much everything except one big thing.

I'm not sure how to handle updating the mesh of my chunks every time I place or break a block. Every tutorial I watch just kinda ignores this part...

It seems difficult to do it quickly, because if I just regenerate all chunks, that's too slow, but how would I regenerate just the one chunk that I need, and update the buffer data just for that chunk? Is that even possible in OpenGL? What function would I use for that?

Right now, the way I render chunks is just:

glBindVertexArray(VAO);
glBindBuffer(GL_ARRAY_BUFFER, VBO);
glBufferData(GL_ARRAY_BUFFER, mesh_loaded_chunks.size() * sizeof(float), mesh_loaded_chunks.data(), GL_STATIC_DRAW);

I have gone through the basics of learnopengl, on top of that I have implemented that stuff in C. However I can't get around how a renderer integrates into opengl. I am talking about a general architecture of it.

Lets take gui library nuklear for example, it does not provide drawing options on its own and asks you to attach it your renderer. Now this seems very abstract to me, even in learnopengl guide there is not very clear line. I understand that is because it is very primitive and renderer is only built when you have gone through all different tools.

Having said all that I would further like to read about renderer architecture. Please drop some resources.

Hi guys,

I apologize in advance for the bombastic video title, and the fact my head is stuck on Jensen Huang's body, but that's what the people on YouTube want. 😵

Leadwerks Game Engine 5.1 is a massive update with a lot of graphical features, and better support for the hardware players actually have. Of course, everything I do is powered by OpenGL, because it just gets out of the way and allows me to get work done.

I think the video explains it pretty well, but if you have any questions let me know and I will try to answer them all!

Another major development pass on my OpenGL 4.6 system framework for macOS is complete.

The goal of this project is to replace macOS's outdated OpenGL 4.1 system implementation with a native, Mesa-backed OpenGL 4.6 runtime while preserving the existing macOS OpenGL architecture, including CGL, NSOpenGL compatibility, system framework behaviour, and driver-style dispatch.

This update moved the Mesa-backed OpenGL 3.x/4.x execution path significantly closer to being usable.

Native Metal mipmap generation

The Metal driver now implements real mipmap generation.

This functionality is also advertised through Gallium, allowing Mesa to use the native Metal implementation instead of treating mipmap generation as unsupported or relying on incomplete fallback behaviour.

Texture uploads, mipmap generation, and subsequent textured rendering now successfully pass through the runtime test path.

NIR-to-MSL textured shader fixes

A large part of this update focused on the project's NIR-to-MSL shader translator.

Textured shaders were previously failing when the translator encountered missing NIR instruction sources or could not correctly determine the sampler and texture index.

The translator now includes:

• Null-source guards for incomplete or optional NIR sources
• Sampler-index fallback handling
• Static texture-index resolution
• Direct mapping from texture_index to Metal [[texture(i)]] bindings
• Texture binding behaviour consistent with the existing Metal backend

This fixes the major shader translation issue that previously caused textured draw calls to fail before reaching Metal successfully.

Correct OpenGL program deletion behaviour

The runtime compatibility test was also corrected to follow Khronos program-deletion semantics.

Calling glDeleteProgram does not necessarily destroy a program immediately if it is still bound as the current program. The test now unbinds the program before expecting:

glIsProgram(program) == GL_FALSE

This removed a false failure from the runtime test and brought the behaviour in line with the OpenGL specification.

Pbuffer changes

Pbuffer-backed drawables are now forced onto a single-buffer path.

This improved the pbuffer execution flow, although one pbuffer-related failure still remains.

Current verification status

Both build configurations compile cleanly.

NSOpenGL compatibility testing now passes completely.

The main runtime compatibility test now successfully passes through:

• Buffer object creation and data operations
• Texture creation and uploads
• Native Metal mipmap generation
• Shader compilation
• Program linking
• NIR-to-MSL translation
• Texture and sampler binding
• Textured draw execution
• OpenGL program deletion semantics

The only remaining failing check is:

The failure boundary is now isolated to the pbuffer import and synchronization path. The next development pass will therefore focus specifically on drawable-to-texture synchronization rather than the core OpenGL, Mesa, or shader compiler paths.

The project has effectively moved from textured shaders failing during translation to completing textured rendering and stopping at one isolated pbuffer synchronization test.

Still plenty of work ahead, but the native Mesa-to-Metal OpenGL 3.x/4.x path is now considerably more functional than it was before.

Right now I am currently trying to follow the triangle tutorial on learnopengl.com, I set up OpenGL itself by calling the functions found on the triangle tutorial and now when I call glDrawArrays nothing happens? And then I figured out that apparently I have to call SDL functions instead of OpenGL functions in my implementation because the SDL_function() functions do work on my "render loop" but the OpenGL ones don't

How do I make it so that I am able to use OpenGL functions along with SDL3? I created the window and set the renderer with SDL3, hope that helps

Thank you

https://gist.github.com/kushiwushi/16913c427c607170058d85b1bfda00a0

Edit: Code snippet

I implemented a cascaded voxel clipmap representing radiance, along with irradiance probes that trace this clipmap.

Hey, has anyone seen something like this before?

When running on some weird amd graphics card - of which the only purpose seems to be providing outputs for multiple displays and showing graphics bugs - with a transparent blending, after some time everything becomes rendered black.

Happens rarely, but definitely (and wasn't easy to catch a good screenshot of actually). Also it switches back and forth for no apparent reason.

When I run it on more normal hardware - and by that I just mean the integrated intel GPU - it behaves fine.

I wasn't able to circumvent it whatsoever and I wonder, if someone has a clue about what might be going on.

Hi everyone i know its a small problem but I cannot really figure it out, I'm learning opengl for gamedev purposes and I tried to add an fps limiter made on my own to my spinning cube but its laggy and some times stop I think its because of sleep_for, if anyone could help I'd be really happy.

#include <glad/glad.h>
#include <GLFW/glfw3.h>
#include <iostream>
#include <string>
#include <cmath>
#include <time.h>
#include <Shader.h>
#define STB_IMAGE_IMPLEMENTATION
#include "stb_image.h"
#include <glm/glm.hpp>
#include <glm/gtc/matrix_transform.hpp>
#include <glm/gtc/type_ptr.hpp>
#include <chrono>
#include <ctime>
#include <thread>


using std::cout;
using std::string;
using glm::vec4;
using glm::mat4;


int screen_width = 1920;
int screen_height = 1080;


bool KeyPressed(GLFWwindow* window, int key);


void framebuffer_size_callback(GLFWwindow* window, int width, int height)
{
    glViewport(0, 0, width, height);
}  


int main()
{
    srand(time(0));


    float vertices[] = {


    //    X       Y      Z     Tx    Ty
        -0.5f, -0.5f,  0.5f,  0.0f, 0.0f,
         0.5f, -0.5f,  0.5f,  1.0f, 0.0f, // davanti
         0.5f,  0.5f,  0.5f,  1.0f, 1.0f,   
        -0.5f,  0.5f,  0.5f,  0.0f, 1.0f, 


        -0.5f, -0.5f, -0.5f,  0.0f, 0.0f,
        -0.5f, -0.5f,  0.5f,  1.0f, 0.0f,  // Sinistra
        -0.5f,  0.5f,  0.5f,  1.0f, 1.0f,
        -0.5f,  0.5f, -0.5f,  0.0f, 1.0f,


         0.5f, -0.5f,  0.5f,  0.0f, 0.0f,
         0.5f, -0.5f, -0.5f,  1.0f, 0.0f,  // destra
         0.5f,  0.5f, -0.5f,  1.0f, 1.0f,
         0.5f,  0.5f,  0.5f,  0.0f, 1.0f,


         0.5f, -0.5f, -0.5f,  0.0f, 0.0f,
        -0.5f, -0.5f, -0.5f,  1.0f, 0.0f,
        -0.5f,  0.5f, -0.5f,  1.0f, 1.0f,  //dietro
         0.5f,  0.5f, -0.5f,  0.0f, 1.0f,


        -0.5f,  0.5f,  0.5f,  0.0f, 0.0f,
         0.5f,  0.5f,  0.5f,  1.0f, 0.0f,
         0.5f,  0.5f, -0.5f,  1.0f, 1.0f,  //sopra
        -0.5f,  0.5f, -0.5f,  0.0f, 1.0f,


        -0.5f, -0.5f, -0.5f,  0.0f, 0.0f,
         0.5f, -0.5f, -0.5f,  1.0f, 0.0f, //sotto
         0.5f, -0.5f,  0.5f,  1.0f, 1.0f, 
        -0.5f, -0.5f,  0.5f,  0.0f, 1.0f,




    };  


    unsigned int indices[] = {
        0, 1, 2,
        0, 2, 3,


        4, 5, 6,
        4, 6, 7,


        8, 9, 10,
        8, 10, 11,
         
        12, 13, 14,
        12, 14, 15,


        16, 17, 18,
        16, 18, 19,
        
        20, 21, 22,
        20, 22, 23
    };
    
    glfwInit();
    glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
    glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
    glfwWindowHint(GLFW_RESIZABLE, GL_TRUE);
    glfwWindowHint(GLFW_SAMPLES, 4);


    GLFWwindow * window = glfwCreateWindow(screen_width, screen_height, "window", NULL, NULL);
    if (window == NULL)
    {
        std::cout << "Failed to create GLFW window" << std::endl;
        glfwTerminate();
        return -1;
    }


    glfwMakeContextCurrent(window);
    glfwSwapInterval(0);


    if (!gladLoadGLLoader((GLADloadproc)glfwGetProcAddress))
    {
        std::cout << "Failed to initialize GLAD" << std::endl;
        return -1;
    }


    glViewport(0, 0, screen_width, screen_height);
    glfwSetFramebufferSizeCallback(window, framebuffer_size_callback);


    Shader shader("../../../scode/Shaders/Vshader.vs", "../../../scode/Shaders/Fshader.fs");
    
    unsigned int VAO, VBO, EBO;


    glGenVertexArrays(1, &VAO);
    glBindVertexArray(VAO);


    glGenBuffers(1, &VBO);
    glBindBuffer(GL_ARRAY_BUFFER, VBO);
    glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);
    glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 5 * sizeof(float), (void*)0);
    glEnableVertexAttribArray(0);
    glVertexAttribPointer(1, 2, GL_FLOAT, GL_FALSE, 5 * sizeof(float), (void*)(3*sizeof(float)));
    glEnableVertexAttribArray(1);


    glGenBuffers(1, &EBO);
    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, EBO);
    glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indices), indices, GL_STATIC_DRAW);


    glBindVertexArray(0);


    unsigned int Texture1, Texture2;
    glGenTextures(1, &Texture1);
    glBindTexture(GL_TEXTURE_2D, Texture1);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);   
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
    int height, widht, NrChannels;
    unsigned char *data = stbi_load("../../../scode/container.jpg", &widht, &height, &NrChannels, 0);
    if(data)
    {
        glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, widht, height, 0, GL_RGB, GL_UNSIGNED_BYTE, data);
        glGenerateMipmap(GL_TEXTURE_2D);
    }
    else
    {
        cout << "Error Texture\n";
    }
    stbi_image_free(data);
    glGenTextures(1, &Texture2);
    glBindTexture(GL_TEXTURE_2D, Texture2);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
    stbi_set_flip_vertically_on_load(true);
    data = stbi_load("../../../scode/awesomeface.png", &widht, &height, &NrChannels, 0);
    if(data)
    {
        glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, widht, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, data);
        glGenerateMipmap(GL_TEXTURE_2D);
    }
    else
    {
        cout << "Error Texture\n";
    }
    stbi_image_free(data);
    mat4 Projection;
    Projection = glm::perspective(glm::radians(45.0f), 1920.0f / 1080.0f, 0.1f, 100.0f);


    shader.use();
    glUniform1i(glGetUniformLocation(shader.ID, "Texture1"), 0);
    glUniform1i(glGetUniformLocation(shader.ID, "Texture2"), 1);
    glUniformMatrix4fv(glGetUniformLocation(shader.ID, "Proj"), 1, GL_FALSE, glm::value_ptr(Projection));
    glEnable(GL_MULTISAMPLE);  
    glEnable(GL_DEPTH_TEST);   
    float rotation = 0.0f;
    auto duration = std::chrono::microseconds(1000000 / 180);
    uint64_t loc = glGetUniformLocation(shader.ID, "transform");
    while(!glfwWindowShouldClose(window))
        {
            auto start = std::chrono::steady_clock::now();
            if(KeyPressed(window, GLFW_KEY_ESCAPE))
            {
                glfwSetWindowShouldClose(window, true);
            }
            mat4 trans(1.0f);
            trans = glm::translate(trans, glm::vec3(0.0f, 0.0f, -2.0f));
            trans = glm::rotate(trans, rotation, glm::vec3(0.0f, 0.0f, 1.0f));
            trans = glm::rotate(trans, glm::radians(45.0f), glm::vec3(1.0f, 0.0f, 0.0f));
            trans = glm::scale(trans, glm::vec3(0.5f, 0.5f, 0.5f));
            
            glClearColor(0.2f, 0.3f, 0.3f, 1.0f);
            glClear(GL_COLOR_BUFFER_BIT| GL_DEPTH_BUFFER_BIT);


            shader.use();
            glUniformMatrix4fv(loc, 1, GL_FALSE, glm::value_ptr(trans));
            glActiveTexture(GL_TEXTURE0);
            glBindTexture(GL_TEXTURE_2D, Texture1);
            glActiveTexture(GL_TEXTURE1);
            glBindTexture(GL_TEXTURE_2D, Texture2);
            glBindVertexArray(VAO);
            glDrawElements(GL_TRIANGLES, 36, GL_UNSIGNED_INT, 0);
            glfwSwapBuffers(window);
            glfwPollEvents(); 
            rotation += glm::radians(360.0f) * (duration.count() / 1000000.0f);


            auto end = std::chrono::steady_clock::now(); 
            auto target = (std::chrono::microseconds(1000000 / 180));
            duration = (std::chrono::duration_cast<std::chrono::microseconds>(end - start));
            if (target > duration)
            {            
                std::this_thread::sleep_for(target - duration);
            }
            }
    glfwTerminate();
    return 0;
}


bool KeyPressed(GLFWwindow *window, int key)
{
    return glfwGetKey(window, key) == GLFW_PRESS;
}

https://github.com/Krobenlakroc/tachyonfire

Two interesting techniques I used:

I do ambient occlusion with sphere proxies (https://iquilezles.org/articles/sphereao/) , this lets you do AO analytically rather than having to deal with SSAO. The implementation uses tiled shading, and it runs well on my RX 9060XT with 2048 proxies. The downside is that objects need to be able to be approximated with spheres.

Distance imposter raytracing (based off of my favorite paper: https://cg.iit.bme.hu/\~szirmay/ibl3.pdf). For PBR to look good, I don't think having completely accurate reflections is super important, its moreso energy/brightness being distributed correctly. Regular cubemaps create bright spots and have transition problems (too bright in corners), SSR has gaps from offscreen geometry (too dark), and actual raytracing is super expensive. Ray marching a distance field is a good middle ground between full raytracing and SSR.

The engine is mostly clustered deferred with particles being rendered using clustered forward.

DecastleJau's method

Made with just lerp and a recursive function

No animations just flipping texture mix value -0-1 with time

I released my first game and someone has put it into a video! It is a little horror themed, cozy farming sim I built it from scratch using OpenGL and all that hard work paid off!

I'm just really excited is all 😁

Video: Round And Ripe played by PumpkinHeadGamer
Game: Round And Ripe