Writing a Basic Renderer in OpenGL

[@rudejehlici5425]

Me: "I'm learning OpenGL, I've watched 16 tutorial episodes on KZbin" Friend: "And what can you render?" Me: "A square" :DDD

[@catinwall4256]

I can't even render a square... I have managed to break my program on an episode where you basically just move stuff around.

[@catinwall4256]

Update: Literally just realized I forget a '&' while passing in the IndexBuffer. Fixed... but I'm almost mad.

[@rudejehlici5425]

@@catinwall4256 My biggest nightmare is to keep up writing code as fast as the Cherno does, as soon as I start to think I keep up, I miss-type a lot of letters and I have to pause the video :)

[@philmsproduction]

@@catinwall4256 I think it would have helped if The Cherno showed us how to implement proper copy/move semantics for those classes. But maybe that would have taken too much time and he wanted to do that in the c++ tutorial series instead. Anyway I believe you should probably disallow copying of some of those classes by deleting their copy constructor and copy-assignment operators. A IndexBuffer should not be copied. because the destructors of both copies will be called at some point. So you are calling glDelete... twice with the same id. Which will lead to an error I guess. (Or you might allow copying it if you do it properly. Like actually allocating a new buffer in the copy constructor with glCreateBuffers(...) and copy the contents over to that buffer.) Anyway if you want to delete the copy constructor and copy-assignment operator of the index buffer, I believe you should write something like: IndexBuffer(const IndexBuffer&) = delete; IndexBuffer& operator=(const IndexBuffer&) = delete; Now the compiler should yell at you right away if you forget that & again instead of compiling properly and the program crashing randomly later for unknown reason. I am not sure about what to do with the move constructor and move assignment. Maybe we should delete them too. or maybe instead implement them something like this: IndexBuffer(IndexBuffer&& other) : m_RendererID(other.m_RendererID), m_Count(other.m_Count) { other.m_RendererID = 0; } IndexBuffer& operator=(IndexBuffer&& other) { m_RendererID = other.m_RendererID; m_Count = other.m_Count; other.m_RendererID = 0; }

[@philmsproduction]

(My answer assumes I understood you correct, that by 'forgot an &' you meant you accidentally made the argument pass-by-value instead of pass-by-reference)

[@carlosdalomba]

It's been about 20 days since I went through the previous episode, but your liveliness and clear explanations give me a sense of urgency like I remember exactly where I left off. You're amazing TheCherno, one of the best teachers I've ever had!

[@szinton]

3:11 into the video: "So let's get right into the code!" Yea... =D

[@superpb600]

I have moved the GLCall macros to a GLErrorManager class because having it on renderer was making an inclusion nightmare XD, I had more than just one loop. Plus its not really logical that the renderer covers logging, and other classes have access to the renderer. However I bet you were planning to change that ^^

[@ascii2510]

funny i did the same thing about 3 videos ago and had no inclusion problems. i mean why should everything know about the renderer?

[@DanielArnett]

Thank you!

[@youreyesarebleeding1368]

To solve the circular dependency issue, I created a separate header file and placed the macros in there, as well as the functions that were in the Renderer source file, but not members of the Renderer class.

[@mylesschultz2848]

I love this series! So much great information. I've been writing tutorials for using OpenGL with Swift on MacOS. I'm currently trying to refactor everything myself and I think I've solidified where I want to take it. I've been thinking about getting some file reading for the shaders first and then maybe a working on models next, but we'll see, haha. I'm a hobbyist, not a professional programer so it takes me awhile, but I've been enjoying it. Regardless, I've gotten some great ideas from your videos and I'm really looking forward to future episodes! Thank you for sharing all of your knowledge and experience!

[@parthlodhia5974]

After 2 years i m watching and learning. And like background setup in this episode, ... Early Morning, Windy, Trees and Good Instructer. Mr cherno really appreciate your efforts.

[@jyandi9063]

