Hope you guys enjoyed this video, let me know if you want to see more like this one! ❤ Also make sure you check out everything Brilliant has to offer-free-for a full 30 DAYS! Visit brilliant.org/TheCherno. The first 200 of you will get 20% off Brilliant’s annual premium subscription!
@@user-dh8oi2mk4f You can say the same thing about Cherno's Game Engine series. I mean, what's the definition of Finish anyway? I don't think you can expect a UA-cam channel to give you all the details about game engine development, right? That playlist is already a good start for Vulkan development. If anyone seriously wants to learn about Vulkan, they can just start there instead of waiting for Cherno to make one.
We need a DirectX series. Like he has even said that he prefers DirectX and he only did OpenGL because, it is simpler to start with and it is cross platform.
Thanks a lot, Cherno... I will truly be happy if you do more videos on how to craft a solid Vulkan renderer like the one in Hazel, can't wait to watch them! Thanks for your amazing job 🎉🎉
a "solid" vulkan renderer guide is probably too much...? at the end of the day it's going to depend on your exact needs, and you need to spend a ton of time architecting it to let it do what you really want, it's really difficult (or even impossible?) to have one solution renderer for everyone, though there was a website that did attempt such as vkguide which provided some helpful hints
I'll let @The Cherno decide what he wants to put inside that "a solid", to satisfy his audience. but in the end, having a series as he did for OpenGL would be a helpful and a great resource for everyone. but yeah for sure designing a renderer is difficult and am not expecting him to do a full course on it as everybody has their own approach. what am looking for is how he approaches it from his own perspectives and views, given his experience on doing such, why he prefers A instead of B, the pros and cons, etc the possible challenges you can face like he did here... hope that make sense
I have been making a game engine using rust and wgpu (an abstraction over vulkan, d3d, metal and webgl) and somehow they managed to preserve the descriptor sets (they are called bind groups) while still maintaining some form of open gl compatability through webgl. Impressive stuff.
I'll second this, I started using Vulkan in my catch all test project that uses Dear Imgui with Docking, so basically using that to force me to learn VULKAN after using OpenGL (mostly ES2) for sooo long, I'm sure I'm accidentally doing it OpenGL style in some ways and seeing some details about this change would be really interesting. Edit: I had been wanting to test Dear Imgui for a long while, but I think it was a Cherno video that made me start, but I didn't want to use his boilerplate to follow along that video so I never remade his old game.
I've never seen a Patreon plug feel so relevant to my needs. Been messing around with Vulkan here and there for the past 2 months and I'm completely new the graphics programming. Definitely would love to see more, thanks for the vid!
I'm curious just how far this could go if hazel had built in multi-gpu support. Like disregarding SLI and Crossfire disappearing, nothing stops game devs from implementing their own multi-gpu support. You could probably implement something like one GPU handles rendering and the other handles physics. Alternatively if the user has an odd number of GPUs for what ever reason like say 3 you could use two for rendering and 1 for physics. Its definitly not a practical feature these days, but would be extremely nice if the capability were there, if it were to work it could mean some insane capabilities when it comes to complex scenes and massive games written using the engine
@12:30 that's the modal configuration. You could also go for the median configuration (if they have a total ordering) by picking the exact middle one. Average is kinda hard with computer hardware... but likely to skew higher than typical.
Cherno that guy is pure genius he was having a majour cpu overhead while rendering the scene of about 3.3ms but he reduced that time upto 0.98ms using multi threaded description of vulkan graphics API
Have you used intel Vtune, to analysis your code? I think it could be interesting to walk through your code using a tool like Vtune, and explaining some of the analysis you can make. I do not know how hard this is. But maybe show a memory bandwidth limited case, CPU limited, GPU limited and maybe VRAM amount limited. What do I know. I just think it could be interesting to see how tools like Intel Vtune or Nvidia FrameView could be used to locate bottlenecks on a system (The interaction between hardware and software).
Sick video as always, I've been working on a vulkan renderer and the technical summary validated a lot of the design goals I have for my own project, vulkan render graph architecture is OP 👍
render thread is only the manager thread for the gpu api, you can manually yourself do all sub tasks in other threads, the main opengl thread just aggregates the data transfers/calls
In that architecture he created vulkan GPU descriptor sets and validated and baked them on particular binding position of a particular shader like texture, vetex ,shadows and lighting
My takeaway is that I'm surprised how frequently I am seeing the March 2023 Steam hardware survey impact the decisions people make - it's as though everyone sort of missed that March was an anomalous month; the Chinese userbase shot up 25% (i.e. it doubled) in one month - to being half of the entire survey. which means the data isn't nearly as useful for anyone outside of China. It's speculated that the increase in 6core intel + RTX3060 is due to an influx of game cafe prebuilts. But that's just speculation. I wouldn't be surprised to see the survey go back to having the GTX 1650/1060 at the top of the chart when April is finished. Alongside the Chinese userbase reducing back to a quarter.
Cherno: Not sure if you've looked into the Vulkan equivalent of DX12's ExecuteIndirect or not, but if you're doing your draw calls CPU side and it's taking much time, it might be worth looking at. I've only been writing DX code for a year and have never touched Vulkan, so am not sure what the equivalent is. In case you're not familiar with it: Your draw call arguments go into in an input buffer that's sent to a compute shader where you can cull stuff, then when culls fail (draw call is visible) you append the draw call arguments to an output draw append buffer. In essence the draw calls are then generated on the GPU in a compute shader instead of in the typical multithreaded loop CPU side. Then CPU side your command list (command buffer in Vulkan?) just records bindings as normal then runs a single ExecuteIndirect call. Voila, in one draw call you can draw the whole scene in just one CPU thread. The loop over thousands of draw calls is completely eliminated. My engine is much simpler than yours graphically (I'm not spawning or deleting stuff like you are with your cubes going everywhere) so I'm not sure if it'd be useful or not in Hazel, but maybe worth a look if your draw call loop takes enough time to leave you wanting a little more. It's kind of a pain to do, but it can reduce CPU use a lot.
@@DFPercush Thanks. Yeah, I think that's the one, mainly the Indexed version. Side note: You can add custom bindings to the buffer as additional draw arguments (constant buffer views and so forth) for each draw call. I do this in my D3D12 engine, but am not sure if it's really the way to go. PIX ends up showing all the bindings occurring every draw call which, when done on the CPU side, is really slow. It seems fast though so maybe if it's doing it on the GPU side it's ok. PIX warns about all the redundant bindings so I'm not really sure. One of these days I'll have to try going fully bindless on that end so there's nothing but the basic draw params in it.
How come you can't continue with the CPU tasks while waiting for the GPU? Why not just skip drawing until it's done but still process physics and logic etc?
But you will leverage Vulkan only when one render thread cannot keep up. So for low poly games OpenGL should be just as fast as Vulkan. Most indies won't go for complex realistic visuals anyway. So you could stay with OpenGL just fine.
Not to mention that in OpenGL the driver can optimize calls for you automatically and corrects common mistakes made by people in Vulkan (which usually lead to performance issues). Vulkan is a really weird and bad API. People usually say it's the best solution for easily going multiplatform, but is that really true? On Apple you're forced to use Metal, so one major platform is already out of reach and you're forced to maintain two renderer implementations from the get go. If you're going native on Apple, then you might as well go native on Windows and use Direct3D 12. And then there's Linux/Android with no real alternative... you either use Vulkan and hope the driver isn't buggy, or use OpenGL... and hope the driver isn't buggy. The only other benefit of modern OpenGL is that's it's actually a better API than Vulkan.
Shouldn't the reference PC represent more like the bottom 25% median to account for older and slower systems, that still cover a sizable chunk of the gaming hardware?
Not a game developer but curious about a few things. Do the new changes to the engine still allow for a DirectX renderer or is it now too closely tied to Vulkan?
I always find it strange when people say "XYZ is why we dropped openGL and went with Vulkan". And then they start listing things like platform-independence: Yeah that would be OpenGL. Low-level - also was in OpenGL first Threading - also possible in OpenGL rendering multiple frames - check command buffering - check Performance - yeah, after you have spent thousands of hours more than you ever did with the other APIs. More often than not it seems people are intentionally comparing OpenGL 1/2 with the latest iterations of DirectX or Vulkan. Might as well just compare the latest OpenGL with the early propietary versions of Vulkan. it is a shame that the Khronos group decided to kill OpenGL for an API that is a lot more error prone and takes a lot more work to get anything done. And yes Vulkan is faster, better suited for multithreading and less overhead - but it is by far not as big of a difference as people often make it out to be
Love your videos man and I'm a beginner using Unity and have now started using UE5 (loving it and think I will move to UE5). I'm really curious why you are making your own game engine? Is it because you have a love for making game engines? Will it do something that other engines can't do? Genuinely curious as I am imagining its a huge amount of work?
Im guessing the game engine series, to educate people, slowly evolved into something bigger and bigger and bigger and now we have hazel. Others do it for low level control over the engine, to make exactly what they want. In my case, unity is extremely fragmented, unreal was great, even if really bad at mobile, and has ridiculous shader compile times, until my project broke suddenly after a patch which added some nasty material bugs, which i wasnt pleased about. And godot, i still to this day dont know how to put a mesh in a scene and just add a shader in that mess. This kind of situation would definitely also bring someone to make an engine. (though in my case, i just moved engine, to a lesser known one called flax. Would not recommend to newbies, kinda buggy, slow development wise, tiny community, but it does exactly what i want it to.)
@@bits3608 Thanks! Yeah I’m gonna stick with UE5 as it does everything I could ever dream of for the type of game I am making but I’ll definitely keep watching videos on Hazel just because I’m interested in who everything works!
It's not the average PC, it's above average, most used components doesn't mean average performance. There's many more people that have less powerful PCs then there is those who have more powerful PCs
forest game can you fix this game xD its using your engine but when i run it.. the sounds are choppy and my whole desktop is lagging.. sadly. dichotomy game this one works well
@@ayoubbelatrous9914 "the base kernel" ... Linux is the kernel. Everything around it is what comprises of the rest of the OS. Desktop Linux is normally compiled by the distro maintainer.
I still wish you'd provide a build for Linux, not just for the engine, but any of these games hosted through itch as well. That would certainly get me to support the engine.
Thanks for watching! ❤ Check out everything Brilliant has to offer-free-for a full 30 DAYS! (and the first 200 of you will get 20% off Brilliant’s annual premium subscription!) ► brilliant.org/TheCherno
@@stephenkamenar 500hz monitors are a gimmick as much as 260hz monitors. Considering the kind of engines and languages available today, you should be thankful if you'll ever reach 144hz in a major AAA product with state of the art graphics.
Lost me. Too much jargon. I couldn't work out make files in Linux either. I searched and read and was lost. One video I found on youtube explained make files and I got the concept immediately. I even thought what a good idea. How did someone come up with that?
The common practice nowadays is to use a meta build system like CMake that can find all your dependencies and generate the makefile for you, but of course that's one more language you have to learn. A basic project with 2 or 3 files is not hard to write though. "add_executable(hello hello.cpp header.h)" that's pretty much it. Cherno uses premake5 (lua) for Hazel, last I checked. It doesn't support as many compilers and output targets as CMake though. A lot of non-Microsoft IDEs can parse CMake projects, like Qt Creator and CLion. The Godot engine uses SConstruct, another meta build system based on Python, but I can't tell you much about that one.
The more I watch your videos the less I get the impression that you actually know what you are doing and I don’t think you were experienced enough when you made the decision to go off on your own and develop your own engine
Your content is great, you audio is VERY poor... not due to your mic... in fact you gave a more than enough mic, but the recording, the equalization, is utter s***.
Hope you guys enjoyed this video, let me know if you want to see more like this one! ❤
Also make sure you check out everything Brilliant has to offer-free-for a full 30 DAYS! Visit brilliant.org/TheCherno.
The first 200 of you will get 20% off Brilliant’s annual premium subscription!
It’d be nice to see the rt series tbh
We need vulkan series.
It’ll be abandoned like rt series
@@NuttachaiTipprasert It's not close to being finished, and the creator skipped a few parts at the very beginning
@@user-dh8oi2mk4f You can say the same thing about Cherno's Game Engine series. I mean, what's the definition of Finish anyway? I don't think you can expect a UA-cam channel to give you all the details about game engine development, right?
That playlist is already a good start for Vulkan development. If anyone seriously wants to learn about Vulkan, they can just start there instead of waiting for Cherno to make one.
@@NuttachaiTipprasert he’s talking about a series on learning Vulkan like The Cherno’s OpenGL series. Not a game engine series
We need a DirectX series. Like he has even said that he prefers DirectX and he only did OpenGL because, it is simpler to start with and it is cross platform.
Thanks a lot, Cherno... I will truly be happy if you do more videos on how to craft a solid Vulkan renderer like the one in Hazel, can't wait to watch them!
Thanks for your amazing job 🎉🎉
;))
a "solid" vulkan renderer guide is probably too much...?
at the end of the day it's going to depend on your exact needs, and you need to spend a ton of time architecting it to let it do what you really want, it's really difficult (or even impossible?) to have one solution renderer for everyone, though there was a website that did attempt such as vkguide which provided some helpful hints
I'll let @The Cherno decide what he wants to put inside that "a solid", to satisfy his audience. but in the end, having a series as he did for OpenGL would be a helpful and a great resource for everyone. but yeah for sure designing a renderer is difficult and am not expecting him to do a full course on it as everybody has their own approach. what am looking for is how he approaches it from his own perspectives and views, given his experience on doing such, why he prefers A instead of B, the pros and cons, etc the possible challenges you can face like he did here... hope that make sense
We need more technical videos, this was awesome!
I have been making a game engine using rust and wgpu (an abstraction over vulkan, d3d, metal and webgl) and somehow they managed to preserve the descriptor sets (they are called bind groups) while still maintaining some form of open gl compatability through webgl. Impressive stuff.
I didn't know wgpu is also compatible with webgl 2! Thanks for that
To be honest, It would be great if you upload the detailed video on Cherno Unplugged. As a Vulkan engine dev It would be a great help.
I'll second this, I started using Vulkan in my catch all test project that uses Dear Imgui with Docking, so basically using that to force me to learn VULKAN after using OpenGL (mostly ES2) for sooo long, I'm sure I'm accidentally doing it OpenGL style in some ways and seeing some details about this change would be really interesting.
Edit: I had been wanting to test Dear Imgui for a long while, but I think it was a Cherno video that made me start, but I didn't want to use his boilerplate to follow along that video so I never remade his old game.
I've never seen a Patreon plug feel so relevant to my needs. Been messing around with Vulkan here and there for the past 2 months and I'm completely new the graphics programming. Definitely would love to see more, thanks for the vid!
I'm curious just how far this could go if hazel had built in multi-gpu support. Like disregarding SLI and Crossfire disappearing, nothing stops game devs from implementing their own multi-gpu support.
You could probably implement something like one GPU handles rendering and the other handles physics. Alternatively if the user has an odd number of GPUs for what ever reason like say 3 you could use two for rendering and 1 for physics.
Its definitly not a practical feature these days, but would be extremely nice if the capability were there, if it were to work it could mean some insane capabilities when it comes to complex scenes and massive games written using the engine
Fun fact: "Cherno" in slavic languages means "darkness" or "blackness"
@12:30 that's the modal configuration. You could also go for the median configuration (if they have a total ordering) by picking the exact middle one. Average is kinda hard with computer hardware... but likely to skew higher than typical.
I would appreciate a series on Vulkan similar to how you did OpenGL, since I learned a lot from that. Are you planning on something like that?
Vulkan is just too OP!
NO
@@sumofat4994 why?
@@sumofat4994 NO
Absolutely!
@@TuxikCE because Sumo Fat says so 🗿
Thanks a lot cherno you are gonna achieve a lot more in game engine development
Cherno you basically taught me to code last year. Thank you so much. Im now in university. Love the videos and learning and following Hazel
Cherno that guy is pure genius he was having a majour cpu overhead while rendering the scene of about 3.3ms but he reduced that time upto 0.98ms using multi threaded description of vulkan graphics API
Have you used intel Vtune, to analysis your code?
I think it could be interesting to walk through your code using a tool like Vtune, and explaining some of the analysis you can make.
I do not know how hard this is. But maybe show a memory bandwidth limited case, CPU limited, GPU limited and maybe VRAM amount limited. What do I know. I just think it could be interesting to see how tools like Intel Vtune or Nvidia FrameView could be used to locate bottlenecks on a system (The interaction between hardware and software).
WE NEED VULKAN SERIES JUST LIKE OPENGL SERIES!!
Love the stress level 0 shirt, didn't know you were into VR. (Great video as well)
I would really like to have your visual studio color theme though. I remember you saying earlier that it is in the process of some further tweaking...
Something very wacky is happening with steam survey. A lot more Chinese users which come with a sudden increase of higher-end GPUs
Sick video as always, I've been working on a vulkan renderer and the technical summary validated a lot of the design goals I have for my own project, vulkan render graph architecture is OP 👍
Needs more flame graphs! 🔥🔥🔥
Aight, now i need to make mine go from 10fps somehow (rendering about 20 trees 😭 including shadows) (2017 Laptop, i5 7th Gen, GTX 1050Ti)
Cool video. Will look into the Patreon video as well. I`m curious how you split and ordered tasks between GPU and CPU.
More details! Patreon here I come!
render thread is only the manager thread for the gpu api, you can manually yourself do all sub tasks in other threads, the main opengl thread just aggregates the data transfers/calls
k.i.s.s. :) glhf
cringe lol
code managerial task succccccc hard
bugs are waste of time
@@Jkauppa are you a bot?
In that architecture he created vulkan GPU descriptor sets and validated and baked them on particular binding position of a particular shader like texture, vetex ,shadows and lighting
My takeaway is that I'm surprised how frequently I am seeing the March 2023 Steam hardware survey impact the decisions people make - it's as though everyone sort of missed that March was an anomalous month; the Chinese userbase shot up 25% (i.e. it doubled) in one month - to being half of the entire survey. which means the data isn't nearly as useful for anyone outside of China.
It's speculated that the increase in 6core intel + RTX3060 is due to an influx of game cafe prebuilts. But that's just speculation.
I wouldn't be surprised to see the survey go back to having the GTX 1650/1060 at the top of the chart when April is finished. Alongside the Chinese userbase reducing back to a quarter.
Please make a vulkan tutorial series. It would be of great help
Why Vulkan over D3D12 if you're planning on targeting console as well (which means rewriting in D3D12 for XBOX anyway)?
Have you tinkered with the VkPushDescriptorKHR extension? I'm curious of any performance changes in using it.
Oooo love the SLZ shirt
Are you using bindless descriptors? If not, I've read that it would be even faster.
Will we get an executable of the Hazelnut editor in the near future?
Cherno: Not sure if you've looked into the Vulkan equivalent of DX12's ExecuteIndirect or not, but if you're doing your draw calls CPU side and it's taking much time, it might be worth looking at. I've only been writing DX code for a year and have never touched Vulkan, so am not sure what the equivalent is.
In case you're not familiar with it: Your draw call arguments go into in an input buffer that's sent to a compute shader where you can cull stuff, then when culls fail (draw call is visible) you append the draw call arguments to an output draw append buffer. In essence the draw calls are then generated on the GPU in a compute shader instead of in the typical multithreaded loop CPU side. Then CPU side your command list (command buffer in Vulkan?) just records bindings as normal then runs a single ExecuteIndirect call. Voila, in one draw call you can draw the whole scene in just one CPU thread. The loop over thousands of draw calls is completely eliminated.
My engine is much simpler than yours graphically (I'm not spawning or deleting stuff like you are with your cubes going everywhere) so I'm not sure if it'd be useful or not in Hazel, but maybe worth a look if your draw call loop takes enough time to leave you wanting a little more. It's kind of a pain to do, but it can reduce CPU use a lot.
There's a vkCmdDrawIndirect and vkCmdDrawIndexedIndirect
@@DFPercush Thanks. Yeah, I think that's the one, mainly the Indexed version.
Side note: You can add custom bindings to the buffer as additional draw arguments (constant buffer views and so forth) for each draw call. I do this in my D3D12 engine, but am not sure if it's really the way to go. PIX ends up showing all the bindings occurring every draw call which, when done on the CPU side, is really slow. It seems fast though so maybe if it's doing it on the GPU side it's ok. PIX warns about all the redundant bindings so I'm not really sure. One of these days I'll have to try going fully bindless on that end so there's nothing but the basic draw params in it.
How come you can't continue with the CPU tasks while waiting for the GPU? Why not just skip drawing until it's done but still process physics and logic etc?
Can you please create a video on adding multiple language support for c++ gui applications
12:02 that was😳
Would you consider adding a new scripting language into your engine such as Lua lor c#?
He already has C# support
Is it possible to ship Vulkan to Web? I know OpenGL is supported only up to 2.0 on the WebGL.
NO
WebGPU/WGPU is your bet. It's similar-lish to Vulkan. Browser support will probably ship this year, Chrome just started to ship it in the recent beta.
But you will leverage Vulkan only when one render thread cannot keep up. So for low poly games OpenGL should be just as fast as Vulkan. Most indies won't go for complex realistic visuals anyway. So you could stay with OpenGL just fine.
Not to mention that in OpenGL the driver can optimize calls for you automatically and corrects common mistakes made by people in Vulkan (which usually lead to performance issues). Vulkan is a really weird and bad API. People usually say it's the best solution for easily going multiplatform, but is that really true? On Apple you're forced to use Metal, so one major platform is already out of reach and you're forced to maintain two renderer implementations from the get go. If you're going native on Apple, then you might as well go native on Windows and use Direct3D 12. And then there's Linux/Android with no real alternative... you either use Vulkan and hope the driver isn't buggy, or use OpenGL... and hope the driver isn't buggy. The only other benefit of modern OpenGL is that's it's actually a better API than Vulkan.
Bravo!!!
Shouldn't the reference PC represent more like the bottom 25% median to account for older and slower systems, that still cover a sizable chunk of the gaming hardware?
Poppy is a name of my neighbour"s dog.
Not a game developer but curious about a few things.
Do the new changes to the engine still allow for a DirectX renderer or is it now too closely tied to Vulkan?
Why do we need DirectX when Vulkan is cross-platform and gives better performance than DirectX?
It's build around Vulkan now. For DX12 it should be modified again.
But why would they do that? ;-) For Xbox support?
@Ethan Minja Microsoft «Dozen»?
@Ethan Minja You can use Vulkan Portability spec. Microsoft dozen is translation layer between Vulkan and DirextX 12
would you ever do a vulkan tutorial series like opengl or would that be not worth it?
hi Chernoooooooooo as there is no single game engine is good at physics. do you have any plans to add robust physical engine to Hazel?
I always find it strange when people say "XYZ is why we dropped openGL and went with Vulkan".
And then they start listing things like platform-independence: Yeah that would be OpenGL.
Low-level - also was in OpenGL first
Threading - also possible in OpenGL
rendering multiple frames - check
command buffering - check
Performance - yeah, after you have spent thousands of hours more than you ever did with the other APIs.
More often than not it seems people are intentionally comparing OpenGL 1/2 with the latest iterations of DirectX or Vulkan. Might as well just compare the latest OpenGL with the early propietary versions of Vulkan. it is a shame that the Khronos group decided to kill OpenGL for an API that is a lot more error prone and takes a lot more work to get anything done.
And yes Vulkan is faster, better suited for multithreading and less overhead - but it is by far not as big of a difference as people often make it out to be
Do you use any fancy vulkan extensions?
Vulkan plus voxel engine would be perfect
Will we get a game engine tutorial on this on the other channel?
just asking does directX have the same situation as openGL?
So you now have time to draw even more boxes? :)
Love your videos man and I'm a beginner using Unity and have now started using UE5 (loving it and think I will move to UE5). I'm really curious why you are making your own game engine? Is it because you have a love for making game engines? Will it do something that other engines can't do? Genuinely curious as I am imagining its a huge amount of work?
Im guessing the game engine series, to educate people, slowly evolved into something bigger and bigger and bigger and now we have hazel. Others do it for low level control over the engine, to make exactly what they want. In my case, unity is extremely fragmented, unreal was great, even if really bad at mobile, and has ridiculous shader compile times, until my project broke suddenly after a patch which added some nasty material bugs, which i wasnt pleased about. And godot, i still to this day dont know how to put a mesh in a scene and just add a shader in that mess. This kind of situation would definitely also bring someone to make an engine. (though in my case, i just moved engine, to a lesser known one called flax. Would not recommend to newbies, kinda buggy, slow development wise, tiny community, but it does exactly what i want it to.)
@@bits3608 Thanks! Yeah I’m gonna stick with UE5 as it does everything I could ever dream of for the type of game I am making but I’ll definitely keep watching videos on Hazel just because I’m interested in who everything works!
@@nolram Haha Oh yeah. Just reading now. Well this answers that then 😂
It's not the average PC, it's above average, most used components doesn't mean average performance. There's many more people that have less powerful PCs then there is those who have more powerful PCs
I didn't know my PC had Steam HW survey specs.
Do you have a playlist teaching Vulcan?
He doesn't unfortunately, btw the API is Vulkan, not Vulcan
@@dimi5862 Got it. Thanks
Dude I'm still trying to make batch rendering work
Ask ChatGPT to fix your code ;-)
Especially, if you would ger access to a GPT-4 based version of it
@@igorthelight ha no
Cool! Wonder how Unity handles this
Unity supports all renderers: DX9/10/11/12 Vulkan OGL3/3.5/4 - so it probably has A LOT of overhead so all renderers could be satisfied ;-)
Did anyone else notice there's a guy hiding behind the computer 😱
Very cool video, and that's coming from someone who knows nothing about Vulkan!
Vulkan is pretty hard! But pretty powerful and tweakable ;-)
should have named the new team member Bill Cherno... 😅
i decided to rewrite my engine in rust
NO
You can't say that word anymore
@@sumofat4994 NO
Language itself is good.
Some decisions by community lawyers are... questionable ;-)
@@nbhjbhyvgbhyuvbhuynnjbhu lol
The PC is the median PC, not the average PC. Probably won't matter but anyway.
Median is an average?
vulkan guide?
optimizations 😋
forest game
can you fix this game xD its using your engine but when i run it.. the sounds are choppy and my whole desktop is lagging.. sadly.
dichotomy game
this one works well
Android also has Vulkan wich is fast on Linux which is what android is based on
Android is Linux.
@@briumphbimbles not entirely it became detached from linux a lot. but the base kernel is still the same as standard desktop linux.
@@ayoubbelatrous9914 "the base kernel" ... Linux is the kernel. Everything around it is what comprises of the rest of the OS.
Desktop Linux is normally compiled by the distro maintainer.
@@dave7244 well when people say linux they mean a GNU/linux + linux is a massive kernel you dont need everything in linux to make it run.
@@ayoubbelatrous9914 Linux is any OS based on the Linux Kernel.
Does watching the sponsor ad at 16x speed count
Can you do a deep dive on Kajiya? It's written by an ex-DICE dev. 🦀
"Microsoft Edging"...ah, is that what they call it before you "chroming"
We need an AI podcast
How tf does this video have 11k views and only has 1k likes HUH?!!
@@transistorjump919 lol
now you need to bog down windows in the standard PC with years of bloatware and improperly uninstalled crap gumming up the registry :D
I still wish you'd provide a build for Linux, not just for the engine, but any of these games hosted through itch as well. That would certainly get me to support the engine.
i am so sad because i can't play Dichotomy because my device isn't supported by Vulkan =(
It's the other way around - your device don't support Vulkan ;-)
Also - buy something like GTX 1050 - it supports it and cost almost nothing.
@@igorthelight Unfortunately i can buy that only after i can afford buying enough food
@@avtem Oh...
What GPU do you have?
@@user-dh8oi2mk4f Intel(R) HD Graphics 4000
Where are you? Is that the EA office?
Damn, dev commentary locked behind a paywall, big L
That's sadly how this channel went, more and more behind a paywall and broken promises.
Thanks for watching! ❤
Check out everything Brilliant has to offer-free-for a full 30 DAYS! (and the first 200 of you will get 20% off Brilliant’s annual premium subscription!) ► brilliant.org/TheCherno
so what about webrtc🥴
the fps of your game was SO LOW i'm not surprised you doubled it. i'm sure it's still slow
490 fps is double 330 fps?
200+ fps is low?
@@user-dh8oi2mk4f 500hz monitors exist. this game is very minimal yet runs like trash still
@@stephenkamenar 500hz monitors are a gimmick as much as 260hz monitors. Considering the kind of engines and languages available today, you should be thankful if you'll ever reach 144hz in a major AAA product with state of the art graphics.
@@Borgilian why would i be playing a AAA product? i play games at 1000s of fps
15 seconds ago
Lol
Lost me. Too much jargon. I couldn't work out make files in Linux either. I searched and read and was lost. One video I found on youtube explained make files and I got the concept immediately. I even thought what a good idea. How did someone come up with that?
The common practice nowadays is to use a meta build system like CMake that can find all your dependencies and generate the makefile for you, but of course that's one more language you have to learn. A basic project with 2 or 3 files is not hard to write though. "add_executable(hello hello.cpp header.h)" that's pretty much it.
Cherno uses premake5 (lua) for Hazel, last I checked. It doesn't support as many compilers and output targets as CMake though. A lot of non-Microsoft IDEs can parse CMake projects, like Qt Creator and CLion.
The Godot engine uses SConstruct, another meta build system based on Python, but I can't tell you much about that one.
no idea what you are talking about half way through...
Welcome to the channel, it’s FILLED with technical stuff like this lol
No idea from beginning to end
4th
Third
The more I watch your videos the less I get the impression that you actually know what you are doing and I don’t think you were experienced enough when you made the decision to go off on your own and develop your own engine
Your content is great, you audio is VERY poor... not due to your mic... in fact you gave a more than enough mic, but the recording, the equalization, is utter s***.
Whats with the fruity thumbnails
First
What happend to your hair???
He still has some :)
I really do like your channel and content but it would be even better if you stopped saying "like" every 5 words😅
DirectX is much easier.
Vulkan lmao
??
@@thev01d12 of course it was vulkan