I think the main thing I take from all these tutorials and classes is how complex a modern game is and the amount of bug chasing that must go on behind the scenes from experts like yourself. It's really mind blowing to think of a massive game and the problems that will arise.
@@doublewhopper67 We recently had a small piece of software at work designed and built by a team and as they fix one bug it creates another. I can now appreciate the level of skill in getting a working game of sorts out the door.
You also need to keep an mind that there's a game and a game engine, the game engine is very complex but the game itself is using the engine and its features, the game bugs usually are related to the developers own mistake and it can be as simple as forgetting to check for a null pointer and having the game crash.
I work as a Software Engineer, mainly working on large-scale cloud-based web applications. You're my favorite RU-vidr as you bring it back to good old-fashioned C\C++ working closely with the hardware. Keep up the amazing work!
That’s very true. I work at a large tech organisation and whilst we have many devs that are proficient in web based solutions and share point based solutions none of them can work down at the machine level C++ It’s like they all rely on packaged solutions to work around problems but cannot write direct code to fix things.
That's me! That's me! That's interesting that it didn't work since the master branch was merged into the docking branch 4th Jan and the docking branch has those changes.
Between 24:48 and 24:49 it's obvios the tween theory is true, this is why Cherno can work in Hazel while doing videos, 1 person is not enough for this amount of work, he works with a tween and he never told us :O
Fantastic video. Live examples combined with great explanations make super worthwhile. You learn about the process of debugging but also rendering fundamentals.
Can you make it always obvious what series the video is about? I can't always tell. This one was fine because of the thumbnail. Also can you create a playlist for the "recreating my first game" series if it's gonna be a longer one?
I don’t understand how these day many lib came up for one reason : draw pixel, analogically or numerical; like old day when we using lots electronic composite to get image. But what i dont like for those > so every lib has syntaxes that final doing same mathematic algorithm for rendering; I m looking to make a lib that can use any rendering graphic lib…
Really interesting, i think i had some issues with ImGui too, but not with Vulkan but rather with modern OpenGL - which was a similar problem, like something i setup was straight ignored from ImGui. But i never used Vulkan in any real application before, so it would be awesome if you could start a vulkan tutorial series. Especially showing how to properly use it. I tried it and successfully initialized a window with vulkan on win32 and X11, eve without any library - just my own code. But i never had the urge, to actualy use it. But i would love too, but even drawing a simple cube on the screen is so much you need to consider, know and handle.
nsight graphics can be used to reverse shaders or models from games too but they stopped supporting 32 bit applications unless u download an old version
Hi, Cherno. I love using RenderDoc and NVIDIA Nsight for graphic debug. I want to debug some of my own gpu ray tracing app using Nsight ( RenderDoc doesn't support raytracing extension now ). But i cannot connect my app to nsight, the log shows that vulkan have a problem linking a dynamic library called RTSSVkLayer64.dll in folder RivaTuner Statistics Server. Sometime it just show no graphic api. I have no clues on this issues, do you have some clues on it? Thanks!
Has anyone had an issue with RenderDoc where source debugging is not working? Idk what happened, but I used to be able to debug a pixel and have RenderDoc step through my shaders (hlsl). Then suddenly it instead only lets me step through the disassembly and has a grayed out icon saying "source debugging Unavailable". very annoying
Just a guess, but if you use the OpenGL driver to compile the shader source at run time, then it probably has all the symbols available somewhere that it can reference. If you're using precompiled SPIRV code, then where would it get those symbols from? Maybe there's a way to compile with debugging information, or pass a separate pdb-like file to it, but not sure about that.
I assume you have an integrated card then, e.g. an APU? As long as your hardware supports OpenGL or Vulkan, it should be fine. If not, then it likely falls back on CPU rendering, which would be really slow even if it has a correct way to fall back on that. Chances are that OpenGL is supported if you have sort of GPU though (including the ones integrated into APUs).
a mipmap is a smaller texture made from a source texture. There optimized for use when stuff is farther away, and you don't need the entire resolution of the source texture. (you'd have more than 1 pixel in the texture per pixel on the screen and thus pre mixing them into a mipmap saves processing later)
@@khoda81 Depends on the sampler settings. In some cases, it could mean to blend between levels 0 and 1. In other cases it could mean to just sample level 0 or level 1 exclusively
