On this channel I'll share cool things I've learned and the projects I'm working on. You can expect to see videos on data structures, algorithms, graphics programming, game development and more! My videos are a mix of tutorials, that teach you how to create your own creative coding projects, and devlogs, that keep you up to date with my personal projects!
One thing you can do to vary the flow pattern is to use a Perlin noise with one more dimension than your display(3d on a flat screen, 4d on a 3d space), and vary that value(z for the 2d case, t for 3d) over time. That should create a smooth change in the flow pattern…
ive always subscribed to the idea that you code the game in mind and an “engine” is the end result of that. It is not a general purpose engine though, but a highly specialized one only designed to run the game you set out to make, no more no less
That's sort of what I've been doing with my current game, it's definitely not a general purpose engine! The issue with that is you've basically got to re-start any time you want to do a different style of game, which can eat up a lot of time! I totally get the appeal of doing things from scratch, but from a practicality stand point, if you're trying to get things done, I think it makes sense to use an off-the-shelf engine or at least a framework, so that the heavy lifting is already done for you!
@@BarneyCodes there's a set of programming paradigms that i recommend you look into: SOLID When you understand SOLID you will not only become a better programmer, but code that you write, no matter how specialized, will tend to be modularized in a way that can be reused for other projects. That said, i totally get where you're coming from. I started out writing a game from scratch myself only to stop and think if what im doing is even fun. In my case i do require a custom renderer, as it is meant to be a voxel ray traced game and in such a case i need to squeeze out as much performance as possible out of the hardware. Godot is a non-starter for me unless i modified the engine code and stripped out absolutely everything i don't need... HOWEVER! i am planning on prototyping it first, in Godot, to see if it would even be worth making. Is my game idea fun? is the question i want to answer before i dig myself in too deep with a custom "engine"
Just cuz i searched for conway one too many times and now, 2 weeks later, my youtube is just conway's game of life: I made a c++ implementation that can run thousands of generations in a few seconds, but more important: it works on an infinite grid. So, take that Barney Codes! I mean, it doesnt really matter but that doesnt stop me. cool vid
Only half way through but this is gold. I've dabbled a little with real basic shaders in opengl using c++ but all that VAO, VBO stuff gets pretty old very quickly. I've also dabbled in p5.js a fair bit but never used shaders (didn't even know until recently that shaders in p5.js were possible). Pretty excited to see what I can create with p5.js shaders. Many thanks for getting me started, much appreciated.
As a software engineer that uses the standard python and java / C# dabbles, this is like a wizard learning a different school of magic lol, so interesting
In this video I'm using P5js which is a creative coding library for JavaScript. It uses WebGL, but the concepts in this video should be translatable to whatever framework or shader language you're using!
This video is the best one I've found so far. The pro tip around 32:00 makes a ton of sense but I hadn't thought of it yet, glad you caught me writing my if statements lol. For context I've been working on my very first shader today! Coincidentally also in P5js like your examples. I came here because of confusing syntax errors I've been getting and although I'll have to troubleshoot those some more (or maybe explicitly define the webGL version the syntax I've learned is correct for? 😅) I think this is helpful. The project I'm writing a shader for is rendering the mandelbrot set, moving the load to the GPU as an upgrade to my current p5 sketch for it. The current version I already built has scrolling to zoom in and mouse-drag panning support, as well as using arrowkeys to change the canvas resolution on the fly... but especially at higher resolutions it's taking minutes to render, so it's far from responsive lmao. I failed to make the rendering function render asyncronously to a graphics object *and* have p5 move or zoom in on the last rendered frame while the next one loaded though, I guess because it's not waiting for 1 long operation or fetch and only for a bunch of small calculations, so doesn't ever hand control back while awaiting, so p5 just shows the preview change for a split second after the next image finally renders and then immediately slaps the new one it's been waiting for over it lol. So I'm skipping that idea since I don't feel like learning web workers for it and instead going straight to shaders for the real performance gains! Before watching this video I'd already ported over (from JS to GLSL) my functions for complex number multiplication, mandelbrot iteration, checking if points are inside the set (need to change to using step function now 😆😅), and for coloring points based on the number of iterations each complex number takes to escape... I was trying to pass some uniforms into it for things like the number of iterations and user input for zooming, but I haven't gotten it to load once without getting syntax errors 😒. I mean I also haven't finished some of the basic features like properly mapping between the fragcoords to mandelbrot space *while* taking the zoom input into account, but I made a map function for it that I was about to test when I got weird syntax errors while trying to load my shader for the first time. Previously in the non-shader cpu version I was mapping from pixelcoords to the complex plane (within a range depending on the zooming and panning) so it'll be a bit different and I'll need to make sure I don't stretch the image by the aspect ratio again like I initially did in the cpu bound pixel version, but it's a work in progress and the whole point of this project was for fun and learning!!! 😁
Rendering fractals with shaders is a lot of fun and a really great project to get familiar with shaders! If you get stuck, I've got a video on my channel about making a mandelbrot shader ;)
Really cool, I have never seen this done with a SDF. Usually this is done with a regular normal map where you use the normal vectors as offsets. That has the added benefit of not only being able to change the shape of the shockwave, but also give it a texture/roughness. You can generate the normal map from a shockwave mesh in blender for instance. You can then also rotate it etc. It can be really versatile, and be used for instance for heat distortion from a flame. But the SDF approach has the benefit of not becoming blocky/revealing the resolution of the texture if scaled up a lot.
It's certainly a more resource intensive than using a texture, but you can calculate the normal from the SDF. The thing I quite like about this approach is being able to change the shapes, it might not be very practical in a game but I think it's pretty cool hahaha Thanks for the comment!
I guess i misunderstood the first sentence of the video. You said its in many games. Not like infinite many shokwaves at the same time. I used a similar shader in my game. The limit was 10 fullscreen shockwaves at the same time. B.c. if you want to add a second wave you need to rerun the hole shader on the already distorted image from the 1st shokwave-image. Right? Thats not parallel at all. With my idea you can run 10000 shockwaves as big or as little at the same time all at once.
Oh I see! I was wondering about this, and I think with this method you'd be able to do them all in a single pass and accumulate the offsets for each wave before sampling the background image. Interested to hear your idea though for sure!
this is an exceptionally well made video. the pace and detail is awesome to reason about the content. Also like the display of "new image" vs "old image". Very well done.
@@BarneyCodes my eyes are trained for this specific mistake because someone configured an important variable with this mistake and unfortunately it has been replicated across the boundaries of an API. So everybody is writing lanGAUges because no one wants to update dozen of different repos
Excellent video! Your explanations combined with the animations made it really easy to follow along. Usually shaders can get pretty messy, but you did a great job
Thanks so much, that's very encouraging to hear! I noticed when I was learning shaders that there wasn't much beginner-intermediate stuff out there, so very glad that my videos are helping to fill that gap!
What are you going to use the shockwave effect for? I'd love to know! And don't forget to check out Code Crafters and get 40% off! app.codecrafters.io/join?via=BarneyCodes
I find it interesting that the particles can flow up and down freely, but they only ever move to the left. The cos function implies that the particles aren't restricted from moving right, but they simply never do. Is this because of the way that the noise is generated? I know nothing about perlin noise, so maybe there's a property about them that naturally excludes values in certain ranges.
You're spot on, it's because the noise values aren't very uniform (you can see that in this sketch: editor.p5js.org/BarneyCodes/sketches/xfnID7zDQ ), you can see it's clumped around 0.5, which maps to left with this code. So theoretically they CAN flow to the right, but the noise makes it WAY more likely that they'll go to the left! Not exactly sure what the best way to deal with that is, maybe there's some way to map the values to a more uniform distribution?
Someone else already mentioned this somewhere else, and you also replied, so I guess I'll just add to the pot: The line between "from-scratch" and "full engine" is often quite blurred. I agree with you that, in a lot of cases, doing things from scratch is often significantly more time-consuming, difficult, and annoying in the long-run. However, I think the subjectivity of the matter comes a lot more from where exactly you start. When you're developing your games, at least as far as I'm aware, you're not using assembly at all. Arguably, you could be going a lot more "from-scratch" if you wanted to, be it machine code, building a computer from the logic-circuit up, or even mining and refining the materials for the computer yourself. I quite liked the sheep and knitting analogy you used, but I wouldn't really say it's fully accurate. I might be able to shear the wool off the sheep myself, but at the same time, I could also buy the wool directly from a farm, while still spinning the wool into yarn myself. I think this can be applied to game dev in many ways, too. Sure, I could write my entire game using a custom physics engine, but at the same time, I could also use a physics library. Maybe I could opt to use a higher-level language such as Python, so that all the memory management is handled for me, unlike with languages such as C. I suppose what I'm trying to say is that it's not a binary between from-scratch and game engine, it's a spectrum between the two. I can go full game engine if I want to, but I could also opt to use a library, such as LWJGL or Raylib, which removes many of the difficulties which come associated with writing a full game engine from scratch. Aside from that, though, I'm loving your channel! It's hard to find non-clickbaity videos where there isn't some guy screaming into the microphone.
Great comment, and I have to agree! I left out frameworks/libraries entirely from my video which may have been a bit of an oversight, they definitely offer a very nice middle ground where you can still get your hands dirty, but you don't need to start from 0. My main aim with this video was just to get people to think about what they are actually trying to achieve and I think in most cases, going from scratch is not the answer! Thanks again for the comment and the kind words!
I haven't really explored the 3D side of things too much yet, but it's definitely something I plan on getting into! I'll be sure to make a video showing what I've learnt when I do! Thanks for the comment :)
I've been meaning to check bevy out for a while now, it seems really interesting! I think a framework (or similar) might be a really great way for me to still feel hands on and code-oriented, without having to do everything from scratch!
@BarneyCodes Being code orientated while not having to so absolutely everything is what I really like about Bevy. Also, Bevy docs are simply amazing. Ps. Great video by the way 👏🏿
Haha yea that was a bit of a fumble on my part, turns out you can pack a full float into the colour channels for lossless data. I knew it was possible in theory but wasn't sure how to implement it!
Godot's got a few bugs but it's pretty easy to get going on! Pronunciation's based on the play "Waiting for Godot", so it's close to Guhdough -- not Go-dot.
Yes. Now I'll watch the video. Edit. Loads of good points. I'm definitely in the camp of build an engine around a crazy concept and see if a viable game can be made, rather than make a game people want to play.
That's definitely how I got started in game dev too, always just trying something technically interesting that I wanted to code, then try and turn that into a game. I carried that mentality forward though when I was setting out with the goal of making a game which was a bit silly of me haha!
I loved your video. I totally get you, and I somewhat agree and disagree. Building things from scratch (provided you have experience) is a bit more straight forward because you're familiar with the process. Especially when it comes to 2D games, you can easily make a game without really an engine. I've done it in the past. But using a commercial engine like UE5 or Unity can be sooooo much better ONLY if you already know how to use them. Like you mentioned, lighting, bloom, etc. no need to configure a framebuffer yourself and code it yourself or even tweak shaders, you can just enable Bloom from the game engine option or click and drag a light actor into the scene. But... the downside of an engine is that, very much like programming things from scratch, it takes A LONG TIME TO LEARN THE ENGINE... and get used to it. So, in other words, you're back at square 1. Not to mention some engines require languages you might have never programmed in... such as GDScript or C#... I've only ever done C++. Either way, I don't regret not using an engine because it made me a better programmer. Now I've just installed UE5 and I'm learning Paper2D... Hopefully I can fully transition to it simply because... sound effects and music for free, and letter formatting for free that comes with an engine... as well as other visual effects, ohh that's just so convenient...!!! Less technical work for me to do and more focusing on the actual game! I just subbed, awesome video the way you phrased everything is to the point and very well explained!
Thanks for the great comment! Totally agree that there's a BIG investment in learning everything required to use an engine. Hopefully, having done things from scratch in the past, we'll have a good starting point and the transition shouldn't be too painful! There's always a bit of bumbling around when learning something new (like a new language), but I think the more you do it, the easier it is, because the concepts are transferable, it's the HOW that changes! Good luck for your UE5 journey!
Trap that's been luring me in: "Games with bespoke engines are easier to release updates for because the engine can be modified at any time. i.e. EVE Online"
