Renderer API Abstraction | Game Engine series
Вставка
- Опубліковано 17 жов 2024
- Patreon ► / thecherno
GitHub repository ► github.com/The...
Instagram ► / thecherno
Twitter ► / thecherno
Discord ► thecherno.com/...
Series Playlist ► thecherno.com/...
Gear I use:
-----------------
BEST laptop for programming! ► geni.us/pakTES
My FAVOURITE keyboard for programming! ► geni.us/zNhB
FAVOURITE monitors for programming! ► geni.us/Ig6KBq
MAIN Camera ► geni.us/t6xyDRO
MAIN Lens ► geni.us/xGoDWT
Second Camera ► geni.us/CYUQ
Microphone ► geni.us/wqO6g7K
The unpleasant feeling when your code suddenly runs but you don't know what was wrong….
I ABSTRACTIFIED THE SHADER CLASS
BY MYSELF
#proud
dude is dat an intrinsic
I ALSO ABSTRACTED THE SHADER CLASS #pragma proud
@@giancedrick507 I go to do that for the glory!
2 years late but heck yea! Good job!
I ABSTRACTED THE BUFFERS AND SHADER CLASS
BY MYSELF
#proud
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. :)
thank you for your great efforts
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).
I really appreciate how well put together the teaching is. No need of diagrams, the explanation itself is perfectly appropriate. Thanks.
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 make an opengl abstraction a vulkan"
Respect+ for the best teacher and the best programmer
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.
it might be similar performance but that's much more elegant, I like it.
I tend to dislike doing checks in code that is being run frequently (as frequently as every frame, like this could be).
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 );
I shall implement your idea good sir
a litle bit late, but the idea is that there is only one renderer class
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
Working on Intel HD too, had the same issues.
I'm guessing your working on a mac
You forgot to change size to count in a lot of places
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.
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?
Are you planning to implement ECS in hazel?
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.
Why do you make different classes for each buffer type, as opposed to having one class called 'Buffer'?
Are you planning on adding a GLCall macro similar to what you did in the OpenGL series to Hazel?
he uses HZ_CORE_ASSERT it's the same
In the constructors for Index and Vertex buffer, could you not just call Bind() instead of repeating the code?
DrBarnabus because it is an extra function call
@@whythosenames But the compiler will inline it.
"i'm mentioning it because i've seen that, don't do that!" aaahahahahah
Can someone tell me if these macros 22:54 (uint32_t etc) are cross-platform or visual c++ only?
It's part of modern C++ (since C++ 11). They are defined in cstdint header.
This is great thanks.
I know I am late, but u should use hazel dev to make the diagrams :))
Would you go as far as to optimize certain things in Assembler? I would find that quite interesting
Most modern C++ compilers do an excellent job at optimising assembly code before linking and there is very little to no gain in doing it manually.
Chris Rivard yeah I know that but maybe it’s still useful in some cases Im not an expert and just recently started learning RISC-V assembly
HELL YES.
Nice :D
Before 500 views
Would like to see Hazel build successfully
What issues are you having? Why isn't it building successfully?
@@TheCherno Its complaining about ImGuiLayer.cpp lines 33, 34, 44, 82, 85 and 86 with C2039, C3861, C2065 and C3861 errors in both the version of Hazel Im following along with and your github version.
ImGuiConfigFlags_DockingEnable
@@Murderface666 seems like you don't have the docking branch of ImGui
Ty xD
I just use dlls that get loaded and provide a generic api to that rendering api.
That's probably what I'm going to do in my game engine.
why do u always use std::cout when u can just put using namespace std; at the start of your code
Because using namespace std; is a bad idea. It pollutes the global namespace.
Test 2
"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.
Why Cherno never ansver to comments?(
UA-cam isn't same as GitHub Issues
@Rafael Arturo Mateo Núñez yea, right, he is not an "UA-camr", he just making amazing videos for UA-cam!
Has anyone successfully built Hazel? ImGuiLayer.cpp is having issues
@@Murderface666 Just look at errors lol
Hello i came from France.Please can you put subtitles on french. I really like your vidéos.
Tibotibo A I assume you are in School for a few years now, so it shouldn’t take you a long time until your level of englisch gets good enough to understand this. Especially since you are watching englisch UA-cam. This boosted my English skills quite a bit 😅.
Seems like a bit of a misuse of polymorphism. These should be opaque types in my opinion.
you mean like hexagonal architecture? passing the object as an rgument to the functions, but it itself doesn't necessarily inherit from the virtual class but is its implementation. I use that pattern quite a lot with golang.
This looks generic enough to justify a header only library. Why not just write and maintain one? ONE being the important part.
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.
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)
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).