Renderer API Abstraction | Game Engine series

thank you for your great efforts

Nice :D

Why Cherno never ansver to comments?(

Before 500 views

Are you planning on adding a GLCall macro similar to what you did in the OpenGL series to Hazel?

In the constructors for Index and Vertex buffer, could you not just call Bind() instead of repeating the code?

Ty xD

Would you go as far as to optimize certain things in Assembler? I would find that quite interesting

You forgot to change size to count in a lot of places

Hello i came from France.Please can you put subtitles on french. I really like your vidéos.

Would like to see Hazel build successfully

Hi, I really like this series. In terms of the design of the graphics API I usually create a description struct for let say buffer. So you can specify all of the parameters on the client side like render mode. And than you pass the structure by reference to the API function to act on it (API::Buffer::Create(BufferDesc & desc); ), so you have everything in one place and you also have an access to any parameter you want. Anyway Great job. I am really interested about your design. Looking for the next episode !!!

I just use dlls that get loaded and provide a generic api to that rendering api.

Seems like a bit of a misuse of polymorphism. These should be opaque types in my opinion.

I've lost interest in your tutorials man, I don't think coding live is a great idea cause it's a waste of time...
It would be better if you used your method where you just show us the code than writing it, because you'll be able to add more features in long length videos.. I mean c'mon, 47 minutes to add a simple buffer class.
I am not saying to skip the explaining part at the beginning and I'm not trying to say shorten your videos, what I'm trying to saying is BLAST the code, give a little explanation then move on to the next feature cause this way, it will be more effective to those who really trying to build a game engine of there own. And this way, you'll be able to finish what you'll achieve in a year in half a year, that would be more efficient.
I really like long length videos, but not like this...
BUT! I wouldn't have achieved this far in my engine without these tutorials, Thank you for your great effort man :D

Yan, once again, thank you for your hard-work. You've taught us so much. Praying for your further success and will be a Patreon soon. :)

Are you planning to implement ECS in hazel?

This looks generic enough to justify a header only library. Why not just write and maintain one? ONE being the important part.

why do u always use std::cout when u can just put using namespace std; at the start of your code

HELL YES.

Respect+ for the best teacher and the best programmer

I am doing this on an Intel HD 4400 and it took me some time to figure out but CreateBuffers crashes the application, guess that function is not available in the drivers

I get "invalid new-expression of abstract class type ‘Hazel::OpenGLIndexBuffer’ "
[Edit]
And then I fixed with
virtual uint32_t GetCount(){return m_Count;};
to
virtual uint32_t GetCount() const override{return m_Count;};

"I care about performance" - same here.. it's so hard to trust someone else's code, even Microsofts'/DirectX/Win32. We have no other option though.

The unpleasant feeling when your code suddenly runs but you don't know what was wrong….

I really appreciate how well put together the teaching is. No need of diagrams, the explanation itself is perfectly appropriate. Thanks.

The glCreate* functions generate object names and initialize the objects, whereas the glGen* functions just create the names. The glCreate* functions are usually used for direct state access (core in 4.5), where you do not need to bind objects before changing state (e.g. glNamedBufferData instead of glBindBuffer followed by glBufferData), where you need to actually have the object initialized (pre-DSA OpenGL initializes objects when they are first bound).

You could have a CreateVertexBuffer method in the Renderer class, and OpenGLRenderer creates a OpenGLVertexBuffer, and VulkanRenderer creates a VulkanVertexBuffer, etc.


m_renderer->CreateVertexBuffer( vertices, size );

For those whose application crashed,
Don't use glCreateBuffer as it will crash on a relatively old machine. glCreateBuffer is only supported on gl4 (OpenGL 4).

I know I am late, but u should use hazel dev to make the diagrams :))

EA wants to push the limits...................... pffffffffffffhaaaaaaaaaaaaahaahaahahahaahahaha!
Best joke I've heard... the limits of shitty-ness? xD
The limits of bad game design? The limits of wanting to milk the user for every penny worth of microtransactions? :))))
C'mon Cheron... like yeah, the engines themselves are quite impressive from a technical point of view, but they do jack diddly squat with them. (fifa mostly)

"i'm mentioning it because i've seen that, don't do that!" aaahahahahah

Why do you make different classes for each buffer type, as opposed to having one class called 'Buffer'?

One thing I decided to do differently here is to use function pointers in order to determine which API's implementation of the buffers to create, rather than a switch statement. I just set the correct function pointers during initialization (during the rendering context's initialization for now but I might change it) and then I only have to make that decision once, rather than every time I want to create a buffer. Not sure whether it'll be more performant in the real world since both conditional statements and function calls have a cost, so I'll have to test the two side-by-side to see which is better.

This is great thanks.

Thanks for your tutorial! I'm following it this summer to see if I could generate a game from draft!
Besides, I'm curious why we don't design a base buffer class(with buffertype variable inside) and inherit vertexbuffer/indexbuffer from it?

Test 2

ChatGPT3.5 Generated content:
- This is part of a game engine series.
- The topic is about abstraction of rendering API calls.
- Handling multiple rendering APIs is important for supporting multiple platforms.
- The speaker believes in prioritizing performance over aesthetics in programming.
- A decision needs to be made on whether to choose the rendering API at compile time or runtime.

On Mac the latest OpenGL version is 4.1 so you are not able to use glCreateBuffers which is available from version 4.5 onwards. I just used glGenBuffers instead.

A thing to keep in mind: you will have to be very careful with copying these buffer abstractions. Both copies will have the same m_renderer_id and as such they will be linked in opengl. The moment the first copy runs out of scope, the destructor will be called and the buffer will be destroyed by opengl. This is especially devious if you pass it by value to some function: this does a copy under water.
It's probably better to delete the copy operations. You can keep the move operations, but make sure to set the renderer_id to 0 in the moved-from object.

The glCreate* functions generate object names and initialize the objects, whereas the glGen* functions just create the names. The glCreate* functions are usually used for direct state access (core in 4.5), where you do not need to bind objects before changing state (e.g. glNamedBufferData instead of glBindBuffer followed by glBufferData), where you need to actually have the object initialized (pre-DSA OpenGL initializes objects when they are first bound).

Hey @The Cherno (does the ats work?) i know this is old stuff, but why exactly do you not do something like namespace gl::vBuffer, which inherits from hazel::vBuffer, as for naming conventions, they all would still store in a vector<vBuffer> and then as you say depending on what the platform is you will staticly compile one or the other? just a curious question, is it a proformance thing? or is it just simply the way you do it? just a thought while i was following along here. btw, and fyi, im doing this on linux, with cmake and in clion. :) thank!