You should absolutely have the loading screens cycle through different titles like "Loading Game" "Compiling Shaders" Just so one of them can say "Beating Level For You" or something in reference to a replay being played in the background to generate the shaders
I remember Terraria has a ton of quirky loading messages. I'm sure some of which are actually indicative of what's going on at that given moment, but there's also ones like "Mining Bitcoin" thrown in there, so who knows.
@@redgeoblaze3752 quirky loading messages that don't actually explain anything are actually quit common. As musch as I can remember Word of Good had quite a few funny ones. Age of Wonders 2 had some. And the oldest I remember is "reticulating splines" in Sim City 2000 level generation.
I also found it pleasantly nostalgic, from back in the Roblox days where you would be loading into a game but you could hear all the other players in the background while you did.
So true, I think most of the gamedev audience is a little brained out for something "entertaining", and just want something interesting and inspiring, amazing video blargis!
@@Blargis3d For the issue with having to choose 2 systems you could have a settings bar where you can choose what system the player is going to play on. I'm not sure if this would work in practice but if it does work it could fix alot of the issues happening for people with older devices. If that doesn't work you could resort to have 2 version of the game on vulkan and the other one OpenGL
@@tophatplayz1648 while it's a nice thought to enable as many people as possible to play, that would also mean double the work for them; two different graphics APIs, reworking would have to be done for all the postprocessing, particles, etc., and even then, it would never be an identical experience due to the difference between the APIs. think of it like a game that has a PS2 and PSP port. that's essentially what you're looking at, and twice the game for one developer ain't that great of an idea ':D
"Light baking can sometimes take a long time, think on the order of minutes." Literally the best advertisement I've heard for Godot as someone whose main engines up to this point have been Source and Unity.
@@STNGR4Y for a complex scene? hours. you can still do other things in the meantime, but if you dare hit play on your scene it goes in the trash and you'll have to wait another 4 & half hours for it to regen
I ran into the same problems with OpenGL and Vulkan when I launched my game on steam. I ended up just adapting all of my visual effects to look mostly the same between OpenGL and Vulkan and then exported both versions and set them as different launch options on steam. Imagine my panic when I launch the game on Steam and I immediately get bug reports on how the game just doesn't lauch 😭
@@Blargis3d yeah it was. It ultimately came down to the fact that it's a retro pixel game. And like you said in the video, people expect to be able to run retro looking games on potatoes :D So yeah, setting up a Compatibility launch option or a beta option on Steam might be necessary to make sure everyone can play.
I'm following ultra engine development and they completely switched to opengl from Vulcan, while gaining performance on amd GPUs. They have a great vide explaining why Vulcan is terrible for development and how almost no games use it, lol
@@sulfur2964 OpenGL is functionally a dead end. Development has ceased entirely on it, and it will not see any improvements nor new features. As far as I can tell by the presentation (that also uses AI generated images, which as far as I am concerned is already a red mark against something, I also have no interest in watching a nearly 2 hour video that's functionally just someone going over a slideshow, so maybe something was covered there but not in the slideshow), with all the main arguments essentially boiling down to pointing at numbers entirely out of context, and pretending like a point has been made. (ex, Vulkan games in 2023 vs GlideFX games in 1999, which ignores that game development as a whole has changed since 1999) Also minimum system requirements for an API doesn't exactly mean anything - sure you can now "support" games on something as old as a geforce 420, but no one is going to be practically targeting hardware that old, meaning it's equally as valid to say "The GeForce GT 630 is the minimum support for Vulkan". Also OpenGL driver support is known to be sketchy at best. This has been well documented. Also the wording of "API drivers buggy" isn't a search term normal people will use. instead, "API driver issue" is FAR more likely to be searched, which shows 15.6m results for DirectX, 10.8m results for OpenGL, and 3.4m for Vulkan. (also the original search query gives completely different numbers, with exclusively DirectX being the only one even remotely close). As with any sudden and significant performance boost, I would sooner suspect a poorly implemented Vulkan pipeline over any actual benefit to switching to OpenGL.
12:40 NO, KEEP IT! Maybe half the volume or something but this is hilarious and exactly in the spirit of older games when devs were allowed to have fun with their projects, adding silly elements in "irrelevant" parts of the game, just for the fun of it while solving problems like this. That always adds so much charm to a game and makes it feel more alive.
its got that old multiplayer servers vibe where you would join the game and see only some random area of the map from one angle while you can hear random slashes from other players around the map not in your view 😆
Omg thank you. I was little bit disappointed when I first launched your game because it run at 25-30 fps on my uhd 620 thinkpad. Now I'll be able to play it at 60fps wohooo Edit: for compiling shaders you can set camera fov to 180, detach it from the player spawn on different parts of the map and rotate it 360 degrees. I saw this method used by antii for his game Road to Vostok. You can check it out on youtube
Nice more fps, road to vostok its pretty good, but pretty buggy now after moving to godot(*rip the guy with godot 3d optimizations*) Godot is really neat for 2d, but 3d hurts. As a web developer I'm afraid of react and testing(*its a pain, but i still do it*)
I wish more devs thought like this. "My game looks retro af, so it should be able to run on potatoes" Tons of indie games with retro aesthetics don't seem to care for optimisation even if it's a simple shooter. Worse yet sometimes they'll force Unreal Engine's Lumen to achieve basically raster graphics we've had for decades. I guess it's their vision and all, but it seems dissonant with the graphics of the game how you need newer cards to run the thing. Glad you're going this route.
I have a sadly expensive potato of a PC, and whenever I get a game with a retro-3d aesthetic it's not terribly uncommon for it to run like absolute ass, and it always feels like such a burn.
the problem is, year 2016 pc is not a potato. a game that visually looks like form the year 1998 shouldn't barely run on 2016 super powerful pc (of course compared to 1998 hw). we'll talk about potatoes when it'll run smoothly on my smart toaster.
@@johnywhil Exactly. I had a crappy 2008 prebuilt back when I first started seriously messing around with PC gaming and even that was getting 1k+ frames in games like Counter Strike: Source.
Hello, speedrunner here. I haven't watched the whole video yet and I'm in a rush but during the AI section you mention adding a random number to the AI's pathing tick cycle. Please seed this random number generator to the same seed everytime or the tiiiinnnnyyy amount of randomness this will cause will certainly screw TASes (and maybe super high level speedruns) forever. Thanks :P
@@Blargis3dit would be even better if you just count up the frame offset % 20. That would almost guarantee a rather even distribution of the calculation.
Unreal Engine game dev here - in principle you can select your renderer in the project settings - DX11/DX12/Vulkan. The engine uses a renderer abstraction layer, allowing the engine to call render commands without worrying about the implementation, and the Render Hardware Interface (RHI) layer converts it into commands in the chosen rendering api. That said, it’s often it’s easier to pick one and stick with it, as some material functions aren’t universally supported so increases the QA time significantly!
I live for developers talking about all the ways they optimize their code. Also you should keep the sound on for compiling shaders. It is really really funny
Your shader compilation solution is the embodiement of what gamedev feels sometimes, you look for the smart solution who will very elegantly solve your problem, but instead you can just brute force the thing in 5 minutes and get the same result ! I loved it !
I think an alternative way to mitigate shader stutters could be to have a main menu background, where a camera flies through a sort of demo/secret level. This would look kinda old school and in line with your game art style.
@@FrozenDozer I wonder if shader compilation blocks the whole process or if the like, menu and player controls and stuff are on a separate thread from the main game, if the menu would stay interactable even if the scene in the background is choppy. It'd be noticeable but certainly not as big of a problem as ingame stutters.
@@Aeduo i don't know for sure, but if during stutter a GPU waits for shaider to process current frame it might be that decoupling menu rendering from the background render is too complex task. Like you will need two renders a separate frames, and than ask gpu to combine current state of both into one frame.
@@L1vv4n I think this is kinda the point of something like vulkan though, where you can have some task going on while other stuff is happening and you synchronize tasks and allow stuff to continue or wait based on what tasks have completed or not.
@@Aeduo asynchronous shader compilation exists, it waits for the shaders to be compiled before rendering, which solves the freezes at the cose that it may make assets invisible for a moment. I'm unsure that exists for Godot though
this is not good advice. this requires the player to make choices and have technical knowledge. as a consumer i just want it to work, i don't want to plan things
@@007kingifrit yeah I agree with u. When I played r6 first time I didn't know about it, and it tanked my preformance. Loking from this angle, I woulden't suggest it now.
Okay, this is ridiculously genius and funny, like "My problem was, that shaders compiled on my machine since I've beat my levels myself. How do I fix it for new players? Okay, guess I just have to beat the level for them first myself too, every time." Like someone said in comments, it would be actually very fun option to just turn on preview of shader compilation sequence. PS: it's really cool to see your devlogs everytime, both interesting and very informative for other dev who just begin to do yheir stuff.
If you can get an id for each enemy, instead of generating a random number for each, you can instead use mod(id, 20) so the 1st, 21st, 41th, 61th, etc enemies will update on the 1st tick, then the 2nd, 22nd, 42nd, etc on the 2nd perfectly dividing the enemies up into 20ths for AI updates every tick
Optimizing is a lost art at this point, devs just go nuclear option assuming everyone has a literal fusion reactor in their basement powering their RTX 9990 Hyper X card from the future. Kudos for doing it and for the video in general, good stuff.
THANK YOU THANK YOU THANK YOU!!!!! As someone who has a potato computer similar to the one in the video (gen4 processor, 8gig ram, no GPU I think) I'm glad you had a computer that bad in mind when optimizing. I'm no programmer by any means, but there's so many games I play that could easily have performance fixed with simple optimizations, such as enabling culling for more objects, staggering calculation times, reducing keyframes, not processing animations for objects out of view, or being able to toggle off shaders so potato PCs like mine don't have to process every object's ray tracing and motion blur. Literally just watching you optimize your game has convinced me to add it to my wishlist :)
Actually turning off animations isnt big optimization benefit, sure every little is good but to turn off as much dynamic lighting as possible was here probably one of the biggest Performance things. Also why the heck did he had dynamic lighting if basicly nothing could interact with it, such things are the reason for bad Performance. Also to make the pathfinding calculations dont happen on the same time only reduce short lag Spikes/time freezes. To make the calculations every 20 frames is a good thing. To the topic of culling, yes it is good but not really important because computers dont have anymore the Problem with drawing normal polygons. Here it is a thing of good models, if your objects are good, you dont use transparent textures and if you have the same object multiple times it uses only one draw call(a Signal that tells the graphic card to draw a object).
A better pattern for the pathing stuff, FYI, is to use a round-robin scheduler. So you set a budget for how many agents are allowed to update on a given frame, and each frame you have a manager move the index by n slots and update that many agents. So you can guarantee a fixed load per frame and also guarantee that an agent only goes so many frames between updates. You can use this pattern for a lot of things to smooth out your load to be precisely consistent over time.
Baked lighting will also make your finished product larger, in terms of memory. Same with OC. All these techniques have the side effect that you're effectively switching the cost from processing cycles to memory usage. One thing to bear in mind with this (amongst many) is that, processing cycles are effectively infinite, you'll always have more, you'll just drop render frames if there aren't enough available. Memory is finite, and if you run out, the kernel will either crash (panic), or kill your game, causing it to crash. Now, in a game of this scope, it's probably not a huge deal, but if the engine has memory leaks (and all engines/code has memory leaks somewhere) and/or your game code has memory leaks, or somewhere along the compilation chain there are memory leaks (you see where I'm going), then after some time, you'll start to encounter issues that are incredibly difficult to fix. I just wanted to clarify that what seems like magic, and to always be a good idea, does have some tradeoffs, and is something every engineer should be aware of. PS: Also, NEVER delete files/directories that you don't know what it does. Just rename the directory (add an _ to the start of it's name or something), or change the file extension (.old works well) and this will usually (there are exceptions) have the same effect as deleting it. Then, if you hit a castrophic, "I shouldn't have done that" moment, then you can just rename it back, even if you have boot Linux from usb or something.
Hey so with your Pathfinding optimization, it might be helpful to add your Knight agents to a queue and have a manager cycle the queue, invoking their pathfind() function on whatever interval you’d like. You’re probably already aware of this solution but I just thought I’d share since it helped one of my projects. Great video!
Youve been talking about all these advanced optimization techniques that ive realized now is literally every single thing I have to do while making maps for source in the hammer editor... entity culling, baked lighting, nav mesh optimization, etc
Constantly finding barriers in your game's development that are tied to years old issues and pull requests on the github that are supposed to be fixed and merged in just the next update, that is just the Godot experience. Lord help us. But also thank you very much for making this video, best insight I've ever gotten on how I can apply optimizations as a fellow Godot developer.
@@Saas_1 quite simply, because I am not smart enough to make my own engine yet. Even if I was, Godot would probably save me so much time that instead of sitting and waiting for bugfixes I'd be fixing them myself and sending pull requests.
Just got done playing the demo and wow when the full release is released im immediately buying it the first two levels were very fun and I’m excited to see the rest of your journey
Having the game do a pre-recorded run for shader compilation is a really clever idea, even if a broader solution is coming for the next versions. For the AI/pathfinding optimization I had a similar issue, and what I found is to have a singleton responsible for all enemies, and have enemies queue into it to have their next update calculated (can be for path update, sensor check, whatever could cause an issue in large numbers). That way you can control how many calculations you want to per tick (could even adjust it dynamically based on performance), and guaranteed to not have any accidental overlaps.
In my experience centralized data structures are the way to go for most things. It allows you to limit and batch work like that. But i do everything in C, so that probably has an impact.
Added to wishlist. While I'm sure the pathfinding randomization technique will generally give you a decent result, you could still end up with situations where most of the random numbers end up at the same time. A more bulletproof solution would be a simple queue you add enemies to. Every 20 frames the queue would advance and call the enemy's pathfinding routine. Additionally, you could have the pathfinding routine take a callback from the queue so that you could guarantee the last calculation was finished before performing the next. Maybe a bit overkill, but hey, this is a video about optimization.
As someone who has been forced to play some games at 20 fps for years, thank you so much for adding some of these optimizations. Specifically i want to point out the resolution scale options. Its relativly simple to implement but, from a players perspective, can make or break how fun a game is.
yeah its great for a number of reasons, tbh w/ the aesthetic of the game I might run it at a lower resolution on my 1440p setup just for the ambiance lol
I find it curious how older games have so little detail that low resolution preserves a lot of visual clarity. I decided to play through Quake 2 RTX on my 4070, and at 1440p I would get ~85 fps at full GPU utilization ("but can it run -Crysis- Quake 2?"). But reducing it down to 1080p I got ~145-155 fps, which is perfect for my 165 hz monitor. I didn't feel any difference - something I couldn't say for modern titles, where 1080p starts feeling a bit fuzzy.
Thank you for this! I don't know how it's typically done, but knowing a game dev legit used out of date hardware to optimize for actually playing the game is outstanding.
As someone who is doing a retro-style fps on godot using Qodot and who has the same performance issues, I can't thank you enough for the techniques displayed here
Another optimization: The thing with computing the shortest path from multiple sources to one destination is that it can be reversed. Instead of doing a calculation for each source, do only one calculation from the destination to all sources and you will find the same paths (but reversed). This ensures that you do minimal work and don’t double calculate anything.
man, i feel like I've learned stuff that takes decades to learn just by watching this video, and the guy seems very supportive of his community which ik doesn't sound like a big deal, but it's actually pretty rare
Man I genuinely cannot thank you enough for these videos. Your 90s level design video introduced me to the trenchbroom + qodot pipeline a few months ago and I have never looked back. Bloodthief is coming along very well, best of luck
Shader pre-compilation is an essential feature for every modern PC game. Glad to see it being implemented, even if it's done in a "unusual way" :D For your game, consider adding a integer scaling for resolution scaling, while also giving an option to disable the filtering. So players can play at 1/2 Res, 1/3 Res, 1/4 Res, etc... Prodeus added this option and I personally love it, even though my computer can easily handle the 1440p Native res, I prefer to play older games at 1/3 Resolution to get the those chunky pixels.
I found Godots reasoning there a bit odd? Fairly sure I've seen games that compile shaders on startup (e.g. Elite Dangerous) instead of only once stuff is seen at least.
2:46 Damn, it's neat how a lower res buffer might save performance, but also cause greedy occlusion like this. 12:05 Running a replay is one of the more creative solutions I've seen to getting over shader jitter, which I thought only happened with particles and didn't realize this was a general class of problem within Godot. Would be cool if you did this when the game started up and then used the same replay in the background like Quake did on it's menu. This video was very good. I'm really happy more stuff is coming out like this that points to major issues in Godot that's getting in the way of making finished games.
I am so so happy that the UA-cam algorithm brought me to this place, I watched all the devlogs and really really loved your videos but more the actual game. I got excited to know that I can play it for free right now and just played the demo and OMG those few minutes made my day. Most fun I have ever had playing a single player game in a while! Thank you and I wishlisted it ❤
Definitely allow for the replay and sound replay, I think it adds charm to the loading screen and is reminiscent of the gameplay demos on the menus of Quake
thats awesome dude, optimisation is a neglected area across software development these days. even some websites are bloated beyond belief. optimisation reduces e-waste! :)
The built-in Mesa kernel driver on Linux does let some older hardware run Vulkan further than most Windows drivers, but just doing that for Linux alone is a whole other mess to implement that could break cross-platform compatibility. Just thought I would mention that if it seems at all useful to you. :)
@@krolmuch "Python level" is not a phrase that means anything, although it just occurred to me this might not be ur first language GDScript is a completely original language created to be closely integrated to the engine and it is also much much faster and just better than Python lol GDScript and C# have pretty much same performance if you use Static Typing on all your variables and methods
15:50 can you make two versions one with OpenGl and one with Vulkan and at startup it checks what it should use eather openGL or vulkan and then deleate the other one?
holy shit this makes me realize so that in so many instances when i've had a game stutter, it's the shaders compiling. saving this video even though i only work in 2d, this is super useful
16:00 With DirectX, there's compatibility layers between different versions of DirectX. DirectX12 is pretty much the same granularity as Vulkan, and Directx11 is the same granularity as OpenGL. Both offer superior performance on Windows machines and are not exclusive to MacOS or Linux. There's also Metal for MacOS
Finally a Devlog thats not just a plain Daily Diary. Thats exactly how a Devlog should be. I wish you your game does well. Even if im not into 3D Platformer this game looks still like alot of fun! Great Job Blargis!
12:25 I actually really liked it when you could see the pre-recorded gameplay during the “Compiling Shaders” screen, lol. In fact, I’d argue that it’s a good way to make the loading screen less boring to look at since looking at a blank screen is incredibly boring.
on top of the resilution setting you should add an aspect ratio setting, i used to play csgo and minecraft on 4:3 and it looked rlly cool and nostalgic. i also like rendering videos on 4:3 for the same reason
This is probably one of the most interesting godot videos I've seen in the past year. Great explanations, interesting from beginning to end and it offered a lot of insight into the engine. Thank you so much for taking the time to document all this, I'm sure it will help a ton of people!
As for GoldSrc approach - you can make special zones (for example, in a room) that will prevent other rooms to render (but don't forget about opening doors)
11:55 you mentioned before that you randomized the path updating of your enemies, making your game not fully deterministic anymore. Could this not break this method somehow, that this input sequence doesn't work, just at a very small chance?
Oh i remember this video! You had the crazy loading screen easter egg. 12:36 Much better than the debate of whether people should add artificial loading screens.
I was also working on a low-poly godot game, even with the compatibility renderer on my shitty laptops, I barely cracked 50-60 fps on basic maps and minimal game logic. I was pissed because I wanted to have LAN parties with CRT's with really low end hardware. I bit the bullet and am rewriting in c++ no engine and just pick and choosing my libraries, now I'm cooking at like 250hz + on these shitter laptops it's great (opengl renderer)
honestly I dont thin the shader comp sounds should be an easter egg. It should just be how it works out the box. It has that behind the scenes jank that games of the age this throws back to actually had.
You know that this video is basically just showing the core problems of Godot: Bad (rendering) engine, age old and not fixed (critical) issues and the "we'll just have to wait a bit more for the engine to become amazing" mentality.
as a beginner godot dev, I find this really interesting. I've known about these techniques before, but seeing them done in the engine gives interesting insight. Also pretty cool game. Quake meets Ghostrunner? Looks good!
i like the volume on the loading screen, it gives that type of old game with some oversight which is cool. plus makes the loading screen something less boring, and if I want I can turn it off myself. Maybe not 10x the audio idk I LIKE IT
Shader loading sounds are fucking hilarious
game be like "son, our neighbour is coming round to visit"
game: "OH SH- FCK FCK CLEAN UP PUT EVERYTHING AWAY, KILL ALL THE DEMONS RQ"
@@UsernameDoesntCare just Gmod glitching out sounds as the game scrambles to make itself presentable
I kinda love it and wish it would stay in.
seriously, the fact that you neither tell why or when shader compilation triggers now that you can't trigger then explicitly is really ridiculous.
He better make a secret setting to enable this
You should absolutely have the loading screens cycle through different titles like "Loading Game"
"Compiling Shaders"
Just so one of them can say "Beating Level For You" or something in reference to a replay being played in the background to generate the shaders
I remember Terraria has a ton of quirky loading messages. I'm sure some of which are actually indicative of what's going on at that given moment, but there's also ones like "Mining Bitcoin" thrown in there, so who knows.
@@redgeoblaze3752 quirky loading messages that don't actually explain anything are actually quit common. As musch as I can remember Word of Good had quite a few funny ones. Age of Wonders 2 had some. And the oldest I remember is "reticulating splines" in Sim City 2000 level generation.
@@krux02 Reticulating splines is my favorite nonsense loading message. It just feels so.. crunchy. It's also in sims 1 and 2 I believe.
If he does this then there should be a message that says "stealing your blood"
"Tidying the Castle" - and it enables the sound so you can hear all the clattering
PLEASE add an Easter egg so that we can enable to the audio or visuals for the shader comp loading screen, that’s hilarious😂😂
100%
yes, please!
signed
was about to comment this. I think that a 10x speed preview of the level is kind of a cool feature as well.
ah i know! record the entire audio of the gameplay and then edit it and shift its speed 10x so it sounds like chipmunks all the whole loadingbar
12:36 PLEASE MAKE AN EASTER EGG TO ENABLE THE SOUND AGAIN
"It sounds like the game is frantically cleaning a room" Is waaay too hilarious
Up, this gives life to the loading screen
i vote for this
I also found it pleasantly nostalgic, from back in the Roblox days where you would be loading into a game but you could hear all the other players in the background while you did.
It also kinda sounds like the character is fighting it's way into the level or something like
Maybe as a code
This is the best kind of devlog, gets you excited about the game and also teaches you something about game dev!
thank you, glad you enjoyed it!
So true, I think most of the gamedev audience is a little brained out for something "entertaining", and just want something interesting and inspiring, amazing video blargis!
@@Blargis3d hey so uh do you know what the price is going to be?
@@Blargis3d For the issue with having to choose 2 systems you could have a settings bar where you can choose what system the player is going to play on. I'm not sure if this would work in practice but if it does work it could fix alot of the issues happening for people with older devices. If that doesn't work you could resort to have 2 version of the game on vulkan and the other one OpenGL
@@tophatplayz1648 while it's a nice thought to enable as many people as possible to play, that would also mean double the work for them; two different graphics APIs, reworking would have to be done for all the postprocessing, particles, etc., and even then, it would never be an identical experience due to the difference between the APIs.
think of it like a game that has a PS2 and PSP port. that's essentially what you're looking at, and twice the game for one developer ain't that great of an idea ':D
"Light baking can sometimes take a long time, think on the order of minutes."
Literally the best advertisement I've heard for Godot as someone whose main engines up to this point have been Source and Unity.
How long does unity take usually for light baking?
@@STNGR4Y yes
@@STNGR4Yyes
@@STNGR4Y for a complex scene? hours. you can still do other things in the meantime, but if you dare hit play on your scene it goes in the trash and you'll have to wait another 4 & half hours for it to regen
@@koekje00005 oh ok ty
I ran into the same problems with OpenGL and Vulkan when I launched my game on steam. I ended up just adapting all of my visual effects to look mostly the same between OpenGL and Vulkan and then exported both versions and set them as different launch options on steam. Imagine my panic when I launch the game on Steam and I immediately get bug reports on how the game just doesn't lauch 😭
Oooof this terrifies me lol. Might end up having to do this. Was your game Godot as well?
@@Blargis3d yeah it was. It ultimately came down to the fact that it's a retro pixel game. And like you said in the video, people expect to be able to run retro looking games on potatoes :D
So yeah, setting up a Compatibility launch option or a beta option on Steam might be necessary to make sure everyone can play.
I'm following ultra engine development and they completely switched to opengl from Vulcan, while gaining performance on amd GPUs. They have a great vide explaining why Vulcan is terrible for development and how almost no games use it, lol
@@sulfur2964 OpenGL is functionally a dead end. Development has ceased entirely on it, and it will not see any improvements nor new features. As far as I can tell by the presentation (that also uses AI generated images, which as far as I am concerned is already a red mark against something, I also have no interest in watching a nearly 2 hour video that's functionally just someone going over a slideshow, so maybe something was covered there but not in the slideshow), with all the main arguments essentially boiling down to pointing at numbers entirely out of context, and pretending like a point has been made. (ex, Vulkan games in 2023 vs GlideFX games in 1999, which ignores that game development as a whole has changed since 1999)
Also minimum system requirements for an API doesn't exactly mean anything - sure you can now "support" games on something as old as a geforce 420, but no one is going to be practically targeting hardware that old, meaning it's equally as valid to say "The GeForce GT 630 is the minimum support for Vulkan".
Also OpenGL driver support is known to be sketchy at best. This has been well documented.
Also the wording of "API drivers buggy" isn't a search term normal people will use. instead, "API driver issue" is FAR more likely to be searched, which shows 15.6m results for DirectX, 10.8m results for OpenGL, and 3.4m for Vulkan. (also the original search query gives completely different numbers, with exclusively DirectX being the only one even remotely close).
As with any sudden and significant performance boost, I would sooner suspect a poorly implemented Vulkan pipeline over any actual benefit to switching to OpenGL.
@@sulfur2964 vulkan is so much fun to use tho, also most new games use it
12:40 NO, KEEP IT! Maybe half the volume or something but this is hilarious and exactly in the spirit of older games when devs were allowed to have fun with their projects, adding silly elements in "irrelevant" parts of the game, just for the fun of it while solving problems like this. That always adds so much charm to a game and makes it feel more alive.
*splines reticulate loudly*
An option to enable the volume of the loading screens would do the work.
its got that old multiplayer servers vibe where you would join the game and see only some random area of the map from one angle while you can hear random slashes from other players around the map not in your view 😆
Omg thank you. I was little bit disappointed when I first launched your game because it run at 25-30 fps on my uhd 620 thinkpad. Now I'll be able to play it at 60fps wohooo
Edit: for compiling shaders you can set camera fov to 180, detach it from the player spawn on different parts of the map and rotate it 360 degrees. I saw this method used by antii for his game Road to Vostok. You can check it out on youtube
Rotate 180° lol
Nice more fps, road to vostok its pretty good, but pretty buggy now after moving to godot(*rip the guy with godot 3d optimizations*)
Godot is really neat for 2d, but 3d hurts. As a web developer I'm afraid of react and testing(*its a pain, but i still do it*)
@@realskyquest I agree. Having good looks doesn't mean it's good at 3d.
Which video did the road to vostok Dev talk about that?
You literally cannot have a 180° field of view with perspective projection.
I wish more devs thought like this. "My game looks retro af, so it should be able to run on potatoes"
Tons of indie games with retro aesthetics don't seem to care for optimisation even if it's a simple shooter.
Worse yet sometimes they'll force Unreal Engine's Lumen to achieve basically raster graphics we've had for decades.
I guess it's their vision and all, but it seems dissonant with the graphics of the game how you need newer cards to run the thing.
Glad you're going this route.
I have a sadly expensive potato of a PC, and whenever I get a game with a retro-3d aesthetic it's not terribly uncommon for it to run like absolute ass, and it always feels like such a burn.
fr
the problem is, year 2016 pc is not a potato. a game that visually looks like form the year 1998 shouldn't barely run on 2016 super powerful pc (of course compared to 1998 hw). we'll talk about potatoes when it'll run smoothly on my smart toaster.
@@johnywhil Exactly. I had a crappy 2008 prebuilt back when I first started seriously messing around with PC gaming and even that was getting 1k+ frames in games like Counter Strike: Source.
An example of this is Gloomwood, it looks nice and retro but my potato is unable to get good frames when playing which is a shame
Hello, speedrunner here.
I haven't watched the whole video yet and I'm in a rush but during the AI section you mention adding a random number to the AI's pathing tick cycle. Please seed this random number generator to the same seed everytime or the tiiiinnnnyyy amount of randomness this will cause will certainly screw TASes (and maybe super high level speedruns) forever.
Thanks :P
Ooooh that's a really good point. Noted! Shouldn't be too hard to seed this
@@Blargis3dNice, sorry to probably add another global variable to the pile :P
@@Blargis3d It also has the potential to break your shader compilation replay!
@@Blargis3dit would be even better if you just count up the frame offset % 20. That would almost guarantee a rather even distribution of the calculation.
i was thinking about how it would totally ruin TASes as well! lol
Unreal Engine game dev here - in principle you can select your renderer in the project settings - DX11/DX12/Vulkan. The engine uses a renderer abstraction layer, allowing the engine to call render commands without worrying about the implementation, and the Render Hardware Interface (RHI) layer converts it into commands in the chosen rendering api. That said, it’s often it’s easier to pick one and stick with it, as some material functions aren’t universally supported so increases the QA time significantly!
I live for developers talking about all the ways they optimize their code. Also you should keep the sound on for compiling shaders. It is really really funny
Agreed, it made me laugh so much when I heard it
It should be added as a secret option in settings that's just labeled something like "toggle loading screen tomfoolery"
Your shader compilation solution is the embodiement of what gamedev feels sometimes, you look for the smart solution who will very elegantly solve your problem, but instead you can just brute force the thing in 5 minutes and get the same result !
I loved it !
I think an alternative way to mitigate shader stutters could be to have a main menu background, where a camera flies through a sort of demo/secret level.
This would look kinda old school and in line with your game art style.
And then your main menu stutters and freezes like crazy. Not exactly ideal, lol
@@FrozenDozer I wonder if shader compilation blocks the whole process or if the like, menu and player controls and stuff are on a separate thread from the main game, if the menu would stay interactable even if the scene in the background is choppy. It'd be noticeable but certainly not as big of a problem as ingame stutters.
@@Aeduo i don't know for sure, but if during stutter a GPU waits for shaider to process current frame it might be that decoupling menu rendering from the background render is too complex task. Like you will need two renders a separate frames, and than ask gpu to combine current state of both into one frame.
@@L1vv4n I think this is kinda the point of something like vulkan though, where you can have some task going on while other stuff is happening and you synchronize tasks and allow stuff to continue or wait based on what tasks have completed or not.
@@Aeduo asynchronous shader compilation exists, it waits for the shaders to be compiled before rendering, which solves the freezes at the cose that it may make assets invisible for a moment. I'm unsure that exists for Godot though
16:30 You could create two separate builds and have them as launch options on steam.
Just like with r6. I noticed it, but I didn't know what was vulkan until now.
@blargis do this
@Blargis
this is not good advice. this requires the player to make choices and have technical knowledge. as a consumer i just want it to work, i don't want to plan things
@@007kingifrit yeah I agree with u. When I played r6 first time I didn't know about it, and it tanked my preformance. Loking from this angle, I woulden't suggest it now.
Okay, this is ridiculously genius and funny, like "My problem was, that shaders compiled on my machine since I've beat my levels myself. How do I fix it for new players? Okay, guess I just have to beat the level for them first myself too, every time." Like someone said in comments, it would be actually very fun option to just turn on preview of shader compilation sequence.
PS: it's really cool to see your devlogs everytime, both interesting and very informative for other dev who just begin to do yheir stuff.
If you can get an id for each enemy, instead of generating a random number for each, you can instead use mod(id, 20)
so the 1st, 21st, 41th, 61th, etc enemies will update on the 1st tick, then the 2nd, 22nd, 42nd, etc on the 2nd
perfectly dividing the enemies up into 20ths for AI updates every tick
Whoah! I'm gonna use this. Also deterministic which is great for speedrunning and stuff
@Blargis3d idk what the mod function in gdscript/c# is but it just gives a remainder, just in case that wasn't clear
@@TavishMcEwen I think everyone understands mod() unless you’re a high school kid. It’s basic maths and so common in programming
@@alphamineron you know what they say about assumptions
@@Blargis3d could you possibly make a tutorial on how to make basic camera movements like the camera in your game on the player
Optimizing is a lost art at this point, devs just go nuclear option assuming everyone has a literal fusion reactor in their basement powering their RTX 9990 Hyper X card from the future.
Kudos for doing it and for the video in general, good stuff.
Re: compiling shaders. That's what me and my colleagues in the industry like to call a "spicy" hack. 👌
THANK YOU THANK YOU THANK YOU!!!!! As someone who has a potato computer similar to the one in the video (gen4 processor, 8gig ram, no GPU I think) I'm glad you had a computer that bad in mind when optimizing. I'm no programmer by any means, but there's so many games I play that could easily have performance fixed with simple optimizations, such as enabling culling for more objects, staggering calculation times, reducing keyframes, not processing animations for objects out of view, or being able to toggle off shaders so potato PCs like mine don't have to process every object's ray tracing and motion blur. Literally just watching you optimize your game has convinced me to add it to my wishlist :)
Actually turning off animations isnt big optimization benefit, sure every little is good but to turn off as much dynamic lighting as possible was here probably one of the biggest Performance things.
Also why the heck did he had dynamic lighting if basicly nothing could interact with it, such things are the reason for bad Performance.
Also to make the pathfinding calculations dont happen on the same time only reduce short lag Spikes/time freezes. To make the calculations every 20 frames is a good thing.
To the topic of culling, yes it is good but not really important because computers dont have anymore the Problem with drawing normal polygons. Here it is a thing of good models, if your objects are good, you dont use transparent textures and if you have the same object multiple times it uses only one draw call(a Signal that tells the graphic card to draw a object).
Ohhh, I was just thinking today, "when are you going to release the video? " and then it comes out right in front of my eyes, enjoy watching it all
A better pattern for the pathing stuff, FYI, is to use a round-robin scheduler. So you set a budget for how many agents are allowed to update on a given frame, and each frame you have a manager move the index by n slots and update that many agents. So you can guarantee a fixed load per frame and also guarantee that an agent only goes so many frames between updates. You can use this pattern for a lot of things to smooth out your load to be precisely consistent over time.
This was probably the most interesting gamedev video I've seen yet, it's production grade information for polish, which is rare imo.
Baked lighting will also make your finished product larger, in terms of memory. Same with OC.
All these techniques have the side effect that you're effectively switching the cost from processing cycles to memory usage.
One thing to bear in mind with this (amongst many) is that, processing cycles are effectively infinite, you'll always have more, you'll just drop render frames if there aren't enough available. Memory is finite, and if you run out, the kernel will either crash (panic), or kill your game, causing it to crash.
Now, in a game of this scope, it's probably not a huge deal, but if the engine has memory leaks (and all engines/code has memory leaks somewhere) and/or your game code has memory leaks, or somewhere along the compilation chain there are memory leaks (you see where I'm going), then after some time, you'll start to encounter issues that are incredibly difficult to fix.
I just wanted to clarify that what seems like magic, and to always be a good idea, does have some tradeoffs, and is something every engineer should be aware of.
PS: Also, NEVER delete files/directories that you don't know what it does. Just rename the directory (add an _ to the start of it's name or something), or change the file extension (.old works well) and this will usually (there are exceptions) have the same effect as deleting it. Then, if you hit a castrophic, "I shouldn't have done that" moment, then you can just rename it back, even if you have boot Linux from usb or something.
Hey so with your Pathfinding optimization, it might be helpful to add your Knight agents to a queue and have a manager cycle the queue, invoking their pathfind() function on whatever interval you’d like. You’re probably already aware of this solution but I just thought I’d share since it helped one of my projects. Great video!
Youve been talking about all these advanced optimization techniques that ive realized now is literally every single thing I have to do while making maps for source in the hammer editor...
entity culling, baked lighting, nav mesh optimization, etc
Constantly finding barriers in your game's development that are tied to years old issues and pull requests on the github that are supposed to be fixed and merged in just the next update, that is just the Godot experience. Lord help us.
But also thank you very much for making this video, best insight I've ever gotten on how I can apply optimizations as a fellow Godot developer.
May I ask why you are using an engine that has the problem you just described?
@@Saas_1 quite simply, because I am not smart enough to make my own engine yet.
Even if I was, Godot would probably save me so much time that instead of sitting and waiting for bugfixes I'd be fixing them myself and sending pull requests.
@@Saas_1 Other engines also have bugs, but the reports and discussion aren't as easy to find when they aren't open source.
@@Saas_1 the thing is with godot it will eventually get fixed but from i know of unity it just gets replaced by an equally broken system
Unreal doesn't have *ANY* of the issues listed in the video, using Godot is literally just shooting yourself in the foot.
Just got done playing the demo and wow when the full release is released im immediately buying it the first two levels were very fun and I’m excited to see the rest of your journey
Having the game do a pre-recorded run for shader compilation is a really clever idea, even if a broader solution is coming for the next versions.
For the AI/pathfinding optimization I had a similar issue, and what I found is to have a singleton responsible for all enemies, and have enemies queue into it to have their next update calculated (can be for path update, sensor check, whatever could cause an issue in large numbers). That way you can control how many calculations you want to per tick (could even adjust it dynamically based on performance), and guaranteed to not have any accidental overlaps.
In my experience centralized data structures are the way to go for most things. It allows you to limit and batch work like that. But i do everything in C, so that probably has an impact.
Well I'll be damned. I just commented something really similar addressing the same point and just saw this. Hats off to you sir
Even allows to do other updates for each enemy, like even general logic, sacrifice "optimal AI" for performance
It's a more powerful tool than the one in the video
Added to wishlist. While I'm sure the pathfinding randomization technique will generally give you a decent result, you could still end up with situations where most of the random numbers end up at the same time. A more bulletproof solution would be a simple queue you add enemies to. Every 20 frames the queue would advance and call the enemy's pathfinding routine. Additionally, you could have the pathfinding routine take a callback from the queue so that you could guarantee the last calculation was finished before performing the next.
Maybe a bit overkill, but hey, this is a video about optimization.
As someone who has been forced to play some games at 20 fps for years, thank you so much for adding some of these optimizations. Specifically i want to point out the resolution scale options. Its relativly simple to implement but, from a players perspective, can make or break how fun a game is.
yeah its great for a number of reasons, tbh w/ the aesthetic of the game I might run it at a lower resolution on my 1440p setup just for the ambiance lol
I find it curious how older games have so little detail that low resolution preserves a lot of visual clarity.
I decided to play through Quake 2 RTX on my 4070, and at 1440p I would get ~85 fps at full GPU utilization ("but can it run -Crysis- Quake 2?"). But reducing it down to 1080p I got ~145-155 fps, which is perfect for my 165 hz monitor. I didn't feel any difference - something I couldn't say for modern titles, where 1080p starts feeling a bit fuzzy.
Thank you for this! I don't know how it's typically done, but knowing a game dev legit used out of date hardware to optimize for actually playing the game is outstanding.
As someone who is doing a retro-style fps on godot using Qodot and who has the same performance issues, I can't thank you enough for the techniques displayed here
Hey thanks for this. I'm pretty new to 3d game dev and your solutions to these problems will definitely influence how I approach my own projects
Chapters
0:00 Intro
1:20 Occlusion Culling
3:03 Baked Lighting
4:27 Optimizing Enemies
7:17 Shader Compilation
13:40 Graphics APIs
17:22 Rapid Fire Optimization Tips
18:14 Ending & Results
What is th point of this?
@@J0rdan069 Maybe the commenter will go back to the video for spesific purposes.
@@SapkaliAkif Yeah, but these chapters are already in the video.
Hmmm... culling, pruning, distributing, simplifying, and memoization.
@@J0rdan069 Ah, then maybe the comment was copied to the description afterwards.
Another optimization: The thing with computing the shortest path from multiple sources to one destination is that it can be reversed. Instead of doing a calculation for each source, do only one calculation from the destination to all sources and you will find the same paths (but reversed). This ensures that you do minimal work and don’t double calculate anything.
Unfortunately Godot's navmeshes don't really support this sort of thing - you'd have to roll out a lot of custom code.
@@ZeroPlayerGame sure but shortest path is really simple to code so it will still be just a little extra work
@@dominobuilder100 no... on graphs maybe, but not on navmeshes where you have to deal with a continuous space
@@ZeroPlayerGame ah ok I see
@@dominobuilder100even if it would be possible, the amount of calculations wouldnt decrease
that's the greatest devlog! i learned a lot about optimization in godot, thank you!
man, i feel like I've learned stuff that takes decades to learn just by watching this video, and the guy seems very supportive of his community which ik doesn't sound like a big deal, but it's actually pretty rare
This was a very well put together video - a lot of this stuff is not mentioned very often and takes a while to figure out!
I'm glad you found it helpful!
Honestly I like the audio during shader comp
Man I genuinely cannot thank you enough for these videos. Your 90s level design video introduced me to the trenchbroom + qodot pipeline a few months ago and I have never looked back. Bloodthief is coming along very well, best of luck
I actually really like the sounds your cache solution produced. it's silly, but symbolic of your passion
Shader pre-compilation is an essential feature for every modern PC game. Glad to see it being implemented, even if it's done in a "unusual way" :D
For your game, consider adding a integer scaling for resolution scaling, while also giving an option to disable the filtering. So players can play at 1/2 Res, 1/3 Res, 1/4 Res, etc... Prodeus added this option and I personally love it, even though my computer can easily handle the 1440p Native res, I prefer to play older games at 1/3 Resolution to get the those chunky pixels.
I found Godots reasoning there a bit odd? Fairly sure I've seen games that compile shaders on startup (e.g. Elite Dangerous) instead of only once stuff is seen at least.
2:46 Damn, it's neat how a lower res buffer might save performance, but also cause greedy occlusion like this.
12:05 Running a replay is one of the more creative solutions I've seen to getting over shader jitter, which I thought only happened with particles and didn't realize this was a general class of problem within Godot. Would be cool if you did this when the game started up and then used the same replay in the background like Quake did on it's menu.
This video was very good. I'm really happy more stuff is coming out like this that points to major issues in Godot that's getting in the way of making finished games.
I am so so happy that the UA-cam algorithm brought me to this place, I watched all the devlogs and really really loved your videos but more the actual game. I got excited to know that I can play it for free right now and just played the demo and OMG those few minutes made my day. Most fun I have ever had playing a single player game in a while! Thank you and I wishlisted it ❤
Definitely allow for the replay and sound replay, I think it adds charm to the loading screen and is reminiscent of the gameplay demos on the menus of Quake
A game inspired by Quake, Hotline Miami, Ultrakill, and Ghostrunner? Literally some of my favorite games. I cant wait to try this game out
thats awesome dude, optimisation is a neglected area across software development these days. even some websites are bloated beyond belief. optimisation reduces e-waste! :)
The built-in Mesa kernel driver on Linux does let some older hardware run Vulkan further than most Windows drivers, but just doing that for Linux alone is a whole other mess to implement that could break cross-platform compatibility.
Just thought I would mention that if it seems at all useful to you. :)
You are so freaking smart. That stutter fix idea is crazy.
Developers like you keep my faith in game developers
the biggest optimisation would not be using a python level scripting language for making a game though
@@krolmuch assembly or c++ would give even more performance
@@krolmuch "python level" bro does not know what he's talking about
@@sheepcommander_ he uses GDScript inside the game engine. tell me how is it not python level language?
@@krolmuch "Python level" is not a phrase that means anything, although it just occurred to me this might not be ur first language
GDScript is a completely original language created to be closely integrated to the engine and it is also much much faster and just better than Python lol
GDScript and C# have pretty much same performance if you use Static Typing on all your variables and methods
13:40, thank you for blinding me while i was watching in the dark
That screen has DirectX, OpenGL and Vulkan, but, for the true blindness experience, it's missing SEGA.
RIP eyes
As someone with a potato I see this as a absolute W.
Edit. I have a Vulcan specific potato so still a W.
Adding to the pile, dear god do I love how the compiling shaders screen sounds. Add an electric drill and handsaw noise.
0:59 the t-posing knights sliding towards you is terrifying
they doing the a-pose
its an A-pose not a T-pose
you are true engineer. i think its the first in a long time i saw someone talking abt optimisation.
I've been learing about game development for a bit and optimization is one of my favorite topics! So this video was like crack to me
That's a nice jade roller you got there bro, so envious
15:50 can you make two versions one with OpenGl and one with Vulkan and at startup it checks what it should use eather openGL or vulkan and then deleate the other one?
your shader compiler is super smart! props
also the shader loading sounds are AMAZING i need that
holy shit this makes me realize so that in so many instances when i've had a game stutter, it's the shaders compiling. saving this video even though i only work in 2d, this is super useful
0:06
"But for gaming,it's terrible"
*start naming the components of my computer
I think all that noise it makes during the compilation screen adds personality! I would leave it in fr
Adds MORE personality i should say
16:00 With DirectX, there's compatibility layers between different versions of DirectX. DirectX12 is pretty much the same granularity as Vulkan, and Directx11 is the same granularity as OpenGL. Both offer superior performance on Windows machines and are not exclusive to MacOS or Linux. There's also Metal for MacOS
Finally a Devlog thats not just a plain Daily Diary. Thats exactly how a Devlog should be. I wish you your game does well.
Even if im not into 3D Platformer this game looks still like alot of fun! Great Job Blargis!
99% of modern game devs need to watch this.
In a round about way, you recreated Quake Demo files. I hope you expose that functionality to the player like id tech / gldsrc / source engine did!
12:25 I actually really liked it when you could see the pre-recorded gameplay during the “Compiling Shaders” screen, lol. In fact, I’d argue that it’s a good way to make the loading screen less boring to look at since looking at a blank screen is incredibly boring.
Would spoil the level tough (altough I agree it looks cool)
Should keep the audio, it's just funny :D
The switch from dark-mode webpage o light-mode webpage during the "changing your light setup" was masterful.
0:36 it's a jade roller
These are probably some of the best devlogs I've seen, really interesting stuff, thank you
12:12 thats such a cool solution
on top of the resilution setting you should add an aspect ratio setting, i used to play csgo and minecraft on 4:3 and it looked rlly cool and nostalgic. i also like rendering videos on 4:3 for the same reason
12:27 its actually so funny, you should leave it in the game
your work is not only informative but also incredibly inspiring!
Funny how for 50 bucks more you can get a Steam Deck.
shows how good of a deal the steamdeck is lol
@@Shrewbloommore like it shows how overpriced that laptop is😭
17:00 - Man, I was not expecting to see that Kenneth Copeland jumpscare
I love this GAME!
Great video, lots of insightful things and exciting to see progress, GGs ^-^
16:11 could it be possible to add at the start of the game like some games do a menu that allows you to chose which graphics api the game runs on ?
I think you're correct in that Steam seems to handle it's own proprietary and separate shader caching.
16:20 could you offer both versions, Vulkan & Open GL, for your players, but that is a lot of work.
This is probably one of the most interesting godot videos I've seen in the past year. Great explanations, interesting from beginning to end and it offered a lot of insight into the engine. Thank you so much for taking the time to document all this, I'm sure it will help a ton of people!
3:41 Hot take:
The left one is way better. Extremely better. So much better-looking.
As for GoldSrc approach - you can make special zones (for example, in a room) that will prevent other rooms to render (but don't forget about opening doors)
12:22 I think it'd be extremely cool If you didn't and the loading screen was the replay, but that could spoil the level maybe?
Omg that solution to the shader compilation problem is hilarious 😂I second including a way to keep those sounds enabled while loading 💀
11:55
you mentioned before that you randomized the path updating of your enemies, making your game not fully deterministic anymore. Could this not break this method somehow, that this input sequence doesn't work, just at a very small chance?
Oh i remember this video! You had the crazy loading screen easter egg. 12:36
Much better than the debate of whether people should add artificial loading screens.
0:03 well my pc is a rotten lotato so you still got better
This is both hilarious and highly useful. And the game is looking fun :)
I was also working on a low-poly godot game, even with the compatibility renderer on my shitty laptops, I barely cracked 50-60 fps on basic maps and minimal game logic. I was pissed because I wanted to have LAN parties with CRT's with really low end hardware.
I bit the bullet and am rewriting in c++ no engine and just pick and choosing my libraries, now I'm cooking at like 250hz + on these shitter laptops it's great (opengl renderer)
honestly I dont thin the shader comp sounds should be an easter egg. It should just be how it works out the box. It has that behind the scenes jank that games of the age this throws back to actually had.
bro get your wife a new computer PLEASE
It's her punishment.
@@sean7221for what
What did she do
Bro people have other things in life than video games
@@toucan6109 doesn't mean she doesn't deserve a better computer? weird take is weird
I would absolutely LOVE if I booted up a game and it's compilation screen had that sound effect. Like you said, sounds like rapidly cleaning up.
You know that this video is basically just showing the core problems of Godot: Bad (rendering) engine, age old and not fixed (critical) issues and the "we'll just have to wait a bit more for the engine to become amazing" mentality.
as a beginner godot dev, I find this really interesting. I've known about these techniques before, but seeing them done in the engine gives interesting insight.
Also pretty cool game. Quake meets Ghostrunner? Looks good!
13:50 Technically all 3 are closed source, as it is up to the GPU manufacturer to implement the APIs. OpenGL and Vulkan are open STANDARD, not source
It also does not necessarily have to be the GPU manufacturer to implement the APIs. You have Mesa as an open-source OpenGPL and Vulkan implementation.
kid called mesa:
i like the volume on the loading screen, it gives that type of old game with some oversight which is cool. plus makes the loading screen something less boring, and if I want I can turn it off myself. Maybe not 10x the audio idk I LIKE IT