"before we mess up writing to files too" Ever heard of the "fsync surprise"? That fun moment in 2018 when database developers realized that writing data to disk without getting errors didn't guarantee that there were no errors, just that none were reported.
It's more like "don't learn OpenGL", "you're too preoccupied with OpenGL". OpenGL is quite literally becoming an obsolete graphics API and there are numerous platforms natively targeting Vulkan and DirectX and not even providing an OpenGL layer, the OpenGL layer is translation. One of those two cross-platform and both have translation layers for everything. Even on Linux the preferred API is EGL or Vulkan if you can muster it. OpenGL is super dead
The problem with OpenGL as Jon gets around to here, is that it's not ideal, but easier and more cross-platform than everything else. 😆 I like OpenGL a lot, I know, I'm an asshole. But notice how Vulkan isn't mentioned.. Metal is Apple only and DirectX is Windows only. -Remember, AMD did JUST overhaul their OpenGL driver code last year and sped it up and made it closer to standard. Meanwhile Nvidia has added Mesh Shaders to OpengGL recently - without bumping up the OpenGL version. OpenGL is still supported and will be for a long, long, long, time.
sadly, Apple support is barely there. 4.1 core, freely violates standard in some places, and you can't even debug it properly without debug utils. Metal is a pretty good API though, it fits right in between DX11 and DX12 in terms of abstraction level
2:20 nobody tell him that if you are A using linux and B using AMD OR Intel, the opengl graphics driver is fully open source and absolutely can be debugged
@@anG_3L404 I think people find the 3d support a bit lacking. That was the only complaint I can really think of but I haven't really used raylib for 3d so can't say for sure.
I love Raylib and I'm currently at the tail end of making a game in Raylib and unsafe Rust, but one problem is that Raylib chooses to target the integrated graphics card over the dedicated graphics card and Raysan seems to think this is fine. I now have to figure out how to fix this, which from some reading I think means changing a row of code in the Raylib source code.
Opengl Is a good tool to learn graphics basics. I don't find It particularly useful to spend 30 hours just to setup a vulkan pipeline to draw a single triangle if you know nothing about computer graphics.
@@jason_m2003honestly, it's probably best to write a software rasterizer first to learn the basics of the graphics pipeline rather than using any of the api's
@@jason_m2003 opengl won't you truly teach how things going on really. It gives you a bunch of function calls that's it, even Vulcan can't teach you that truly, you need to join a company like AMD or Nvidia to understand doing these kind of things.
The point isn't that you don't get your stuff done. The point is, that using the API doesn't give you a very good understanding of how things actually work under the hood.
Raylib creates a window on any OS, abstracts the graphics card and gives you input on keyboard, phone, controller, and VR. You then write code to make game. Done. And if you want to know how it works, go read the source.
@@kasufertfor that you better check WGPU or BGFX. People should check Elie Michel (a graphics researcher at Adobe) guide to WGPU programming with C++. Just search in Google: eliemichel wgpu And the result will come up.
Raylib is simple. But far from perfect. The problem still is that it "abstracts". In the past it was just write to some mapped memory, and graphics appeared on screen. No abstraction at all. Full understanding of everything that happens. This is still lost even if you use raylib (which is a good library).
@@ovi1326 hardware back then sucked, that's why programs used to be fast... wait a minute... anyways, jokes aside, I think you meant to say that modern software sucks, there, ftfy.
@@ovi1326Hardware didn’t suck back then, it’s the same architecture that we use today. There are just more transistors on the chips. Software on contrary is definitely very bloated and messy.
Yeah, I understand the complaint, but the suggestions he gave are not solutions to the problem. They just forward the problem to someone else to solve.
@@Salabar_Modern cpus are capable of software rendering its just that modern software does too many things on the side to allow you to take advantage of it. There are other operating systems that do not have this problem and they can render things at 60 fps cpu only theyre just so niche nobody uses them.
His positive comments don't get clipped and/or shared to youtube, rants and controversial opinions are what get views on youtube so that's what gets shared
"Use SDL or Raylib instead of opengl" SDL requires raw opengl code to do 3D or shaders, and Raylib is just a wrapper around opengl. I don't really understand what his point is here.. If you want to make games, Raylib is amazing. If you want to learn graphics programming, yeah, no harm in using opengl
The point is that OpenGL is a horrible API. I don't know anything about graphics, but what I think is happening in reality is that CPU sends data to the GPU. How is that more complex than "hey, OS, open to me /dev/gpu/0 for rw" and then you do whatever you want with this file descriptor through whatever library you want is beyond my comprehension.
Game development isn't all about graphics dev, graphics Vulcan, opengl etc are just %5-10 of it at most. If you're an indie, you gotta be as fast as you can to build and ship your game because changes are you will unlikely be successful. You can't waste your time with playing computer graphics in a deep level, either you use pre-made game engines or use raylib etc, or you will have to work at McDonalds to pay your bills.
@@rogo7330that's because gpu vendors don't want to open their architecture datasheet, only THEY develop these APIs that's why they're not truly cross platform and can't perfectly abstracted.
@@rogo7330that would be kinda awesome however that's not how gpu memory works on modern devices. opengl just hides a bunch of complexity by being 20 years in the past hence why there are 8 texture slots and magically shared buffers. what you actually want is vulkan which does give you almost direct control over the memory.
As an indie game dev, I have found OpenGL to be the perfect balance between simplicity and usefulness. Vulkan/DX12 are too much work, I can't be productive when I need to think about so many things. Anything higher-level starts to get into rendering engine territory, and I think making your own rendering engine is important to give your game a unique look & feel.
i haven't found it simple nor useful. I guess it would be useful if it was actually simple but I can't figure out how it works and yes I read the documentation and it sucks ass.
There are no zero cost abstractions. You can use a simple, high level API but you will be trading off performance or control. The better answer is to use the level of abstraction that makes sense for you. Usually, libraries that let you dive deeper when needed are better.
I love OpenGL, I don't really get what point he's trying to make here. I've designed my engine to be somewhat easier to swap the renderer out later on, but I don't think I'll add another API aside from GLES ever. Vulkan gives the graphics programmer control that the driver developer should have, which is why OpenGL drivers are so damn fast
OpenGL apps that used compatibility profile tanked in performance with the use of NVIDIA GTX series graphics cards in 2014 and the general fear is it's going to happen to core profile too once support for the API becomes uninteresting. If the overwhelming majority of people is playing non-OpenGL games, it could well happen. The stranglehold of game engines on devs is not helping, either, since they allow you to upgrade the backing API to something more common pretty much at will.
@@Silencer1337 I hope that doesn't happen, though it's not too unlikely that OpenGL will be removed at some point in the future with some Vulkan based GL compatibility layer being used to make old software work
vulkan is debuggable just use validation layers it's complex but so are modern gpus that's how you do performance it's not complicated - in contrast to opengl, dx11, metal and wgpu it reflects very closely what the gpu is actually going to do, how the data is synchronized and even how to display the output. there's no magic you only need vulkan if you want bare metal performance though and or to learn how gpus work
I would like a vulkan boilerplate. Just one sample implementation that gets you a triangle on the screen. Then I'll poke at all the parts in there to learn things. Instead of trying to climb a huge vertical cliff with a million options hoping I can figure out a path to finally get that triangle. I just want one marked path to a solution that I can experiment with, explore the options and see results.
@@Trezker there's the vulkan tutorial the source code is available for free also there's the vkroots library which does all the boilerplate for you but i havent used it yet so idk
If all you need is to draw a rectangle, nobody's stopping you from using OpenGL 3. It's braindead easy to draw triangles, triangle strips or quads there.
Yep, I think that makes OpenGL a somewhat decent 3D graphics tutorial API. Eg. start with the immediate mode fixed function stuff -> introduce projections -> introduce vertex buffers -> introduce basic shaders, ->.... No need to learn how modern GPUs work in one go, and instead you can basically follow along the same path as GPU architecture development took throughout history.
Even just using WINAPI to draw stuff to your window isn't really that hard. While not exactly braindead easy, as it requires some thinking, and looking up some algorithms, but teaches you how that stuff works under the hood at the same time. And if you struggle with adapting such simple algorithms, it's good practice before the more complex stuff that awaits you once you get into actual graphics programming on top of it. At least, I had a lot of fun with figuring this stuff out on my own for 2D rendering.
we need a bare metal revolution in PCs. I want to see more options that are like powerful game consoles, or single board PCs, no background processes, or OS, just the 1 app at a time in arcade mode, maybe a tiny boot loader menu, giving you 100 percent of your resources. We need a modern version of micro-computers. Every app should not require any libraries, it should be self contained, with all the drivers built into each app, with a region of memory that directly talks with peripherals. I basically want a modern MSX, without any software bloat, strong enough to run AI or modern games, but with open source code and no operating system, just some graphics apis and an example file system to start with, but it should be able to edit all of its own code.
Software rendering exists. You can use a software implementation of OpenGL (or any API) and have full debugging power/access. It won't compete with the GPU but it does have its perks. PortableGL is my contribution to the space and I think it has its uses. I would make a game with it.
We had simpler APIs like GDI and QuickDraw but they were framebuffer only. GPUs are the only practical way to achieve modern rendering for complex geometry/effects, even things like interactive brush strokes in paint programs because artists need large brush sizes. I had hoped OpenGL would refactor but Vulkan took that idea and made a verbose low-level API, and as you've mentioned the GPU and platform vendors prefer developer lock-in. The best thing would be to mimic Unreal Engine's renderer and make a nice API from that, because Epic has figured out the cross-platform stuff.
Honestly I just hope there's some open source JSON-based API in the future to directly talk to GPUs. Preferably written in Java so it can run everywhere, something kind of like a LSP that's just constantly running in the background that you exclusively debug in VS that you can actually step through.
The problem with opengl for me was that you have a single life and you either learn how to do games or learn opengl (at an intermediate level). You cannot have both
The cap is crazy. You can do both. learning the basics of opengl just takes a couple of days(took me a couple of hours to render a triangle, and im terrible at programming). intermidiate stuff i would assume takes months, if your decent in c or c++, and you can make a basic game even with the simple stuff. If your making the next fortnite sure, using the next opengl is a waste. but if your a new dev, you have time for both
Oh, I guess I should stop making my opengl game and learn vulkan instead. /s Yes, the API is old, but so what? My game will work on almost any device, because I'm using ES 2.0 :D Vulkan is HARD and not supported on older devices, DirectX is windows only, Metal is apple-only... OpenGL FTW
What Jon is truly asking for - even if he hasn't reached that conclusion - is not another wrapper, but open hardware. The practical reason to stay on any of these mystery-meat APIs is to satisfy intermediaries like Nvidia, who are perfectly willing to make the experience worse for both users and developers if it means that they have an edge over the competition. The whole gaming-enthusiast sphere amounts to corporate cheerleading. It's not the broader audiences, who just want a standard way for a game to work. And it's not the majority of developers, who want "good enough" 3D support, so they end up with OpenGL, because it is still good enough for what they're doing. As we get more open hardware setting a lowest common denominator, that's bound to change. I mean, I'm already doing it by going the retrocoding route. Agon Light is open enough, programmable enough, for me to feel fine with hacking on it. It's not "genuine" retro, it has a whole ESP32 driving the firmware, but that's actually good in certain ways. The design is about as clean as they come, and if the flavor isn't quite right there are alternatives out there like the rapidly advancing RISC-V space.
To be fair to AMD amd actually publishes the isa of their gpu, and thanks to the open drivers you could potentially do a low level debugger for them. Problem is it would only work on AMD and some older cards have completely different isas....and moreover itś not gonna be simple anyway. GPUs are complex and hinerently parallel
Agreed. The problem is, open hardware can become the norm in 10 years, or in 100, or never. So in the meantime it'd be nice to have a flexible thin wrapper that doesn't need 1500 lines to draw a triangle. What I've enjoyed the most so far is OpenGL compatibility mode.
I don't know about this one. Jonathan Blow just assumes that everybody is an expert in the field and thinks that everything is so easy. Sure, if you do gamedev for as long as he did and live through all of those different technologies that were developed along the way, it all might seem easy. But if you are a student or very early on in your programming career then learning OpenGL just to learn the pipeline and understand how it all works under the hood doesn't seem that bad. Vulkan takes more setup than the actual code that renders a thing on the screen. I guess if you don't care about writing cross platform code then you could start with directX or metal, but OpenGL is still good for learning purposes
sdl is nice because you can use it as a complete libc replacement. it does basic i/o, graphics, sound, input (keyboard, mouse, gamepad etc) cross platform and all of them fairly well
Here is to everyone saying that you need to learn GPU stuff anyway and there is no way around it. For 2D games, drawing bitmaps is not prohibitively slow on CPUs, even with your own code. Even handmade rasterization is pretty fast on CPU. It's even faster if you use AVX stuff. If you need it even faster you can shoehorn in something like threads or CUDA (not sure if there is a hardware agnostic alternative to CUDA). Technically, you do not need to start with learning how to use frame buffers, shader languages, etc. as a beginner gamedev who is learning basic rendering.
He's right. This point is inarguable. There's no good reason why doing something as simple as drawing stuff to the screen should require as much complexity as it does. The fact that it's this difficult to do something this simple means that modern civilization has failed in a very fundamental way.
@@Tezla0 ok? So OpenGL is dead and Vulkan is overkill. What the fuck should people use to make stuff? DirectX - Complicated as Vulkan and no Cross-Platform-Integration? WebGL? For smaller projects OpenGL is great or libraries like wpu. If you want to create a serious game engine, then you might consider Vulkan.
I like OpenGL. It's simple and easy to use. For large games where performance needs to be razorsharp, sure use something more complicated. For a solo dev, use something nice that gets the job done. That way you can focus more on your game than on vulkan api documentation.
100% agree with this view on OpenGL. The issue is that GL is still getting a lot of attention in the newcomer space, and that has a lot to do with educators still using it as a teaching tool across the internet. The other issue is that while OpenGL sucks ass, it is still somehow easier to get into by a newbie compared to Vulkan, which requires the programmer to really get into the standard. I agree that this situation is frustrating. There are some attempts at creating these middlewares between low overhead APIs and high level engines, but they aren't getting well recognized.
Oh, okay. There's no reason to use OpenGL... unless you need to write portable, relatively low level graphics code. But seriously, just pretend you don't have to do that
Well yes, most people don't have to do that. Most people just want to make games or do simple graphics. That's his point - most people have no reason to use OpenGL.
I do empathize with Jonathan here. It is ridiculous how difficult we (as programmers) make it for other programmers to use our stuff. Barring some edge cases, there's no reason why we shouldn't have, as he put it, a drawRect function that just works everywhere and is optimized for all/most cases.
OpenGL isn't a good API, but it is the API that we are Stuck with. That most of us can't question. And like faithful people want to hear all the time that Jesus is the best, we the developers want to hear all the time that the tools that we've chosen, that we are stuck with and can't escape, are the best.
I do respect Jo Blow and his opinion, but if he had something to say, he didn't articulate it very well. Opengl is popular and well documented API, it's cross-platform and relatively simple to use (comparing to something like vulkan), it gets the job done, he uses it himself, raylib uses it under the hood, and learnopengl is a very good starting point to the rendering in general. Instead he provides alternative to use SIMP which is not available for mere mortals like us. If you ultimate goal as a game developer is to just draw something on screen, go ahead and use some engine. But performance heavy games - if you intend to code a clone of minecraft, for example - are almost impossible to write without understanding the GPU graphics well enough, using just the "DRAW A TRIANGLE" option of some magical API. If he is talking about production code... I'm highly skeptical that someone who has authority to choose the graphic API wouldn't know what drawbacks Opengl could have.
"Just draw a rectangle" Sure, but also, any graphics API that doesn't give you full access to the shader capabilities of your GPU is not really worth learning. It's a lot of work to make the basic stuff easy and the complex stuff possible.
Personally I really like GLES, it's a bit like C but it's quite approachable and fun to use. If you want to know more about how things actually work, maybe a good way is to make some things, like make shaders in GLES in whatever language. This way you're not just plugging in PBR textures, you can make things look unique and work the way you want. Saying people should avoid OpenGL is like saying people shouldn't bother learning to drive... from the front seat of your car :)
gpus don't draw rectangles goddamit that's what you got sdl, raylib, allegro, sfml and the game engines for gpu's do float math in parallel and blit triangles and that's why you need a complex api to make them do whatever you want and preferably below 16ms i for one despise opengl but can't call draw rectangle isn't one of it's flaws
@@kennykenken4567 Part of the reason is that GPUs do tile rendering - for a ton of good reasons (Z buffer and stencil and color buffer stay in cache, pixels behind an already drawn solid surface can be discarded...). Drawing a rectangle as a couple of triangles is the correct way to ask the GPU to draw a rectangle - it makes sure the surface gets the correct gradients and correctly goes through tile rendering (and you get the upside - fast Z buffer, discarding of behind the rectangle etc...).
Oh, and if you are on Linux, ditch X11 today and use Wayland. X11 is still very much stuck in that world of graphics primitives and blitter acceleration. Great for 90s systems, not today's. Wayland concerns itself with providing a memory region you can use the GPU to draw into and then compositing that into the final display and punts on literally almost everything else. It's a much more flexible design. Most UI toolkits and graphics libraries will be removing X11 support in the next 5-10 years or so.
I don't think it makes sense to use either imo, just use GLFW or SDL2 with GL or Vulkan. Xlib is awful, but Wayland protocols are even worse to get going in terms of includes etc. (you have to use a strange command-line tool to generate header files _in the make file_ .. just look at the CMake for GLFW, it's awful), so it makes sense to use something like GLFW or SDL2 instead of dealing with those libraries themselves, plus it gives Windows and Mac portability for free as long as you don't use very specific OS features
Seems like you just ignoring the fact that Xorg server running everything through Direct Render Manager. The only issue with Xorg is that it's a mess from hundreds of extensions and it's hard to bring it together apparently. Wayland is dumb shit because they stated "we gonna start from scratch" and now they basically going the same way that X11 is already got through because rendering windows is not just drawing stuff on the screen, but nobody from Wayland party won't listen and continue to do nothing.
@@rogo7330 I'm aware of the relationship between X11 and DRM, thank you very much. And it's a force fit because X was designed for a different graphics paradigm entirely. Wayland was designed to fit better with how the graphics stack actually works now. Whether you think it's dumb shit or not, the fact of the matter is the X maintainers gave up on maintaining X because it was so old and full of legacy cruft, being originally designed for 90s graphics hardware and not modern hardware. Wayland is their solution to that problem. And the GNOME and KDE developers are already considering removing the old X code paths, leaving Wayland as the only path forward for those DEs and toolkits. So if you want to run modern software in a Linux environment, it's going to be Wayland.
WebGPU is the closest we have to a modern, efficient and cross-platform graphics API we have. Despite the name, it's a great API to use in C, C++ or any other language. Other than that, there's one more reason to use OpenGL (or an API that provides OpenGL): web browser support. Specifically, OpenGL ES 3.0 which is well translated to WebGL 2.0.
@@chocolatecoveredgummybears Why not? webgpu is basically a thin compatibility layer with Vulkan, Metal and DX12. That has much less overhead than the typical OpenGL driver.
The mayor problem I see with OpenGL is debugging. Last time I did graphics programming, I had to use Nvidia Nsight (a third party tool) to inspect the contents of the textures and vertex buffers, and it was difficult to setup because it all depended on the graphics driver. Also, I could be wrong, but I don't remember it was possible to debug compiled shaders. This all meant that the debugging could only be done to the CPU code, and nothing could be done on the GPU side (other than pray and hope that, once all the textures and buffers setup, absolutely nothing would go wrong on the GPU). I do agree that if you want to learn low-level graphics programming you'd be better off using the proprietary API for your specific OS (e.g. Direct3D in Windows); you'll save yourself a lot of headaches. However, if you want to write a graphics application that can run on multiple platforms, then OpenGL is the only viable option (even if you're using a wrapper, chances are that you'd still need to know some OpenGL in order to write shaders for that wrapper).
I tried using raylib but it didn't do the one exact thing I needed it to do (batching generated quads) so I had to drop it. Probably better for basic gamedev stuff.
Listening to Jon complain is sometimes worth the wait. I was trying to see what he would actually recommend in place of dealing with OpenGL directly and once he mentioned Raylib I looked it up. It looks based as fuck and exactly what I'm after. Thanks Jon!
OpenGL is one reason why I gave up on 3D programming and game develoment 15 years ago. It just wasn't possible to make a good object oriented model around it (for me, at least). I have started up a hobby project recently, to make a simple game with my son, so that he can learn how it's done. I make it software rendered like it's the 90's again, because it's fun, I can make the code structure the way I want it, and because I want to try things that are not possible on a GPU. A demo I've made runs at more than 3000 FPS in 720p, which I think is pretty insane.
@@seriouscat2231 The standard Windows functions... CreateDIBSection with a memory buffer with pixel values. Then I've written my own rasterizer (like we used to in the 90s).
OpenGL is like that is because it's a Graphics API and it supposed to be low level so you can control each vertices but i agreed that OpenGL error sucks
As usual he doesn’t suggest what we should use instead of OpenGL (raylib is not that). Always just don’t use that, don’t do that… well, what fucking should we do then, John?
Something with a "drawRectangle" function. 🤡 SFML can do that just fine. And it comes with an OpenGL backend. He even admitted that OpenGL is the backend in whatever thing he's working on, "just because it's there". What a hypocrite! 🙄
@@zdspider6778 drawrectangle !! a simple function! it will just have to take 200 arguemnts to properly pass to the gpu everything i might do with the fucking rectangle. Sometimes I think heś an actual moron, he knows that openGL is complicated because gpus are complicated and have a l;ong history, and opening a window with a drawable surface is hard because OS and drawing toolkits are also complex and can´t just give you a random region in your memory and draw it to the screen whenever they feel like it?
As far as I see it, that's his criticism here. There is none. Vulkan is pretty complicated and not supported on a couple platforms (linux is not important for games). OpenGL is supported on (some)platforms but everybody seems to be fed up with it. DirectX is pretty good but only for Windows and XBOX - which is pretty good coverage. WebGL kinda failed - at least that is how I am interpreting the rational for WebGPU. WebGPU like WebGL is much more complicated than needs to be since they must take into consideration async loading from server. Metal is non-relevant for games. Currently only abstraction layers can provide what John would like hence him also building SIMP which is also an abstraction layer. Until graphics cards open up their ISA-s and we can come up with languages for them like for CPU-s I don't expect the situation to improve because nobody gains from having an even playground, everybody is fencing around their own sandbox via these API-s.
@@dreastonbikrain1896 well then how can he say don't learn OpenGL? If you say that you need to tell people what to learn, because learning nothing or learning raylib is certainly worse
@@TheExtremeCubeif you wanna learn something that Is actually used in the industry, learn DirectX 12 or vulkan. But yeah i would not suggest to do that if you know nothing about computer graphics. Those APIs are so convoluted that It took me nearly a month to draw a single triangle. Just start with opengl, learn the fundamental concepts and After you have done that you can move those more modern APIs
@@tonyvisente5286 yeah, I have been using OpenGL for a game I'm making for the past year. It's my first project involving a graphics API, and OpenGL was suggested online as better for beginners than Vulkan so I went with it. I am more so focused on the game than learning something for getting into the industry, though I am interested in learning Vulkan at some point I think.
Khronos is trying to ignore OpenGL as far as I can tell while Vulkan has had a lot of marketing given to it. But even after 8 years(!) it still doesn't feel like there's much love for Vulkan and productivity with it hasn't really improved, sadly. It's not sexy but OpenGL remains the only game in town, if you want to get serious graphics done.
There are already so many projects to try to present a platform-agnostic or API-agnostic layer over the top of all the different options. They exist all over the place. The problem is that none of them have reached any kind of critical mass of acceptance. There aren't any that are THE standard. So people keep making more, like in that XKCD comic.
As long as they're maintained, I don't really see an issue with this. This is more of an issue with things like Wayland & Pipewire, where the idiot devs reinvent the wheel for things that are already working well. Cairo for example seems to still be used extensively in Linux, & it's 20 years old.
bgfx (opengl like shaders) is used in the microsoft minecraft client. using diligent engine rn and its pretty decent (D3D11 but good). all the bells and whistles
The thing probably is, that there seems to be nothing (ie. no standard) in between having a game engine like Unity and using OpenGL directly. Maybe Vulcan will do it. He is right about - Debugging - Having to call too many functions to draw 3D stuff. People always say it's fundamental to know OpenGL. But there is a lot of historical stuff, because people make a difference whether "you tell the machine WHAT to do, not HOW...." But in the same time you need to know HOW to tell OpenGL WHAT to do. Update: Maybe just update the code according to new OpenGL via LLVM
"Having to call to many functions to draw 3d stuff" "maybe vulkan will do it" do you know the Lines of code needed to draw a single triangle in vulkan......
So vulcan doesn't render primitive triangle but starts out with recangle? Or is the problem that vulcan doesn't ensure that bad code breaks? Github link plz.
Id say the best alternative is wgpu or atleast it will be it encourages you to learn how modern graphics work while being a safe place where you can’t really screw stuff up because you don’t have to worry about memory management and synchronization In that way wgpu is the perfect generic hardware agnostic wrapper I absolutely love it and hope to use it more in the future
If you use everything you can with 4.6, adhere to AZDO, use DSA functions and bindless texturing, OpenGL is pretty much the same as an average Vulkan implementation. Only if you have a really good Vulkan implementation or an OpenGL implementation that looks like LearnOpenGL's stuff, then the difference will be huge. If you're solo or part of a small team, Vulkan is NOT worth it.
Is that a bad thing? It should be fairly obvious that he finds problems in things because that is the first step to improving that thing. And before you say "but all he does is complain, he doesn't actually build anything better", remind yourself that he has dedicated years of his life to writing an entirely new low-level language and an engine/library to go with it, with the intention of making something better than C++. So basically, what is your issue? Do you not want to improve things that are bad? Do you not even want other people like Jon to do that for you?
@@slynt_ I'm not aware of his language and engine. Maybe that's the problem. Either his stuff doesn't improve on anything really or he's recycling concepts of other successful languages
@@thanosfisherman How can you say that when you just said you know nothing about his language (Jai)? To start with, it hasn't been finished yet, but there are countless videos and stream VODs on TH-cam where you can learn all about it. Casting a judgment on the language while knowing literally nothing about it makes you seem like an idiot.
OpenGL is horrible but it's insane to expect everyone to use your language. Hell I don't even know how to start using it. I've been doing OpenGL for the past 4 months and hate programming in general at this point because I'm not seeing a fucking point to it nor enough progress and OpenGL is a nightmare to fucking work with and figure out and I hate whoever wrote it's documentation truly and deeply because it's caused me a lot of suffering since I'm stupid enough to think that it should actually explain how it works as opposed to be a masturbatory reference for whoever wrote the shit.
I like Jon, i think he has some great ideas and is doing positive things in the game space. He's a little washy with his opinion on OpenGL here. Debugging anything that is hidden in dll files and drivers is a pain, but the trade off here is its better than writing a graphics library from scratch, and certainly something as rich as OpenGL would be almost certainly impossible to gain access to low level GPU instructions for shaders etc. Opengl might not be the best but its the best we have. And it works with all operating systems including mobile.
This is kind of the stupidest thing I've heard from him. He doesn't really outline any specific problesm with opengl, just that you 'can't call a function and get a triangle'. I mean, I'm glad he's not the one that makes industry decisions. OpenGL is light years better than Vulkan. It's not going away because it's by far the simplest yet most powerful gfx API, and, like, it's not even fucking close. He even admits he uses it. Really braindead take honestly.
His takes are really bad, but GL lightyears better than VK? I understand that Vk is not for beginners, but you get there eventually - from necessity, trying to run away from GL's inherent and unfixable design flaws to develop your own design flaws which can actually be fixed after a finite amount of rewrites if you know what you want from the GPU.
4:28 because GPUs(General Processing Units) are not only used for graphics instead they have very general structures thus harder to program the more general the architecture the harder it gets to program it was easier back then when GPUs were solely graphics processing units
@@zdspider6778 Game development perspective WebGL is lowlevel because there are libraries and engines where you don't think how to draw rectangle, instead you can draw 3D-scene or object from model.
Why would we be using anything other than the objectively best language in existence? Unless we're just fooling around or doing statistics in Python, I suppose. I'll admit, Python is handy to use as a calculator when I'm working in a terminal.
Raylib is huge, too. I looked at it. It's nice, but it's huge. That's because it's a wrapper for a large surface of stuff. There's no getting around that it's a large surface. Also, one does not simply draw stuff to the screen. Maybe back in the 80s and early 90s, when you had stuff like writing directly to a framebuffer, or using graphics primitives like arc, line, polyline, rectangle, fill, etc. You can still do that today with the CPU, but all you will do is waste electricity and contribute to global warming, AND it will be slow. To draw stuff to the screen today, you need to use the specialized drawing computer inside your computer -- the GPU. Which means you have to write shaders, allocate memory for the resources the GPU needs in order to draw your screen, and then send commands to the GPU. You have to think about overdraw, you have to think about when to calculate vs. looking up in memory. It's not the 90s anymore, graphics pipelines are hard, embrace the suck. For a good user-facing graphics API, use Direct3D. If you're on Linux, use one of the wrappers like DXVK. OpenGL is indeed bad.
If you're that upset about it you need to stop making TH-cam videos. OpenGL is a great way to start learning the fundamentals without the complexity of Vulkan. Like it or not, there are far more novices than professionals in the world, and OpenGL is fairly easy to get your head around as a novice. And by sheer percentages, if you're going to post TH-cam videos or do live streaming, you're going to attract more novices than professionals.
Nobody tell him we barely know how to properly write to terminals now. Just a bit more before we mess up writing to files too.
Sad truth
@@Rand0081sad? not everyone has to suffer learning vim or emacs
I'm pretty sure this isn't a problem unique to the current year it's just people tend to reach out for naive solutions
also are you a windows user cause on real OSes the trivial solution is very near optimal
"before we mess up writing to files too"
Ever heard of the "fsync surprise"? That fun moment in 2018 when database developers realized that writing data to disk without getting errors didn't guarantee that there were no errors, just that none were reported.
JB be like:
don't use OpenGL
- unless you're interested in getting things done
- and also I use it
exactly
Yeah. The stupidest thing I've heard from him
As I understand it: He's using it because he's creating a wrapper, so that we don't have to use it directly.
It's more like "don't learn OpenGL", "you're too preoccupied with OpenGL".
OpenGL is quite literally becoming an obsolete graphics API and there are numerous platforms natively targeting Vulkan and DirectX and not even providing an OpenGL layer, the OpenGL layer is translation. One of those two cross-platform and both have translation layers for everything. Even on Linux the preferred API is EGL or Vulkan if you can muster it. OpenGL is super dead
he's saying it has no future, which ig may also be one of the reasons the same group went on to make vulkan
The problem with OpenGL as Jon gets around to here, is that it's not ideal, but easier and more cross-platform than everything else. 😆 I like OpenGL a lot, I know, I'm an asshole. But notice how Vulkan isn't mentioned.. Metal is Apple only and DirectX is Windows only. -Remember, AMD did JUST overhaul their OpenGL driver code last year and sped it up and made it closer to standard. Meanwhile Nvidia has added Mesh Shaders to OpengGL recently - without bumping up the OpenGL version. OpenGL is still supported and will be for a long, long, long, time.
yeah compared to vulkan, opengl even with all the DSA, bindless, compute and other whistles is still far easier to manage.
vulkan can arguably reach more platforms
Vulkan requires a substantial minimum hardware spec. It’s not as cheap as it looks.
sadly, Apple support is barely there. 4.1 core, freely violates standard in some places, and you can't even debug it properly without debug utils. Metal is a pretty good API though, it fits right in between DX11 and DX12 in terms of abstraction level
2:20 nobody tell him that if you are A using linux and B using AMD OR Intel, the opengl graphics driver is fully open source and absolutely can be debugged
I am happy Jonathan mentioned raylib! It's a very nice lib without much fuzz
It could be awesome but it has some flaws and looks like the creator doesn't care.
@@alvarohigino What are the flaws?
@@alvarohigino The flaws have yet to be found to this day.
@@anG_3L404 I think people find the 3d support a bit lacking. That was the only complaint I can really think of but I haven't really used raylib for 3d so can't say for sure.
I love Raylib and I'm currently at the tail end of making a game in Raylib and unsafe Rust, but one problem is that Raylib chooses to target the integrated graphics card over the dedicated graphics card and Raysan seems to think this is fine. I now have to figure out how to fix this, which from some reading I think means changing a row of code in the Raylib source code.
Opengl Is a good tool to learn graphics basics.
I don't find It particularly useful to spend 30 hours just to setup a vulkan pipeline to draw a single triangle if you know nothing about computer graphics.
Very true, atleast do it in OGL first, so then it u kinda understand the pipeline
@@jason_m2003honestly, it's probably best to write a software rasterizer first to learn the basics of the graphics pipeline rather than using any of the api's
He is a dumb man
@@jason_m2003 opengl won't you truly teach how things going on really. It gives you a bunch of function calls that's it, even Vulcan can't teach you that truly, you need to join a company like AMD or Nvidia to understand doing these kind of things.
The point isn't that you don't get your stuff done. The point is, that using the API doesn't give you a very good understanding of how things actually work under the hood.
Raylib creates a window on any OS, abstracts the graphics card and gives you input on keyboard, phone, controller, and VR. You then write code to make game. Done.
And if you want to know how it works, go read the source.
But is Raylib a good library for learning the fundamentals of graphics programming like OpenGL?
@@kasufertfor that you better check WGPU or BGFX.
People should check Elie Michel (a graphics researcher at Adobe) guide to WGPU programming with C++.
Just search in Google:
eliemichel wgpu
And the result will come up.
yes
Raylib is simple. But far from perfect. The problem still is that it "abstracts". In the past it was just write to some mapped memory, and graphics appeared on screen. No abstraction at all. Full understanding of everything that happens. This is still lost even if you use raylib (which is a good library).
I mean you can read the source ¯\_(ツ)_/¯
Last time i knew how to draw a triangle on the screen i was using Pascal
as a young programmer I surely admire the simplicity from before
@@sournois90hardware back then sucked that's why coding it was simple, just learn how modern hardware works you're not going to regret it
@@ovi1326 hardware back then sucked, that's why programs used to be fast... wait a minute... anyways, jokes aside, I think you meant to say that modern software sucks, there, ftfy.
I was using ms paint
@@ovi1326Hardware didn’t suck back then, it’s the same architecture that we use today. There are just more transistors on the chips. Software on contrary is definitely very bloated and messy.
Jon's amazing solution to graphics API's is to make a wrapper.. Much like the bazillion other OpenGL/Vulkan wrappers! Brilliant!
Vulkan wrappers tend to be "D3D11, but worse". There is definitely a niche for "OpenGL 3.3, but good" kind of library.
Yeah, I understand the complaint, but the suggestions he gave are not solutions to the problem. They just forward the problem to someone else to solve.
That’s not what he said at all. He said it’s a temporary solution to the bigger problem that is the APIs themselves.
@@captainfordo1 I guess in 30 years or so CPUs will become good enough to use software rendering again, but this is not on the cards yet.
@@Salabar_Modern cpus are capable of software rendering its just that modern software does too many things on the side to allow you to take advantage of it. There are other operating systems that do not have this problem and they can render things at 60 fps cpu only theyre just so niche nobody uses them.
Can someone link me to 3 videos where Johnathon blow says something positive about anything?
They’re all about Jai
th-cam.com/users/shortsIdvYk45xRPo
There’s one where he is positive about his water filer he bought for $400 on Amazon
His positive comments don't get clipped and/or shared to youtube, rants and controversial opinions are what get views on youtube so that's what gets shared
He's a doomer clown
"Use SDL or Raylib instead of opengl" SDL requires raw opengl code to do 3D or shaders, and Raylib is just a wrapper around opengl. I don't really understand what his point is here..
If you want to make games, Raylib is amazing. If you want to learn graphics programming, yeah, no harm in using opengl
The point is that OpenGL is a horrible API. I don't know anything about graphics, but what I think is happening in reality is that CPU sends data to the GPU. How is that more complex than "hey, OS, open to me /dev/gpu/0 for rw" and then you do whatever you want with this file descriptor through whatever library you want is beyond my comprehension.
Game development isn't all about graphics dev, graphics Vulcan, opengl etc are just %5-10 of it at most.
If you're an indie, you gotta be as fast as you can to build and ship your game because changes are you will unlikely be successful. You can't waste your time with playing computer graphics in a deep level, either you use pre-made game engines or use raylib etc, or you will have to work at McDonalds to pay your bills.
@@rogo7330that's because gpu vendors don't want to open their architecture datasheet, only THEY develop these APIs that's why they're not truly cross platform and can't perfectly abstracted.
@@rogo7330that would be kinda awesome however that's not how gpu memory works on modern devices. opengl just hides a bunch of complexity by being 20 years in the past hence why there are 8 texture slots and magically shared buffers. what you actually want is vulkan which does give you almost direct control over the memory.
@@rogo7330I love the idea of exposing the gpu as a generic unix device, it's just gpus are too complex for that kind of api to be useful.
As an indie game dev, I have found OpenGL to be the perfect balance between simplicity and usefulness. Vulkan/DX12 are too much work, I can't be productive when I need to think about so many things. Anything higher-level starts to get into rendering engine territory, and I think making your own rendering engine is important to give your game a unique look & feel.
i haven't found it simple nor useful. I guess it would be useful if it was actually simple but I can't figure out how it works and yes I read the documentation and it sucks ass.
There are no zero cost abstractions. You can use a simple, high level API but you will be trading off performance or control. The better answer is to use the level of abstraction that makes sense for you. Usually, libraries that let you dive deeper when needed are better.
That's far too much nuance for Jon's tiny brain
time to go back to borland graphics.h....
I was actually taught Borland graphics.h in college as a computer engineer... in 2018...
@@snipdeathwtf
great times ❤
Story teller way to end a tale: "...and everyone lives happily ever after..."
JB: 😫😩
what? 🤪
"This is so stupid!" - Blow, Jonathan.
I love OpenGL, I don't really get what point he's trying to make here. I've designed my engine to be somewhat easier to swap the renderer out later on, but I don't think I'll add another API aside from GLES ever. Vulkan gives the graphics programmer control that the driver developer should have, which is why OpenGL drivers are so damn fast
OpenGL apps that used compatibility profile tanked in performance with the use of NVIDIA GTX series graphics cards in 2014 and the general fear is it's going to happen to core profile too once support for the API becomes uninteresting. If the overwhelming majority of people is playing non-OpenGL games, it could well happen. The stranglehold of game engines on devs is not helping, either, since they allow you to upgrade the backing API to something more common pretty much at will.
@@Silencer1337 I hope that doesn't happen, though it's not too unlikely that OpenGL will be removed at some point in the future with some Vulkan based GL compatibility layer being used to make old software work
I have been learning Vulkan and god it's so complicated, finickly and error prone, whoever designed it really hated people.
@Cakez has a really fast vulkan tutorial four ~30 min videos to render a triangle
vulkan is debuggable just use validation layers
it's complex but so are modern gpus that's how you do performance
it's not complicated - in contrast to opengl, dx11, metal and wgpu it reflects very closely what the gpu is actually going to do, how the data is synchronized and even how to display the output. there's no magic
you only need vulkan if you want bare metal performance though and or to learn how gpus work
Yes. The brilliance of OpenGL takes an experience like this to understand.
I would like a vulkan boilerplate. Just one sample implementation that gets you a triangle on the screen. Then I'll poke at all the parts in there to learn things. Instead of trying to climb a huge vertical cliff with a million options hoping I can figure out a path to finally get that triangle. I just want one marked path to a solution that I can experiment with, explore the options and see results.
@@Trezker there's the vulkan tutorial the source code is available for free
also there's the vkroots library which does all the boilerplate for you but i havent used it yet so idk
If all you need is to draw a rectangle, nobody's stopping you from using OpenGL 3. It's braindead easy to draw triangles, triangle strips or quads there.
or even good old 1.1 fixed pipeline style for that matter, its still there and it still works
Yep, I think that makes OpenGL a somewhat decent 3D graphics tutorial API. Eg. start with the immediate mode fixed function stuff -> introduce projections -> introduce vertex buffers -> introduce basic shaders, ->.... No need to learn how modern GPUs work in one go, and instead you can basically follow along the same path as GPU architecture development took throughout history.
I love legacy GL. Although I use glad 2.0 to get vertex buffer objects for performance (could do it with extensions but that feels weird).@@ekshalibur
Even just using WINAPI to draw stuff to your window isn't really that hard. While not exactly braindead easy, as it requires some thinking, and looking up some algorithms, but teaches you how that stuff works under the hood at the same time.
And if you struggle with adapting such simple algorithms, it's good practice before the more complex stuff that awaits you once you get into actual graphics programming on top of it.
At least, I had a lot of fun with figuring this stuff out on my own for 2D rendering.
we need a bare metal revolution in PCs. I want to see more options that are like powerful game consoles, or single board PCs, no background processes, or OS, just the 1 app at a time in arcade mode, maybe a tiny boot loader menu, giving you 100 percent of your resources. We need a modern version of micro-computers. Every app should not require any libraries, it should be self contained, with all the drivers built into each app, with a region of memory that directly talks with peripherals. I basically want a modern MSX, without any software bloat, strong enough to run AI or modern games, but with open source code and no operating system, just some graphics apis and an example file system to start with, but it should be able to edit all of its own code.
I like this idea. Not sure of the practicality of it, but it's a cool idea.
seems like WGPU (and WGPU-native for c/c++) is close to being what jonathan describes here (although still a bit complex)
More like sokol_gfx.h :)
Jon has already said that WGPU is dead on arrival and not a good API at all.
@captainfordo1 Why?
@@captainfordo1then which is good one?
@@captainfordo1i'd be curious to hear why, I only did a really small project with it, but it seemed way more simple than vulkan
Poor guy is going crazy from this.
Based on what he's saying here, it's not just OpenGL, it's virtually all APIs that are the problem.
Software rendering exists. You can use a software implementation of OpenGL (or any API) and have full debugging power/access.
It won't compete with the GPU but it does have its perks.
PortableGL is my contribution to the space and I think it has its uses. I would make a game with it.
We had simpler APIs like GDI and QuickDraw but they were framebuffer only. GPUs are the only practical way to achieve modern rendering for complex geometry/effects, even things like interactive brush strokes in paint programs because artists need large brush sizes. I had hoped OpenGL would refactor but Vulkan took that idea and made a verbose low-level API, and as you've mentioned the GPU and platform vendors prefer developer lock-in. The best thing would be to mimic Unreal Engine's renderer and make a nice API from that, because Epic has figured out the cross-platform stuff.
Honestly I just hope there's some open source JSON-based API in the future to directly talk to GPUs. Preferably written in Java so it can run everywhere, something kind of like a LSP that's just constantly running in the background that you exclusively debug in VS that you can actually step through.
true
hahahahhaha
I can't imagine throwing json-s arround when talking to a card would be acceptable performance wise.
JSON? Java? VS? Barf!
Sounds good but you have to be tripping if you suggest Json and Java for the gpu
The problem with opengl for me was that you have a single life and you either learn how to do games or learn opengl (at an intermediate level). You cannot have both
You don't need to learn it at an advanced level to make good games.
The cap is crazy. You can do both. learning the basics of opengl just takes a couple of days(took me a couple of hours to render a triangle, and im terrible at programming).
intermidiate stuff i would assume takes months, if your decent in c or c++, and you can make a basic game even with the simple stuff. If your making the next fortnite sure, using the next opengl is a waste. but if your a new dev, you have time for both
Oh, I guess I should stop making my opengl game and learn vulkan instead. /s
Yes, the API is old, but so what? My game will work on almost any device, because I'm using ES 2.0 :D
Vulkan is HARD and not supported on older devices, DirectX is windows only, Metal is apple-only...
OpenGL FTW
What Jon is truly asking for - even if he hasn't reached that conclusion - is not another wrapper, but open hardware. The practical reason to stay on any of these mystery-meat APIs is to satisfy intermediaries like Nvidia, who are perfectly willing to make the experience worse for both users and developers if it means that they have an edge over the competition. The whole gaming-enthusiast sphere amounts to corporate cheerleading. It's not the broader audiences, who just want a standard way for a game to work. And it's not the majority of developers, who want "good enough" 3D support, so they end up with OpenGL, because it is still good enough for what they're doing.
As we get more open hardware setting a lowest common denominator, that's bound to change. I mean, I'm already doing it by going the retrocoding route. Agon Light is open enough, programmable enough, for me to feel fine with hacking on it. It's not "genuine" retro, it has a whole ESP32 driving the firmware, but that's actually good in certain ways. The design is about as clean as they come, and if the flavor isn't quite right there are alternatives out there like the rapidly advancing RISC-V space.
To be fair to AMD amd actually publishes the isa of their gpu, and thanks to the open drivers you could potentially do a low level debugger for them. Problem is it would only work on AMD and some older cards have completely different isas....and moreover itś not gonna be simple anyway. GPUs are complex and hinerently parallel
Agreed. The problem is, open hardware can become the norm in 10 years, or in 100, or never. So in the meantime it'd be nice to have a flexible thin wrapper that doesn't need 1500 lines to draw a triangle. What I've enjoyed the most so far is OpenGL compatibility mode.
I think webgpu is good alternative to opengl for indie devs who just want to put stuff on the screen
I don't know about this one. Jonathan Blow just assumes that everybody is an expert in the field and thinks that everything is so easy. Sure, if you do gamedev for as long as he did and live through all of those different technologies that were developed along the way, it all might seem easy. But if you are a student or very early on in your programming career then learning OpenGL just to learn the pipeline and understand how it all works under the hood doesn't seem that bad. Vulkan takes more setup than the actual code that renders a thing on the screen. I guess if you don't care about writing cross platform code then you could start with directX or metal, but OpenGL is still good for learning purposes
sdl is nice because you can use it as a complete libc replacement. it does basic i/o, graphics, sound, input (keyboard, mouse, gamepad etc) cross platform and all of them fairly well
i'm putting my eggs in the sdl3 basket. if their take on a graphics api wrapper is solid it'll be my one-stop shop.
Here is to everyone saying that you need to learn GPU stuff anyway and there is no way around it.
For 2D games, drawing bitmaps is not prohibitively slow on CPUs, even with your own code. Even handmade rasterization is pretty fast on CPU. It's even faster if you use AVX stuff. If you need it even faster you can shoehorn in something like threads or CUDA (not sure if there is a hardware agnostic alternative to CUDA). Technically, you do not need to start with learning how to use frame buffers, shader languages, etc. as a beginner gamedev who is learning basic rendering.
He's right. This point is inarguable. There's no good reason why doing something as simple as drawing stuff to the screen should require as much complexity as it does. The fact that it's this difficult to do something this simple means that modern civilization has failed in a very fundamental way.
You can learn OpenGL in order to learn the basics of Vulkan. Starting with Vulkan or something similar is a bit overkill
Vulkan itself is overkill. Using it is a torture
@@Tezla0 ok? So OpenGL is dead and Vulkan is overkill. What the fuck should people use to make stuff? DirectX - Complicated as Vulkan and no Cross-Platform-Integration? WebGL?
For smaller projects OpenGL is great or libraries like wpu. If you want to create a serious game engine, then you might consider Vulkan.
I feel this in the core of my being.
I like OpenGL. It's simple and easy to use. For large games where performance needs to be razorsharp, sure use something more complicated. For a solo dev, use something nice that gets the job done. That way you can focus more on your game than on vulkan api documentation.
100% agree with this view on OpenGL. The issue is that GL is still getting a lot of attention in the newcomer space, and that has a lot to do with educators still using it as a teaching tool across the internet. The other issue is that while OpenGL sucks ass, it is still somehow easier to get into by a newbie compared to Vulkan, which requires the programmer to really get into the standard. I agree that this situation is frustrating. There are some attempts at creating these middlewares between low overhead APIs and high level engines, but they aren't getting well recognized.
Oh, okay. There's no reason to use OpenGL... unless you need to write portable, relatively low level graphics code.
But seriously, just pretend you don't have to do that
Well yes, most people don't have to do that. Most people just want to make games or do simple graphics. That's his point - most people have no reason to use OpenGL.
I do empathize with Jonathan here. It is ridiculous how difficult we (as programmers) make it for other programmers to use our stuff. Barring some edge cases, there's no reason why we shouldn't have, as he put it, a drawRect function that just works everywhere and is optimized for all/most cases.
OpenGL isn't a good API, but it is the API that we are Stuck with. That most of us can't question. And like faithful people want to hear all the time that Jesus is the best, we the developers want to hear all the time that the tools that we've chosen, that we are stuck with and can't escape, are the best.
I would disagree-I think it is a brilliant state hiding simple API.
But yes-it is weird and annoying and bizarre as heck.
I do respect Jo Blow and his opinion, but if he had something to say, he didn't articulate it very well. Opengl is popular and well documented API, it's cross-platform and relatively simple to use (comparing to something like vulkan), it gets the job done, he uses it himself, raylib uses it under the hood, and learnopengl is a very good starting point to the rendering in general. Instead he provides alternative to use SIMP which is not available for mere mortals like us.
If you ultimate goal as a game developer is to just draw something on screen, go ahead and use some engine. But performance heavy games - if you intend to code a clone of minecraft, for example - are almost impossible to write without understanding the GPU graphics well enough, using just the "DRAW A TRIANGLE" option of some magical API.
If he is talking about production code... I'm highly skeptical that someone who has authority to choose the graphic API wouldn't know what drawbacks Opengl could have.
"Do not learn OpenGL". Ok, then I will learn WebGL. 😄
Someone tell blow that you can use renderdoc to debug whatever you're doing in opengl
"Just draw a rectangle"
Sure, but also, any graphics API that doesn't give you full access to the shader capabilities of your GPU is not really worth learning. It's a lot of work to make the basic stuff easy and the complex stuff possible.
Personally I really like GLES, it's a bit like C but it's quite approachable and fun to use. If you want to know more about how things actually work, maybe a good way is to make some things, like make shaders in GLES in whatever language. This way you're not just plugging in PBR textures, you can make things look unique and work the way you want. Saying people should avoid OpenGL is like saying people shouldn't bother learning to drive... from the front seat of your car :)
gpus don't draw rectangles goddamit that's what you got sdl, raylib, allegro, sfml and the game engines for
gpu's do float math in parallel and blit triangles and that's why you need a complex api to make them do whatever you want and preferably below 16ms
i for one despise opengl but can't call draw rectangle isn't one of it's flaws
OK...why not just let us programmers worry about doing the parallel math and give us back the control of easier pixel drawing?
@@kennykenken4567 you can do easy pixel drawing perfectly fine on a cpu
@@kennykenken4567 Part of the reason is that GPUs do tile rendering - for a ton of good reasons (Z buffer and stencil and color buffer stay in cache, pixels behind an already drawn solid surface can be discarded...). Drawing a rectangle as a couple of triangles is the correct way to ask the GPU to draw a rectangle - it makes sure the surface gets the correct gradients and correctly goes through tile rendering (and you get the upside - fast Z buffer, discarding of behind the rectangle etc...).
Oh, and if you are on Linux, ditch X11 today and use Wayland. X11 is still very much stuck in that world of graphics primitives and blitter acceleration. Great for 90s systems, not today's. Wayland concerns itself with providing a memory region you can use the GPU to draw into and then compositing that into the final display and punts on literally almost everything else. It's a much more flexible design. Most UI toolkits and graphics libraries will be removing X11 support in the next 5-10 years or so.
wayland adds a couple frames of latency which is bad for games. also it's missing some X features.
I don't think it makes sense to use either imo, just use GLFW or SDL2 with GL or Vulkan. Xlib is awful, but Wayland protocols are even worse to get going in terms of includes etc. (you have to use a strange command-line tool to generate header files _in the make file_ .. just look at the CMake for GLFW, it's awful), so it makes sense to use something like GLFW or SDL2 instead of dealing with those libraries themselves, plus it gives Windows and Mac portability for free as long as you don't use very specific OS features
Seems like you just ignoring the fact that Xorg server running everything through Direct Render Manager. The only issue with Xorg is that it's a mess from hundreds of extensions and it's hard to bring it together apparently. Wayland is dumb shit because they stated "we gonna start from scratch" and now they basically going the same way that X11 is already got through because rendering windows is not just drawing stuff on the screen, but nobody from Wayland party won't listen and continue to do nothing.
@@rogo7330 I'm aware of the relationship between X11 and DRM, thank you very much. And it's a force fit because X was designed for a different graphics paradigm entirely. Wayland was designed to fit better with how the graphics stack actually works now. Whether you think it's dumb shit or not, the fact of the matter is the X maintainers gave up on maintaining X because it was so old and full of legacy cruft, being originally designed for 90s graphics hardware and not modern hardware. Wayland is their solution to that problem. And the GNOME and KDE developers are already considering removing the old X code paths, leaving Wayland as the only path forward for those DEs and toolkits. So if you want to run modern software in a Linux environment, it's going to be Wayland.
Wayland is horrible and no serious distro would ever use it. Read "Wayland isn't going to save the Linux Desktop" by dudemanguy.
WebGPU is the closest we have to a modern, efficient and cross-platform graphics API we have. Despite the name, it's a great API to use in C, C++ or any other language. Other than that, there's one more reason to use OpenGL (or an API that provides OpenGL): web browser support. Specifically, OpenGL ES 3.0 which is well translated to WebGL 2.0.
LOL no
@@chocolatecoveredgummybears No what? Please elaborate.
@@DiThi webgpu being modern and efficient. just no
@@chocolatecoveredgummybears Why not? webgpu is basically a thin compatibility layer with Vulkan, Metal and DX12. That has much less overhead than the typical OpenGL driver.
@@DiThi you web shills are wild. go fiddle and keep shipping your "software" in electron. we will truly transcend as a species with that mindset
The mayor problem I see with OpenGL is debugging. Last time I did graphics programming, I had to use Nvidia Nsight (a third party tool) to inspect the contents of the textures and vertex buffers, and it was difficult to setup because it all depended on the graphics driver. Also, I could be wrong, but I don't remember it was possible to debug compiled shaders. This all meant that the debugging could only be done to the CPU code, and nothing could be done on the GPU side (other than pray and hope that, once all the textures and buffers setup, absolutely nothing would go wrong on the GPU). I do agree that if you want to learn low-level graphics programming you'd be better off using the proprietary API for your specific OS (e.g. Direct3D in Windows); you'll save yourself a lot of headaches. However, if you want to write a graphics application that can run on multiple platforms, then OpenGL is the only viable option (even if you're using a wrapper, chances are that you'd still need to know some OpenGL in order to write shaders for that wrapper).
Never heard something smart and understandable by this guy.
I tried using raylib but it didn't do the one exact thing I needed it to do (batching generated quads) so I had to drop it. Probably better for basic gamedev stuff.
I understand his frustration with Opengl.
It's not the same as 15 years ago where Opengl is much simpler and more straight forward
MSX basic does it. What went wrong?
In parallel universe J Blow whines about api being too simplistic, so he cant write code in gpu-favourable way
Vulkan is potentially faster than OpenGL, but is *your* Vulkan code faster?
facts
Listening to Jon complain is sometimes worth the wait. I was trying to see what he would actually recommend in place of dealing with OpenGL directly and once he mentioned Raylib I looked it up. It looks based as fuck and exactly what I'm after. Thanks Jon!
directx hasn't taken over the world in the end
It must hurt to be this incorrect.
OpenGL is one reason why I gave up on 3D programming and game develoment 15 years ago. It just wasn't possible to make a good object oriented model around it (for me, at least).
I have started up a hobby project recently, to make a simple game with my son, so that he can learn how it's done. I make it software rendered like it's the 90's again, because it's fun, I can make the code structure the way I want it, and because I want to try things that are not possible on a GPU. A demo I've made runs at more than 3000 FPS in 720p, which I think is pretty insane.
Wow, frames for the whole family 😀Was the hobby project also in OpenGL?
@@GreenwooddPop No, software rendered... Custom made.
That's on os vendors to give us draw call functions but they don't that.
@@alexanderhugestrand, in Windows? Using what?
@@seriouscat2231 The standard Windows functions... CreateDIBSection with a memory buffer with pixel values. Then I've written my own rasterizer (like we used to in the 90s).
4:06 for real
Guys hear me out! OpenGL compatibility mode!
OpenGL is like that is because it's a Graphics API and it supposed to be low level
so you can control each vertices but i agreed that OpenGL error sucks
If you want just learn OpenGL do whatever you want...
As usual he doesn’t suggest what we should use instead of OpenGL (raylib is not that). Always just don’t use that, don’t do that… well, what fucking should we do then, John?
Something with a "drawRectangle" function. 🤡
SFML can do that just fine. And it comes with an OpenGL backend.
He even admitted that OpenGL is the backend in whatever thing he's working on, "just because it's there". What a hypocrite! 🙄
@@zdspider6778 drawrectangle !! a simple function! it will just have to take 200 arguemnts to properly pass to the gpu everything i might do with the fucking rectangle. Sometimes I think heś an actual moron, he knows that openGL is complicated because gpus are complicated and have a l;ong history, and opening a window with a drawable surface is hard because OS and drawing toolkits are also complex and can´t just give you a random region in your memory and draw it to the screen whenever they feel like it?
If you want to make games, use literally anything else. If you want to do low level graphics programming, consider a new line of work.
@@dreambuffer Why?
He did not give a good alternative to OpenGL, relying on someones abstraction like raylib is not it
As far as I see it, that's his criticism here. There is none.
Vulkan is pretty complicated and not supported on a couple platforms (linux is not important for games).
OpenGL is supported on (some)platforms but everybody seems to be fed up with it.
DirectX is pretty good but only for Windows and XBOX - which is pretty good coverage.
WebGL kinda failed - at least that is how I am interpreting the rational for WebGPU.
WebGPU like WebGL is much more complicated than needs to be since they must take into consideration async loading from server.
Metal is non-relevant for games.
Currently only abstraction layers can provide what John would like hence him also building SIMP which is also an abstraction layer. Until graphics cards open up their ISA-s and we can come up with languages for them like for CPU-s I don't expect the situation to improve because nobody gains from having an even playground, everybody is fencing around their own sandbox via these API-s.
@@dreastonbikrain1896 well then how can he say don't learn OpenGL? If you say that you need to tell people what to learn, because learning nothing or learning raylib is certainly worse
@@TheExtremeCubeif you wanna learn something that Is actually used in the industry, learn DirectX 12 or vulkan.
But yeah i would not suggest to do that if you know nothing about computer graphics.
Those APIs are so convoluted that It took me nearly a month to draw a single triangle.
Just start with opengl, learn the fundamental concepts and After you have done that you can move those more modern APIs
@@tonyvisente5286 yeah, I have been using OpenGL for a game I'm making for the past year. It's my first project involving a graphics API, and OpenGL was suggested online as better for beginners than Vulkan so I went with it. I am more so focused on the game than learning something for getting into the industry, though I am interested in learning Vulkan at some point I think.
Khronos is trying to ignore OpenGL as far as I can tell while Vulkan has had a lot of marketing given to it. But even after 8 years(!) it still doesn't feel like there's much love for Vulkan and productivity with it hasn't really improved, sadly. It's not sexy but OpenGL remains the only game in town, if you want to get serious graphics done.
I needed this clip. I'm just trying to learn the code and constantly asking chatGPT "how would I draw a pixel to the screen" and getting nowhere
When did he say that? (Nvm just saw the end)
Ideas in the future : make simp C wrapper, so people can port it to another language.
I rather use Vulkan but I also don't want to write 800 lines of code to draw a static triangle...
so we are going to ignore the obvious benefits of have almost direct access to the hardware or convenience of use?
>It is so complicated to draw a rectangle on the screen
>Didn't even mention Vulkan
4:35 the gist of it
Seems like a meme in the making.
Compared to directx opengl looks like it was sent by gods, IMHO.
There are already so many projects to try to present a platform-agnostic or API-agnostic layer over the top of all the different options. They exist all over the place. The problem is that none of them have reached any kind of critical mass of acceptance. There aren't any that are THE standard. So people keep making more, like in that XKCD comic.
As long as they're maintained, I don't really see an issue with this. This is more of an issue with things like Wayland & Pipewire, where the idiot devs reinvent the wheel for things that are already working well. Cairo for example seems to still be used extensively in Linux, & it's 20 years old.
bgfx (opengl like shaders) is used in the microsoft minecraft client. using diligent engine rn and its pretty decent (D3D11 but good). all the bells and whistles
The thing probably is, that there seems to be nothing (ie. no standard) in between having a game engine like Unity and using OpenGL directly. Maybe Vulcan will do it. He is right about
- Debugging
- Having to call too many functions to draw 3D stuff.
People always say it's fundamental to know OpenGL. But there is a lot of historical stuff, because people make a difference whether "you tell the machine WHAT to do, not HOW...." But in the same time you need to know HOW to tell OpenGL WHAT to do.
Update: Maybe just update the code according to new OpenGL via LLVM
"Having to call to many functions to draw 3d stuff" "maybe vulkan will do it" do you know the Lines of code needed to draw a single triangle in vulkan......
@@zackwumpus9364 no
1000 lines of code for a basic triangle, sometimes more. im not even joking. opengl is like 100.@@Babaelow
So vulcan doesn't render primitive triangle but starts out with recangle? Or is the problem that vulcan doesn't ensure that bad code breaks? Github link plz.
Id say the best alternative is wgpu or atleast it will be
it encourages you to learn how modern graphics work while being a safe place where you can’t really screw stuff up because you don’t have to worry about memory management and synchronization
In that way wgpu is the perfect generic hardware agnostic wrapper
I absolutely love it and hope to use it more in the future
Bevy and wgpu makes this wayy better . See the new material extensions its lit
This is why silicon graphics went bankrupt
If you use everything you can with 4.6, adhere to AZDO, use DSA functions and bindless texturing, OpenGL is pretty much the same as an average Vulkan implementation. Only if you have a really good Vulkan implementation or an OpenGL implementation that looks like LearnOpenGL's stuff, then the difference will be huge. If you're solo or part of a small team, Vulkan is NOT worth it.
OpenGL is a best thing that humanity invented
It really isn’t. It’s a horribly designed API, and the only reason it’s popular is because it’s cross platform.
Anyone used llgl? Seems good.
wgpu is this exact thing he'd describing
I guess asking for Vulkan is out of the question
This guy exists to find problems to everything
Is that a bad thing? It should be fairly obvious that he finds problems in things because that is the first step to improving that thing. And before you say "but all he does is complain, he doesn't actually build anything better", remind yourself that he has dedicated years of his life to writing an entirely new low-level language and an engine/library to go with it, with the intention of making something better than C++.
So basically, what is your issue? Do you not want to improve things that are bad? Do you not even want other people like Jon to do that for you?
@@slynt_ I'm not aware of his language and engine. Maybe that's the problem. Either his stuff doesn't improve on anything really or he's recycling concepts of other successful languages
@@thanosfisherman How can you say that when you just said you know nothing about his language (Jai)? To start with, it hasn't been finished yet, but there are countless videos and stream VODs on TH-cam where you can learn all about it. Casting a judgment on the language while knowing literally nothing about it makes you seem like an idiot.
@@slynt_right lets wait and see then if the Jai thing becomes yet another toy experiment on the pile of useless, needless programming languages.
4:25 I dunno, ask IBM, they have the patent for it
Hahaha. Yeah Vulkin is so great lol.
OpenGL is horrible but it's insane to expect everyone to use your language. Hell I don't even know how to start using it. I've been doing OpenGL for the past 4 months and hate programming in general at this point because I'm not seeing a fucking point to it nor enough progress and OpenGL is a nightmare to fucking work with and figure out and I hate whoever wrote it's documentation truly and deeply because it's caused me a lot of suffering since I'm stupid enough to think that it should actually explain how it works as opposed to be a masturbatory reference for whoever wrote the shit.
Something tells me I shouldn't ask him about WebGL and Three.js.
Going beyond HTML and CSS was a mistake
up yours puzzle boy
I like Jon, i think he has some great ideas and is doing positive things in the game space. He's a little washy with his opinion on OpenGL here. Debugging anything that is hidden in dll files and drivers is a pain, but the trade off here is its better than writing a graphics library from scratch, and certainly something as rich as OpenGL would be almost certainly impossible to gain access to low level GPU instructions for shaders etc.
Opengl might not be the best but its the best we have. And it works with all operating systems including mobile.
Unironically, the only time O've done graphics was in TempleOS and it was pretty neet
This is kind of the stupidest thing I've heard from him. He doesn't really outline any specific problesm with opengl, just that you 'can't call a function and get a triangle'. I mean, I'm glad he's not the one that makes industry decisions. OpenGL is light years better than Vulkan. It's not going away because it's by far the simplest yet most powerful gfx API, and, like, it's not even fucking close. He even admits he uses it. Really braindead take honestly.
His takes are really bad, but GL lightyears better than VK? I understand that Vk is not for beginners, but you get there eventually - from necessity, trying to run away from GL's inherent and unfixable design flaws to develop your own design flaws which can actually be fixed after a finite amount of rewrites if you know what you want from the GPU.
4:28 because GPUs(General Processing Units) are not only used for graphics instead they have very general structures thus harder to program the more general the architecture the harder it gets to program it was easier back then when GPUs were solely graphics processing units
Easiest way to learn lower level and have usable API knowledge today, is likely WebGL.
I wouldn't call JavaScript "lower level", tho. 🤔
@@zdspider6778
Game development perspective WebGL is lowlevel because there are libraries and engines where you don't think how to draw rectangle, instead you can draw 3D-scene or object from model.
Its 2023 and were still using C apis so...
Why would we be using anything other than the objectively best language in existence? Unless we're just fooling around or doing statistics in Python, I suppose. I'll admit, Python is handy to use as a calculator when I'm working in a terminal.
@@slynt_ bro, i hate python, java and all that crap.
Raylib is huge, too. I looked at it. It's nice, but it's huge. That's because it's a wrapper for a large surface of stuff. There's no getting around that it's a large surface.
Also, one does not simply draw stuff to the screen. Maybe back in the 80s and early 90s, when you had stuff like writing directly to a framebuffer, or using graphics primitives like arc, line, polyline, rectangle, fill, etc. You can still do that today with the CPU, but all you will do is waste electricity and contribute to global warming, AND it will be slow. To draw stuff to the screen today, you need to use the specialized drawing computer inside your computer -- the GPU. Which means you have to write shaders, allocate memory for the resources the GPU needs in order to draw your screen, and then send commands to the GPU. You have to think about overdraw, you have to think about when to calculate vs. looking up in memory. It's not the 90s anymore, graphics pipelines are hard, embrace the suck.
For a good user-facing graphics API, use Direct3D. If you're on Linux, use one of the wrappers like DXVK. OpenGL is indeed bad.
no just use vulkan, it's cross platform and has almost the same level of abstraction of directx
i am inclined to disagree, sorry
"but all you will do is waste electricity and contribute to global warming"
🤣🤣🤣
Q U A K E
isn't it just webgpu?
so use glfw, BGFX on cpp or WGPU on rust
Llgl looks good too
Fucking redundancy for doing so little! A full software rasterizer has less code than drawing a fucking triangle in opengl or even worse in directx!
If you're that upset about it you need to stop making TH-cam videos. OpenGL is a great way to start learning the fundamentals without the complexity of Vulkan. Like it or not, there are far more novices than professionals in the world, and OpenGL is fairly easy to get your head around as a novice. And by sheer percentages, if you're going to post TH-cam videos or do live streaming, you're going to attract more novices than professionals.
You realize that this is not his channel?
@@maksymiliank5135😂😂😂