Yes, that is our plan. We get both an expanded C++ SDK and a C# SDK at the cost of one.
6 Likes
Lua has been the main scripting language for the engine, and I’ve heard that it would always be. I also understand that having C/C++ support is great for performance and is already the engine language, and due to the openness of the engine that would reasonable to extend the engine in a great way. What’s the idea with C# now? I’ve heard before that the Defold team were against this, but now things have changed. Unity used to have 3 languages, and now it’s just one. C# certainly attracts dissatisfied Unity users, and that’s a good reason to have C#, but as a Lua user I have concerns about a heavier, bigger engine. What runtime would the engine use? Mono, .NET Core? Would C# support be available as extension, or a different engine build? I think it would be nice to address those questions for the user base, if not done already (I may have missed something)
1 Like
Hi!
It seems a lot of users feel a worry about our upcoming C# support.
I don’t think there is a reason to. We’ll keep things working “the Defold way”, just as we have for the past ten years (that I’ve been working on Defold).
Small engine size and performance is still part of our main directives.
We’re not moving away from Lua as a the primary scripting language.
We’re merely adding C# support for our extensions, just as we already support C/C++/Java/Objective-C/Zig.
It will not impact the engine unless you choose to use C# extensions in your project.
C# support will come at a price (executable size, runtime performance etc), but that’s for the individual developer/studio to decide upon. We’re merely giving them the option. As for specific numbers, it’s too early to tell reliably yet.
As for adding more functions to our C++ sdk, it’s beneficial for certain studios to use those functions directly. E.g. to write more game code in C or C++ (and later C#). The effort itself is mostly cleaning up our apis, as they already exist in our private headers. The notable exception was resource.h which required a big refactoring/cleanup, which was a long time overdue.
As for C# itself, it’s a relatively minor change for us, as we already support many languages in our plugin system. We will keep our sdk’s in sync by generating the bindings. This will allow us to keep them up-to-date with minimal effort.
We’ve previously been against this C# support, but we decided to go for it for a few reasons:
- We’ve continued to get questions about C# support
- We’ve scoped it down to extensions only (i.e. low effort)
- We realized it won’t impact the core engine
- We can keep (generated) api’s in sync with minimal effort
- We get paid (!) for this task
We’ll use the DotNet 9 (currently in preview) with NativeAOT, thus generating static libraries that we can link against (just like any other Defold extension).
I hope this answers your questions.
11 Likes
Amazing release!
I’ve seen the Defold team answering that question a couple of times here and on Discord. I think it should be a good idea to make a sticky post or a blog about it.
3 Likes
Yeah, I thought the same thing! ^^
Thanks! This means that for the future we may have an extension that provides the full Defold scripting API in C#? That would be great to have if that is the case. Would attract lots of new users without compromising the Lua users. Sounds great.
I added an FAQ entry:
4 Likes
My friend is reporting that he can’t open the game anymore after I make a new build for OSX (I don’t have a Mac myself, I know his Mac is quite old to say the least).
Maybe the migration to glfw3 for MacOS is what broke it for him.
Do you see anything what might explain it in the following crash log? Building the same game in the previous version of Defold (1.8.0) still works.
Attached you will find the crashlog which hopefully sheds some light on the issue at hand :).
mmm-crashlog.txt (41.9 KB)
Dyld Error Message:
Symbol not found: _OBJC_CLASS_$_NSConstantDictionary
Referenced from: /private/var/folders/*/Martian Meteor Massacre 2.app/Contents/MacOS/MartianMeteorMassacre
Expected in: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
in /private/var/folders/*/Martian Meteor Massacre 2.app/Contents/MacOS/MartianMeteorMassacre
Are you using any native extensions? If so which ones? And which versions?
1 Like
Thanks britzl!
I’m using DefOS v2.7.1 and DefSave v1.2.5
Other extensions I’m using (not sure if these are native extensions) are:
- Defold Input 4.6.2
- Monarch 4.5.0
- HorriFold 1.0.0-beta3
- Defold Orthographic 3.3.0
This is the only native extension you have. I’m able to build and run it on macOS 14.5. Which version of macOS does your friend have?
OS Version: Mac OS X 10.13.6 (17G14042)
I’ll try to see what happens when I disable DefOS from a build for him.
I have rebuilt our glfw3 library for macOS, with support for osx 10.13.
You can try it here to see if it works better:
3 Likes
@britzl Disabling DefOS didn’t work. But thanks for thinking / debugging with me 
@Mathias_Westerdahl The rebuild with support for OSX 10.13 seems to have done the trick. When building with v1.9.1 alpha (and changing the build server to https://build-stage.defold.com) I got word that this version starts up again without any issues and plays fine.
Thanks again for all your support guys!
7 Likes
Is there any working compute program example? I try to follow manual, but can’t make it work.
I have a very simple example here, that I use for developing graphics backends with Defold:
It’s nothing interesting, but it can be a good starting point
2 Likes
Yep, probably it’s a hardware issue. I try to run on intel mac & Vulkan. Vulkan has issue with ‘non-opaque uniforms outside a block’ in shader, but fixing it still doesn’t help much.
This example actually works, thanks!
1 Like