Debug drawing

[Xrayez]

I'd like to implement a singleton which allows to draw stuff from anywhere.

• Add support for immediate-mode debug drawing godotengine/godot-proposals#112

It makes sense to add Debug2D/Debug3D singletons.

The implementation would be similar to https://github.com/Zylann/godot_debug_draw/blob/master/addons/zylann.debug_draw/debug_draw.gd.

Additionally, I want to add a way to commit draw commands and be able to sort of animate them (would be extremely useful for visualizing how an algorithm works step-by-step).

Useful stuff which can be integrated alongside core drawing capabilities:

• Add GridLayer class goost-plugins#1

I'm already working on this, feel free to suggest something that you'd find useful.

[Xrayez]

I have implemented Debug2D singleton: #162.

There's a nasty bug/limitation as seen in #163, not sure how to resolve. But my primary use case is drawing at run-time, not the editor, yet it would be nice to fix regardless. Update: fixed in #164.

[Xrayez]

@golddotasksquestions @DanaFo @ywmaa

Hello! I've noticed discussion happened in godotengine/godot-proposals#112. It's too bad they locked the proposal. I don't think it's going to be reopened, because project manager's decision to lock discussion is identical to this one: godotengine/godot-proposals#100 (comment).

Again, blame YuriSizov, aka pycbouh (read my post about him). They also see Goost as a threat to Godot's existence, so they prefer not to talk about it unless asked, see godotengine/godot-proposals#3864. They generally avoid everything that pertains to me, since they banned me now from all Godot communities, so I can freely criticize their toxic leadership now.

I see Calinou's suggestions to create a prototype in GDScript as a way to play a fair game and somehow smooth the rejection out, but I don't think this immediate mode debug feature is going to be implemented in Godot out of the box. Most of this is implemented in Goost via Debug2D singleton.

I suggest not to waste your precious time on these Godot proposals discussions. If not, I suggest to avoid talking to YuriSizov, because he's one of the most toxic members in Godot community. I mean, literally, just ignore him, it may be difficult to do because he makes up imaginary strawman arguments and goes into gaslight mode for the most part, but it's not worth to prove your point to him. But, your reactions are adequate to YuriSizov's gaslighting. He must not represent Godot project.

This is one of the reasons why I left Godot community... They are not interested in having professional game developers working on the engine, because it's easier for them to manipulate users who have no clue about Godot's governance and their hypocritical decisions. There's absolutely no meritocracy in Godot, nor even do-ocracy. It was always about trust and having an attitude of never questioning Godot's decisions if you want to get into their inner cult.

[Xrayez]

replace Juan ?

I think this is impossible. I've tried every productive approach with him, but his manipulative and coercive approach to contributors must be punished, therefore what you see me talking on Twitter is not just ramblings, I have good reasons to do so.

[ywmaa]

for now I read that you don't want to use Godot, maybe bevyengine.org could interest you. maybe you can find your visions are better executed there.

I have found Love2D for prototyping already, works great. I just have to port debugging and visualization stuff from Goost to Love2D/Lua, just what you see here with Debug2D in Goost. This is not a big deal.

I'm mostly interested in 2D, as you can figure by the feature set in Goost.

Unfortunately I almost know nothing about 2D in games, I can do some math, but what is a sprite ?
I don't know lol

I always work in 3D since unreal engine.

[Xrayez]

I'd also likely pick Unreal Engine if I were to start developing 3D!

[ywmaa]

Yeah I started in unreal but switched to Godot recently, and I found that doing stuff myself instead of it being ready made me learn more, so this is why I am using Godot 4

[Xrayez]

Hello! I've noticed discussion happened in godotengine/godot-proposals#112. It's too bad they locked the proposal. I don't think it's going to be reopened, because project manager's decision to lock discussion is identical to this one: godotengine/godot-proposals#100 (comment).

As predicted, it's been roughly a month, but godotengine/godot-proposals#112 is still not reopened.

[ywmaa]

after reading more of your twitter posts, I really suggest stop criticising godot for any aspect of it just for the sake of criticism, provide solutions (actual solutions that can be executed) or start a new engine that suits your ideas, maybe more people could find your ideas really useful, don't be destructive be productive.

[ywmaa]

godotengine/godot#19602 (comment)

juan here is right :

If you want a revolution, begin with it yourself. If you want to prove your ideas, invest in them because words are free.

[Xrayez]

Sure, but the thing is that, we, contributors, don't really want to make a fork of Godot. Most people in Godot community would like to prevent division. And now, Godot core developers get angry at me that I created Goost (which is not a fork, more like an extension), and say things like "you want undermine and sabotage Godot". This highly repulsive attitude is what made me completely abandon Godot, and not the other way. And that's probably another reason why you don't see much forks around Godot, because people don't even want to deal with Godot because of this community response: "you should not criticize Godot". 🙂

Here's a proof that Godot would like to prevent division:

• Godot Engine's vision and development philosophy should be better formalized or easily accessible godotengine/godot-proposals#575 (comment)

So, I have already tried the "productive" approach as you said. Preventing division means writing development philosophy. They refuse to write it, therefore division and difficult-to-resolve conflicts are inevitable in Godot community. Even if I create a fork, I'll be attacked for maintaining one. This is not healthy.

What I say on Twitter is the net result.

[Xrayez]

@golddotasksquestions

I think it may be worth to bring up a topic about Unity's ImGUI facilities at godotengine/godot-proposals#5196.

• Unity: Immediate Mode GUI (IMGUI)
• Unity: IMGUI Basics

I know that Godot may be repulsive to discuss Unity features, but you can bring those ideas, at least. In any case, I hope that helps!

[golddotasksquestions]

Not sure I understand. As a positive or negative example?
I don't have experience using these features in Unity, so I would not want to bring it into the discussion honestly.

[Xrayez]

I just noticed the discussion started to shift towards ImGui solution. For that matter, Godot could reinvent Dear ImGui capabilities, with its own technicalities in relation to Godot of course. There are even Godot' modules that integrate Dear ImGui for that matter, like https://github.com/pkdawson/imgui-godot.

So, it's not really about Unity. If a feature like this already exists in Unity, considering that a lot of Godot folks want Godot to become like Unity, it makes total sense to have Unity's ImGui feature set. Feel free to ignore this, though. Of course, that's only part of the solution, I just wanted to show that the approach and/or implementation ideas can be taken from ImGui.