How good is Defold for desktop?

Questions
#16

I think you’re misinterpreting Ross. The analogy with Phaser and Love is pretty good. Defold has some features that are more mature than their counterparts in Phaser or Love and vice versa. The three products are still more bare bones than some of the massive engines such as Unity or Corona where anything and everything is included in the shipped product. If you expect Defold to provide you with many ready to use high level constructs such as those you can find in Unity or Corona then you’re out of luck. Defold will never provide those. Our philosophy is that if we were to provide for instance a high level GUI system with components such as buttons, checkboxes, lists, grids, screens, popups and transitions then it will work for many cases but it will never be perfect for everything. It’s much better to include the basic building blocks for creating a GUI system and then leave the rest to library/extension creators or the actual game developers so that they get the GUI system they want, not the GUI system we in the Defold team think you want.

When it comes to things such as hiding the mouse cursor or modifying the window properties on desktop then yes, ideally these features should be included in the engine itself since they are pretty basic, but as someone already pointed out, the focus for us has previously been mainly on mobile. Luckily the native extension system and LuaJIT’s FFI system has allowed the community to fill in the gaps with nice and easy to use projects such as DefOS.

5 Likes
#17

I can definitely see why one would find this misleading. We’re doing some work on defold.com behind the scenes, and looking at our messaging is one of these. Thanks for the feedback!

Maybe @sergey.lerg’s great OpenAL extension could help with this?

4 Likes
#18

There are quite a few third party libraries and extensions out there, but they are not very easy to find. That is a problem that is only going to get worse unless we fix discoverability. Fortunately that is happening. :slight_smile:

#19

Good to hear that there’s an extension for that! And I agree with @sicher about the discoverability :smile:

#20

What high level constructs are you talking about specifically? I didn’t use either Unity or Corona for a longer period of time - can you give me an example?
The stuff I’ve seen (also GUI) seems to be fairly high level to me - but that may be my libGDX background (or my inexperience with Defold)? :thinking:
One thing that isn’t there which I’m aware of is 2D light - are there plans on adding this?

#21

As Sicher said, it’s coming! Sticky Iron is a project the web team are working on—with some sort of soft launch happening in September. Meanwhile, check out this thread which collates a bunch of extensions, assets and libraries.

#22

Me neither, but just by looking at the API reference it’s easy to pin-point a couple of high level constructs:

  • Corona has a widget system. widget.newPickerWhell(), widget.newSegmentedControl() etc. These things are very unlikely to ever be found in the core Defold API. Such constructs can be created using our basic building blocks and then shared as a library, instead of forcing it onto every user of Defold.
  • Unity has the High Level API. The name speaks for itself. Yes, networking is hard, but throwing message handlers, high performance serializers, state sync and distributed object management into a single library is in my mind not the way to do it. I’d much rather make decisions on each of these myself.

Some other comments on Corona:

  • Corona has a transition system. This is similar to what you can create using go.animate() or gui.animate() in Defold. Corona also has some nice convenience functions such as transition.fadeOut(). These should perhaps not be included in the Defold engine, but they would be nice to have in a library.
  • Corona has LFS built into the engine. This is nice, but not useful for everyone. Personally I think it’s better to provide this as a native extension such as in defold-lfs and only increase the binary size (although very slightly) for those that require this, instead of everyone.
1 Like
#23

In a nutshell Defold needs some kind of “Essential Pack”, which would include a selection of extensions. Go to project settings and check/uncheck checkboxes with each such component to enable/disable it. Around there provide a link to sticky iron for better discoverability.

4 Likes
#24

Yes, or perhaps something in the ilk of Sublime’s or Atom’s package browsers. We definitely want this to be integrated into the editor for fast and easy access at some point.

5 Likes
#25

Okay I understand the point of keeping the engine tight instead of bloated and I like the point. But I would vote for official extensions - extensions like widgets - which get support like any other engine feature from official site instead of community. Of course not every extension needs to be official but for some things garanteed support is a major point. Coming back to my widget example - not every project needs them so an extension would be okay. But it should be there because users have come to expect certain input shemes (like the picker wheel you mentioned) and having a unified way to input data across apps and games is generally a good idea (at least in my opinion).

Edit: Maybe I should explain why I’m a bit paranoid of community extensions sometimes. Like I mentioned I started using libGDX and used it for a while. Since libGDX is a bit all over the place - you basically choose a different software packet for everything you do like level editor, physics editor, atlas generator, font, particle etc. you relie on all those little pieces to get a nice experience in general. Speaking about level editors - I watched how two promising projects died without any warning :grinning: Additionaly you might get dependency issues when using software from many different origins. That’s why it’s important to me that some features have official support.

3 Likes
#26

We use Defold for 2 Desktop FullHD prorotypes.

One of big problem it when you have huge scene with huge count sprites Defold Editor start very lagging and build very slow. Second problem it rebuild all project components every time when you start Editor or rebuild/bundle project.

Vsync problem present too.

