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.
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.
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.
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 RU-vid 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 RU-vid. 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.
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.
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.
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'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
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).
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
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.
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.
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
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.
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.
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.
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 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.
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.
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 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.
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.
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.
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 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)?
Small observation. Inside his classes interfacing with OpenGL he should be speaking OpenGL "language". Meaning he should be using/casting to OpenGL types.
@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 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.
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'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
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
Personally, I don't pay attention to style guides. I just do what's easiest and makes reading back my own code easier. Take a couple of weeks off and come back and read what you wrote, if you can't understand how your own code works, then change your style. If you can, then that's what works for you and stick with it.
There's an issue with that. Identifiers with a leading underscore and a capitalized letter are reserved. And a trailing underscore is used by user defined literals. Just be careful with it.
@ The Cherno I llearned c++ but I won't get how can I start the advance c++ and what are the topics in it can you tell it please .and more then stuck on problem solving with c++ I want to work with in applications using c++.
Shader and mesh actually should be heap allocated because they are assets. In this project it is not important because almost all code is located in main function, but i think it would be cool to implement at least simple asset managing system. Also, yes, they should be smart pointers.
