Hazel - My Game Engine // Code Review

[@TheCherno]

Hope you enjoyed a look at Hazel - more to come! Also definitely visit brilliant.org/TheCherno/ to get started learning STEM for free, and the first 200 people will get 20% off their annual premium subscription.

[@oamioxmocliox8082]

;)

[@PhoenixDigitalGamer]

Can u make tutorial on creation of game engine Cinematics system. Please :)

[@椿絢音]

ｻｲｷｯｸﾌｨｰﾊﾞｰ🇯🇵🏎️

[@cherno2232]

No I'm cherno

[@ChimeraReiax]

Imagine if you finished this review going "woof, this whole thing needs a rewrite"

[@TheCherno]

Haha, I definitely feel like that about certain parts 😅

[@oamioxmocliox8082]

;)

[@jordanyates3349]

RIIR :)

[@椿絢音]

@@oamioxmocliox8082 🏎️RAMPAGE🇯🇵

[@elturco9573]

Cherno, it's great to see someone explain the code for their own game engine. Thanks.

[@myanrueller91]

The large file size bit: I'm always of the thought that if the file will be as large as it needs to so long as it only does what is in its domain. For example, if the renderer also ends up implementing math functions for physics, that's when I might break things out.

[@navibongo9354]

Completely unrelated but i love ur dog! Hes super cute

[@Ulchie]

@Harshil Pandey "Completely unrelated but..." I... think they know that...

[@c.codyflick2210]

Loved the Ctrl+m text overlay. Literally was thinking to myself last night how I need to learn more keystrokes in VS but as I'm still learning it's hard to know what the useful ones are, or what they'd call the ones you use and I love the style of navigating code and highlighting/replacing text you use. I think I've seen in discord that your vs profile is available or something, but it would be great to have one quick video of all the shortcuts you use so I can be faster. Thanks for all the great content!

[@Rythm0562]

I love you so much for telling me the keybind

[@BenBE1987]

Re around 25 min in with the array marshalling: If you need to look up how that is done it's likely complicated enough that you might be better of abstracting it away. Putting DRY to the extreme might not be the solution either, but abstractions (especially when they can be done at zero cost™) can help to improve your overall project and code structure. That being said: While having large files isn't wrong by itself, the scripting engine example is a good place where it might be worth considering to split things by topic (one file per subject: audio, 3D objects, rendering, shaders, utils) as even though regions (as seen in the video) give one level of structure, so can both additional files and folders. In my projects I often tend to split heavily by functionality/concerns. Simple example: Consider a motor controller you need to talk to: You have one layer raw communication (like a serial cable or digital signal), one layer for the communication protocol (implementing e.g. frame encoding/decoding or checksums needed for command frames), another one for the commands you need to send (go forward, backward, speed control, acceleration, breaking), the control logic (does it make sense to hit the break while pushing full speed ahead?), and finally the actual application logic. That's 5 layers of distinct functionality that should be reflected in the code by splitting those concerns. In my case this would likely result in about 5 code files (+headers), even though those all are concerned with driving that one single motor (controller). And similar can be applied to your scripting engine and interfacing logic: One layer just interfacing the raw data types and helper functions/classes for that task, a second layer (potentially split horizontally) to map/translate your logic, and a third layer implementing high-level logic that's not just plain mapping/translation between those two worlds. I see why you might want to do it in one big file, but abstraction and grouping of concerns may reduce the amount of code you write and as a side effect even make it more easy to understand overall. 2ct

[@skip9827]

to see your progress motivates me good job keep going

[@benoitrousseau4137]

Just my 2 cents, but personally I prefer spreading the implementation of my very large classes over multiple cpp that cover a facet of it, ie: mainscene_physics.cpp, mainscene_rendering.cpp, mainscene_devmode.cpp, etc. That's a very "C" approach to structuring code but it works better for me than a giant file that I need to Ctrl+F or use VAssist to find anything, or that constantly needs merging because everyone works in it. This is also really nice to avoid Windows.h macro pollution if you sandbox the platform-specific parts of a class into its own cpp.

[@samvodopianov9399]

Haters gonna hate

[@orlovskyconsulting]

Even if dont like big source code files, i say the code is clean and neat. Good work!