Just a note: Just trying to be careful with my class definitions, I was using { #ifndef #define and #endif } until this episode. Apparently with forward class declarations, using these include guards negate any other references to these "non complete" classes. Even switching around my includes for the better part of an hour would not fix the problem. Finally, after switching my guards back to the simple "#pragma once" fixed the errors immediately. Maybe this is something that could be talked about at some point...

[@cocbuilds]

I had this problem too. I had 3 header files, the first one containing the 2 other ones (as well as some other code). Both the other 2 included the first one too, and all of them had #ifndef guards. So header file 3 was unable to find the definition for header file 2, even though I was including header file 2 before header file 3 in the main header file (header file 1). I then tried doing "extern headerfile2class" in the beginning of header file 3 and it worked, albeit with a warning during compilation. It works, but I really don't think extern was made with that in mind so I don't really recommend using this, although I'd prefer it this way than with pragma once just in case I was going to use a different compiler.

[@rabidhamper7]

Thank you so much for posting this. It saved me hours of frustration!

[@marsbars1105]

As someone who is following these tutorials in C, I cannot relate to such high-level problems :D

[@wirosk2916]

11:30 Issue with the shader: Eatch time renderer.Draw(...) is called the shader passed in to renderer.Draw(...) is bound inside that function. So to clean things up at this stage the uniform can be set after the renderer.Draw(...) Maybe an odd order to do things in, set the uniform after the drawcall, but it will be set to the next frame. An other way is to move the responsibility to set the uniform to the renderer, after the shader is bound and before the actual drawcall.

[@vitluk]

Ye, cyclical dependencies were very frustrating for me at the start (since I came from C# that didn't have those problems). But I just made a habit of forward declaring everything, which saves my life all the time

[@exodus8814]

Can't wait for your game engine tutorials. I'm way too behind,still in the first half of your C++ videos :(

[@Mustis1524]

What I found worked best was to follow along with just one video a day, but really apply myself and try my best to understand everything being taught. That's still 30 videos a month which will mean you'll catch up in no time. When I began I would try to get through 10 videos in a day or something unreasonable, which meant I'd always end up forgetting everything and having to start over.

[@exodus8814]

Mustis1524 Thank you soo much for the tip, yes basically I'm doing the same thing. I'm following along 2 videos a day with some practicing. I don't want to get through more than that because as you said it's unreasonable. Also, knowing C++ very well is really important to be able to start with something complicated as game engines. So yes, I'll take it slow.

[@exodus8814]

Thenx apprendist Exactly my friend, i really can't wait for the game engine tutorials. I searched it up and found some good game engine videos, but they were written in Java which is not what i like. By the way, I believe you're the same guy that comments on OreonEngine videos. Right?

[@vladimirlazarevic6772]

Well you can always look at his Sparky game engine series. You can learn a lot from it, and it was written in C++.

[@BlackJar72]

I find this interesting because its so completely different from what I did in my attempt at a 3D game engine. (Note that my rending system worked well enough, though not optimized, but I hadn't planned well and ran into trouble working in the other systems such as IO and logic, among other things.) What I did was to follow the OOP idea of having object do things for themselves: Instead of using a renderer class I put my GL drawing code into the model class, based on the OOP philosophy objects processing themselves. I then hid all my graphics behind a very thin facade along with registries of models and model components such as meshes and textures. I'd seen reference to renderer in the code of existing games, but never gave any thought to how to make them or what their actual duty was.

[@jpsilver3510]

Java programmers be like : RenderFactory

[@andy-bandy]

RenderFactory factory

[@user-dh8oi2mk4f]

Import render.renderer.*

[@spidzsaus]

@@user-dh8oi2mk4f import render.renderer.rendererer.renderererer.*

[@caareystore5058]

Renderer render = new Renderer();

[@andrefaustino5514]

RenderFactory.getInstance(); pls

[@DukeLaze]

6:52 - No unfortunately it didn't compile just fine >____< After some arbitrary amount of time debugging, it looks like some header inclusion problem. In VertexArray.cpp I included VertexArray.h before Renderer.h, and that led toC4430 (missing type specifier) and C2143 (missing ',' before &) for the Renderer.h Draw() signature. I am pretty new to c++, and I'm wondering if I either didn't write the code the same way you did, or forget to clean up an include somewhere along the line. I assume the "conflict"(?) is because Renderer.h includes VertexArray.h, and VertexArray.cpp includes Renderer.h & VertexArray.h. Anyone have any tips for how to correct this? Or will I be forced to continually debug as new headers are added? (header includes in header files are a pain >_

[@DukeLaze]

So, since Renderer.h now includes VertexArray.h, I figured I could remove VertexArray.h from VertexArray.cpp, since that includes Renderer.h. Lo and behold, it works properly again :D (Would still appriciate helpful tips, gonna rewatch the c++ header video soonish) Edit: So, obviously I should've just continued watching since he finds a different (kind of the same) issue. Why'd he say it compiled fine when it really didn't? >_< oh well

[@MsTheBiggest]

@@DukeLaze I had the same issue. But on my side it was about shader.h. I was including renderer.h in shader.h and vise versa. If you wanna pinpoint - draw a graph to see which header includes which header. there must not be any cycles afaik

[@catorials444]

if you write the chain events of header inclusion on a sheet of paper you'll be able to find the conflict.

[@ccpmustfall6445]

@@MsTheBiggest I have both XD trolololol

[@slurpeesauce1750]

THANK YOU!!!!

[@orbitalstudios6411]

Very inspiritional!! Thank you for your tutorials!!

[@MuscIeBomber2021]

This might be helpful for someone else who happens to run into the same problem I did (unlikely, because I'm quite the idiot when it comes to programming -_-). I followed the steps in this video exactly and, when I tried to compile it at the 10:30 mark, I got an error "C4430 missing type specifier - int assumed" for my Draw function. It took a while, but it turned out my problem was in Shader - I had included iostream, fstream, and sstream in the header file. Moving those over to the cpp file fixed it.

[@KneeCapThief]

THANK YOU SO MUCH, i guess we both didn't look in what file the includes went. Edit: Now openGL just doesnt draw anything. AAAAAAAAAAAAAA Edit2: I'm stupid

[@tothpeter2296]

Well, in my case I just needed to move the Renderer into the cpp and leave the rest in the header It works and it even draws

[@slurpeesauce1750]

If you are getting errors with your vertexarary class make sure to include renderer.h before vertexarray.h. This should fix your ',' before & error

[@Frederick773]

I’m watching this in 2024 and you are a LIFE SAVER

[@MakiYamazaki]

Really looking forward to your text rendering videos! Great work :D

[@m96fa40]

I'm so interested in that, like REALLY. Anyway, hope you're doing okay, 5 years later :D

[@barellevy6030]

You are awesome, love your content.

[@colepeterson5392]

I am learning so much from this series thank you.

[@lucasmorais3694]

Yay! More The Cherno Videos! Keep the good job m8! I really love ur job.

[@matthewjohnrussell]

One index buffer is remembered by the VAO and is automatically rebound when you rebind the VAO. It's not neccessary to manually bind/unbind the index buffer all the time.

[@kaustubhnarkhede5166]

Love this guy man!! 🖤🖤

[@praveshgaire3437]

Cherno's such a clever, will leave anything he doesn't want to explain by saying " I might have a specific C++ video for that, check if its there / I might explain it in detail in game engine." Oh man you have so much thing to explain us on buffer :D

[@christ4791]

Great video as always! Can't wait for new videos. I was wondering if you are going to cover exceptions, file handling, polymorphism and multi-threading

[@hmmmidkkk]

if anyone is having problems after cherno fixed his cyclical include errors but youre just getting "Syntax error 'Shader'/'VertexArray'/'IndexBuffer' not defined" then go to Shader.h , VertexArray.h and IndexBuffer.h and check if you included Renderer.h in there , if it is included in those header file , move that to the correspoding cpp file and remove it from .h files , i hope this helps

[@finnbuhse4775]

For anyone else experiencing my problem, after adding vertex buffers to my vertex array, the vertex array needs to be unbound otherwise opengl has a fit

[@koungmeng]

4:35 the IndexBuffer and VertexBuffer is included in VertexArray

[@longbra]

For some reason Visual Studio lost my project settings from last I opened this project... DOH! Finally back up compiling, but probably linking in all the default Libs

[@kfir_dars]

10:14 Do you have a video of #include stuff in C++?

[@phee3D]

I shot myself in the foot multiple times today, it was tragic. 8:44 into the video when you hit the build/run button, I paused the video and went to run my code. Immediately started running into weird bugs such as ASSERT is undefined and whatnot, for some reason in the back of my head I thought you didn't face this issue at this stage. I have been trying to debug for about 2 hours now after reading up on things such as what exactly is pragma once and all sorts of other things, I finally figured out that I had a cyclic include file thing going on. When I came back to your video i nearly flipped over my table seeing you faced the same problem and were gonna show how to fix it.

[@JimD20619]

I just renamed all the existing "Renderer" files, includes, etc to "ErrorHandler" everywhere before creating the Renderer.cpp / .h files. Made life simpler.

[@shadow_blader192]

thanks

[@alejandroghio3204]

I recomend a more comfortable solution for the problem of the Renderer.h header defined inside itself Use a preprocesor envolture like this: #ifndef CLASSNAME_H #define CLASSNAME_H ...definition...; #else class classname; type independent_functions; #endif /*CLASSNAME_H*/

[@IshanChaudharii]

I Finally Got past Abstraction😆😆😆 Did some things on my own cause the template system wasn't working for me , but Yeh , I DID IT ! Thanks Cherno😄

[@ilyosbeknajmiddinov6754]

why this error c4430 and c2143 ?

[@spht9ng]

I get the same error and have been looking and still have not found a solution. Not sure if I did something wrong. I'm constantly missing steps and it's getting really hard to follow this since he keeps shifting around different files and switching things in a split second constantly.

[@wirosk2916]

Just remove the error handling from the renderer and replace the #include "Renderer.h" with #include "GLErrorHandler.h" in the classes that is not dependant of the renderer but you still want to catch errors in/from. Example below... #pragma once #include #define ASSERT(x) if (!(x)) __debugbreak(); #define GLCall(x) GLClearError(); x; ASSERT(GLLogCall(#x, __FILE__, __LINE__)) void GLClearError(); bool GLLogCall(const char* function, const char* file, int line); #include "GLErrorHandler.h" #include void GLClearError() { while (glGetError() != GL_NO_ERROR) {} } bool GLLogCall(const char* function, const char* file, int line) { while (GLenum error = glGetError()) { std::cout

[@pugsly8087]

Thanks man, appreciate the help with that

[@mrroshblue5383]

Thanks

[@noah9013]

Ran into a bug that felt satisfying to figure out, maybe it will also be interesting to someone else. My program was crashing with "VAO names must be generated with glGenVertexArrays before they can be bound or used." When I went through with the debugger, I saw that the VertexArray destructor was being called after the first call to renderer.draw(...). That includes a call to delete the vertex array. Ok, we're deleting the VAO so it's easy to see why we get that error. But why was the destructor being called in the first place? Well, turns out I forgot the '&' on VertexArray parameter (dumb mistake), so I was passing a copy of the VertexArray object that was getting cleaned up at the end of the draw method. And even though this VertexArray was just a copy, its call to delete the VAO was just as real to OpenGL. When I pass the parameter by reference, the object persists outside the scope of the method, so no destructor. Small error, but a cool insight to how the lifecycle works and the big consequences it can have!

[@FelipeRicobello]

If you are getting C4430 error, I recommend you to replace your "Renderer" class to another file, that is separate from "GLClear".

[@rewe3536]

Do you have any ideia of why does this error occur?

[@rewe3536]

It doesn't make any sense for my little knowledge db

[@lorenzobianco4350]

Are you going to cover Vulkan in the future?

[@gage2560]

Vulkan is not stable enough to release plus it is extremely hard to code

[@supremedeity9003]

@@gage2560 yeah because its low level. you have a lot of control with it. same as dx11, if you mess up your computer can shut down.

[@sidalimostefaoui269]

Why isn't the IndexBuffer passed as a parameter to the VertexArray and binding it in the constructor and then just passing the VertexArray and Shader to the Draw() method, since the OpenGL automatically binds the EBO currently bound VAO ?

[@JakobRobert00]

4:40 I read it's generally a good idea to unite many small vertex buffers to one large vertex buffer. Doesn't the same count for index buffers? So would it make much difference in performance if you use one index buffer per model and then pass the offset and count for the different parts of the model using different materials?

[@vitor-a12]

What renderer methods do you use? (Like batching method and etc...)

[@fleskimiso]

Cool series.

[@nilaysharma4040]

Is it a good idea to use CUDA with OpenGL? If yes how can I do that?

[@MaxwellsWitch]

Nilay Sharma It's a massive pain in the ass to do that. You can interop both OpenCL and CUDA to OpenGL, and you can share GPU memory resources between the APIs. But search CUDA OpenGL interop.

[@giancedrick507]

I have a bug that the rectangle disappears half a second after it's being loaded, every code is the same. It seems to be renderer.Draw(va, ib, shader); that is causing it, because it works fine before I implemented it. Is it a scope error? Idk someone help me

[@muhammadseyan8361]

does binding shaders, index buffers and vertexarrays in the draw call hurt performance by a lot?

[@platin2148]

Should we write a function for every primitive that is possible to draw like GL_LINES , GL_TRIANGLES , GL_TRIANGLE_FAN or should that do the renderer for us?

[@sasanace]

why there is no execution to test the shape ?

[@kylefillingim9658]

This video seems to break my program and I can't seem to get it back, I have linker issues but I cant seem to find which file is having the issue

[@kylefillingim9658]

I ended up making a separate header file for the assert, and glcall and used it everywhere instead of tenderer.h that fixed most my issues #include void GLClearError(); bool GLLogError(const char* function, const char* file, int line); #define ASSERT(x) if (!(x)) __debugbreak(); #define GLCall(x) GLClearError();\ x;\ ASSERT(GLLogError(#x, __FILE__, __LINE__))

[@noneofyourdamnbuisness3484]

sometimes link errors arent really link errors (i know); I've had it where I just forgot to declare the class (ie: ShaderProgramSource ParseShader(...) vs ShaderProgramSource Shader::ParseShader(...) ) could be anything

[@guidowitt-dorring124]

Why do we need a Renderer Class at all? As far as I can see, in this and the following tutorials the Class keeps containing only one Method. Wouldn't a simple function be enough? What benefit does this Class provide unless we abstract it further, like design the Renderer so it can draw a triangle of size x at position y, and letting it take care of creating the Vertex Array, Vertex Buffer, Layout, Index Buffer and Shader.

[@kartikgadagalli1008]

you are right. I would only abstract the shaders into one class and vertex arrays , buffers into one class.

[@hunterer90]

Would be awesome to see a great OpenGL tutorial on how to do a deferred renderer! :)

[@ty_teynium]

I'm loving this series! Please don't stop making these videos.

[@hamseiggeh6331]

Is there is language only for graphic programming or another language uses API for representing data

[@giancedrick507]

yeah, GLSL

[@ilyboc]

I thought by specifying #pragma once it won't include something already included (confused)

[@matthewmoulton1]

You are right, but #pragma once solves a different problem. The problem that we had here was a circular dependency. If A requires B to compile and B requires A to compile, then which one should be compiled first? Most other languages I have worked with figure this out behind the scenes, but for C++ it must be explicit. #pragma once is about not defining the same function (or class or whatever) twice. This would be a problem because theoretically, the same function could be defined in two different ways. Then the compiler wouldn't know which definition to choose when it needed to use one.

[@ilyboc]

@@matthewmoulton1 Thank you!

[@johndoe2790]

@@matthewmoulton1 pragma once also doesn't work on macros. found that out the hard way (tried to put the error handling from this series into its own header)

[@JakobRobert00]

What about instead of using a Renderer class and passing the data to a draw method, you have a Model class which contains its own data like vertex array, index buffer, shader and just has a draw() method without any parameters? Then you could as well derive the different models from an abstract class and just iterate through the models and call their draw method. So you have concrete classes like Triangle, Rectangle, Circle which each have their own implementation of draw. Would this be a usual approach as well?

[@bobjones304]

Unbinding is not a bad habit IMO, e.g. you do need to unbind if you are rendering to an FBO.

[@onesmaskungu7716]

thanks a lot

[@shivanshuraj7175]

Could you make a video for object selection...

[@oldunused.emailmetogetmyne1997]

You know it's special when it's the only one with a blue opengl logo =P

why don't you use qt-opengl or qt-3d renderer?

[@lahusa_]

This wouldn't fit into the simple and general style of this tutorial

[@sablanex]

Because the point is the write your own

You can build your own but you can build real native corss platform mobile and desktop and embedded apps with same code and same performance.

[@BlackJar72]

Well, for Qt you have to either (a) make everything open source and release under then GPL 3.0, or (b) pay a *lot* of money for a non-opensource license. ("Pricing starts at $459/mo.:) Also, like other said, this is about doing as much as possible yourself -- the same reason he's not using SDL. But I'm sure a lot of this can be transferred to use with Qt.

there is 2 more licence aggrements. python and lgpl(just use dll can't complie static)

[@郑祺瑞]

nice cherno!

[@SalvaKaraka]

Why not creating an "error checker" class instead of importing renderer everywhere?

[@F0r3v3rT0m0rr0w]

void Draw(const VertexArray& va, const IndexBuffer& ib, const Shader& shader) const; i get 2 errors missing type specifier - int assumed, note C++ does not support default-int syntax error missing , before & this is infurateing because it makes no damned sence why it wouldnt like this ... its exactly 1 to 1 as to what he types ...

[@Erlisch1337]

Missing an include?

[@mini-nu1sx]

Did you found it? I got the same problems

[@aternias]

Make sure your ib.Bind() and Unbind() are const

[@abdulrahmanzaki8545]

I had the same problem and resolved it by moving include "Renderer.h" from Shader.h to Shader.cpp

[@software-namibia]

had a little chuckle when you tried to make the renderer class xD glad i had the foresight to make "GL_ERROR.h" from the start because i knew there would be a renderer class down the line.

[@goranantonijevic1709]

People please help me... project from this video on my computer takes 1GB of memory. Is this normal? Are there some settings where I can fix that?

[@Zucc0]

in my computer takes even 1.5 GB of memory xD, though that is absolutely normal, VS is an ide, so it has features like syntax highlight (IntelliSense) and code analysis that may allocate a lot of ram easily

[@matthewmoulton1]

There are other IDE's that are a lot slimmer. I use Code::Blocks and my project so far is 5.6 MB. XD Code::Blocks doesn't have all the bells and whistles as VS, but it gets the job done.

[@wrawler]

@@matthewmoulton1 I am using vscode with cmake and my project is 1.7MB so far

[@androth1502]

this cross referencing in the headers broke the entire thing for me so i just gave up and did what i always do when using an awful protocol like in c/c++ and moved everything into a single header and problem solved.

[@Metalwrath2]

Or do forward declaration

[@esben181]

I've been trying to solve this issue for over 4 hours: Error LNK2019 unresolved external symbol "public: unsigned int __thiscall IndexBuffer::GetCount(void)const " (?GetCount@IndexBuffer@@QBEIXZ) referenced in function "public: void __thiscall Renderer::Draw(class VertexArray const &,class IndexBuffer const &,class Shader const &)" (?Draw@Renderer@@QAEXABVVertexArray@@ABVIndexBuffer@@ABVShader@@@Z) Error LNK2019 unresolved external symbol "public: unsigned int __thiscall VertexBufferLayout::GetStride(void)const " (?GetStride@VertexBufferLayout@@QBEIXZ) referenced in function "public: void __thiscall VertexArray::AddBuffer(class VertexBuffer const &,class VertexBufferLayout const &)" (?AddBuffer@VertexArray@@QAEXABVVertexBuffer@@ABVVertexBufferLayout@@@Z) Error LNK2019 unresolved external symbol "public: class std::vector const __thiscall VertexBufferLayout::GetElements(void)const & " (?GetElements@VertexBufferLayout@@QGBE?BV?$vector@UVertexBufferElement@@V?$allocator@UVertexBufferElement@@@std@@@std@@XZ) referenced in function "public: void __thiscall VertexArray::AddBuffer(class VertexBuffer const &,class VertexBufferLayout const &)" (?AddBuffer@VertexArray@@QAEXABVVertexBuffer@@ABVVertexBufferLayout@@@Z) Error LNK1120 3 unresolved externals

[@asarcagatay]

I was having this error too , the problem was that I defined the inline function "IndexBuffer::GetCount" in both the cpp and the header files. Then I learned that inline functions should be defined only in the header file.

[@arthurproctor613]

@@asarcagatay As soon as I took inline off in both files my program compile and ran correctly. Thank you!

[@TahmidSadik]

love_this_series();

[@weltlos]

returning 1

[@sharif47]

This is something I won't be having until next year. So, my question is: Isn't learning a popular rendering engine better than making one? Or am I making no sense whatsoever?

[@PenguinMaths]

It depends on what your goal is. If your goal is to release a game and an existing rendering engine or game engine meets your needs and has a license that will work for your project, then using an existing rendering engine would be a good idea. But also there has to be someone who understands how rendering engines work so that they can maintain existing ones, and create new ones. Some people (myself included) are more passionate about creating render engines and game engines than making games themselves. If you fall into this category, then this is a good series for you and worthwhile skills. If you just want to make a game, there are faster routes you can take to completing a game.

[@sharif47]

@@PenguinMaths actually, I'm asking this because we have a course on using OpenGL next year. So, I was wondering whether making one or using a pre-existing one works better. Also, after creating an engine, what do people of your field do with it? Do they sell it or do they create it in order to use it for their projects?

[@Chimponaut]

@@sharif47 some engines are sold as licenses, like unreal or unity. Others are specialized in just being used for a certain game, or for a couple of games in a studio. An engine that can do everything is rarely the best at doing a very specific things that a game might need. And if it is okay at a lot of things(somewhat like unity) you will usually see a performance loss.

[@sharif47]

@@Chimponaut I was talking about render engine (more like Blender than Unity)

[@Chimponaut]

@@sharif47 Well most studios use Maya/3dsmax/zbrush for those sorts of things, not sure how often Blender is used as a professional tool. And yeah you would be better off using one of those tools for that, but if a studio made their own it would probably be to make it a more lightweight version with just the things they really need for their projects.

[@bies_moron4404]

Hello guys, my name is the Cherno and i am wizard. ;)

[@martinkrajda5521]

Hi, cool Videos so far. I have a little Problem though. When i run it in VisualStudio everything runs perfectly fine, but when i try to run the binary (both DeBug and Release build) the program stops and it says "OpenGL.exe is not working....". I get a console output, that there is a problem in my Shader.cpp file with the Bind() Method (precizely with this line: GLCall(glUseProgram(m_RendererID));. The binaries worked before. Am I just not getting something? Is this even supposed to work? Greetings :)

[@thestovietunion790]

People who used #ifndef x #define x guards: Writing a "Basic" Renderer in OpenGL

[@matthewmoulton1]

I always use header guards for portability's sake, and I didn't have any problem with it. Do you care to explain what went wrong? I will help if I can.

[@thestovietunion790]

​@@matthewmoulton1 I don't remember exactly what caused the problem, but the code just refused to compile, and the reason wasn't clear to me. I don't remember all the details, but it was probably a circular dependency problem. I eventually just resorted to pragmas since I wanted to learn more. I didn't understand much of the code anyways, since this was one of my first introductions to OpenGL. I also had only a few months of C++ experience, and the use of malloc() in this tutorial didn't help. I tried to look for a fix in the comments but only found more people who had stumbled upon the same problem. It has been a year or two since I wrote this comment, though. I know more than I knew then. I am not using this solution anymore. You can rest assured that my current GL setup uses header guards.

[@antoinedevldn]

Woooww!

[@slurpeesauce1750]

Bruh my code didnt run, spent next 20 mins trying to fix it. Yay its fixed. Unpauses video and the mad lads code himself is also crashing then he solves in sub 1 min lol

[@TheChrisey]

A small advice when it comes to including headers: Don't include headers in other headers! Instead create one main header that includes all of the headers you need, that way it will be much easier to track the order you include them in, and you will be sure to only include them once. Finally, include that main header in all your compilation units, otherwise it's very easy to create chaos with includes. Always remember that, Visual studio will cry about things it doesn't recognize, that will happen because IntelliSense isn't intelligent enough to parse the compilation unit itself, instead it only focuses on the current file. Thus if you need to include and you do so in a collected main header (or in the cpp file directly) and then you add an include for your custom header where you've also used string, IntelliSense will not recognize it when you open that header, but it's perfectly fine to compile. Headers are never compiled, they are just modules for the cpp files.

[@ascii2510]

i could be wrong, but doing headers like that means every single header file will be compiled and linked into the exe X amount of times.x being how many different places you included it.

[@sweetberries4611]

it will be compiling longer

[@jessprogany4345]

What are the pros if you create Renderer as Singleton?

[@sweetberries4611]

isn't it better to make mesh class?

[@NightSkyBlade]

I think you should work on audio quality a little bit, you know you should bring the microphone closer or something like that to improve quality.

[@Chimponaut]

God I hate const, const const const, const and just to be safe const.

[@williambeeton1223]

thank you for this amazing vid xx but python is better for games

[@sweetberries4611]

python isn't

[@catinwall4256]

your stupid

[@giancedrick507]

lol wut

[@jombokabary4540]

lmfao what's wrong with u?

[@andresmorales7762]

the whole video is spent on talking, talking and talking and shows nothing at the end

[@no5x937]

Still talking way too fast to the point it no longer sounds like English. Are you from a Piker family?