colugomusic
patreon
Dev Log #63 - Bug fixing and stability (boring post)
🕑 Added 2022-04-05 23:51:59 +0000 UTCSince the v0.21.0 build all I've been doing is working on bugs and improving stability. I won't be adding any new features until I am happy with how things are working. So v0.21.1 will just be a big bug-fix build and then the plan is still to do a "free-for-everybody" public build (probably v0.21.2 or v0.21.3.) I'd like the public build to be useable for long sessions without fear of crashes or everything breaking horribly.
Even though no new features are being added, some parts of the codebase are changing quite a bit because of refactors and large changes to the way I am doing things. I've ascertained that some of the "random" crashes are definitely caused by the fact that I dynamically pull things in and out of the Godot scene tree during things like drag+drop, resizing and even just hovering over blocks.
For example when you click on a block to begin dragging it, it is moved out of the scene tree and temporarily placed into a canvas layer so that it can appear above other UI elements. Then when it is dropped it is removed from the canvas layer and inserted back into the scene tree inside the appropriate lane control.
Godot technically supports doing this, and it is how Blockhead has worked for a long time now, but in practice moving things around the tree in this way tends to cause a particular category of problems which i refer to as "pissy little fucking problems". Moving something in and out of the tree in a single frame is particularly troublesome as Godot controls sometimes need a frame or two to initialize themselves properly after entering the tree. I tend to end up writing a lot of garbage code just to deal with some of Godot's unpredictable behavior while manipulating the scene tree. Things that seem like they should be very simple like detecting if the mouse is hovering over a control end up being extremely fiddly due to Godot weirdness.
So one of the things I am doing at the moment is changing everything so that block controls always sit in the same place in the scene tree, which will be a sort of invisible layer that sits on top of most of the rest of the UI. When a block is on a lane it won't actually be placed inside that lane's control in the scene hierarchy, but it will instead be floating above it and positioned in a way that makes it look like it's on the lane.
The positioning and sizing of blocks is basically what I am doing already anyway, so not much will change there, except that they won't have to move around in the scene tree anymore which should solve a lot of my problems (and i'm pretty sure it will eliminate a few hard-to-reproduce crashes).
The other large change I have been making is to change a bunch of old code to be less tightly tied to Godot's object system. In a Godot C++ project if you need something to interact with GDScript, or otherwise want to take advantage of some feature of Godot's object system, you need to register your classes with Godot.
From the start many of the objects and system in Blockhead have been written as Godot-registered classes but over time I have settled into a neater way of doing things which doesn't rely so much on Godot's object system. I also rarely use GDScript for things anymore outside of prototyping so it is not necessary to expose so many things to the scripting language.
Godot-registered classes allow you to do some cool things but they also have a bunch of problems, mainly:
- They're more verbose
- They can't have constructor arguments which basically forces you to structure your code in a stupid way
- They have to be allocated and deallocated in a particular way, and always on the heap
- It's easy to make typos or type errors when using Godot's signal/slot connection mechanism which can lead to runtime crashes
Therefore I have been "ungodotifying" a lot of old C++ classes and rewriting things in a way that no longer relies so heavily on Godot's object system. This has allowed me to clean things up quite a bit which should be good for maintainability, and hopefully lead to less bugs down the line.
Blockhead Wiki
In case you didn't know, there is a Blockhead Wiki here:
https://blockhead.website/dokuwiki
It's still quite barebones but big thanks to fkeyz and yankscally for adding a bunch of stuff already.
Unfortunately public editing is not enabled because a bunch of bots found the site and started messing stuff up, but if you'd like to help out then just contact me and let me know your user name and I'll give you edit permissions.