[@mjthebest7294]

Can't wait to see the follow up videos. This is very motivating!

[@DiogoManteu]

I was stunned by the quality of the engine and then I remembered. Oh yeah this guy coded the engines for EA

[@jarekmyszko3332]

@The Cherno To answer your question at 23:25: Let's say you just started your project and you have 6 interconnected classes. It's easier to just swap between the files in your project viewer than keep scrolling up and down. Also, from the psychological point of view, when you have to look through large amount of code your brain subconsciously analyzes a lot of text, which may cause a feeling of being overwhelmed. I prefer to encapsulate a simple functionality in a small class, which I can then save in a separate file and forget.

[@zdeneksotolar2852]

Hi. You can have a similar feeling just to see over 50 files that are interconnected in some way. I´d say it has to have a technical meaning to divide a feature into more files/classes. About "ubconsciously analyzes a lot of text"... let´s say you need to go through all the different files to put together the solution to the problem. You can´t just forget what you saw. Navigating through one file is much easier than jumping around among files if it´s done properly.

[@jarekmyszko3332]

​@@zdeneksotolar2852 I like to work with people that use descriptive function and class names and organize them in files with similar names. If there is a bug and it takes me more than 5-10sec to analyze the code/algorithm then it's a waste of time. I currently work on a project that has thousands of files, each with about 100-200 lines, all well organized in filters(VS) and I don't have to remember more than 3-5 at a time. I can't imagine the pain of debugging that code if they would put it in fewer, larger files, but then again, maybe for you it's easier.

[@zvxcvxcz]

Nano doesn't have a project viewer, nor do gedit or notepad... it's easier for me to ctrl+w than monkey around in a bunch of files... I'm often working on remote servers without a GUI. Yes, there are IDEs with no GUI... but the chances that it will be configured the way you like on the server are slim. Yes, you can move around the profile... but that's a slow down all by itself.

[@zvxcvxcz]

@@jarekmyszko3332 "If there is a bug and it takes me more than 5-10sec to analyze the code/algorithm then it's a waste of time. "

[@epiphaeny]

I am actually pretty happy, when I have to deal with only 3000 loc in a file :D. Some older files in our projects have almost 30 000 loc that are hardcore old C style code with goto's and up to 15 nested if statements and loops... Those files are absolutely insane.

[@xr.spedtech]

30,000?

[@Steven-tw7iz]

I am sure many people want to dive into a lot of the complex systems like rendering and events and what not. But I'm sitting here wondering how the launcher works lol. Would be super cool to see how to put that together :)

[@icesentry]

Would love to see a video doing an overview of the sound graph thing.

[@powerclan1910]

What are your plans for Hazel in the long run. Do you want to build your own indie games with it, or do you want to become competition for the big 3 of game engines? (not including propriatary engines ofc)

[@diligencehumility6971]

Wow the UI looks smooth

[@exa211]

It looks exactly like Unreal Engine 5

[@gwentarinokripperinolkjdsf683]

Hay I just wanted to comment about a game engine feature that I really think more game engines need. Unigine is the only modern game engine I know of that does this. Unigine is effectively just a library, you still control the main function in your game, this allows for significantly more freedom. If you still can, please try and make that a possibility in Hazel, and check out Unigine they do some very cool stuff that's not standard for game engines.

[@GonziHere]

Because Unigine is aimed at industries. But still, I absolutely agree. It's my most favorite engine, actually, because of things like these. It feels like a well documented toolset rather than opinionated program.

[@TeriyakiTakeout]

I haven’t watched you in a while, although I have always loved and used your content to learn, but I just want to make sure you are okay because you seem absolutely exhausted. Like, you seem so tired to me, from your voice and mannerisms in comparison to a few years ago. Please make sure you are taking care of yourself and your energy. Love your content either way, even if I’m catching up after a few years.

[@s1nister688]

Looking forward to videos on modifying imgui to have no titlebar and making these modern looking UIs, and the node editor that you have. :D

[@Ev3r0x]

Imgui has nothing to do with that, titlebar belongs to non-client area and can only be removed using winapi. It's most often done using DwmExtendFrameIntoClientArea function

[@evannibbe9375]

