Good to hear that there’s an extension for that! And I agree with @sicher about the discoverability 
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)? 
One thing that isn’t there which I’m aware of is 2D light - are there plans on adding this?
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.
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
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
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
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 
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
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
@tarnumius That doesn’t sound too good. But I don’t think that I as a beginning solo developer will run into such limitations 
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
It make developing little more complicated, but not really problem. Resolve problem with lagging - restart editor after edit full scene 
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
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?
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
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.
Yeah we have not many sprites, but many animations.
Are the atlases 4096x4096 or bigger?
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.
9 Likes
Yeah 4096x4096
That’s a brilliant answer! It will help me with my engine considerations alot. Thanks so much for the effort
2 Likes
You’re welcome! The Battle of the Engines is a real pain in the butt, I know.
On a more practical note (and your original question), I’ve fiddled with DefOS a bit. On windows, with the DefOS lua module, pretty much everything works perfectly. I did have an intermittent issue going back to a maximized window from fullscreen—sometimes it resized the window based on its inner dimensions, meaning the title bar and borders were outside the screen (one way to do borderless windowed I guess? 
). But, it was pretty easy to work around that (toggle maximize off when going fullscreen and back on again after). A little extra flicker maybe, but no big deal.
Give it a whirl here if you want (assuming you are on windows).
Defold - Ross Fullscreen Test (Win).zip (4.9 MB)
Press space to toggle the mouse cursor, enter to toggle fullscreen, and alt-enter to toggle maximize (or use the default windows stuff). Don’t mind the vaguely game-like things going on. 
I did a very quick test with Defold’s built-in fullscreen. It does seem broken. Unless I built the game with my monitor’s resolution it stretched things out of whack. That may depend on your render script though, I didn’t try to mess with it.
5 Likes
Yes, the default render script would stretch your game if the aspect ratio changes from what you have in game.project when launching and when going into full screen mode.
1 Like