4 ms·
Next week the answer to your question is probably "yes" https://twitter.com/NathanGDQuest/status/1430992735192985605 https://twitter.com/NathanGDQuest/status/14
by humps 5y ago
Next week the answer to your question is probably "yes" https://twitter.com/NathanGDQuest/status/1430992735192985605 https://twitter.com/NathanGDQuest/status/1430992735192985605
- adamrezich 5y agoyooooo that's rad! great news for Godot!
- jay_kyburz 5y agoJuan made it very clear in a follow up tweet that Sega would have had to have made significant changes to the engine in order to ship a game on it. I spent three months working in Godot a few years ago and it was clear even then that there were significant bugs in major systems. If you want to ship on Godot you had better be prepared to roll up your sleeves and dive right down deep into the engine. This is one of the few bugs I logged before finally giving up on the engine. https://github.com/godotengine/godot/issues/32383#issuecomment-899122701 https://github.com/godotengine/godot/issues/32383#issuecomme... The object pooling system reuses references so that your script can't tell when a reference to an object it is holding, changes. They doubled down on the bug by making the behavior in Debug different to a Release build. It's marked closed, but users still report it happening.
- kevingadd 5y agoAside from whether this should be fixed, that's a classical problem not unique to godot: https://en.wikipedia.org/wiki/ABA_problem https://en.wikipedia.org/wiki/ABA_problem The real problem is that you are not properly managing the lifetime of your objects so you have dangling references. Obviously Godot could provide better tooling to help you identify and troubleshoot it, but dangling references like that will cause breakage in basically any runtime environment that makes it possible to have them. IDs of that sort can be reused in many environments. For example, if you use Unity, .NET GCHandle IDs can be reused in the exact same way.
- jay_kyburz 5y agoSure, there are easy workarounds, but the issues are unexpected and secret (and now only in release). In any other scripting language I've worked on you can do some test on a reference to see if its null or doesn't exist. In Godot you have to listen for the object reference leaving the scene. I can guarantee this is not an issue in Unity where a object that has been removed from the scene is null.
- kevingadd 5y agoAs it happens, Unity has its own version of this problem, where it pretends that a non-null dangling reference is a null-reference: https://jacx.net/2015/11/20/dont-use-equals-null-on-unity-objects.html https://jacx.net/2015/11/20/dont-use-equals-null-on-unity-ob...
- jay_kyburz 5y agoThat is not the same at all. The equivalent would be that your reference is pointing to some other object in the scene.
- thaumasiotes 5y ago> In any other scripting language I've worked on you can do some test on a reference to see if its null or doesn't exist. Except - and this is called out in the github thread - the reference is not null and does exist. The check is working correctly. The problem lies in the fact that what you want to check for is "is the object I originally pointed to still around?", but instead of doing that, you're checking "is the thing I'm pointing to currently a valid object?".
- jay_kyburz 5y agoYes, but read further, there is no method to test whether the object I pointed to still exists. You have to listen for a signal that the object is leaving the scene and manually clear your reference.
- dkersten 5y agoMy experience back in 2018 was similar. I wanted to do some fairly simple 2D things and it was quite a lot of hassle. I’m sure the issues I hit are fixed now, but at the time it was frustrating. With that said, I’m still happy to have contributed a little bit of code to gdnative. Nothing exciting, just some quality of life stuff I wanted at the time (a few variadic template wrapper functions around the C api to avoid having to manually construct godot list objects of parameters). Last I checked it was still in use, although moved to a different file.
- Arech 5y agoOne of the funniest moments I've experienced with Godot while developing the FitOwl [1] was the behaviour of a flag that governs sleeping state of RigidBodies. That flag was meant to exclude the body from physics-related computations to save some CPU-cycles and it just didn't work. When I reported the issue to the bugtracker, I was asked by devs literally "I still don't understand the issue you're experiencing. Aside from saving resources, why is it important that Rigidbodys are asleep?"... I was (and still is) speechless from that attitude, because, c`mon guys, the sole reason for that flag is to save some resources! But they didn't really cared about that, just reworded the docs a little and happily closed the issue. Moreover, I got an email from one of the Devs stating that I'm violating their Code of Conduct for the phrase "I'm struggling to not interpret your comment as a joke.". That was the last time I tried to take part in Godot improvement... [1] https://news.ycombinator.com/item?id=28402743 https://news.ycombinator.com/item?id=28402743
- meibo 5y agoA lot of ports, especially from Japan, only do menus and graphics in new/general-purpose engines and use a native library with their old codebases for logic. I can imagine that this was done here, Godot isn't really ready for a game like this IMO - it would have taken a huge amount of work.