I don’t like that aspect of games, since it takes away power from the user. Getting rid of the red X in the corner is what different malware use to undermine the confidence of newbie computer users.

[@HappyMatt12345]

So basically this video is exactly what I do whenever I look back at Its a Cube and especially Deathly Descents code base lol. This will be cool to watch!

[@TheDoomerBlox]

30:00 - Hey look, it's another version of the Tesselated Ocean Simulation Underneath the Game World (achieved with CryEngine 3(tm)) Very cute!

[@Glyn-Leine]

I partially disagree with the large files thing. the script glue stuff for instance could be a large folder instead. i generally find things easier to find in well organized folder structures with medium sized files than in a large file

[@zvxcvxcz]

So you're going to search file contents in your folder by catting them all or something to find the example you're looking for and that is somehow more convenient to you than ctrl+f? I don't buy it. It is often the case that you need to find some piece of code but don't know quite exactly where it is, and you are suspecting perfect recall of which of those many files you will need to check. Yes, you can work around this by gluing yourself to an IDE that will search the entire project...

[@Glyn-Leine]

@@zvxcvxcz I barely ever use ctrl+f I always use ctrl+t, also if you name your files correctly then it won't be an issue to know what is in which file

[@majormalfunction0071]

​@@zvxcvxczC++ is harder to search, but grep will find the definition and references if you know the symbol. I use 'sed -i s///g ' to globally search and replace.

[@nicholasamaral7156]

Would love a sequel with the audio part :)

[@Gmitbotw]

Having a 3k line of code file isn't good for compilation times since it can't be compiled in parallel. Also, the most important thing is *recompilation* times. If you modify a single line in this file the whole 3k lines have to be recompiled. Also, having an organized file structure for your different functionality is a good thing for code maintainability in the long run with a bigger team. At work we have some C++ files of 15k+ lines and it's a pain... There is a huge effort to refactor them into smaller files. Also, CTRL-F can easily be replaced by a grep command or some CTRL-SHIFT-F

[@edwin5145]

But it is good for performance given that everything in that file can be inlined if used within the same file without the use of lto. Besides, it's just 3k likes, that isn't that much.

[@Gmitbotw]

@@edwin5145 But you have LTO, so that doesn't change anything. Having a 3k lines file isn't the end of the world, but splitting up your files can really improve iteration speed when you need to recompile your code. And IMO if you have good code navigation tools in yout IDE (idk about VS), I find it easier to find what you're looking for, but that's a personal thing

[@gulneckm.3475]

@@Gmitbotw He uses visual assist, so he should have no problem navigating around.

[@dankmemesstudios3987]

But on the flip side you have thousands of files, split over hundereds of 'organized file structures' and you have to open up uselessly many files to find what you actually need. Then you need to change something and then go through all these other files to change it properly. And then what about your member data? A class is a nice things because it contains also data. Now you have to worry about how the data gets transfered between different files or you have to build a large data struct which you create here and then pass along there. And if all your 'organized files' just contain some static functions that take in data and spit it back out, then why not just have them back into the initial file in the first place (apart from your recompilation argument)? Like all things you have to have a good balance between under organizing your project and over-organizing it.

[@dankmemesstudios3987]

And I should mention that splitting things up into many different files is much better AFTER you have figured out how the program will achieve it's end result. Otherwise doing it too early can be very very bad. Say you thought of this 'idea' about how to do it, and then you go about making all these small files and abstractions which removes flexability in your program. Then you idea turns out to be flawed. Then you hate life. So aswell as personal preference it also depends on the stage of your program if splitting things up is a good idea also.

[@Fewkulele]

Would love a video about your sound graphs and your audio engine

[@GonziHere]

While I absolutely agree with readability of the (reasonably) larger files, there is one caveat to it, which is IMO the main reason against it: refactoring and teamwork. Say you have 10 people and every one is touching something between cpp and csharp. They might touch totally different parts of it for totally different reasons, but they will have to deal with it in the merge. On the other hand, if one touched "arrayglue.cpp" and other touched "stringglue.cpp", its easier to see/review those changes for others while also preventing merge conflicts. Add to it, that someone actually changes something in a more meaningful way (say reorder/rename/split of a few functions) and you are in a world of hurt.

