One other thing with handling the resizing that you need to consider is performance; you probably don't want to be resizing all of your framebuffers whilst resizing is taking place (as seen by the log text at 11:30), but rather after resizing has finished.
Great video as always, Just a quick one a more robust way to handle the minimizing is to use the glfw function glfwSetWindowIconifyCallback(window, window_iconify_callback); This is similar to other glfw callbacks set in the WindowsWindow.cpp file. If you create a new ApplicationEvent for WindowMinimizedEvent you can set the minimized state in the WindowData. This will help anyone having issues on Mac / Linux with minimizing as the window size is not set rather the window is push to a background task and 'iconified' Thank you for this series :)
The calculation you are looking for to keep everything same size and just see more when the window is resized is as follows: Obviously its bad to have that 720.0f in there - you'd need to pass that in from sandbox somehow. bool OrthographicCameraController::OnWindowResized(WindowResizeEvent& e) { float yScale = e.GetHeight() / 720.0f; m_aspectRatio = yScale * (float)e.GetWidth() / e.GetHeight(); m_camera.SetProjection(-m_aspectRatio * m_zoom, m_aspectRatio * m_zoom, -yScale * m_zoom, yScale * m_zoom); return false; }
I don't know if that happenend only to me, but the resizing was working fine already (exactly like his at the end of the video). And It took me some time to figure out that in the ImGuiLayer class, at the End() method, I was running the following piece of code: GLFWwindow* window = s_GetNativeWindow(); int display_w, display_h; glfwGetFramebufferSize(window, &display_w, &display_h); glViewport(0, 0, display_w, display_h); Which already corrects the size of the viewport on every Run() call of the Application class based on the Frame buffer size (apparently GLFW updates the frame buffer size when the window resizes?).
Considering MacOS has some weird things when it comes to window size vs frame buffer size, I wouldn't use a glfwWindowSizeCallback for resizing the frame buffer. GLFW does have a glfwFramebufferSizeCallback though, or at least that's what I use.
I have built some kind of mixture between cropping and scaling: when resizing vertically (changing 1920x1080 to 1920x800) it gets scaled as I want to fit exactely 2 units into my ortographic camera. When resizing horizontally it gets cropped. You can change that behaviour in the camera to scale horizontally and crop vertically.
With what we have now, it should be possible to create a view/viewport system comparable to what sfml has. This would combine the camera, the camera controller and some of the stuff of this episode. Only I would do it differently, because I think the sfml approach is very confusing and hard to use. For someone with my kind of brain, it's hard to keep the aspect ratio right with the sfml approach, because they have the view in pixels, but the viewport in normalised units that are relative to the window. I would fix it so that the aspect ratio of the view and the viewport are always equal, so that the graphics are not getting distorted when the aspect ratio of the window is changed by a resize. This implies that either change in width or change in height is dominant. Also I would do the api entirely in pixels and convert it to normalised units internally. I would also make the viewport the "main" thing instead of the view. Of course in opengl there is one viewport per context, so that if you want to draw to multiple viewports, you would have to have multiple scenes that each have a viewport. Every begin_scene would change the opengl viewport to reflect the scene viewport.
When you were just starting out, what books did you use to get the fundamental basics of what makes up a game engine and walked you through implementing a simple one?
Cherno said in a couple of videos (I think) that his favourite graphics API is DX11 - How about a DirectX 11 series? Like, it could be a sort of conversion course comparing it with the equivalent OpenGL calls and pipeline.
He already said that the engine is definitely going to support DX11 and maybe Vulkan at some point too. If you can't wait maybe look into ChiliTomatoNoodle's tutorials. He is currently doing something similar but with DX11.
@@supremedeity9003 Yes, I agree, his way of explaining things is pretty straight forward. At the same time, however, you get the feeling that it is actually your project and that you are researching how specific things _can_ be done, how specific mechanisms work and not so much how to implement them step by step, because this is mainly your task, as project manager, so to say. Good luck!
I'm having a lot of problems with the resizing. I copied all of the code exactly to see if it would work, but when I resize the window everything rotates by almost 90 degrees on the y axis. (or it's just squishing everything to be very thin, it's hard to tell) Has the glViewport() command changed or something?
He keeps saying that you shouldn't use imgui in the game itself, just in debugging and development tools, but he never gives a reason why not. Now, I think imgui looks pretty good (better than most actually) and it has a lot of functionality. I guess for a game it looks a bit office-y, but building your own gui is quite a project in its own right. Is there any reason beyond looks not to just use imgui as the game gui?
I don't know for some reason on my Mac OpenGL 4.1, the resizing was working fine without setting the viewport. Does anyone know if there a particular reason for that?
Can you make a video on what visual studio plugins you use and what are the best ones For eg: How do you get the words underlined in red when there's an error and stuff I don't get that in my vs Please!
One other thing with handling the resizing that you need to consider is performance; you probably don't want to be resizing all of your framebuffers whilst resizing is taking place (as seen by the log text at 11:30), but rather after resizing has finished.
Excited about multi-threading! Hope it will come soon! xD
Great video as always, Just a quick one a more robust way to handle the minimizing is to use the glfw function glfwSetWindowIconifyCallback(window, window_iconify_callback);
This is similar to other glfw callbacks set in the WindowsWindow.cpp file.
If you create a new ApplicationEvent for WindowMinimizedEvent you can set the minimized state in the WindowData.
This will help anyone having issues on Mac / Linux with minimizing as the window size is not set rather the window is push to a background task and 'iconified'
Thank you for this series :)
+1
The calculation you are looking for to keep everything same size and just see more when the window is resized is as follows:
Obviously its bad to have that 720.0f in there - you'd need to pass that in from sandbox somehow.
bool OrthographicCameraController::OnWindowResized(WindowResizeEvent& e) {
float yScale = e.GetHeight() / 720.0f;
m_aspectRatio = yScale * (float)e.GetWidth() / e.GetHeight();
m_camera.SetProjection(-m_aspectRatio * m_zoom, m_aspectRatio * m_zoom, -yScale * m_zoom, yScale * m_zoom);
return false;
}
OMG, I learned English only for watching your videos. Perfect work, Yan. (Здесь русские есть?)
Inco Gnito noice
Zdyes nyet russkogo
@@agfd5659 Zdyes yest ruskovo!
@@warstt Konehn!
Im learn English only watching ThinMatrix (Karl), TheCodeUniverse and TheChernoProject (Yan) videos.
I don't know if that happenend only to me, but the resizing was working fine already (exactly like his at the end of the video). And It took me some time to figure out that in the ImGuiLayer class, at the End() method, I was running the following piece of code:
GLFWwindow* window = s_GetNativeWindow();
int display_w, display_h;
glfwGetFramebufferSize(window, &display_w, &display_h);
glViewport(0, 0, display_w, display_h);
Which already corrects the size of the viewport on every Run() call of the Application class based on the Frame buffer size (apparently GLFW updates the frame buffer size when the window resizes?).
Considering MacOS has some weird things when it comes to window size vs frame buffer size, I wouldn't use a glfwWindowSizeCallback for resizing the frame buffer. GLFW does have a glfwFramebufferSizeCallback though, or at least that's what I use.
I have built some kind of mixture between cropping and scaling: when resizing vertically (changing 1920x1080 to 1920x800) it gets scaled as I want to fit exactely 2 units into my ortographic camera. When resizing horizontally it gets cropped. You can change that behaviour in the camera to scale horizontally and crop vertically.
With what we have now, it should be possible to create a view/viewport system comparable to what sfml has. This would combine the camera, the camera controller and some of the stuff of this episode. Only I would do it differently, because I think the sfml approach is very confusing and hard to use. For someone with my kind of brain, it's hard to keep the aspect ratio right with the sfml approach, because they have the view in pixels, but the viewport in normalised units that are relative to the window. I would fix it so that the aspect ratio of the view and the viewport are always equal, so that the graphics are not getting distorted when the aspect ratio of the window is changed by a resize. This implies that either change in width or change in height is dominant. Also I would do the api entirely in pixels and convert it to normalised units internally. I would also make the viewport the "main" thing instead of the view.
Of course in opengl there is one viewport per context, so that if you want to draw to multiple viewports, you would have to have multiple scenes that each have a viewport. Every begin_scene would change the opengl viewport to reflect the scene viewport.
27:54 It's not a bug it's a feature!!
Perfect timing Cherno, just came home from Uni!
Haha same
0:58 Java won't ever let you forget about updates.
When you were just starting out, what books did you use to get the fundamental basics of what makes up a game engine and walked you through implementing a simple one?
Game Engine Architecture is one
Cherno said in a couple of videos (I think) that his favourite graphics API is DX11 - How about a DirectX 11 series? Like, it could be a sort of conversion course comparing it with the equivalent OpenGL calls and pipeline.
He already said that the engine is definitely going to support DX11 and maybe Vulkan at some point too.
If you can't wait maybe look into ChiliTomatoNoodle's tutorials. He is currently doing something similar but with DX11.
@@weltlos He Jumps the gun a lot, new episode and bam all windowing stuff + input done. following along can be a hassle that way.
@@supremedeity9003 Yes, I agree, his way of explaining things is pretty straight forward. At the same time, however, you get the feeling that it is actually your project and that you are researching how specific things _can_ be done, how specific mechanisms work and not so much how to implement them step by step, because this is mainly your task, as project manager, so to say. Good luck!
You've stopped the forwad progression of time during minimize.
I'm having a lot of problems with the resizing. I copied all of the code exactly to see if it would work, but when I resize the window everything rotates by almost 90 degrees on the y axis. (or it's just squishing everything to be very thin, it's hard to tell) Has the glViewport() command changed or something?
Nevermind I just had a random - symbol where it shouldn't have been. I spent 2 hours on this haha
thanks!!!
He keeps saying that you shouldn't use imgui in the game itself, just in debugging and development tools, but he never gives a reason why not. Now, I think imgui looks pretty good (better than most actually) and it has a lot of functionality. I guess for a game it looks a bit office-y, but building your own gui is quite a project in its own right. Is there any reason beyond looks not to just use imgui as the game gui?
Can you also render while resizing or doesn’t it work in opengl?
Window Resize Event not show the {0,0} in Minimized in my Ubuntu 20.04
So excited about each new vid!
I don't know for some reason on my Mac OpenGL 4.1, the resizing was working fine without setting the viewport.
Does anyone know if there a particular reason for that?
for anyone looking for answers it has something to do with RetinaDisplay
My entire picture stretches when I do that
You need to update the camera's orthogonal matrix at the same time.
Ah, what is your VS theme it kinda looks cooler than the default one. BTW AWESOME VIDEO!
default VS theme with visual assist x
@@scrub6515 wait I didn't understand the orange, yellow combination of the text color comes with visual assist x?
@@nicolassurfay2585 yes it does, you may need to go into visual assist settings and turn on the plugins highlighting
@@JackPunter2012 OK!
Early squad reporting in
Oh look whose squad it is ;)
Can you make a video on what visual studio plugins you use and what are the best ones
For eg: How do you get the words underlined in red when there's an error and stuff
I don't get that in my vs
Please!
There should be an option in the tools>options
Br?
Make videos about competitive programming with c++
I always feel like we don't do anything in your tutorials. I'm a beginner and I learn by doing not listening.
Broken Puzzle maybe creating a game engine is not really suitable for beginning to program. Maybe consider some other tutorials?