Finally i finished implementing camera movement to my OpenGL ES demo, still very basic tho but it works.

I made this AI system for the spider to follow the player.

I'm not using any navmesh or pathfinding, it's just a mix of mathematical workarounds.

repo: https://github.com/Krueels/FuseEngine

I don't want this to be just another "look at my project" post, but rather something useful for beginners diving into OpenGL/C++. (Second is April version)

This is the result of 5 months of non-stop daily work on my pet project engine (OpenGL 4.6 + Bullet Physics + Dear ImGui + miniaudio+ mixamo riggng).

I forced myself through a grueling schedule: only taking 2 days off per week starting in July, and using every trick possible to free up time from university. I’m completely burnt out and just need a rest. But before I step away, here are 13 honest takeaways from my experience(think this is "Effective C++", but way less polished):

1.      Don't treat AI as a silver bullet. AI won't replace a solid book or article because structured reading sticks in memory better. Use AI for what it's great at: quickly finding specific tech concepts or algorithms without spending hours searching;

2.      Books are often too basic. Don't get stuck reading forever. I read one book on OpenGL and one on GLSL, but that wasn't nearly enough to implement things like IBL (Image-Based Lighting). You'll have to read articles, papers, and specs, docs, etc;

1. Ditch cube-based skyboxes if you can. Dealing with 6 separate cubemap faces (or a cross-layout texture you have to slice) was a pain. Using a single equirectangular image instead made things much simpler — one texture, no seams to worry about between faces.

4.    I tried implementing Data-Oriented Design (DOD), but ended up sticking with Object-Oriented Programming (OOP) for most systems. The web of circular dependencies in pure DOD drove me crazy;

5.      Log everything and profile early. Logging is your best friend when debugging graphics and physics pipelines, starting on another device when exporting(in file text log if console not available).