[@TurtleKwitty]

Other than the fact that two people working in entirely different parts of the file nowadays is basically free to merge because the auto merging is smart enough to realise theyre entirely different parts of the file you'd be right

[@GonziHere]

​@@TurtleKwitty yeah... unless you move something somewhere ;) I'm not saying that it will be an issue at every single merge, but it's enough to be annoying. For us, it was typically something like menu, because reordering was producing conflicts and EVERY time two developers have tried to add something at the end, it was a (simple) conflict. The general idea is that you should have a file(or files) per feature, so that when you work on said feature, you aren't touching anything else (think modules). The glue isn't a feature, it's a layer.

[@gulneckm.3475]

VSS has merge tool built-in so it's not an issue.

[@teamclouday]

Would love to learn how the engine handles shadows for so many point lights😀

[@NeiroGMD]

Hi! Nice video! I have a question to run user's scripts are u using multi threading?

[@AntonioNoack]

Why is there a sponsored section in a video, that is effectively an ad (for a commercial project, because access *is limited to paying people) anyway? 🤨

[@maverikmiller6746]

Yep

[@snesmocha]

when hazel releases, is it possible to bypass the c# scripting and directly use the c++ api?

[@manucanedo8039]

What's the Cpp standard the project uses? Unrelated question, why don't you AAA (almost-always auto)? It's cool to see that you can simply stop App from running, cleanup and let that while loop restart your everything. Most code I see out there has many global static objects (such as singletons) lingering around that force to fully stop the execution to do a complete reset.

[@Ev3r0x]

C++17

[@lalishansh]

Try writting code without intellisence you'll know (experience from cpp20 modules)

[@zvxcvxcz]

" why don't you AAA (almost-always auto)?"

[@manucanedo8039]

Yo are right about intellisense. But not using a code server it's a voluntary choice and we should not pesimize maintainability and performance based on a developer's choice to not use tools. Regarding the las reply. What's the runtime performance cost of type deduction? None. AAA in large codebases actually improves performance because i avoids implicit conversions.

[@snarkyboojum]

Code review starts at 11:17 :)

[@mishabytes8209]

you’re an inspiration to me

[@mkfusion2522]

There's always something in these videos, that attracts me. It's always an inspiration.

[@tematoscybersage5626]

Do you have main targets in developing of Hazel? Like unique benefits comparing to other engines? Or it mostly simplicity and education?

[@mastershooter64]

Cherno in the intro: Standing here I realize....

[@felipelopes3171]

From my perspective, it's very hard to justify huge files. There are several reasons: (1) compiler optimizations work by applying several passes of optimization algorithms. If there's way too much data, this optimizer can get lost and it will waste a lot of compilation time without optimizing anything. (2) if something changes in that file, the compiler will have to recompile everything, and if you change signatures or types, it's likely that will cascade to everything that depends on it, which can be even the entire code. (3) The complexity of the code grows exponentially with the side. It's much easier to read code scattered on several files than a large one, because dependencies are more constrained. There have been several times in my career where I stuffed a lot of things in a class because I needed them to optimize things. I thought "yeah, it's unavoidable", and only after I broke up the file in desperation, it was obvious to see that I could have used a better data structure, initialize something to speedup queries later, use a design pattern to make something configurable, etc. I literally could only see this after I broke up a giant file. (4) if you go by the data, software engineering research is pretty much unanimous on this. They call it the god class code smell, and studies show that it slows development quite a lot. Try to keep your classes small!

[@zvxcvxcz]

