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.
This is one of the things I like about Unreal. I can make glass easily in unreal without going into all this technical detail. I can choose to do this kind of extra work in Unreal if I want to go the extra mile, but it’s not required.
Godot needs stuff like this to be built-in by default. Glass is a super common thing that devs need to make, and having to do this wastes developer time they could be spending on more important things.
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.
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.
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.
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.
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.
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.
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.
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.
I agree, someone should work on that and make a PR!
Well, Godot is a lightweight engine, so it doesn’t have almost anything extra built-in. Which is advantageous because the engine itself then takes up negligible space on disk and the editor starts up within seconds, which can’t be said for Unreal. But everyone prefers something different, of course. I mainly wanted to show that implementing your own blur effect can be simpler than it might seem at first glance.
I don’t prefer something other than Godot. I’ve used a number of engines now, and I use what I do bcz I have to spend an inordinate amount of extra time doing stuff in Godot that are just blocks in other engines. It’s not a good use of my time as an Indie dev. I really enjoyed Godot when I first started making games, but once I got serious about making a commercial game I realized it just didn’t have the features I needed. I learned about the missing features from the engine devs themselves when they wrote a post specifically discussing the missing features for AAA games. (Not that I’m trying to make a AAA game). My game is just big enough that level streaming is important for performance.
@NocturnalMorning @FencerDevLog you really have three options here :
a) switch engines *highly recommended*
b) be the change you want in the world , submit patches and try to make godot better
c) continue to be upset and just complain a lot *definitely most fun option*
Easier said than done. You have to be an engine dev to submit changes, which is a whole other ball game. I spent a week trying to figure out an engine bug with the collisions once, and I couldn’t make heads or tails of the issue. If I started learning the engine code and submitting PR’s, I wouldn’t have any time to actually make games (which is what I want to do)
@NocturnalMorning side note , do you have a link to your game you are working on? besides all this bickering i would love to see what you are working on…
Sure, I have a bunch of videos on my YouTube channel of the game. Still pretty early stages, working on a boss fight right now that I haven’t recorded any of yet.
https://m.youtube.com/watch?v=ZTLKJUyqkMA