But if you make small games it very easy for learn and work. And very good support on forum.

PS: Best Regards to Defold team!

5 Likes
#27

@tarnumius That doesn’t sound too good. But I don’t think that I as a beginning solo developer will run into such limitations :stuck_out_tongue: But out of curiosity, Defold devs is there anything that one could do to not get into such a situation? Is this a known problem?

1 Like
#28

It make developing little more complicated, but not really problem. Resolve problem with lagging - restart editor after edit full scene :slight_smile: If you edit small game objects it not really problem. (My projects used 4-5Gb RAM for Editor if opening full scene. We use about 500 images summarry volume about 500Mb)

PS: I think if Defold Team add function for clearing memory after close collection it resolve problem.

1 Like
#29

There are still things left to optimise. A few questions so we can benchmark better:

  • Are you running on editor 1 or 2?
  • What number of sprites do you have? How many atlases etc?
#30

It one of our project.
Now used Editor 2(more flexible) (We have about 1GB compiled textures :))

Atlases - 34
Sprites - 68

And more about 100 sounds

I use Notebook with 8GB Ram and this sometimes is not enough

PS: I know about small optimization with delete transparent pixelies in our images, but now it not important :slight_smile:

#31

Ok. That is definitely not many sprites.

Yes, the editor is pretty memory hungry. I guess your sprites have very large textures that cause the editor to slow down.

#32

Yeah we have not many sprites, but many animations.

#33

Are the atlases 4096x4096 or bigger?

#34

That’s my goal, to scare people away so I have Defold all to myself! Haha, sorry. Defold does a lot of things for you (I’m sure I don’t even know most of them), just don’t set your expectations at Unity level.

I took a look at the Godot website again and my own old projects. I probably exaggerated the difference between them. Here’s a list of things that Godot has out-of-the-box and Defold does not:

  • A fairly extensive array of GUI widgets. (though some of them are non-customizable and don’t work very well *ahem, *scrollbox ) This is probably the largest feature that Defold does not provide.
  • Spline paths & path followers. (and in-editor spline editing)
  • 2D lighting & shadows.
  • Pausing functionality built into nodes.
    • I never missed this. It’s just a difference in organization. In Defold you use collection proxies.
  • Easy in-editor check-boxes for features like render aspect ratio modes, stretching, etc.
    • Defold now mostly equal with Rendercam or Defold-Orthographic.
  • Easier camera setup, no worries about render depth clipping & precision (it uses integer z-order, then the hierarchy order of your nodes), built-in camera following, dead-zone, etc.
    • Camera stuff in Defold now equal or better with Rendercam or Defold-Orthographic.
  • Custom physics engine which doesn’t work terribly well (lots of momentary penetrations at 30fps), but has more features (CCD) and is totally dynamic. You can make any collision shape you want in-editor and change size, shape, collision masks, etc., at runtime. Defold uses Box2D which has most of this stuff, but it’s not exposed yet.
  • Visual animation editor, in-editor playback.
  • Animate basically every property by default.
  • Some “Animation Tree” animation blending features, though they kind of stink.
  • Editor plugins!
  • Tons of other random useful little functions that have an 85% chance of working, but are totally undocumented.

. . . and more general things:

  • Much more dynamic in general. In Defold most things are set and preallocated and can’t be easily changed at runtime (this is slowly improving I think).
  • More standard API, everything synchronous. Defold advertises asynchronous stuff as a positive feature, but it does cause serious headaches for some things.
  • Really nice, simple, “any-node-can-be-a-scene” system. Defold has the same capability, but splits things into “game objects” or “collections” and “components”, and it’s just . . . less simple.
  • A lower quality standard. Just read Juan’s latest blog post, he actively advocates for a quick-and-dirty, low quality standard, and that philosophy permeates Godot. He adds new features amazingly fast, but never adequately documents them and rarely goes back to fix/finish old features, so the engine is in a perpetual alpha state. The Defold team takes its time and does things properly, considering all the implications. Despite their quick update cycle, Defold is always release-ready.

As for the GDScript performance, I don’t have any detailed “proof”, as far as I can tell it’s just slow in general. I don’t know anything about how scripting languages are bound, unfortunately. But, just more instances of basic math operations seemed to take more CPU time than they should. You can test it yourself with a Bunnymark (Defold, Godot Note: these don’t use quite the same methods ) or something, just disable the graphics and see how identical scripts run in Godot and Defold. Last I tested with graphics, Defold could run 41% more bunnies.

This was quite a while ago, so it’s possible things have changed. I forget the version exactly, 2.1 maybe? I have a nightly build from 10-16-2016 (they started breaking things for 3.0 soon after that.) This was before the C++ and C# plugins existed. I assume using C++ would give you better performance. I believe you can use C++ entirely if you want.

[Edit] This is testing on Windows. I did test things on Linux too, but didn’t do direct comparisons.

8 Likes
Anyone here who has worked with Godot?
#35

Yeah 4096x4096