1) Compilers seem to slow down much more dealing with code spread across many files, or perhaps it is the linkers that do, but in any case that seems to slow down the build more than having the code in fewer larger files, this also matches Chernikov's experience. 2) No disagreement on this point 3) I couldn't disagree more. One large file allows reading code that belongs together conceptually to actually be together. The code complexity is identical. We're dealing with file size, not different algorithmic choices. Spreading it across many files just increases cognitive load as we hop around many files trying to figure out the big picture of what is happening and dealing with the inevitable changes to variable names as they are passed around. So now we can't see what is happening in one place and I need to remember two names for the variable because it gets a new one when it comes into the class, which is hopefully similar but systemically different. Yes, some people prefer to handle this cognitive load by their choice of IDE... but nano, gedit, and notepad don't really help out with that and they're usually what is reliably installed so they're what I'm usually using. 4) Citation needed, particularly outside of corporate work. In corporate work with large teams it is advantageous to break things up because each can be designated their own responsibilities, i.e. the code structure serves double duty as a way to break up the work with each piece being individually testable with another person just to right tests for it. For a small team that can all be involved in all parts of the project, well, I'm skeptical that the same results would hold because being able to keep everything logically in working memory seems to be a larger concern than divvying up work. It's more important that they can find all the C# bindings in one place easily than for the bindings to be individually testable or for a person to be responsible for writing a single binding. In this scenario it is more important that the code structure matches the mental model than for it to be chunkable for any given size.

[@normwaz2813]

Really enjoying your videos. Quick question - how do AAA game engines export game projects to an executable format?

[@kendarr]

I belive they build it, like unreal or unity does, I don't know what they do do technically speaking tho

[@cvspvr]

they run it through a compiler like visual studio but with more files automatically generated by the game editor

[@CamdenVaughan]

Would love to see you do something like this but going through godot or unreal engine

[@yoshi314]

oh boy, he'd never finish that.

[@zvxcvxcz]

I think Unreal Engine is closed source? Godot is all available though. Ah, interesting, Unreal Engine is source available commercial, not sure if one could comment on it in a video under the license though, maybe, probably fair use but might be pushing the envelope a little.

[@CamdenVaughan]

@@zvxcvxcz Its full open source and its license lets you comment on it or adapt it fully main stipulations come from actually using it, there are a couple of KZbinrs who have made videos about its achitecture but I would love to get Cherno's opinion on it, but I bet that would be a massive undertaking so I don't expect it :(

[@juanfranciscocastillo5149]

Great job!! 🛸🙋🏻‍♂️

[@MBBGun14]

This is amazing

[@snarkyboojum]

For the record there are far better ways of coming up to speed with the basic maths required for 3d graphics than Brilliant :) Cool engine, btw.

[@mindgame6404]

Great content. May I know what font are you using in this vid?

[@theforthdoctor7872]

Reminds me of that sticker you will find of many Monty Python books "Winner of the Monty Python award for their own books..." 🤣

[@user-ux3cp4kr6r]

All code in one file?! Great

[@G1g4ntvltLP]

Hey CHerno, super interesting! It would be kinda nice, if you would have the time to do a video on the custom render RenderQueue, or at least the concept of creating a fixed sized buffer, submitting functions with parameters into it and then retrieving everything during process. I can't figure it out on my own and also do not know where and how you would learn this...

[@椿絢音]

Generations🇯🇵TV

[@zvxcvxcz]

Why aren't you statically linking assimp? I'm a bit of a noob at this... but oh, is it because Forest was a game jam game so you wanted a faster compile cycle?

[@neotune64]

Hey, Yan, what are your thoughts on rust?

[@TheWayManREAL]

What are your opinions on carbon? I am sure someone has been trying to ask, will you make a vid on it?

[@visuallization]

Holy moly, hazel looks almost like unity!

[@GokdenizCetin]

Mix of unity and unreal

[@SabeDoesThingsChannel]

What is your visual studio theme?

[@developer6508]

Hey bro you have that "Open file in solution" extension, it won't be that hard for you to find necessary file if you split it onto multiple

[@FreddieGames9]

A little weird question but since you have C# scripting, would it be possible to use C++ together with this engine?

[@madeso]

17:45 wouldn't it be way better if you could connect to the game your are playing on your phone in the editor instead? Like unity remote or chrome devtools.

[@matthewdee6023]

3000 line file is ok, 3000 line function probably not. The 3000 line SQL script I had to work with once, was about as far away from ok as you can get 😢

[@CreativeOven]

Thanks to explain the actual state of your engine, looking forward to use it any luck with mobile phone developement what about linux?

[@evannibbe9375]

Apparently the community has made it work in Linux if what he said at the start of the video is correct.

[@benlee6140]

Hi will you make a video talking about Carbon, the new language Google invented to replace C++? I'm really interesting in your thought! Thank you ~

[@KingTateMaster]

