YEAH!!! I agree! And I also suggest ChiliTomatoNoodle he is really good too and has made tutorials on directx and also on cpu architecture if you are interested:)
Something that you haven't discussed, that I'd rather like to see, is unit and integration testing. Even though it isn't strictly related to a game engine, I would really like to see how to organize and write them in an effective manner, in a large scale application. Most tutorials merely cover the basic setup and syntax.
I was wondering, why don't we just add the UploadUniform functions as pure virtual in the Base Shader class so we can call it without having to cast the shader to an openglshader?
Considering that glm is just a good maths library (I probably would use matrices, vectors and strings in any renderer implementation), I personally did just this - put'em in the base shader class. This way I don't see "OpenGL" in sandbox or higher level engine modules, and that feels good to me.
In OpenGL, you can create a pipeline object that allows you to attach different shader program stages at runtime (as long as they are compatible). In Vulkan, however, you can't do this since shader stages are fixed at the creation of the pipeline. You can mimic OpenGL by creating a pipeline for every combination of shader stages. I hope that was relavent to your question
What's the point of using reference counted objects? It obviously induces overhead, but more importantly it makes object ownership unclear, which sounds like a maintenance and code readability burden (see: Rust's ownership system). Why not use *std::unique_ptr* s instead?
if you want to pass a reference somewhere else, like a method or something, you can't use std::unique_ptr. As its name suggests, it is unique and can't be copied/passed around
So many videos, love it!
The Cherno makes the best learning material I've seen. THANK YOU, I am binge watching so much of your content and learning so much!
YEAH!!! I agree! And I also suggest ChiliTomatoNoodle he is really good too and has made tutorials on directx and also on cpu architecture if you are interested:)
3 Vids in one week... Welcome back cherno :)
Hope all is going well since you left EA
Look the stanford bunny on the desktop, cool~~~
i've been following you since my day one of learning c++,am very thankful for your good videos
Something that you haven't discussed, that I'd rather like to see, is unit and integration testing. Even though it isn't strictly related to a game engine, I would really like to see how to organize and write them in an effective manner, in a large scale application. Most tutorials merely cover the basic setup and syntax.
Definitely would love to see testing incorporated into it.
Every engine writer gangsta until they need to make shaders portable 🤣
I'm so happy for you and your wife! :)
you can also do glUniform4fv(location, 1, glm::value_ptr(matrix)) and the same with the other vectors
thanks!
23:52 add "ImGui::ColorEdit3("Square Color", glm::value_ptr(m_SquareColor));", could change color
Shader Abstraction, add OpenGLShader.h
You have an update available for your VS.
I was wondering, why don't we just add the UploadUniform functions as pure virtual in the Base Shader class so we can call it without having to cast the shader to an openglshader?
Considering that glm is just a good maths library (I probably would use matrices, vectors and strings in any renderer implementation), I personally did just this - put'em in the base shader class. This way I don't see "OpenGL" in sandbox or higher level engine modules, and that feels good to me.
Where can I learn to write proper Shader class that The Cherno mentioned ?
Does directx and vulkan use shaders in the way that opengl handles it? A "pipeline" during runtime?
In OpenGL, you can create a pipeline object that allows you to attach different shader program stages at runtime (as long as they are compatible). In Vulkan, however, you can't do this since shader stages are fixed at the creation of the pipeline. You can mimic OpenGL by creating a pipeline for every combination of shader stages.
I hope that was relavent to your question
I wont lose my interres for this series even if it will have 1000 videos!
Wow look at your old video 😂
Nice
What's the point of using reference counted objects?
It obviously induces overhead, but more importantly it makes object ownership unclear, which sounds like a maintenance and code readability burden (see: Rust's ownership system).
Why not use *std::unique_ptr* s instead?
if you want to pass a reference somewhere else, like a method or something, you can't use std::unique_ptr. As its name suggests, it is unique and can't be copied/passed around
@@fanisdeli Of course it can be passed around! As long as the method doesn't hold on to the reference after returning
2D!
first.
2nd
Fourth