Clone the sources: git clone --recurse-submodules github.com/emeiri/ogldev.git If you want to get the same version that was used in the video you can checkout the tag 'VULKAN_01'. Build on Windows: Open the Visual Studio solution: ogldev\Windows\ogldev_vs_2022\ogldev_vs_2022.sln Build the project 'Vulkan\Tutorials\Tutorial01' PS: if you didn't get the joke behind the thumbnail, go see 'Darkest Hour' with the great Gary Oldman :-) Notes: 1. Just in case you are developing Vulkan on Wayland - you won't be able to see the window at this stage. This is by design. A Wayland window is not shown until a buffer is committed. Thanks Alexander Kiefer for this info. 2. If you are compiling my sources but you created the Visual Studio project yourself make sure to define the following preprocessor macros: OGLDEV_VULKAN; _USE_MATH_DEFINES; 3. (#2 followup) Also make sure to enable 'ISO C++ 20 Standard (std:c++20)' in the project properties -> C/C++ -> Language.
Hello thank for the information, so I will start OpenGL first, but you said I need GPU while I don't have pc I am using laptop which also only have CPU and the graphic is integrated the CPU the laptop isn't powerful, so should I continue learn or stop learning OpenGL or Vulkan until I buy better devices? do you need information about laptop to see if it is suitable or not
Sorry for the late response. I just saw this comment. Hopefully you already handled it on you own. fwiw, most integrated CPUs have support for OpenGL. Some of them even support Vulkan so even if the laptop is not powerful, if the CPU is fairly new there's a good chance it supports it. Good luck!
YES!! A vulkan series!! This is exactly what I need. Please keep going with this. I have to convert my 2D game development framework from OpenGL to Vulkan at some point and this would be invaluable to that process. 🤘🏻
This is the best thing in 2024 so far! I've been enjoying your content a lot recently, i have tried learning vulkan before but it was too complicated for me.
Good Luck with the new series, Etay. Not for me at the moment - I still have a ton to learn about OpenGL - but I'd love to get into Vulkan at some point in the future. Many Thanks for sharing your knowledge.
I actually prefer using my own math library but I think that for this series I will make an effort and provide a GLM path as well because I know most people use it.
@@OGLDEVcool, what i experienced that there is enough challenge with the API on its own to have something appear on the screen, but having to battle with math concepts like handedness, and row major or column major mismatches in a more complex tutorial like cascade shadow map deems it almost impossible task for beginners to tackle with
That's why the focus of the series, at least in it's initial stages, will be on the API itself without introducing new math concepts. So we can implement the same samples as in OpenGL but in a "vulkanized" way. At some point there will be new material with new math and I may implement it in both APIs, if I have the time...
Wow, this is the treasure. But i have a question. At 9:53 i found there is a VulkanCore.lib at the folder but i don't see that at the github code. I have install the Vulkan SDK, but i don't found the solution to solve that problem.
Thanks! Did you build the solution? Windows\Lib is the destination folder for the VulkanCore project so the tutorials projects know where to find it. I don't have it on github because it is constantly being changed. I only upload to github 3rd party stuff which is rarely updated.
Ray tracing is out of scope at this point. Maybe in the future. The plan is to develop a 3D renderer. Something that takes a description of a scene and renders it as efficiently as possible. That you can build a game on top of it.
@OGLDEV I'm asking because you mentioned a performance as the main advantage. So it would be interesting to see how lightning or collision detection can be implemented using low-level api
Not sure if Vulkan will process long shaders (a.k.a complex lighting models) faster than OpenGL. After all, the execution units are still the same. The potential is the reduction in draw call count, preparing most of the frame offline, multithreading, zero driver overhead, etc.
I'm definitely interested in DirectX because, let's admit it, it's a huge market on Windows. But it will have to wait until I can free some bandwidth for it.
I guess you can consider Vulkan to be batched rendering on steroids. If you do your job correctly you prepare as much of the frame as possible before the render loop and then do minimal changes (matrix updates, etc) inside the loop.
Hello thank for the information, so I will start OpenGL first, but you said I need GPU while I don't have pc I am using laptop which also only have CPU and the graphic is integrated the CPU the laptop isn't powerful, so should I continue learn or stop learning OpenGL or Vulkan until I buy better devices? do you need information about laptop to see if it is suitable or not
Definitely continue learning! If your laptop is from recent years I'm almost 100% sure it supports OpenGL and most likely Vulkan too. For example, Intel Integrated graphics supports Vulkan for the past few generations of CPUs. Upgrading to a PC with a dedicated GPU is only required if you plan to develop complex scenes with many assets and very large textures. For getting started you should be fine with what you have.
You can use any dev env that you want, but I'm using Visual Studio so if you have that you can run my code out of the box. Other than that you just need to set up the build/link flags on your preferred env and you're good to go. Unfortunately, I only have time to support a single env.
I do everything in VS Code using Cmake (with cmakefiles for build setup) with ninja, and mingw-w64 compilers. Once you become familiar with how to link and compile a basic cpp program and how to link libraries with cmake, the rest of the tutorial should be the same.
a gtx 660ti supports vulkan 1.2 since the apis depend on the versions of the drivers and as long your old gpu has a driver version that supports vulkan youre fine
Curious to see where this goes. After 4+ years with Vulkan I will go back to OpenGL. Vulkan just gets on my nerves. OpenGL with AZDO techniques is much better and was the direction they should have went with the API.
@@OGLDEV Not too much in my case since I was never CPU bound with OpenGL in the first place. You benefit from it if you're not able to keep the GPU busy enough. Vulkan's command buffer concept that you can easily fill from multiple threads is a plus in that case. The major benefits aren't performance in my opinopn, but validation layers and the fact that it isn't a big state machine. It feels cleaner in that regard. But then it is just is too convoluted. Also, I had trouble getting Linux and Windows to behave the same way regarding input lag etc. (you can look up an ImGUI issue about that). Just problems I never had with OpenGL. Vulkan is for the people with *very* specific requests and too few gamestudios build their tech on it. DX12/Metal are a much better investment of time if one want a "modern" API. OpenGL could have been molded into something modern and I hope more people will realize this.
Thanks. I'm always amazed when people claim that "OpenGL is dead" and that everyone should switch to Vulkan while so many beginners are finding out OpenGL to be very very challenging. Not just the API itself but also the math (which is the same for Vulkan) but when you add everything together you can be overwhelmed. I can easily identify with what you're saying.
@@OGLDEV Too much OpenGL code is out there and WebGL is still in use. I doubt it is easy to replace all that stuff. Also, it just makes no sense to replace something that is and has running well for a long time. You can make an argument for Vulkan if you need the absolute bleeding edge but you get only to the bleeding edge when you know exactly how you sync everything with barriers and fences correctly which can be hard to get right. Especially because Vulkan code reads like noise. Yes, it is explicit and all and you can abstract it away; but good luck getting it all right. And then again: If you go through the hassle of doing all that you can also just use DX12 or Metal. I assume that OpenGL will get its renaissance eventually.
I wanted to have all the setup info in the first video, even if we only use the first Vulkan function in the next one. I expect the compile/link config to be relevant for quite a few videos.
I'm already overwhelmed and discouraged from just trying to learn OpenGL let alone Vulkan. I have found it very difficult to understand how the functions work together. It's the only thing I have had this much trouble with. I really hate it's interface.
Sorry to hear that. The way I see it Vulkan is the result of a very long process that took place in the industry which involved the HW vendors (who sit in the various work groups of Khronos) and top game and game engine developers. These people hit a performance wall with OpenGL which originated in the early 90s before the age of multi core CPUs. While OpenGL has improved in this department there was still performance left on the table due to driver overhead, cpu/gpu sync problems and other factors. The industry (the elite of it actually) wanted more control over everything which is going on and the result is Vulkan, DX12 and Metal. But many people are happily programming in OpenGL and even more people use a game engine and don't really care. So if you find it too much of a challenge don't feel that you "have" to switch right now just because various people on reddit are saying that OpenGL is dead. Believe me, it's far from it. If OpenGL is almost 35 years old then Vulkan may be there around 2050 (I'm counting from 2016 ;-)) . How crazy is that? You have plenty of time to digest OpenGL and make yourself ready for Vulkan or any other API.
I think that's what I have on my old computer and it runs Vulkan just fine. Very affordable if you are stressed for cash. Today I have GTX 1650 which is also not high end.
new series, yay! My current favorite vk series is ruclips.net/p/PLmIqTlJ6KsE1Jx5HV4sd2jOe3V1KMHHgn . The clear categorization of commands at ruclips.net/video/J1A1kWBVrzc/видео.html or the vulkan sync video are one of my favorite videos of all time on youtube. But the playlist focuses on vulkan basics, and never talks about the higher level topics like you do with openGL series. eg: font rendering or using depth/stencil buffers. I hope your series will finally fill that gap. Also, just in case you haven't thought about it yet, there might be audience for a webgpu series? Vulkan (while great) is too low level and unsafe is just ugh.. meanwhile, webgpu (dawn/wgpu) will have a *much* simpler API that is based on vulkan/metal with pipelines, command buffers, render/compute passes, device/queues, bindgroups etc.., BUT skip the complex parts like spirv, explicit sync etc.. You also get metal (apple) support for free. And you get to deploy them on web (plenty of free static hosting like github/netlify). eg: bevyengine.org/examples/2D%20Rendering/move-sprite/ uses wgpu and will work on both webgl and webgpu with the same code. It will also allow you to use Rust (with wgpu) or JS (on web or with deno), both of which will completely eliminate c problems like segmentation faults (mostly). A good example is resizing the Surface (swapchain/viewport), which will crash with a proper error upon bad values (width/height being zero). This makes debugging easy, and focus on the drawing part.
Thanks for the links. I'll be sure to check them out. Regarding webgpu - I guess it is out of scope for now. I'm not familiar with it so I don't know how much effort it requires on top of Vulkan.
disagree with your setup, I think you should've gone with volk, which takes a little more effort to do but ties in with vma and simplifies extension loading when you are done with instance creation.
Volk can be nice for some things, but I disagree that volk would/should be preferred here. Given his approach to OpenGL, I think his setup here is best case scenario. I don’t think volk is lesser necessarily. I just think a more direct approach to Vulkan fits this channel much more. And that approach is the reason why I subscribed long ago, so I’m glad he went the way he did with his setup. Volk is nice to mention though, and thankfully I think you can still follow along if you prefer volk.
Volk enables dynamic loading instead of static linking. I consider this to be somewhat more advanced and I want to keep things as simple as possible for the newcomer. Will probably cover it in the future.
This should be interesting to watch but I'm sticking with OpenGL, I mean I'm making a game. I have to be objective. And frankly as indie I don't see the benefit of using Vulkan over OpenGL.
That's totally fine. I keep telling people that OpenGL is here to stay since Vulkan is very complex and geared towards people who want to squeeze every cycle from the machine. So engine devs, etc. If the game doesn't hit any major bottleneck then there's no reason not to use OpenGL.
@@OGLDEV Indeed. To clarify I'm not complaining at all. :) I very much appreciate the content you already have put out for OpenGL and found myself multiple times consulting it to figure out how to do things in my game. I understand that for you, as an educational content creator, you have all the reasons to expand your content, that makes sense.
Clone the sources:
git clone --recurse-submodules github.com/emeiri/ogldev.git
If you want to get the same version that was used in the video you can checkout the tag 'VULKAN_01'.
Build on Windows:
Open the Visual Studio solution: ogldev\Windows\ogldev_vs_2022\ogldev_vs_2022.sln
Build the project 'Vulkan\Tutorials\Tutorial01'
PS: if you didn't get the joke behind the thumbnail, go see 'Darkest Hour' with the great Gary Oldman :-)
Notes:
1. Just in case you are developing Vulkan on Wayland - you won't be able to see the window at this stage. This is by design. A Wayland window is not shown until a buffer is committed. Thanks Alexander Kiefer for this info.
2. If you are compiling my sources but you created the Visual Studio project yourself make sure to define the following preprocessor macros: OGLDEV_VULKAN; _USE_MATH_DEFINES;
3. (#2 followup) Also make sure to enable 'ISO C++ 20 Standard (std:c++20)' in the project properties -> C/C++ -> Language.
Hello thank for the information, so I will start OpenGL first, but you said I need GPU while I don't have pc I am using laptop which also only have CPU and the graphic is integrated the CPU the laptop isn't powerful, so should I continue learn or stop learning OpenGL or Vulkan until I buy better devices? do you need information about laptop to see if it is suitable or not
Sorry for the late response. I just saw this comment. Hopefully you already handled it on you own. fwiw, most integrated CPUs have support for OpenGL. Some of them even support Vulkan so even if the laptop is not powerful, if the CPU is fairly new there's a good chance it supports it. Good luck!
Finally, so excited for this series already. Your videos on ogl have been nothing but great, keep up the great work man!
Thanks!
NO WAYYYY, I learned opengl from you, can't wait to learn vulkan too! Thanks for the great tutorials man, they really help me a lot
Glad you like them!
Sweet, perfect timing! Been thinking about learning Vulkan recently, you are a good teacher so I can't wait!
Hope you enjoy it!
YES!! A vulkan series!! This is exactly what I need. Please keep going with this.
I have to convert my 2D game development framework from OpenGL to Vulkan at some point and this would be invaluable to that process. 🤘🏻
Will do!
This is the best thing in 2024 so far! I've been enjoying your content a lot recently, i have tried learning vulkan before but it was too complicated for me.
Awesome, thank you!
THANK YOU! You got me started in openGL. Realized that its not as flexible as I need, so been thinking of learning Vulkan. Perfect timing!
Cool!
Your work inspired me alot, I am really happy to see you start to work on this new API, I will look forward for other videos!
Happy to hear that!
Finally, so excited for vulkan🤩🤩
:-)
lets go! cant wait for this series
Thanks!
Looking forward to it! I’ve come a bit far on Vulkan and really would like this series to continue as most have been abandoned :,(
Thanks!
Good Luck with the new series, Etay.
Not for me at the moment - I still have a ton to learn about OpenGL - but I'd love to get into Vulkan at some point in the future.
Many Thanks for sharing your knowledge.
You're welcome!
Damn! Just started learning Vulkan myself one month ago. Can't wait to see how this series turns out
me2 ;-)
Oh the new Vulkan tutorial for gentlemen
Especially if your name is Winston... ;-)
very excited to learn vulkan!
Nice!
the goat is back with new api, what a chad thanks al ot
LOL! You're welcome :-)
much appreciated, the community needs as much help as possible, as vulkan curve is steep ... if you could use GLM for math, that would be great
I actually prefer using my own math library but I think that for this series I will make an effort and provide a GLM path as well because I know most people use it.
@@OGLDEVcool, what i experienced that there is enough challenge with the API on its own to have something appear on the screen, but having to battle with math concepts like handedness, and row major or column major mismatches in a more complex tutorial like cascade shadow map deems it almost impossible task for beginners to tackle with
That's why the focus of the series, at least in it's initial stages, will be on the API itself without introducing new math concepts. So we can implement the same samples as in OpenGL but in a "vulkanized" way. At some point there will be new material with new math and I may implement it in both APIs, if I have the time...
@@OGLDEVreally great, thank you for the effort, i hope khronos guys notice!
Looking forward to it!
:-)
Wow, this is the treasure. But i have a question. At 9:53 i found there is a VulkanCore.lib at the folder but i don't see that at the github code. I have install the Vulkan SDK, but i don't found the solution to solve that problem.
Thanks! Did you build the solution? Windows\Lib is the destination folder for the VulkanCore project so the tutorials projects know where to find it. I don't have it on github because it is constantly being changed. I only upload to github 3rd party stuff which is rarely updated.
Thank you so much for doing this! Will you use the latest features such as dynamic rendering or device buffer address?
You're welcome! I hope to cover both topic later on.
What exactly are you planning to develop for the tutorials? How about a simple ray tracer?
Ray tracing is out of scope at this point. Maybe in the future. The plan is to develop a 3D renderer. Something that takes a description of a scene and renders it as efficiently as possible. That you can build a game on top of it.
@OGLDEV any insights about the scene? How about global illumination, or it's only going to be uploading 3d models and textures for them?
@OGLDEV I'm asking because you mentioned a performance as the main advantage. So it would be interesting to see how lightning or collision detection can be implemented using low-level api
We will start with simple lighting/texturing but the plan is definitely to improve these with global illumination, pbr and the other goodies.
Not sure if Vulkan will process long shaders (a.k.a complex lighting models) faster than OpenGL. After all, the execution units are still the same. The potential is the reduction in draw call count, preparing most of the frame offline, multithreading, zero driver overhead, etc.
good
lets get this done
:-)
im excited
Thx :-)
Just yesterday I was considering to start trying Vulkan. I guess now is a good time
Exactly!
How frequent will the tutorials be uploaded?
Probably every two to three weeks. Unfortunately that's my current capacity.
oh boy...vulkan...begginers...interesting. Are there any plans for any DirectX content or will you keep it vendor neutral ?
I'm definitely interested in DirectX because, let's admit it, it's a huge market on Windows. But it will have to wait until I can free some bandwidth for it.
@@OGLDEV got it, take your time, and thank you for the content
Is there an equivalent to batch rendering in Vulkan?
I guess you can consider Vulkan to be batched rendering on steroids. If you do your job correctly you prepare as much of the frame as possible before the render loop and then do minimal changes (matrix updates, etc) inside the loop.
Hello thank for the information, so I will start OpenGL first, but you said I need GPU while I don't have pc I am using laptop which also only have CPU and the graphic is integrated the CPU the laptop isn't powerful, so should I continue learn or stop learning OpenGL or Vulkan until I buy better devices? do you need information about laptop to see if it is suitable or not
Definitely continue learning! If your laptop is from recent years I'm almost 100% sure it supports OpenGL and most likely Vulkan too. For example, Intel Integrated graphics supports Vulkan for the past few generations of CPUs. Upgrading to a PC with a dedicated GPU is only required if you plan to develop complex scenes with many assets and very large textures. For getting started you should be fine with what you have.
We must use visual studio code? Vs code isn't capable?
You can use any dev env that you want, but I'm using Visual Studio so if you have that you can run my code out of the box. Other than that you just need to set up the build/link flags on your preferred env and you're good to go. Unfortunately, I only have time to support a single env.
I do everything in VS Code using Cmake (with cmakefiles for build setup) with ninja, and mingw-w64 compilers. Once you become familiar with how to link and compile a basic cpp program and how to link libraries with cmake, the rest of the tutorial should be the same.
a gtx 660ti supports vulkan 1.2 since the apis depend on the versions of the drivers and as long your old gpu has a driver version that supports vulkan youre fine
thx, 1.2 is good enough at this stage.
YESSSS!!!!
:-)
Curious to see where this goes. After 4+ years with Vulkan I will go back to OpenGL. Vulkan just gets on my nerves. OpenGL with AZDO techniques is much better and was the direction they should have went with the API.
Have seen any performance gain from switching to Vulkan?
@@OGLDEV Not too much in my case since I was never CPU bound with OpenGL in the first place. You benefit from it if you're not able to keep the GPU busy enough. Vulkan's command buffer concept that you can easily fill from multiple threads is a plus in that case. The major benefits aren't performance in my opinopn, but validation layers and the fact that it isn't a big state machine. It feels cleaner in that regard. But then it is just is too convoluted. Also, I had trouble getting Linux and Windows to behave the same way regarding input lag etc. (you can look up an ImGUI issue about that). Just problems I never had with OpenGL. Vulkan is for the people with *very* specific requests and too few gamestudios build their tech on it. DX12/Metal are a much better investment of time if one want a "modern" API. OpenGL could have been molded into something modern and I hope more people will realize this.
Thanks. I'm always amazed when people claim that "OpenGL is dead" and that everyone should switch to Vulkan while so many beginners are finding out OpenGL to be very very challenging. Not just the API itself but also the math (which is the same for Vulkan) but when you add everything together you can be overwhelmed. I can easily identify with what you're saying.
@@OGLDEV Too much OpenGL code is out there and WebGL is still in use. I doubt it is easy to replace all that stuff. Also, it just makes no sense to replace something that is and has running well for a long time. You can make an argument for Vulkan if you need the absolute bleeding edge but you get only to the bleeding edge when you know exactly how you sync everything with barriers and fences correctly which can be hard to get right. Especially because Vulkan code reads like noise. Yes, it is explicit and all and you can abstract it away; but good luck getting it all right. And then again: If you go through the hassle of doing all that you can also just use DX12 or Metal. I assume that OpenGL will get its renaissance eventually.
I really hope that they will realize that they should update the OpenGL spec and continue improving it.
YAY!
:-)
I personally prefer start with d3d11. Now I'm a big fan of Vulkan and D3D12.
I would love to make a D3D11 series. Unfortunately I don't have the time for it...
There is no project VulkanCore in the opened solution
I showed it in the video to explain the project structure but we actually start developing it in the next video so will be checked in by then.
But at 07:13 "right-click the project" you are starting setting properties on it.
I wanted to have all the setup info in the first video, even if we only use the first Vulkan function in the next one. I expect the compile/link config to be relevant for quite a few videos.
I'm already overwhelmed and discouraged from just trying to learn OpenGL let alone Vulkan. I have found it very difficult to understand how the functions work together. It's the only thing I have had this much trouble with. I really hate it's interface.
Sorry to hear that. The way I see it Vulkan is the result of a very long process that took place in the industry which involved the HW vendors (who sit in the various work groups of Khronos) and top game and game engine developers. These people hit a performance wall with OpenGL which originated in the early 90s before the age of multi core CPUs. While OpenGL has improved in this department there was still performance left on the table due to driver overhead, cpu/gpu sync problems and other factors. The industry (the elite of it actually) wanted more control over everything which is going on and the result is Vulkan, DX12 and Metal. But many people are happily programming in OpenGL and even more people use a game engine and don't really care. So if you find it too much of a challenge don't feel that you "have" to switch right now just because various people on reddit are saying that OpenGL is dead. Believe me, it's far from it. If OpenGL is almost 35 years old then Vulkan may be there around 2050 (I'm counting from 2016 ;-)) . How crazy is that? You have plenty of time to digest OpenGL and make yourself ready for Vulkan or any other API.
cool !
Thanks!
we are getting errors on games with this one!
What errors exactly?
I recommend the Nvidia 1030 GT
I think that's what I have on my old computer and it runs Vulkan just fine. Very affordable if you are stressed for cash. Today I have GTX 1650 which is also not high end.
new series, yay!
My current favorite vk series is ruclips.net/p/PLmIqTlJ6KsE1Jx5HV4sd2jOe3V1KMHHgn . The clear categorization of commands at ruclips.net/video/J1A1kWBVrzc/видео.html or the vulkan sync video are one of my favorite videos of all time on youtube.
But the playlist focuses on vulkan basics, and never talks about the higher level topics like you do with openGL series. eg: font rendering or using depth/stencil buffers.
I hope your series will finally fill that gap.
Also, just in case you haven't thought about it yet, there might be audience for a webgpu series? Vulkan (while great) is too low level and unsafe is just ugh.. meanwhile, webgpu (dawn/wgpu) will have a *much* simpler API that is based on vulkan/metal with pipelines, command buffers, render/compute passes, device/queues, bindgroups etc.., BUT skip the complex parts like spirv, explicit sync etc.. You also get metal (apple) support for free. And you get to deploy them on web (plenty of free static hosting like github/netlify). eg: bevyengine.org/examples/2D%20Rendering/move-sprite/ uses wgpu and will work on both webgl and webgpu with the same code.
It will also allow you to use Rust (with wgpu) or JS (on web or with deno), both of which will completely eliminate c problems like segmentation faults (mostly). A good example is resizing the Surface (swapchain/viewport), which will crash with a proper error upon bad values (width/height being zero). This makes debugging easy, and focus on the drawing part.
Thanks for the links. I'll be sure to check them out.
Regarding webgpu - I guess it is out of scope for now. I'm not familiar with it so I don't know how much effort it requires on top of Vulkan.
:)
:-)
disagree with your setup, I think you should've gone with volk, which takes a little more effort to do but ties in with vma and simplifies extension loading when you are done with instance creation.
Volk can be nice for some things, but I disagree that volk would/should be preferred here. Given his approach to OpenGL, I think his setup here is best case scenario.
I don’t think volk is lesser necessarily. I just think a more direct approach to Vulkan fits this channel much more. And that approach is the reason why I subscribed long ago, so I’m glad he went the way he did with his setup.
Volk is nice to mention though, and thankfully I think you can still follow along if you prefer volk.
Volk enables dynamic loading instead of static linking. I consider this to be somewhat more advanced and I want to keep things as simple as possible for the newcomer. Will probably cover it in the future.
This should be interesting to watch but I'm sticking with OpenGL, I mean I'm making a game. I have to be objective. And frankly as indie I don't see the benefit of using Vulkan over OpenGL.
That's totally fine. I keep telling people that OpenGL is here to stay since Vulkan is very complex and geared towards people who want to squeeze every cycle from the machine. So engine devs, etc. If the game doesn't hit any major bottleneck then there's no reason not to use OpenGL.
@@OGLDEV Indeed. To clarify I'm not complaining at all. :) I very much appreciate the content you already have put out for OpenGL and found myself multiple times consulting it to figure out how to do things in my game. I understand that for you, as an educational content creator, you have all the reasons to expand your content, that makes sense.
FUCK YEAH LETS GO LOVE UR VIDS BRO
Thanks!
❤
:-)
:-)