What theme is Visual Studio?

[@kurciqs8355]

the epicest ever

[@countinfinity776]

Now that Unity shot itself, Maybe Hazen can slowly start taking its place in a few years lol.

[@erenenadream]

Hello @TheCherno I have downloaded your lastest github repo (master branch). And I have runned cloc program and it says 6464 lines of code total in Hazel-master\Hazelnut\src. Why is that ??

[@lavakusa9638]

Please make a video about design patterns in c++.. I read documents and manuals in internet but not able to understand properly.. If possible make a short video about it..

[@zvxcvxcz]

Don't worry, design patterns are just opinions. That's how you should think of them, they're just common ways that some opinionated people like to organize their code. They may or may not be applicable or appropriate for the problem you are actually working... so while they may inform you approach, don't be afraid to ignore them when they don't fit your use case.

[@Lameless]

Is hazel gonna have implemented multiplayer?

[@Veraxo]

amazing

[@SourceCodeDeleted]

This isn't a code review. This is a code explaination.

[@francis_the_cat9549]

Could you make a code review of the godot engine?

[@mmj-video-logs]

There is a video for that by the lead developer of Godot

[@turdle69420]

@22:45 - i'm a c++ noob, but i've heard that over the years the view as shifted from the mid 90's, where they viewed large files as inherently bad. Now it's more acceptable. My project file I'm learning c++ on is 2k lines and growing, and after the initial few days, navigating the file isn't a struggle at all

[@victordedon3917]

Hi please could you do a Video on Carbon and what you think about the language?

[@RomanianProductions]

The logo in your thumbnail looks a lot like the Hostinger logo

[@astroid-ws4py]

Cool, Thanks..

[@nickandrievsky5705]

After 10 minutes 0 lines of code. What we’re even doing here?

[@maxi-g]

why did you choose to use openGL instead of DirectX as the graphics api ?

[@anon_y_mousse]

Looking at all of those includes you must be chomping at the bit to get modules in C++.

[@lemonke8132]

hey cherno, could you please take a look at john lin's voxel engine (on youtube) and analyze how he renders so many voxels at once? He's made some absolutely INCREDIBLE stuff, and I would really appreciate your view on it! (awesome video btw!)

[@mikelowery6732]

Most Voxel Engines use Octrees, don't they?

[@exa211]

John lin uses raytracing with octrees to get reasonable performance.

[@lemonke8132]

@@exa211 No he doesn't.

[@lemonke8132]

@@exa211 A quote from lin himself: "octrees are extremely terrible for ray tracing, and dags actually do a very poor job of representing sparse voxel data despite their gains over esvo, which is also a terrible structure for representing sparse voxels"

[@exa211]

Im sorry but where did you get this information from exactly? Did you read his blog-post? He is of course saying that octrees are bad for storing data but not so bad for rendering. His micro-voxel engine is developed in Vulkan with Raytracing.@@lemonke8132

[@MatteoDeCarlo]

Splitting a big file into multiple files is faster, if you compile with more than one core

[@sacredgeometry]

It's also way more legible and manageable. Plus it generally insinuates that you have properly organised your code but the converse could be true too. Its all about the rationale. If the code belongs there, it belongs there. Doing it because you think that its easier to find things (learn your tools better) is just a bad a reason in my opinion as moving it explicitly because its longer than n lines. Code organisation especially in an OO language is pretty much informed by the paradigm.

[@MatteoDeCarlo]

I'm going to expand on what I wrote. I had the necessity to split into multiple files only once, when I was compiling some boost::python bindings. I had to separate each binding into a separate file or I would not have enough ram to compile (boost::python heavily uses templating). As a side result the compilation time got more then halved, because the very big job could now be divided into multiple jobs on multiple cores. Apart from this, I generally agree with Cherno. Do what makes your code more organized and comfortable, don't bind yourself to certain rules just because, make the choices that make sense for your project. Big files are useful in certain occasions. Curiosity: Unreal Engine has some big classes that are splitted across multiple cpp files.

[@gulneckm.3475]

Also you don't have to recompile functions you didn't change, which is always a plus. And let's be honest, in file that has KLOCs it's majority of the functions.

[@stuntfax9004]

