Hope you all enjoyed this one! If you have anything to add drop a comment below 👇 Also hurry and visit brilliant.org/TheCherno to get started learning STEM for free! The first 200 people will get 20% off their annual premium subscription.
I think since since "pointer to x" is ultimately the type, the target type and pointer-star should be grouped together, just like Cherno did in the video.
@@theRPGmaster It should be like that, but it's not. If you write `int* a, b`, a will be a pointer but b will not. As far as the parser is concerned, the pointer is part of the variable name, not the type.
@@squelchedotter I 100% agree. The * makes more sense to me associated with the type but, alas, the language does not work that way and int *foo is correct. K&R, the Linux Kernel etc and other big projects all do it that way.
I actually type all my pointer (and reference) declarations like that. To me it just makes the most sense, that way it's really obvious if something is a pointer or a normal value, instead of being grouped together and your eyes potentially glossing over the thing. There's also semantic separation in it for me - an int is very different from an int pointer, and spacing the * out makes that fact more obvious. But if I'm working with them I always write it as &ref or *ptr, I'm not crazy enough for that. Probably part of why I picked up the habit was that our C/C++ teacher would insert spaces literally everywhere. I don't know if it's his personal style, or people used to just do it like that back in the day, but where you'd write "this->function(value1, value2)" he'd do something like "this -> function ( value1, value2 )". Never really got used to it and eventually I naturally got into a code style that's basically the common Java style, but the pointer star in the middle just kinda stuck I guess.
32:20 AFAIK, for the GPU, a mat3 is just a mat4 with padded zeroes. GPUs don't have specialized mat3 registers, so a mat3 is just a mat4 which is treated like a mat3 in code.
Really impressive how such young people are good at programming nowadays , i wrote my first line of code when i was 18 and only now in my early 20s that i started to really taking it seriously on learning programming and computer graphics. Real Props for that dude!
A lot of young people have resources and networks to learn that weren't around even 2-3 years ago. Everybody knows somebody who codes now, and with more people picking it up, it's the new thing for nerdy kids to get into.
Having to code in the 90's was painful, it involved setting up EPROM erasers with UV lamps and old serial line PIC programmers that got compiled through windows 98. A custom C language called PIC C existed to allow using the chips. You basically had to design your own micro-controller from scratch and budget project kits like arduino, raspberry pi's(Technically SoC), esp32's didn't exist.
it is but I find not many understand the underlying architecture or code that gets produced. It's different for C++ programmers, or should be, since C++ is more tightly coupled with hardware, but people who only know Java or Python e.g., while they maybe hot at algorithms and data structures, would have a hard time debugging at assembler level. Similarly people have difficulty with pointers for the same reason - they're hardware-oriented. That said, there's less and less need to do hardware-level debugging outside of kernel, driver and embedded development.
@@To-mos Really? I don;t remember it being that problematic. We had desktops from Computer Shopper and Borland at least had turbo C and Pascal. We even played DooM on the college network LoL.
16:20 There is a saying in our company, if you want speed, pass by value. Most of the time the compiler (especially with O2) will decide what is fastest and either pass by reference or by move semantics.
I really enjoyed this code review. The level of detail was great; I appreciate all of the small points you made, even if you think that you "took too long on those earlier parts", I'm learning something. Please, more of this.
15:30 It's interesting whether pass by value or reference/pointer is better. Obviously it can differ case by case but I saw a video of Chandler Carruth at cppcon (Google employee, works on Clang and does a lot of talks about optimization). He said pass by value is often better even for semi-large structs. The reason is that compilers don't do optimization as well when they have to deal with memory. If you pass by value, the compiler knows the function has a unique copy of the data and can better optimize. That may be the reason why you said that code at EA performed better when you did so.
I'm with right gang. Asterisk goes with the variable. Another thing, I completely agree that fragmented memory is slow (not really much to agree on, that's just a fact) but to counteract that, I like to allocate a couple gibibytes of memory at the beginning and put all my non stack memory on there
As an aspiring c++ developer (used python for 6ish years), I have trouble understanding code structure. I know it's subjective, but deciding where to put what and what should handle what is the biggest roadblock for me. It'd be helpful (for me at least) going over some structure and design. Syntax and implementation are no problem, however it always ends up being needlessly complex and I usually rewrite everything once or twice till I'm happy with it. Regardless, thanks for the video cherno, really appreciate your work. Keep it up!
Same. I've spent a riddiculous amount of time pondering where my public members should be declared, for example. Put them last in the class? Put them first and use an extra access specifier? Maybe struct instead of class? What about member functions? Indecisiveness kills productivity.
Proper code structure and correct use of design patterns etc. are just something that you figure out eventually with experience. Programming isn't like working in a manufacturing line, it's an art, and just like there is no best color for every painting, there is no best solution for all situations. And I wouldn't worry about rewriting and restructuring the code. Maybe one in a million novelists can write a book without ever going back to change something, but it shouldn't be anyone's goal to replicate that.
There are the SOLID principles, which are nice to follow imho. But they can confuse new programmers. Structuring your code in a way, that you only interact with blocks of code through an interface is a very powerful idea. If you introduce some unit testing, in my experience the code structure follows from testing, since you need to find a good way to have small enough code, so that it can be tested separately
@@axelanderson2030 Det är nog bara mild OCD, like another guy above said: it might be subjective, so we should decide on our own best practices / style rules.
For the SSBO update you may see some speedup if you orphan the data (see: OpenGL buffer orphaning) before the grass positions upload, instead of using glBufferSubData. As written, with glBufferSubData (or glBufferData without orphaning) it could force a sync between the CPU and GPU as the pending GPU draw commands that read from the buffer must complete before the new buffer upload to ensure that the memory is not stepped on while it's in flight, since all draw commands are sourcing from the same buffer (if I understood the code correctly).
I absolutely *LOVE* this type of content, Yan! As someone with a few college degrees including a doctorate, I've basically devoted my life to life-long learning. I've been following you for years now on RUclips and really must compliment you, as you've developed into an excellent educator. You've always been an excellent C++ developer, and inspire me (read "kick my ass") to push myself to become a better C++ developer with each and every one of your videos I watch. Thank you for making this type of content. I'm incredibly impressed with the amount of effort that this young man has devoted to this project. It's awesome that you took the time to not only do a code review of his code, but also to demonstrate techniques to make it better. I'm not even an OpenGL developer, and I learned a bunch from watching this video. Perhaps the biggest compliment I can give you is to tell you that of all the videos out there these days with what I call "in-content advertising" (ie; the content creator does the commercial live during the video), the commercial you did for Brilliant.org is the only one I've actually watched for months and months now. Usually I just scroll through them, but I watched yours--and even went there and signed up using your 20% discount. So thanks for that as well... I have to say I had my doubts as to the path your channel would take when you left EA and charted this new course, but I'm very happy to see where you're taking it--it's really working very well, and you've really grown into the role. You are *easily* one of the most educational development channels I've ever seen on RUclips. And finally to Nathan: GREAT JOB on this code! Yan gave you some incredible tips, and I'm sure you will grow as a developer if you understand and implement them. I wish I would have been half the developer you already are, when I was 15.
Great way you handled the idea of program structure for such a small program. As code grows, the benefits of structure grows. I think if you make this point clearly, viewers can see how excess abstraction is problematic and yet tackle the perhaps intended question of how to restructure as the code base grows.
Sometimed I forget how late I started programming. Im 23 and wrote my first line of code a couple months ago. Its still quite cryptic to me, but I hope to one day make and release my own video game
its worth noting that trig functions on GPU specifically, at least for sin, cos and tan, are done on the hardware layer directly and end up being only slightly more expensive than something like multiplication. This is of course vastly different that what would occur if you ran the same calculation on CPU which does not have a dedicated hardware instruction for those.
15:16 std::string_view is not guaranteed to be null terminated which is what opengl expects, std::string is though, something to keep in mind. Taking an std::string_view would require extra validation and possibly copy to add null.
For the mat4 that can be faster in not const& in some cases, well that's a register. 64byte, is only a few registers, so it can be passed by register, and that is faster then a memory access that the ref needs, even if the referred memory is in the stack and in cache... But there is a limited amount of register, pass a certain point, it will move the params to the stack instead of register, and that can slower then the ref due to stack move + copy then memory access...
39:15 I think a better way to speed it up would be maybe have a single 2048x2048 buffer (perhaps smaller or bigger, not giving heavy thought to this for now) to generate then use for every tile, no re-generating positions of grass blades, just make it dense enough that it difficult to notice it's being reused, as for when the grass should be sparse, still use the same buffer but just min/max blade opacity based on the meshes seed value for rand_r(), if it doesn't have one make it.
the grass looked amazing damn, man has made grass in opengl and c++ when i still take 5 days of errors doing it in unreal engine while following tutorials
That's what made me start doing graphics programming from scratch, I used UE for a long time, but really it's too much of a spaghetti engine, the only people able to fix those bugs properly are those who made it. The codebase isn't written to be easily extensible/patchable by independent devs.
You imply that it's more difficult to do in OpenGL and C++, but I'd argue that it is easier than in a high-profile game engine like Unreal. It's similar to what Cherno says in the beginning, that overabstraction is not needed on simple projects, and that actually simplifies the task. Same with OpenGL and C++, simple projects are actually easier without Engines, I'd argue.
@@peezieforestem5078 Yup, I can never seem to figure out these stupid engines. Always seems like there's a million arbitrary cryptic steps to the incantation and you invariably forget one.. and no amount of logic or thinking will let you fix that, just need to hunt up and down the UI and search for a tutorial or something like that... OpenGL, yes, it's a lot of additional code to write, but at least it's code and you wrote it so you know where the hell to find it and fixing it works by the rules of the logic and the programming language, no voodoo required.
I took a look at hazel. It's pretty neat but has a long ways to go. I would suggest having an components class with all static elements though as opposed to singletons because that way you can control their initialization and destruction
15:15 std::string_view should not be used to pass strings to C-like APIs like OpenGL, which take strings as const char*, because they typically expect null-terminated strings. string_view does not necessarily point to a null-terminated string, which can make for some painful debugging.
I generally like having the asterisk next to the type, which is nice when you want to define functions without naming the parameters: void operation(type*, type*) It's not as nice when trying to declare multiple pointers at once though. int* a, * b, * c In the last case I tend to just write the pointer next to the name.
30:52, simple solution, keep the flat plane, rename the y axis to z axis, decide grass xz as usual but before generating any further detail just see if there's a top view triangle of the mesh that encompasses the blade position, if yes then decide the blade's y position based on the triangle's vertices, if no then the blade is never finished or rendered
25:03 it's interesting that you mention dropping the `{` onto a new line for function definitions. I've been in the "put it on the same line" gang for years now, but I sometimes find myself adding an empty line at the top of the function body anyway as a way to fight back against the density. I never thought about it though or how the ` {` would fix it
I'd rather have a blank line than drop it. It's what I've always did in CSS, and is standard with how I write. Even if I wanted to drop it. If I genuinely tried, it'd become inconsistent. As I'd have to edit it every time.
@@rmt3589 Use a formatting tool like clang-format or whatever tool you fancy. No more inconsistencies. I personally like curly braces on the same lines everything as it just waste too much vertical space for no reasons (namespace, classes / structs / enum, functions, if, switches, loops, lambda, etc). Especially with code folding, having that extra return before the opening curly brace makes the folding happen below, which is counter intuitive imho. I do jump a line in certain situation to make my code less dense, where logical, separating declaration, or return and things like that from the rest of my code, and for constructors, if I use the initializer list, I just put the opening curly below. But that's just a personal preference and in the end, the only thing that really matter is following a convention to make your codebase consistent.
Please credit the Acerola! He did actually make a video about grass rendering. And from what we can see apart from the implementation the ideas are the same!
I was “middle gang” for a while, though to clarify it wasn’t really in the middle. It was aligned to the variable name, but with a space between. Just happened to fall into the middle when it wasn’t aligned to other similar locs, if that makes sense.
Im sitting here, trying to learn C++ as a senior developer, and your viewers be like: "Hi I am xy, Im 4 years old, and I just wrote something without any study that &re will never be able to. I hope you like it :3 "
I have a question: if header files can't compile and make an obj file, how can we run a project, it has only a header file (main function definition in this file)?
I became middle star when I was learning C++. It just made more sense to me that this a" character pointer" which in C++ land is char *. I might go to lhs gang though.
Small observation. Inside his classes interfacing with OpenGL he should be speaking OpenGL "language". Meaning he should be using/casting to OpenGL types.
I believe it was added in VS 2017. I vaguely remember hearing about it around that time, and that's the first version that has a mention of a 3D model editor in the docs.
@15:54 Luckily you show it there that pass by reference is valid for immutable object like std::string by passing it's constant object reference..maybe I should watch your video again
i'm not quite sure passing 64 bits of data by reference create increased performance at all. I mean it will likely be evaluated using a pointer (except if your function gets inlined), so you are still passing a 64 bit value anyway
You have a pretty decent knowledge of graphics. Check out the book real time rendering to get even better as well. I like it cause there is literally no code...it just describes the methods used. You're getting pretty good though. I'll send you my engine one of these days...it's over 100k lines though cause I've been working on it for years
I do not agree, for the same reason this won't compile. int* a, b = nullptr; or that this does compile but doesn't do what a lot of people might assume that it does: int* a, b; However since it is possible to write the second example, keeping the * by the varible name is perfectly understandable. To be clear no one should be writing code like the above, and, int *a, *b = nullptr; is a recipe for disaster that isn't doing what a lot of people probably expect either.
@@not_ever There's a simple solution to that issue. Don't declare multiple raw pointers on the same line (or if you really want to, separate them with a semi colon like `int* a; int* b;`), and keep the asterisk with the type where it belongs. It shouldn't be much of a problem in C++ anyway, as using naked pointers instead of references or smart pointers should be avoided where possible and thus, you shouldn't have to declare multiple of them, of the same type, in the same scope, or ever at all.
looks like some "mistakes" may be cause the developer is used to java that primitive types are initialized when instantiating a class. I'm a java dev too so I don't see anything wrong in their code lol
structs aren't heap allocated in C++? News to me! You can allocate anything from the heap. A struct is semantically identical to a class other than the default access control (everything is public by default in a struct, private in a class). Similarly you can allocate classes on the heap, the stack or static memory in C++. I know you know this, I just found the statement misleading, probably because you were trying to identify differences with default Java (or C#) behavior?
Hope you all enjoyed this one! If you have anything to add drop a comment below 👇 Also hurry and visit brilliant.org/TheCherno to get started learning STEM for free! The first 200 people will get 20% off their annual premium subscription.
;)
@The Cherno, spot on code review. I always learn a tidbit or two from these and they all add up over time, thx! 👍👍👍
graphics programmers don't touch grass, they would rather generate and render virtual grass and touch the screen.
Can confirm. Sauce: am
Yep
If you're a VR dev you can even "touch it"
UNDERRATED COMMENT 😂
i can confirm wath you say, cuz as a game dev i will make an entire game just to make a virtual hand touch virtual grass...
0:30 oh hey I know that guy
Me too!
have my babies
@@RetroMMO okay
Uhmmmmmmmm
I really don't like middle star because it makes a lot of type definitions look a lot like multiplications
Yeah, I don't like the trailing star either. The only way to go is leading star. Leading star gang
I think since since "pointer to x" is ultimately the type, the target type and pointer-star should be grouped together, just like Cherno did in the video.
@@theRPGmaster It should be like that, but it's not. If you write `int* a, b`, a will be a pointer but b will not. As far as the parser is concerned, the pointer is part of the variable name, not the type.
@@squelchedotter I 100% agree. The * makes more sense to me associated with the type but, alas, the language does not work that way and int *foo is correct. K&R, the Linux Kernel etc and other big projects all do it that way.
I actually type all my pointer (and reference) declarations like that. To me it just makes the most sense, that way it's really obvious if something is a pointer or a normal value, instead of being grouped together and your eyes potentially glossing over the thing. There's also semantic separation in it for me - an int is very different from an int pointer, and spacing the * out makes that fact more obvious. But if I'm working with them I always write it as &ref or *ptr, I'm not crazy enough for that.
Probably part of why I picked up the habit was that our C/C++ teacher would insert spaces literally everywhere. I don't know if it's his personal style, or people used to just do it like that back in the day, but where you'd write "this->function(value1, value2)" he'd do something like "this -> function ( value1, value2 )". Never really got used to it and eventually I naturally got into a code style that's basically the common Java style, but the pointer star in the middle just kinda stuck I guess.
i really wish you implemented all your suggested changes so that we could see the difference it makes
I was really frustrated...
32:20
AFAIK, for the GPU, a mat3 is just a mat4 with padded zeroes. GPUs don't have specialized mat3 registers, so a mat3 is just a mat4 which is treated like a mat3 in code.
Really impressive how such young people are good at programming nowadays , i wrote my first line of code when i was 18 and only now in my early 20s that i started to really taking it seriously on learning programming and computer graphics. Real Props for that dude!
A lot of young people have resources and networks to learn that weren't around even 2-3 years ago. Everybody knows somebody who codes now, and with more people picking it up, it's the new thing for nerdy kids to get into.
Having to code in the 90's was painful, it involved setting up EPROM erasers with UV lamps and old serial line PIC programmers that got compiled through windows 98. A custom C language called PIC C existed to allow using the chips. You basically had to design your own micro-controller from scratch and budget project kits like arduino, raspberry pi's(Technically SoC), esp32's didn't exist.
it is but I find not many understand the underlying architecture or code that gets produced. It's different for C++ programmers, or should be, since C++ is more tightly coupled with hardware, but people who only know Java or Python e.g., while they maybe hot at algorithms and data structures, would have a hard time debugging at assembler level. Similarly people have difficulty with pointers for the same reason - they're hardware-oriented. That said, there's less and less need to do hardware-level debugging outside of kernel, driver and embedded development.
@@To-mos Really? I don;t remember it being that problematic. We had desktops from Computer Shopper and Borland at least had turbo C and Pascal. We even played DooM on the college network LoL.
@@rnayabed Ah, OK.
16:20 There is a saying in our company, if you want speed, pass by value. Most of the time the compiler (especially with O2) will decide what is fastest and either pass by reference or by move semantics.
I really enjoyed this code review. The level of detail was great; I appreciate all of the small points you made, even if you think that you "took too long on those earlier parts", I'm learning something. Please, more of this.
15:30 It's interesting whether pass by value or reference/pointer is better. Obviously it can differ case by case but I saw a video of Chandler Carruth at cppcon (Google employee, works on Clang and does a lot of talks about optimization). He said pass by value is often better even for semi-large structs. The reason is that compilers don't do optimization as well when they have to deal with memory. If you pass by value, the compiler knows the function has a unique copy of the data and can better optimize. That may be the reason why you said that code at EA performed better when you did so.
heck yeah more Acerola recognition. Grass enthusiasts should definitely check out his channel.
Please do the video on grass rendering, especially talking about LOD! Would love to see that :) Great video!
I'm with right gang. Asterisk goes with the variable. Another thing, I completely agree that fragmented memory is slow (not really much to agree on, that's just a fact) but to counteract that, I like to allocate a couple gibibytes of memory at the beginning and put all my non stack memory on there
As an aspiring c++ developer (used python for 6ish years), I have trouble understanding code structure. I know it's subjective, but deciding where to put what and what should handle what is the biggest roadblock for me. It'd be helpful (for me at least) going over some structure and design. Syntax and implementation are no problem, however it always ends up being needlessly complex and I usually rewrite everything once or twice till I'm happy with it.
Regardless, thanks for the video cherno, really appreciate your work. Keep it up!
Same. I've spent a riddiculous amount of time pondering where my public members should be declared, for example. Put them last in the class? Put them first and use an extra access specifier? Maybe struct instead of class? What about member functions? Indecisiveness kills productivity.
Proper code structure and correct use of design patterns etc. are just something that you figure out eventually with experience. Programming isn't like working in a manufacturing line, it's an art, and just like there is no best color for every painting, there is no best solution for all situations. And I wouldn't worry about rewriting and restructuring the code. Maybe one in a million novelists can write a book without ever going back to change something, but it shouldn't be anyone's goal to replicate that.
@@theRPGmaster I feel you dude, hopefully with more practice this will get easier!
There are the SOLID principles, which are nice to follow imho. But they can confuse new programmers. Structuring your code in a way, that you only interact with blocks of code through an interface is a very powerful idea. If you introduce some unit testing, in my experience the code structure follows from testing, since you need to find a good way to have small enough code, so that it can be tested separately
@@axelanderson2030 Det är nog bara mild OCD, like another guy above said: it might be subjective, so we should decide on our own best practices / style rules.
For the SSBO update you may see some speedup if you orphan the data (see: OpenGL buffer orphaning) before the grass positions upload, instead of using glBufferSubData.
As written, with glBufferSubData (or glBufferData without orphaning) it could force a sync between the CPU and GPU as the pending GPU draw commands that read from the buffer must complete before the new buffer upload to ensure that the memory is not stepped on while it's in flight, since all draw commands are sourcing from the same buffer (if I understood the code correctly).
Would love to see you make all your changes and upgrade the quality to make the absolute best grass rendering example!
I'm sure I'm not the only one who would love to listen to you talking about rendering grass, without you restraining yourself
I absolutely *LOVE* this type of content, Yan!
As someone with a few college degrees including a doctorate, I've basically devoted my life to life-long learning. I've been following you for years now on RUclips and really must compliment you, as you've developed into an excellent educator. You've always been an excellent C++ developer, and inspire me (read "kick my ass") to push myself to become a better C++ developer with each and every one of your videos I watch. Thank you for making this type of content. I'm incredibly impressed with the amount of effort that this young man has devoted to this project. It's awesome that you took the time to not only do a code review of his code, but also to demonstrate techniques to make it better. I'm not even an OpenGL developer, and I learned a bunch from watching this video.
Perhaps the biggest compliment I can give you is to tell you that of all the videos out there these days with what I call "in-content advertising" (ie; the content creator does the commercial live during the video), the commercial you did for Brilliant.org is the only one I've actually watched for months and months now. Usually I just scroll through them, but I watched yours--and even went there and signed up using your 20% discount. So thanks for that as well...
I have to say I had my doubts as to the path your channel would take when you left EA and charted this new course, but I'm very happy to see where you're taking it--it's really working very well, and you've really grown into the role. You are *easily* one of the most educational development channels I've ever seen on RUclips. And finally to Nathan: GREAT JOB on this code! Yan gave you some incredible tips, and I'm sure you will grow as a developer if you understand and implement them. I wish I would have been half the developer you already are, when I was 15.
Great way you handled the idea of program structure for such a small program. As code grows, the benefits of structure grows. I think if you make this point clearly, viewers can see how excess abstraction is problematic and yet tackle the perhaps intended question of how to restructure as the code base grows.
Great video. And through it I discovered the existence of RenderDoc. Thanks a bunch! :D
Sometimed I forget how late I started programming. Im 23 and wrote my first line of code a couple months ago. Its still quite cryptic to me, but I hope to one day make and release my own video game
its worth noting that trig functions on GPU specifically, at least for sin, cos and tan, are done on the hardware layer directly and end up being only slightly more expensive than something like multiplication. This is of course vastly different that what would occur if you ran the same calculation on CPU which does not have a dedicated hardware instruction for those.
15:16 std::string_view is not guaranteed to be null terminated which is what opengl expects, std::string is though, something to keep in mind. Taking an std::string_view would require extra validation and possibly copy to add null.
For the mat4 that can be faster in not const& in some cases, well that's a register. 64byte, is only a few registers, so it can be passed by register, and that is faster then a memory access that the ref needs, even if the referred memory is in the stack and in cache... But there is a limited amount of register, pass a certain point, it will move the params to the stack instead of register, and that can slower then the ref due to stack move + copy then memory access...
39:15 I think a better way to speed it up would be maybe have a single 2048x2048 buffer (perhaps smaller or bigger, not giving heavy thought to this for now) to generate then use for every tile, no re-generating positions of grass blades, just make it dense enough that it difficult to notice it's being reused, as for when the grass should be sparse, still use the same buffer but just min/max blade opacity based on the meshes seed value for rand_r(), if it doesn't have one make it.
the grass looked amazing damn, man has made grass in opengl and c++ when i still take 5 days of errors doing it in unreal engine while following tutorials
That's what made me start doing graphics programming from scratch, I used UE for a long time, but really it's too much of a spaghetti engine, the only people able to fix those bugs properly are those who made it. The codebase isn't written to be easily extensible/patchable by independent devs.
You imply that it's more difficult to do in OpenGL and C++, but I'd argue that it is easier than in a high-profile game engine like Unreal. It's similar to what Cherno says in the beginning, that overabstraction is not needed on simple projects, and that actually simplifies the task. Same with OpenGL and C++, simple projects are actually easier without Engines, I'd argue.
@@peezieforestem5078 Yup, I can never seem to figure out these stupid engines. Always seems like there's a million arbitrary cryptic steps to the incantation and you invariably forget one.. and no amount of logic or thinking will let you fix that, just need to hunt up and down the UI and search for a tutorial or something like that... OpenGL, yes, it's a lot of additional code to write, but at least it's code and you wrote it so you know where the hell to find it and fixing it works by the rules of the logic and the programming language, no voodoo required.
I took a look at hazel. It's pretty neat but has a long ways to go. I would suggest having an components class with all static elements though as opposed to singletons because that way you can control their initialization and destruction
Isn't that more OOP than ECS?
I prefer OOP, but I don't think Cherno does.
Took a nap watching yt, woke up to this
enjoyed
When the world needed him most, he came back.
The thumbnail so funny 🤣
Welcome to _grass_
15:15 std::string_view should not be used to pass strings to C-like APIs like OpenGL, which take strings as const char*, because they typically expect null-terminated strings. string_view does not necessarily point to a null-terminated string, which can make for some painful debugging.
hey I'm middle gang! Seemed like the most intuitive way to type in pointers to me when I was learning about them so I stuck with it.
me too, except i do it to be different
I generally like having the asterisk next to the type, which is nice when you want to define functions without naming the parameters:
void operation(type*, type*)
It's not as nice when trying to declare multiple pointers at once though.
int* a, * b, * c
In the last case I tend to just write the pointer next to the name.
30:52, simple solution, keep the flat plane, rename the y axis to z axis, decide grass xz as usual but before generating any further detail just see if there's a top view triangle of the mesh that encompasses the blade position, if yes then decide the blade's y position based on the triangle's vertices, if no then the blade is never finished or rendered
i think the pointer star belongs next to *window like this, since if you have multiple pointers you‘d have to repeat the * too
A video on grass rendering in hazel would be really cool
Am I the only one who didn't know Visual Studio had a 3d model viewer?
TNice tutorials just made it so clear to thank you so much
this video is kind of nice. I really kind of liked it.
25:03 it's interesting that you mention dropping the `{` onto a new line for function definitions. I've been in the "put it on the same line" gang for years now, but I sometimes find myself adding an empty line at the top of the function body anyway as a way to fight back against the density. I never thought about it though or how the `
{` would fix it
I'd rather have a blank line than drop it. It's what I've always did in CSS, and is standard with how I write.
Even if I wanted to drop it. If I genuinely tried, it'd become inconsistent. As I'd have to edit it every time.
@@rmt3589 Use a formatting tool like clang-format or whatever tool you fancy. No more inconsistencies.
I personally like curly braces on the same lines everything as it just waste too much vertical space for no reasons (namespace, classes / structs / enum, functions, if, switches, loops, lambda, etc). Especially with code folding, having that extra return before the opening curly brace makes the folding happen below, which is counter intuitive imho. I do jump a line in certain situation to make my code less dense, where logical, separating declaration, or return and things like that from the rest of my code, and for constructors, if I use the initializer list, I just put the opening curly below. But that's just a personal preference and in the end, the only thing that really matter is following a convention to make your codebase consistent.
@@DenshinIshin I didn't even know there were formatting tools. I'll see what vscode has.
I learned a lot from this! I might submit something at some point!
Possibly the greatest Cherno thumbnail to date 🤣
This code and view i had seen 20 years ago; when i start with OpenGL and my theses on Topology of Fractal geometry.
I LOVE CHERNO CODE REVIEWS!!!
I like this form of content
Just seen first few mins. This is super impressive for a 15 year old. Especially in C++ and after a years(!) of Java
not really... most 14-17-year-olds (including me and my friends) who aren't idiots know shit like this...
Please credit the Acerola! He did actually make a video about grass rendering. And from what we can see apart from the implementation the ideas are the same!
commenting for the algorithm. would like to see your take on grass. ive been experimenting with different techniques and its pretty fun
Love these reviews, learn so much.
I was “middle gang” for a while, though to clarify it wasn’t really in the middle. It was aligned to the variable name, but with a space between. Just happened to fall into the middle when it wasn’t aligned to other similar locs, if that makes sense.
Im sitting here, trying to learn C++ as a senior developer, and your viewers be like:
"Hi I am xy, Im 4 years old, and I just wrote something without any study that &re will never be able to. I hope you like it :3 "
I have a question: if header files can't compile and make an obj file, how can we run a project, it has only a header file (main function definition in this file)?
You mentioned UBOs, could you maybe do a video on Uniform Buffer Objects for the OpenGL series.
Regarding code formatting, why don't we just let formatting and naming convention left to the static analyser tools?
wish you review projects that has written in c#
I became middle star when I was learning C++. It just made more sense to me that this a" character pointer" which in C++ land is char *. I might go to lhs gang though.
Re abstracting: I want to know that sort of thing. I am writing a gui program using walnut, and the abstractions in there were all new to me.
Small observation. Inside his classes interfacing with OpenGL he should be speaking OpenGL "language". Meaning he should be using/casting to OpenGL types.
Since when did Visual Studio have a model viewer?
I believe it was added in VS 2017. I vaguely remember hearing about it around that time, and that's the first version that has a mention of a 3D model editor in the docs.
Still waiting for your vs color scheme
Thank you very much for this review.
Could you please tell me that did you press at 36:34 Nsight for correction memory structure?
Thanks in advance.
Where to learn these advanced topics?
The thumbnail 💀
@15:54
Luckily you show it there that pass by reference is valid for immutable object like std::string by passing it's constant object reference..maybe I should watch your video again
Alright, I'm settled. Converting to middle gang
is there a way to make a vulkan/opengl application outside the windows/default main window?
I have a question how I can start with opengl c++ like you is there any video how to set up openGL and c++ in pc
Do you in general try to avoid heap allocation?
Hi, i want the c++ software to my computer please help me to find it, can you give the link to download the software
I really like the Ray Tracing series. when will the next video come?
color theme?
What color scheme are you using?
LOL!... Great thumbnail!!
grass reminds me of the good old days
i'm not quite sure passing 64 bits of data by reference create increased performance at all. I mean it will likely be evaluated using a pointer (except if your function gets inlined), so you are still passing a 64 bit value anyway
It’s 64 bytes. But yeah this could get inlined in which case passing by value would be faster
You have a pretty decent knowledge of graphics. Check out the book real time rendering to get even better as well. I like it cause there is literally no code...it just describes the methods used. You're getting pretty good though. I'll send you my engine one of these days...it's over 100k lines though cause I've been working on it for years
remarkably little roasting on this one
2:40 Dear Lord, DId you touched it ? DID YOU TOUCHED IT ?
Yoo cooolll
Imo the * should be next to the type, since it's part of the type. Never understood why some prefer it next to the name.
I do not agree, for the same reason this won't compile.
int* a, b = nullptr;
or that this does compile but doesn't do what a lot of people might assume that it does:
int* a, b;
However since it is possible to write the second example, keeping the * by the varible name is perfectly understandable.
To be clear no one should be writing code like the above, and,
int *a, *b = nullptr;
is a recipe for disaster that isn't doing what a lot of people probably expect either.
@@not_ever There's a simple solution to that issue. Don't declare multiple raw pointers on the same line (or if you really want to, separate them with a semi colon like `int* a; int* b;`), and keep the asterisk with the type where it belongs. It shouldn't be much of a problem in C++ anyway, as using naked pointers instead of references or smart pointers should be avoided where possible and thus, you shouldn't have to declare multiple of them, of the same type, in the same scope, or ever at all.
looks like some "mistakes" may be cause the developer is used to java that primitive types are initialized when instantiating a class. I'm a java dev too so I don't see anything wrong in their code lol
I always ditch hungarian notation, even for members. I just append a '_' at the end of the member (e.g. u32 fragement_shader_id_).
It would be cool to see some Rust videos! Have you already tried it?
You gotta move to Bevy. Bevy is where it's at.
structs aren't heap allocated in C++? News to me! You can allocate anything from the heap. A struct is semantically identical to a class other than the default access control (everything is public by default in a struct, private in a class). Similarly you can allocate classes on the heap, the stack or static memory in C++. I know you know this, I just found the statement misleading, probably because you were trying to identify differences with default Java (or C#) behavior?
I said they're stack allocated in C#, not C++. Structs in C# are value types, classes are reference types.
15 years old, my gosh. I dont even remember what kind of toy I was playing with at that age...
can you please talk more about the grass
Theme?
Card review? 0:00
please review this : int x = 9;
Approved. You'll live.
- Putin
Very unoptimised and clunky. Disappointed.
auto x{9}; please
@@OfficialGamingNetwork you broke my heart
@@on-hv9co you are not a C programmer .
What font is that?
Middle gang!
Cherno touched grass?!?
What's grass?
It's that thing that is green in color the youngsters are telling each other to touch. I'm not sure where you purchase it though.
i think you can smoke it
Middle gang!!!!! :D
Thank you tNice tutorials really helped!!!!!!!!!!!!
Middle pointer gang
MIDDLE GANG!!!
All my homies hate middle pointer gang....
When I was 15, the best thing I know was calculus.