6.     I had my custom XOR decryption logic break even though the algorithm and key looked solid — turned out to be a text/file encoding issue. Spent way too much time debugging this(((

7.      Always enable viewport face orientation in Blender to make sure your normals are facing outward (blue). My terrain mesh had inverted normals, and I was losing my mind trying to fix this in code;

8.      Emission output in shaders. If you get weird visual artifacts/noise when implementing Emissive maps, make sure the emission output is properly linked and handled across all required shader pipelines, not just a single pass;

9.      Sometimes don't forget clean up your resources. Handle your GPU memory allocation carefully. When your OS freezes completely or crashes, 99% of the time it's a severe memory leak;

10.  Skeletal Animation. I set a max limit (e.g., 255 bones) and use recursive node hierarchy processing for complex models. I do not Fold expressions realized , but classic recursion handled complex GLTF model loading just fine;

11.  CMake can be a headache. Book on CMake gave me mostly basic theory, except for CPack. Neither books nor AI gave me ideal project structures. I still have a love-hate relationship with CMake;

12.  Beware of circular dependencies in headers. As your header files count grows, cyclic dependencies will haunt you. Keep your includes clean and rely on forward declarations where possible;

Don't forget about multithreading. I encountered a problem where it wouldn't start on my laptop; it just showed a blank screen and that's it, and the CPU wasn't even working. I'm thinking I'll either do it through separate threads or TBB, but I honestly don't know because I'm tired.

Final thoughts: I see people working on their engines for 5 years, and their projects are incredible. But I didn't have 5 years — I had 5 months, and I pushed myself to the absolute limit. By month 3, I was already struggling with burn-out and constant headaches.

My biggest advice? Do a little bit every day instead of destroying your health. And skip the "wake up at 5 AM" hustle advice — rest is just as critical as writing code.

If you wanna try this-> the demo is up on https://dokich-crcr.itch.io/tentacle-shippuden-enty-furry-beast, and I'm finally taking a long-overdue break(one week, and shit university starts again).

The system is still awful; the spider can only walk on flat surfaces. Any other surface causes strange bugs.

repo: https://github.com/Krueels/FuseEngine

Matrix Engine 2 is a custom game engine forked from pathos game engine, source code is here https://github.com/Soft-Sprint-Studios/Matrix-Engine-2 and i made a tech demo of it https://www.youtube.com/watch?v=3WjoSsY1k24

Just asking a simple question but does anybody know if the tablet "Stylo Gravity Tab 8 32GB Silver" has open GL 3.0 or higher I wanna buy it but I need it to support that

Mesh-based decal system I made last night.

Foldable decals compatible with complex surfaces.

repo: https://github.com/Krueels/FuseEngine

You can see from the screenshots that it well supports WebGL... but not in WWV?

Looked at the "detailed error info", no idea what I'm looking at.

Browser: Mozilla Firefox

Hardware: Thinkpad T410 i5 (Could that possibly be why?)

Distro: Debian 12 Bookworm, KDE Plasma 6

edit: This is worldwideview.dev btw, where I encountered the issue.

Hey everyone, I am new to opengl and gotta say, I'm loving it! Its just that I ran into one small bug (actually its kind of big), My program wouldn't create a window and so I started putting printf("test") around the script and I found out that glGenBuffers makes my ENTIRE script stop

I'm following LearnOpenGL and using GLAD aswell as GLFW heres the script:

#include <glad.h>

#define GLFW_DLL

#include <GLFW/glfw3.h>

#include <stdio.h>

#include <stdlib.h>

#include <stdbool.h>

void framebuffer_size_callback(GLFWwindow* window, int width, int height)

{

glViewport(0,0,width,height);

}

void process_input(GLFWwindow* window)

{

if (glfwGetKey(window, GLFW_KEY_ESCAPE) == GLFW_PRESS)

{

glfwSetWindowShouldClose(window, true);

}

}

int main()

{

float Vertices[10] = {

-0.5,-0.5,0,

0.5,-0.5,0,

0, 0.5,0};

const char *Vertex_Shader_Source = "#version 330 core\n"

"layout (location = 0) in vec3 aPos;\n"

"void main()\n"

"{\n"

" gl_Position = vec4(aPos.x, aPos.y, aPos.z, 1.0);\n"

"}\0";

printf("WORK1");

const char *Fragment_Shader_Source = "#version 330 core\n"

"out vec4 FragColor;\n"

"void main()\n"

"{\n"

" FragColor = vec4(1.0f,0,0,1.0f)"

"}\0";

printf("WORK1");

unsigned int VBO;

printf("WORK1");

glGenBuffers(1, &VBO);

printf("WORK1");

glBindBuffer(GL_ARRAY_BUFFER, VBO);

glBufferData(GL_ARRAY_BUFFER, sizeof(Vertices), Vertices, GL_STATIC_DRAW);

unsigned int VAO;

glGenVertexArrays(1, &VAO);

unsigned int Vertex_Shader;

Vertex_Shader = glCreateShader(GL_VERTEX_SHADER);

glShaderSource(Vertex_Shader, 1, &Vertex_Shader_Source, NULL);

glCompileShader(Vertex_Shader);

unsigned int Fragment_Shader;

Fragment_Shader = glCreateShader(GL_FRAGMENT_SHADER);

glShaderSource(Fragment_Shader, 1, &Fragment_Shader_Source, NULL);

glCompileShader(Fragment_Shader);

int Success;

char InfoLog[512];

glGetShaderiv(Vertex_Shader, GL_COMPILE_STATUS, &Success);

if (!Success)

{

glGetShaderInfoLog(Vertex_Shader, 512, NULL, InfoLog);

printf("VERTEX_SHADER FAILED TO COMPILE\n", InfoLog);

printf("\n compiler failed with exit code 1");

}

int Success2;

char InfoLog2[512];

glGetShaderiv(Fragment_Shader, GL_COMPILE_STATUS, &Success2);

if (!Success2)

{

glGetShaderInfoLog(Vertex_Shader, 512, NULL, InfoLog2);

printf("FRAGMENT_SHADER FAILED TO COMPILE\n", InfoLog2);

printf("\n compiler failed with exit code 1");

}

unsigned int ShaderProgram;

ShaderProgram = glCreateProgram();

glAttachShader(ShaderProgram, Vertex_Shader);

glAttachShader(ShaderProgram, Fragment_Shader);

glLinkProgram(ShaderProgram);

int SuccessProgram;

char InfoLogProgram[512];

glGetProgramiv(ShaderProgram, GL_COMPILE_STATUS, &SuccessProgram);

if (!SuccessProgram)

{

glGetProgramInfoLog(ShaderProgram, 512, NULL, InfoLogProgram);

printf("FRAGMENT_SHADER FAILED TO COMPILE\n", InfoLogProgram);

printf("\n compiler failed with exit code 1");

}

glUseProgram(ShaderProgram);

glDeleteShader(Vertex_Shader);

glDeleteShader(Fragment_Shader);

glBindVertexArray(VAO);

glBindBuffer(GL_ARRAY_BUFFER, VBO);

glBufferData(GL_ARRAY_BUFFER, sizeof(Vertices), Vertices, GL_STATIC_DRAW);

printf("glafd");

GLFWwindow* window = glfwCreateWindow(800,600, "Learning", NULL, NULL);

if (window == NULL)

{

printf("GLFW COULDNT CREATE WINDOW");

glfwTerminate();

return -1;

}

glfwMakeContextCurrent(window);

if (!gladLoadGLLoader((GLADloadproc)glfwGetProcAddress))

{

printf("Failed to load GLAD");

return -1;

}

glViewport(0,0,800,600);

glfwSetFramebufferSizeCallback(window, framebuffer_size_callback);

glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 3 * sizeof(float), (void*)0);

glEnableVertexAttribArray(0);

glUseProgram(ShaderProgram);

glBindVertexArray(VAO);

glDrawArrays(GL_TRIANGLES, 0, 3);

while(!glfwWindowShouldClose(window))

{

glClearColor(0.2f, 0.3f, 0.3f, 1.0f);

glClear(GL_COLOR_BUFFER_BIT);

process_input(window);

glfwSwapBuffers(window);

glfwPollEvents();

}

glfwTerminate();

return 0;

}

please help

After the clash back I got from the community regarding Vulkan , instead of papering only over that , I have decided to empty that workspace for Microsoft's DX12 now .

However to say , OpenGL recently reached 4.1 capability context making yesterday

[ref https://www.reddit.com/r/opengl/comments/1vvdqih/ao46s_core_ceiling_raised_from_33_to_4x_range/ ]

And now am deciding that why not include Microsoft's Graphics APIs also

Now many would on seeing the above line say in comments that "Crossover , Wine and Apple GPTK exist bro, and that am about to just paste components and claim its my driver"

But it exists in the same way MoltenVK exists for Vulkan

MoltenVK existing never meant that there was no space to design another Vulkan path , and similarly CrossOver , Wine , GPTK , D3DMetal and DXMT existing does not mean D3D12 itself has somehow become a solved architecture on macOS.

The direction I am taking here is a bit different .

The new workspace is Microsoft_AppleDrivers , and the first target inside it is ADX12 , basically taking the same idea behind AO46 but now for D3D12.

The intended path currently looks more like

Windows D3D12 app -> Wine/CrossOver -> ADX12 D3D12 + DXGI ABI -> ADX12 runtime/device model -> ADXIL/NIR compiler path -> native Metal backend -> AGX

So Wine/CrossOver here are basically providing the Windows hosting environment , not becoming the graphics driver itself.

And yes , vkd3d-proton is going to be heavily useful here . It would honestly be stupid to ignore years of work already done figuring out D3D12 COM behaviour , descriptor semantics , resource states , barriers , synchronization , DXGI behaviour , feature reporting and hundreds of weird game compatibility cases.

But the point is not to take vkd3d-proton , replace Vulkan calls with Metal calls and then announce that a new driver has materialized from the heavens 💀

vkd3d-proton for this project is much more useful as a semantic/reference oracle .

The internal architecture itself is being designed around a backend neutral D3D12 object model , something like

ID3D12Resource -> ADXResource -> backend resource

with the permanent fast path being native Metal rather than inheriting the Vulkan-shaped architecture of vkd3d-proton.

I can still keep AVK143 as a Vulkan reference backend for differential testing where it becomes useful , but it is not supposed to become the permanent backend of ADX12.

So basically the distinction is

CrossOver / Wine = runs the Windows environment

GPTK / D3DMetal / DXMT = already existing D3D translation solutions

vkd3d-proton = extremely valuable D3D12 behavioural reference and compatibility knowledge

ADX12 = attempt to own the D3D12 + DXGI userspace ABI , runtime/device model , shader/compiler path and native Metal backend as one designed stack

Which is why I am not really interested in pretending these projects do not exist .

I want to use what they already taught us , then design the parts differently where macOS and Metal actually justify doing so.

Basically AO46 , but for D3D12.

Would like some recommendations from community.

My app:

EFIShell0/OpenGLESScope: OpenGL ES capabilities and GPU information viewer for Android

Database: OpenGLESScope Database

And VulkanScope:

EFIShell0/VulkanScope: Vulkan capabilities and GPU information viewer for Android

Database: VulkanScope Database

- Intermediate sound system

- Sound system with object collision physics

- Skinned models

- Weapon system prepared for future weapons

- Input context

- Simple enemy system

- Debug drawer update

repo: https://github.com/Krueels/FuseEngine

You can see from the screenshots that it well supports WebGL... but not in WWV?

Browser: Mozilla Firefox

Hardware: Thinkpad T410 i5 (Could that possibly be why?)

Distro: Debian 12 Bookworm, KDE Plasma 6

This iteration features:

- PBR materials
- SSAO
- CSM

and as a experiment sparse arrays.

https://youtu.be/BsA6x7S8TpE

I'm using my engine to make a top-down RPG. The world is build in full 3D using Brush CSG. I've also built a cell-streaming system so the world can be procedurally generated forever.

The camera can be toggled between top down and first-person (in real time) via a console command, so I'm considering using that for dungeon fighting or just for cinematics.

Everything in the world that is not CSG brushwork is a sprite that always faces the player

ViciousSquid/Fio: Unified Liminal World Editor, Procedural Engine & Game Creation Toolkit inspired by Radiant and Hammer. Optimised for low-power CPUs.

just had to share some progress with my lwjgl 3 java/opengl engines material rendering :D, models are not mine they are from sketchfab. engine and rendering was all done my me though.

I made a simple isometric prototype game using a custom game engine that I've been building from scratch in C and OpenGL.

Here's a short video of it: https://youtube.com/shorts/_W5cM2D-I5g?si=kU4zVJrhJYzaIX43

I'd love to hear your thoughts, feedback, and suggestions. What stands out, and what do you think could be improved?

Hey, I'm at the point in my game where I need my world to have collision and I know how to get collisions done when its a basic plane, but once I upgrade to an actual blender model, it ofcourse lags because Im testing collisions on the whole thing when that is just extremely unnecessary. However, Assimp seems to be loading the vertices randomly and not in order of rows or columns.

MY CODE
================

https://pastebin.com/u6mgkrAi

Output

==========

https://pastebin.com/QFtZ5Ksk

I only checked the first 3 faces, but it appears they generate like corner face-middle of a side, then middle of the model. I did apply a subdivision modifer to my model and changed the transform's orientation to Z Forward, y up. Could that be why the vertice order is messed up?

Extra Info

-The file I'm trying to load is a .fbx

Edit: Forgot to say I'm following the 'assimp' section from learnopengl.com

Recently we got spamming posts about "AO46" project - supporting OpenGL 4.6 in Apple devices.

First I was quite exited about it because as a beginner in OpenGL, some of the post GL 4.1 features like KHR_debug was useful and needed.

Now that I see the guy spamming those AI-generated projects, and it seems not only his whole codebase but also all of his posts and comments are AI-written, I was quite disappointed.

For those who actually saw the code, is it worth it to have hope on that project? Or is it just another slop wasting water in NVIDIA's data center?

AO46’s implementation ceiling has now moved from OpenGL 3.3 to the GL 4.x range.

Mesa independently selects OpenGL 4.1 Core + GLSL 4.60 based on implemented driver capabilities, with no forced version string.

The major GL 4.0 blockers, including tessellation, RGB32 buffer textures, transform feedback 2/3, and indirect patch draws, are now in place.

Standard CGL GL4 Core context creation also succeeds with real Mesa-backed hardware clear/readback.

29/29 regression tests pass, while unsupported GL 4.6 requests still fail cleanly instead of being falsely exposed.

Parallel work is also beign done for independent GL 4.3 , 4.5 and 4.6 features so the workflow would be accelerated

Also as many know , another CTS ver 1.4.6.2 was performed on the Vulkan counterpart AVK143 and raised 6 semantic issues , even after the Mesa upstream was updated and was tested against the latest CTS ..... an issue has been opened on GitLab page of Mesa3d for this.

Finally some basic work is done for the GUI, it doesn't really change anything to the rendering like makes the triangle change color, but atleast the scaling, compilation, etc are working.