Maybe start a company who makes games like a game engine, and get like 40 employee or something to help

[@LimitedWard]

The argument for breaking up code into multiple files has little to do with how many lines of code you have to scroll through. It has to do with separation of concerns. By splitting up your code into smaller classes, it makes it easier to reason about what the code actually does while simultaneously making it easier to test. Imagine you wanted to create a unit test using one of your monolithic classes. You'd have a really hard time mocking/stubbing out the behavior. By contrast, if your code were split up into smaller classes, each with a single responsibility and backed by an interface, you could inject mock implementations of your interface as necessary to isolate the behavior of each class while testing. A lot of people seem to think that unit testing matters less when it comes to game engines and computer graphics, but I'd argue testing (and consequently testability of your code) is important regardless of the type of software you are writing. Untested code leads to delays when debugging your game. It also encourages the propagation of other anti-patterns which can reduce the maintainability of your code long term. Both add up to game devs working long hours and crunching toward the end of a release cycle.

[@TwistedSageXR]

What code editor is that? 😁

[@SomeoneOnlyWeKnow.]

Just visual studio

[@user-ib3gl6pj6h]

How to ship a completed C++ project?

[@unkgames-abdullahali4048]

Could u make blueprint code (graph editor) on your game engine "hazel"

[@davidheary2482]

For the algorithm

[@evantseng6832]

“cannot open Hazel/vendor/Glad: No such file or directory” Hello Cherno, I have this issue when running the setup.bat. But I'm sure that Hazel/vendor/Glad exist. Could you please let me know if you have any idea?

[@ghitagusteru7823]

Did you recursively clone the repository?

[@saomoon]

what ide are u using?

[@thebasicmaterialsproject1892]

oi oi to the cherno is there any nvidia cuda round here i just got a nividia gpu

[@teyo_gh]

Love your videos. Can you do one on Carbon the new programming language intended to replace C++. I would like to know your opinion it.

[@xr.spedtech]

C++ is it's own successor ...

[@Ilyas_Alrai]

man the giant files scare me, what is your opinion about design patterns ? I suppose you like to focus on the goal rather than structuring code

[@stevencowmeat]

My question is how do u loop through all those objects and have decent performance

[@vunderstudios]

data orientated

[@stevencowmeat]

@@vunderstudios what do u mean data oriented? Edit: googled it nvm😂

[@RogyDev]

What about spot lights?

[@tristonarmstrong4617]

sooo, Godot is one of the top smaller game engines.. and yours LOOKS so much better.. Especially that node graph, gosh Godot's nodes are horrible! And thats coming from a Godot fanboy

[@subhamprasad1373]

your thought about carbon programming language

[@lazizkhan1]

I'm waiting for next video of ray tracing

[@tri--]

Does Hazel 3D support OpenGL?

[@slygamer01]

Love the approach. I'm an old-school game developer and much prefer this straight-forward approach than the haphazard, scripts and components everywhere approach that Unity and UE promote.

[@chrs8466]

Hey, Cherno! What syntax highlighting theme are you using? Thanks, Chris

[@static_bantic360]

visual assist

[@chrs8466]

@@static_bantic360 Thank you!

[@luz_reyes_676]

@@chrs8466 he actually changed it. so its not the same one

[@chrs8466]

@@luz_reyes_676 Thank you! I noticed that.

[@shoaibzafar5663]

Please make series on Nvidia physx

[@trafficface]

Hazelnuts are very healthy

[@linuxlegion4312]

Is it true that Google carbon will take over c++ ?

[@Ev3r0x]

no, it isn't...

[@azrnzala]

large files -> poor namespaces, compilations cannot be parallelized. let your IDE help you with searching for stuff.

[@petrkiyashko4248]

The compiler works slower on fragmented files. With larger files you still have compiler parallelizm cause there's still not one of them. On the other hand: 1) you get the overhead of launching a process for each file 2) have to parse every header including std lib template monstrosities that are themselves thousands of lines long per every file 3) Then get more slowness because it's harder to link If you watch Casey Muratori's videos, he literally #includes all cpp files into one, and it compiles faster. Try that yourself, you'd be surprised

[@Mr_Coco_GameDev]

Hey，I really like your Video,Can you share your Camera and Len