The good news is that Vulkan gives you complete access to the entire graphics pipeline. The bad news is that Vulkan gives you complete access to the entire graphics pipeline.
I'm a beginner C++ programmer and I've done some tutorials and then I thought; what do I want to use it for? Visual stuff. OpenGL is surpassed by Vulkan. I'm a gonna learn me some VULKAN! Thanks for the video. And yes do a Vulkan series.
Found this video because I've just started learning Vulkan few days ago and went through the same tutorial (as many others). So fun to look at the reaction we beginners have after going through it! Yep, it's scary and overwhelming!
Vulkan is perfect for hard level graphics/physics modeling. It takes thousands lines to draw it, and it gives you a great performance tho. However, you have to learn how to draw a triangle first
I disagree, vulkan has much better error reporting than opengl. The vulkan validation layers are awesome. And the fact that you finally have bytecode shaders is awesome. Opengl regularly has glsl code breaking on one gpu and working on another.
Some notes. Vulkan and DX12 are faster and harder to program than OpenGL and DX11. The reason is abstraction. The former 2 are heavily abstracted, taking care of a lot of the memory management and other stuff for you. Vulkan and DX12 are low level APIs, giving far more control, and responsibility to the user. They cropped up after AMD showed of Mantle, which IIRC more or less morphed into Vulkan. For a while, AMD was behind Nvidia in DX11 performance, some was due to Nvidia drivers being heavily optimized for DX11. The newer APIs aren't necessarily that much faster on the GPU, but on CPU, there is far less overhead, and multithreading is much easier and more effective. Not quite as "close to the metal" as older consoles, but low enough to give vast control. You can even do things like use an Nvidia AND AMD GPU at the same time to render the same game, rendering the same frames..... since you aren't limited by the heavy abstraction of previous APIs.
> You can even do things like use an Nvidia AND AMD GPU at the same time to render the same game, rendering the same frames Didn' know about that tbh... i thought multi-gpu rendering was dead
@@mparagames It isn't Crossfire and SLI aren't supported in drivers anymore, but multi-gpu rendering at the API level like this can still be done. I don't think it is used much, but I remember back when DX12 and Vulkan were coming out seeing articles on proof of concepts for cross-vendor rendering.
@@xeridea i see... well, i knew about vulkan being able to use a gpu other than the one generating the output to render the games (aka a gpu without any output connected to it). I tried that once and despite it giving a significant performance overhead, since the buffer had to be transfered to the OTHER gpu, it kinda worked somewhat well, i could play the game at decent enough framerrates. (Basically what i did was connecting the hdmi cable to the igpu and using the dgpu to render the game, despite this not working as well as connecting he cable to the dgpu, the performance was still much better than the igpu raw performance) But multi-gpu rendering through vulkan is new to me
@@mparagames yeah there is overhead but it can be worth it for demanding games. An advantage over Crossfire/SLI is you can have each GPU render part of the same frame, instead of using Alternate Frame Rendering, which increases latency, and is also difficult to properly optimize. Seems the industry is moving to massive GPUs instead, but it is still interesting to play around with. Maybe it will have a resurgence in the future as Moore's Law slows.
Bro, thanks. Despite the length of that code, this video was actually super motivating because now, I can see the finish line, and also see that that first 1000 lines of code is the main learning curve. I'm excited. thanks a bunch, respect. "some sick joke" haha, that's too funny. GJ for making it through that haha.
Great video mate, thanks a lot! SDL has been fun to learn but wow is it difficult to cross compile from Mac to Windows. I think I'm close though, just need to work out how to find SDL_gfx for windows.
@@1u8taheb6 well, you have to realize that Assembly takes in account, and I mean it, everything. So now think about that. I'm drawing a 500 by 500 hundred pixels square. That's already at the very least 250 000 assembly lines. And for sure I can tell you it's nowhere near that simple, so it might be even 10 times this amount. Dig it up.
this is maybe true if use literally no sort of abstractions. No functions, no macros. I seriously doubt even that though. The c++ to assembly LOC translation is not like... 1000 to 1, lol.
I’m new to Vulkan but I started on OpenGL and I gave up on DX for some reason so I have some knowledge of Graphics Programming but not much and yet I’m still willing to make something in Vulkan.
So if vulkan uses alot of code to get started why don't you write a program to make it easier to do all the options with configurations, to get you started. So all you need to do is input your information in the fields provided and than select a option to auto write for you. Than all you need to do is inspect and write what U need to do.
you can very easily just copy the code and patch a few stuff so it works for you, but i find that writing all the boiler plate line by line makes it easier for me to understand how it works
I spent a whole bunch of time doing OpenCL with OpenGLOpenCL interop, only to find that my graphics card driver has a bug and it's not a non-zero copy share between the API. Result: Even the simplest kernel functions were super laggy.
I'm making a renderer because I don't know what kind of game to make. If I had an idea, I would have started with Unreal, but here I am about to make my own engine.
Vulkan is an very low level API. You need to write everything yourself, stuff that an engine or library like SFML has already done. It's your choice. I didn't regret it, since i learned a lot of how graphics stuffs on a computer works and how to properly organise my code! You learn what code to put where, so that it doesn't annoy you anymore.
I want to make a 2D game on a phone that has almost the same amount of battery drain as leaving the screen on while social media is on so Vulkan seems good. But I am not going to spend the next 5 years trying to learn it.
I'm a beginner at programming. Not a complete noob, but I've never done something big. My biggest project I did on my own was probably that one Java project with about 1500 lines of codes, but recently I have more practice with c and Python. At the moment I'm having fun learning how game engines work. I try to do one myself. I have a game Idea, but I could also use preexisting engines after I had my fun making a slow and barely working engine myself. Let's assume I actually manage to keep my motivation to finish a decent engine. My game should have some decent rendering distance. Like I want to make a 3D game where you can stand on a tall mountain _(like actual mountains, not those puny minecraft hills)_ and look over a forest. And the viewing distance should not be limited by some arbitrary fog of war which I have to set because of my bad programming skills. I know with that goal in mind I have to have a solid plan on how to handle level of detail. At the moment I plan on making the engine in C++. And I'm not too sure on what API I should use. According to that video Vulkan seems to be a bit of a difficult start. Is it doable to start with a simpler API and changing it mid-project. Dave Frampton, the developer of the game sapiens, changed from OpenGL to Vulkan during the game development. But he is also way more experienced than I am. Or will I have have to restart my engine project anyways since this is a project one can not succeed in at the first try. What kind of API would you reccoment? I used pygame in python and whatever API contains those swing.JPanels in Java. Basically I only used simple default APIs. Which kind of API would be the next step for me to take?
For the project you're working on, you'll need something that is fast. Vulkan and C++ would be the ticket here. I would recommend starting on a smaller project in Vulkan and C++ to figure out your way around those tools. After that then I'd move on to your bigger project. That's what I'm doing currently. I have a big idea for a game, but it's a big idea. So right now I'm making a smaller game first for practice.
@@codergopher8270 Thank you for your response. I guess I will go that route. I noticed that there are a lot of average to good tutorials out there _(not c++/vulkan- specific)_ and sometimes I find a gem among tutorials. Do you know of any gems of a tutorial on either Vulkan or c++? The difficulty level should roughly be around beginners level. I haven't watched any others of your videos. So If you think your c++ videos fall under the category "supreme" then don't feel ashamed to recommend them.
@@benrex7775 For Vulkan, I do plan to eventually create a tutorial on how to make a 3D game from scratch, but first I want to thoroughly learn it so I can teach it well. This vulkan-tutorial.com/ has been very helpful, but not really geared towards beginners. That tutorial expects a fair bit of knowledge of C++. It's been the best I've been able to find. For learning C++, you can follow along with my SDL/C++ series where I teach C++ and game mechanics at the same time. The SDL series is also going to cover a 2D physics engine, which a understanding of 2D physics can easily enough be applied to 3D physics. I'd also recommend TheCherno on learning C++ itself, and TheNewBoston Bucky's C++ tutorials here on RU-vid. Both are excellent, and that's where I've learned most of what I know in C++.
@@codergopher8270 Thank you again for the thought through answer. It's rare to get them on RU-vid. For the 3D engine I already found the channel _javidx9_ (done in c++, for some old game console) and _thebennybox_ (done in java with OpenGl). They both have a slightly different approach to creating the 3D engine. I also started with recreating javids tutorial in pygame. But after a bit of pygame usage I'm not too happy with it. That one of the main reasons why I started to look around a bit more. If the 2D stuff is translatable to the 3D stuff then I will add your playlist to my watchlist. I just watched a C++ tutorial. Apparently it's quite similar to C. So I will not have to specifically learn that. But it's always great to know, in case I notice that I still need it. And _TheCherno_ has a game engine tutorial. Perhaps I look into that as well. Let's see of I'm faster at learning vulkan or if you are faster at making that tutorial. If I can keep up my motivation, I will be faster with just going for the tutorial you recommended. From quickly looking over it, it doesn't seem to be that bad. Perhaps I'm overestimating myself. Or I'm underestimating myself. Probably the latter. Who knows...
Only reason I came by this video is the faact that I am working on my own game on SDL, and heard about Vulkan and thought maybe I should reconsider, I think I'll stick to SDL, it's 2D multiplayer RPG, to learn more about web stuffs and games, probably will integrate with OpenGL and then Vulkan (but I think by that time I will move on to next project, damn sure just getting it down in OpenGL will be hard)
@@codergopher8270 It's more of learning project, but I will surely get some 100+ playerd around, create some puzzles, have some laugh in multiplayer dungeons, before I stop working on it
Hi I have been trying from a long to convert yuv image to rgb using vulkan instead of Renderscript but didn't get any solution. It would be realy helpful if you make video on YUV2RGB conversion using VK_KHR_sampler_ycbcr_conversion. Thank you
I don't understand why it's going in reverse compared to CPU programming like, we've come far from assembly language to now Java and python that has very high level of abstractions but in GPU programming we've gone back to more and more assembly like programming for GPU. It makes sense that it gives higher performance but the same can be said for assembly too, but there are languages like C, C++ that has compilers that can output the equivalent machine codes without burdening the programmers too much... So why can't we have a compiler for GPU programming as well, like you write some openGl stuff and the compiler will output Vulkan level code?
OpenGL and Vulkan are just APIs, the real 'code' is on the graphics drivers side. High level of abstraction is not always better, the main issue with OpenGL is that it has been designed a long time ago (>20 years) when GPU were very different from now. Thus, it becomes more and more complicated for graphics vendors to ensure maximum performance when sticking to OpenGL. Vulkan is an remedy to that, it put more burden on the app developper, less on the driver developper.
does GLFW, GLEW, and GLM have a Vulkan counterpart? I'm interested in the vulkan stuff but im still learning opengl in c++ so later lol but i might need to move to vulkan when the lag spikes get too intense.
nah, im a c (non) god and after i wrote my own standart library imma make a 2d game in glfw opengl, then i seperate opengl code as much from game code as possible and then rewrite rendering backend in vulkan glfw
I would make the prediction that in the not-so-distant future autonomous cars and other vision-based robots would use Vulkan quite heavily. So I don't think that it is just a video game/3D rendering API. I think soon people will realise how useful it is to have the 3D rendering pipeline plus compute shaders in the same low level API allowing for fast and efficient sharing of GPU resources on top of the faster overall performance compared to both 3D rendering and computing APIs.
So how great is the difference between the 1162 lines of Vulcan, to get a triangle on screen, vs. using pure home-written C++ to do it yourself? How many lines would that be, because I guess Vulcan is written in C or C++?
Vulkan is a specification for graphics. The actual code is provided by your graphics drivers, which is provided by your graphics card vendor (nvidia, amd, intel). So to do what Vulkan does in plain C/C++ you would have to write the specification for Vulkan for your graphics card. Basically your own driver.
@@soulextracter No, as you now know that is not the case. The graphics card manufacturer gives you low level access to the graphics card by implementing the Vulkan functions in their drivers. You then just need to use the function signatures in your code to tell the driver what to do with the graphics card.
Ssooooo.. If I'm trying to make a simple raytracer as a beginner in 3d graphics (I've done stuff with java's Swing). do I need the speed of Vulkan? or will OpenGL (or even OpenCL) do fine?
I would recommend starting with OpenGL first. Much of the rendering concepts are the same in Vulkan, and pretty much any graphics API, so getting a handle on the graphics pipeline would be much easier in GL.
The standard graphics pipeline is about rasterization, it won't do anything for you. I say try Vulkan, setting up computr shaders is easier than setting up the raster pipeline for drawing a single triangle.
In a nutshell, they're full of telemetry+ bloatware. Sometimes, it's really cool to use lightweight text editors like geany or sublime, with some execution parameters
The problem is if you want to directly acess the GPU without using some high level library that was built on top of one of the low-level API's there is basicly just OpenGL and Vulkan. The problem with Vulkan is really verbose and complicated to learn and use. OpenGL is significantly easier but is very old. It has tons of deprecated legacy functionality and design flaws. It comes from a time where GPU's simply worked different than how they function today. It also seems like KHRONOS more or less abandoned it in favor of Vulkan. In reality Vulkan isn't the answer to everything, for the same reason you don't code everything in C or Assembler. Simplicity and ease of use just are a important factor. When you write a sprite based 2D game having to write 1000 lines to see your first triangle would be ridiculous. If you just want to spice up the GUI in your application with some 3D you don't want to have to learn Vulkan. There either needs to be a reworked OpenGL 5.0, a new simpler API or a standardized high level wrapper for Vulkan that reduces it's complexity.
@@Vitriol-dk3xh That‘s not even true, for example if you target Mobile basicly no one uses Windows. It’s all Android/IOS. And even on the Desktop every engine worth mentioning also supports other Platforms than Windows. „Just stick to only DirectX“ ain‘t the solution.
@3:31 "You can see that, after 17 hundred lines, you've got yourself, a model loading." "You compare that, one thousand lines of code with something like OpenGL, you can see that essentially the same thing can be achieved in only 200 lines of OpenGL code.. it's just a little square, pretty much the same thing..." Like bro are you kidding right now? Firstly that's a TRIANGLE NOT A SQUARE and oh um, a statically placed, not-animated triangle is nuh-thing like displaying a rotating fbx model of a cabin,
Thumbs up for realising it was a triangle!!! hahaha Great video, great introduction to Vulkan. 1000 lines just to initialise it... jezz... you'd of thought with it being a "modern" replacement for OpenGL it would of been less and the setting up could of been an API call on its own. Guessing there is a valid reason for the way Kronos has done it this way. I know a little OpenGL (not much), but about to enter the world of Vulkan!!!
I've never really had an issue with the SFML community. Stackoverflow, on the other hand, tends to get a little bunged up from time to time, if you know what I mean, but the SFML forums are usually helpful. Where'd you hear that the SFML community is toxic?
@@danieleccleston7928 I saw it a few days ago in a reddit thread... "If you need a 32 version you need to compile it for yourself" says in the download section of sfml :'v ok...
So why do you have to rewrite 1100 lines of code just to display some primitive solids. Why is there not a high level object that you can call on that does all that, out of the box???
@Sinneslöschen But why everyone has to reproduce the same effort to display basic geometry? That should have been done by them once, so we can use it to create what we want to create. Coders are NOT Human. You guys have been assimilated by the Borg already. You think one dimensionally. We think in 3D images. Creating a User friendly Interface is an art and coders have no idea how to do it. You should hire Graphic artists and process engineers to create GUIs.
@@We-Do-NOT-Consent-303 i don't know,maybe it was not supposed for everyone to use it?That is why opengl was not exporting core functions but only you create a context,and then use function pointers to able to use them.And that is also the fact that modern opengl deprecate all basics 3d transformations such as glTranslate and glRotate in version 3.3 which is annoying because you have to write transformation matrices yourself.
@@We-Do-NOT-Consent-303 usually,you lose versatility when you simplify things for higher level.But i don't understand why Vulkan has to be so verbose on this since both modern opengl and vulkan are using shaders which is already focussing on gpu side.
The vulkan spec www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#introduction Not very beginner, or really anyone friendly documentation, but if you wade through it, you'll get there. vulkan-tutorial.com/ this kind fellow has been very helpful
its not for beginners. Its really not even for experience programmers. The caveat being, that its not for either or these people if they are writing one program to do one thing. You use things like vulkan and GL primarily to build up a reusable body of code. I would not call vulcan an API at all; you really should not be writing applications with it. You should be writing libraries with it. Its an LPI, lol.
I swear that i can create my own GPU and code it on arduino and create my own circuit board and create my own 3d API which is still easier than Vulkan.
I tend to disagree with the concept that difficulty should measure weather it is for or not for beginners. Instant gratification has no place in programming. Directx has way to many training wheels and filled with garbage code and dead code and even more legacy code than opengl and garbage code left in from legacy code and dead code. Also opengl was actually on par with directx up until around 2014, in most cases ahead but most of the shift went to vulkan from 2012 to now with directx losing more and more support in the backbones and taking features that were being worked on for a long time like tessilation and ray tracing and shifting the focus into incoperating them into a newer faster API that didn't have all that legacy code. They also changed the license around to the apache license probably because opengl used this weird combination mix of bases off multiple licenses. FSF use to approve appache license but now they are against everything that isn't gnu gpl v3+, even going against gpl v2 software to claim its not free because they don't have policies in the license that feed their EGO driven war on everyone not FSF, even if it were to be basically the GNU GPLv3 re-written they would be against that.
You now know C++, OpenGL and Vulkan and you are just like, 17 yo, while I'm barely holding on with c++ and couldn't really wrap my head around opengl. Might as well not even try.
Failing to try is failure itself. Don't give up. Start off with something lik SDL2 or SFML, and you'll find it's a lot more encouraging. You'll get results faster without the gruelling work.
Actually there is a lot of young people that are pretty good at c++ and graphics programming, just look at cherno's discord server for example. i am 17 and i am pretty good at c++ and opengl, and i am currently learning vulkan(it isnt that hard if u have already expierence with opengl or d3d11), but i know 13yo which is much better than me in c++, opengl and vulkan. If you want to learn graphics programming just go to cherno's server(you can find there people which for sure will help u with it). also i would recommend "Vulkan discord server" where you can find people that designed vulkan. so learning c++ or graphics programming isnt that hard in 21 century. PS: In my opinion if u know sdl2 or sfml it wont help u too much in learning vulkan, better to learn d3d11 or opengl, this are the easiest Graphics API's.
I don't do drugs, and you shouldn't either. Taking recreational drugs is a terrible path to take.. Reality must be faced forthrightly and courageously. Hiding from reality through drugs is a terrible thing to do, and it is nothing but detrimental to your future. There is no excuse or justification for recreational drugs, and the only ones who pay for it is yourself and the people around you.
@@codergopher8270 marijuana is not same as heroine..it is a garbage spit out by pharma industry..try research urself on cbd..heck united states event patent cbd..go research urself..u should be grateful..marijuana is harmless...alcohol and tobaco way danger and yet its legal..oh well...
@@codergopher8270 While I agree with the sentiment, I don't see a problem with smoking an occasional joint or having an occasional drink. Moderation is key. This is coming from someone who used to abuse mostly weed but also alcohol. I wanted to escape, but even that caught up with me eventually. At the time I was extremely depressed. Now that I'm not, I simply don't have a desire to smoke/drink often, and when I do it's a lot more enjoyable.
@@electric26 There's a difference between smoking a joint and having a cup of wine, for example. When you smoke weed, you are doing it for the sole purpose of getting high. However, in many cultures it is very normal to take a cup of wine or champagne with your meal. Many people drink wine and such for the taste, and or the cultural custom. You can have a cup of wine and not get drunk. You smoke 1 joint, and you're high. (of course depending on the purpose). Getting high and drunk are both very problematic actions.
how did you set up vulkan in sublime text? i'm having some problems linking the vulkan-1.lib file and the glfw lib file(s). i keep getting unresolved external errors. would really like to move my project to sublime if possible (i finished the vulkan tutorial in visual studio 2019 but i dislike visual studio)
@@codergopher8270 windows, i got everything set up now except for glfw so i'm just using the standard windows.h header file to create a window. sublime > vs!
