Hi everyone! Do you remember the video about detecting edges using the Sobel operator, which we enhanced by using Gaussian blur? One of the drawbacks of Gaussian blur is that it’s somewhat computationally intensive, which can pose some performance issues for our game if we want to apply such an effect in real-time. In this video, I will demonstrate a much faster way to blur our sprite or the entire screen.

  • @Quetzalcutlass
    link
    English
    8
    edit-2
    8 months ago

    It definitely slows down development needing to find third party solutions for basic tasks. On the other hand, knowing the implementation details means it’s easier to tweak things to meet your needs.

    The Asset Library is supposed to be a middle ground, but it needs a lot more content and polish before I’d call it ready.

    • @NocturnalMorning
      link
      1
      edit-2
      8 months ago

      Yeah, I just fundamentally disagree with the approach the Godot team has taken with the project on basic stuff like this. I want the project to succeed beyond Indie, but it never will until it takes stuff like this seriously and integrates it into the engine.

      Nobody but an Indie dev or hobbiest is going to want to waste time on this. There’s too many other things that need done to make a game to get bogged down by this one thing.

      I think water shaders are in the same situation. I can make nice looking water out of the box in Unreal Engine. But to make it interactive water takes a ton of work ontop of that depending on the scope of what you want to achieve, could even be months of work to make good looking interactive water if it includes actually height to the waves and not just normal maps. No way any serious dev team is going to want to go down the road of implementing the water shader under the hood first before they make it interactive.

      They’ll skip using the engine, and use something else. Unless they’re a big enough team with enough resources to have an engine dev team of their own, in which case they weren’t very likely to use Godot in the first place.

      • @WhiskyTangoFoxtrot
        link
        68 months ago

        Why does it need to succeed beyond indie, at least in the short term? Especially since they haven’t succeeded with indie yet. The Godot team doesn’t have unlimited resources; better to focus on one market than to spread themselves too thin trying to cater to everyone all at once.

        • @NocturnalMorning
          link
          -18 months ago

          They got a pretty big influx of cash from the fiasco with Unity. They could use it to implement these features. They’ve already hired a few additional people. They could also stop wasting time coming up with new names for everything and implementing breaking refactoring changes in each release.

          That’s why I’m not using it right now. I got tired of how broken and different everything was from 3 to 4.

          It’s probably somewhat better a year later. But I still read the release notes on the sub-releases from 4.0 to 4.1, 4.2, etc, and they are still breaking things from sub-release to sub-release.

          When I upgrade Unreal Engine, the programming doesn’t change significantly each time bcz the devs decided to rename and refactoring stuff for funsies again. From 5.2 to 5.3, something with the hair physics did break, but I didn’t have to recode anything that I already had, and I should very very rarely have to do that. That’s basic good software practices, and they’re not following them right now.

          Do I have strong opinions on software? Sure, but I’ve also been programming in various capacities for 15 years now, and I get tired of watching people turn stuff into dumpster fires bcz there’s no consistent direction. That’s Godot 4 right now.

          • @WhiskyTangoFoxtrot
            link
            78 months ago

            So you think that reworking previous things in a major version change in order to make a more consistent overall engine instead of letting every previous bad decision persist in a build-up of cruft is “turning stuff into a dumpster file because of no consistent direction,” and that the better use of the developers’ time would be to implement features that any half-decent shader coder could do on their own, and that anyone who wasn’t a half-decent shader coder could easily copy and paste from someone who was?

            I’m glad you’re not making the decisions for Godot. Curious as to why you’re hanging around the Godot Lemmy community, though.

            • @NocturnalMorning
              link
              3
              edit-2
              8 months ago

              It’s not more consistent. If it was, I wouldn’t have complained about it. When I brought it up to the developers, they admitted that they went overboard with the renaming of their stuff.

              Any half decent shader coder could do on their own

              Have you even read this thread, or did you just jump in to complain after the conversation started? I said, verbatim, this wastes time bcz there’s a ton of other stuff to do in developing a game, and serious game studios aren’t going to have time to do this stuff from scratch. And if they do have engine devs, or enough resources to do it, then they probably aren’t using godot anyway.

              For the record, I’m an aerospace engineer. I am plenty capable of writing my own shaders. The point is, and you seem to be missing that, I shouldn’t have too.

              I want to make my game, not spend time developing functionality that should already exist. Hell, I spent the last 6 months working on a game, adding inventory management, soulslike fighting, AI, a tutorial level, etc, and I still have a metric fuck ton of stuff to do. And I didn’t write my own water shaders, or glass shaders.

              Its about managing your time and resource, of which there’s currently only one of me to work on my game.

          • @Kelly
            link
            English
            68 months ago

            UE has been going since 1996, Unity since 2005., while Godot started in 2014.

            No one likes breaking changes but if they are needed then better done sooner than later.