The last hack day I continued the work on the joints, but this time I focused on the design. I.e… thinking of the future editor support for them and other concepts needed in order to make the feature robust. Some new things popped up which we’ll have to address. However, my hope is still that we can make an MVP that gives you at least the scripting interface for it. But, ETA still unknown 
8 Likes
mmmm 
6 Likes
Not sure if we have any teasers. I’ve been working a lot on improvements to our testing environment and processes (boring but necessary stuff). I’m currently wrapping up a Lua module to work with the accelerometer on mobile devices, and prior to that I’ve done a bunch of bug fixes in a couple of my assets, as well as a working analytics extension for Google Firebase (iOS support is pending).
@jhonny.goransson might have some cool stuff to show regarding his recent work on the fonts.
And maybe @sven can show some metrics from our upgrade of Emscripten (smaller and faster)?
12 Likes
Anything new, Mathias? (joints… physics.)
4 Likes
Curious as well, especially on the editor side since it seems like the one getting less attention
1 Like
No, nothing new. Mathias has mainly been working with our native extension system.
Unfortunately we’ve been understaffed in the editor team. This is soon changed as we’ve hired two new editor devs, both starting in January.
11 Likes
I’ll jump in and tease a bit of the iOS simulator branch;
Demoing a bundled iOS simulator compatible app and launching a game through the editor.
28 Likes
Optimizing background resource loading
I’ve been spending my exploration day (and some evenings before that) digging into the preloader - there have been reports of stuttering while loading data in the background and I also have been curious in figuring out how the code works.
The main focus has been to reduce the time the engine spend managing background loading while executing the main game loop, as much as possible should be done in the background thread. At the same time I didn’t want to affect the absolute time for the loading to complete.
The end goal is smoother loading, not necessarily faster loading.
I noticed that the queue to the preloader tended to get full which caused it to not load as much resources in the background as it should and instead putting that work onto the main thread. There were some refactoring that needed to be done to allow to increase the queue without taking up a lot more memory. The queue is not significantly larger while not using any more memory than before and the games I have tested show that we are no longer bound by the size of the load queue.
Next I look at what else was taking time in the main thread and found some memory allocation/deallocation related to the load queue was hitting the main thread - a minor refactoring and that was moved to the background loading thread.
Another thing that was hindering the preloader was lock contention - while the main thread was checking and doing final creation of loaded resources the loading thread could get blocked when it found more resources to preload. More refactoring and the contention was greatly reduced.
Finally I tweaked how the main thread checks for work done and how long it waits for incoming resources from the loading thread - we don’t want to hang around and wait to long causing frame rate issues but we don’t want to rush it causing us to wait more frames for the loading than necessary.
Here are the results so far from testing one Kings in-house games:
WALL TIME is the time it takes from the game script requesting a load of a game collection until the loading is complete.
MAIN TIME is how much of that time is spent creating loaded resources and checking if the loading is complete.
I’m comparing between our current dev branch which is what we have so far for the next release (1.2.143) and my changes.
OLD:
WALL TIME: 12,2 seconds
MAIN TIME: 3,1 seconds
NEW:
WALL TIME: 9,9 seconds
MAIN TIME: 1,5 seconds
So, pretty good results. Of note is that no optimisations has been done on the actual resource loading, all that is same code and same format, we get the benefits just by making sure the preloader can run as unblocked as possible.
Hopefully this will lead to less frame rate stuttering when loading resources in the background, it needs more testing but it is looking promising.
33 Likes
Today I’ve experimented with having our physics simulation run with a fixed delta-time instead of going in lockstep with the framerate.
In this video we see Box2D running in 300 steps/s and in 20 steps/s respectivly. When debug-rendering the physics shapes the lower rate or 20 steps/s becomes more evident. The actual gameobject components has their position and rotation interpolated to still get smooth rendering at whatever frame rate the rest of the gamesystems are running in.
Decoupling the physics timestep from the global game timestep lets us be more flexible in using actual frame duration timestep in the rest of the engine, which should work well for most cases that are otherwise hard to cater for using a global fixed timestep (variable refreshrate monitors, phone battery saving modes, missing desktop drivers etc.).
Next up is of course 3D physics, as well as figuring out how collision notification should work with messages if we for example take multiple physics step within a single frame.
21 Likes
I’ve been looking into the font rendering a bit lately and added support for “multi-layered” font rendering. This should help to fix stuff like outline bleeding/covering and shadow offsetting. Also, I’ve implemented shadow support for distance field fonts so you can do stuff like drop shadows, soft shadows and / or glow effects. It should be available in the next release 
Happy friday!
23 Likes
Awesome! Love more text features. 
3 Likes
Sneak peek on a feature we’re shipping in the next release: Local and World vertex space.
We’ve added a new property to materials that dictates how the meshes that the material is associated with should be rendered and more specifically where vertices are transformed. There’s two options - vertex-space-local and vertex-space-world. World is the classic way of transforming and batching, just like it works in previous releases. Local space however doesn’t transform vertices on the CPU or put them into a large vertex buffer. Instead this is performed on the GPU which is much faster for models that have huge amounts of vertices.
This will break batching since we can’t share world transforms anymore, which means that the draw calls will increase, but as you see in this video the rendering is much faster for 3D rendering with detailed geometry. There’s a bunch of things that isn’t supported yet, but this is a decent first step towards better overall 3D support which I hope people will utilize more in the future!
19 Likes
Another exploration day today
Today I continued working on the results from a previous exploration day: Supporting ProGuard for Android. It’s a tool used to remove redundant Java classes, and also to optimise byte code, and obfuscate functions.
Today I mostly worked on the actual pipeline of this feature. My goal was go get a MVP working.
In the future, this feature will be improved upon along the way, when we start supporting AAR files as well (Android archive (Zip) files containin libraries, jar files, manifest stubs and also ProGuard files).
All in all, this first MVP feels ok, it just needs some cleanup (and some discussions) and I hope this can be released in a sprint or two.
A new game.project setting:
The final size compared to the same (empty) project without using ProGuard:
Here’s a glimpse of how a .pro file looks like:
19 Likes
Another exploration day!
A lot of cool stuff happened in the office today 
Here’s one thing I implemented: Synchronous Raycasts!
In this example, the (kinematic) hero uses 3 raycasts, directly in the update function, to resolve it’s collisions.
Calling the function 3000 times from Lua takes ~5ms (if you get a hit), or ~2ms (if it misses).
This is an actual pull request, and if it passes the design review, it should land in one of our next releases.
22 Likes
That’s actually super useful. I have a Button class that works with game object sprites and I do the picking manually. Maybe it can be done with this instead.
2 Likes
On this exploration Friday I decided to add extra polish to printing of values evaluated from editor. It will try to print as close to Lua data literals as possible. In places where it’s not possible, for example, in cases of circular references, function values and custom types, it will hint on impossibility to print that by using <angle brackets>
18 Likes
This is very good news. For static environment this is enough. But if we want to move raycast target and cast rays again…
Can your raycast implementation do what I quoted above?
This is just the raycast function.
There is currently no way to update the physics engine manually, to update the broad/narrowphase info.
My exploration day was dedicated to this library for simpler message sending from JS -> Lua: https://github.com/AGulev/jstodef
On Lua side:
local function example_2_listener(self, message_id, message)
if message_id == "ObjectEvent" then
--do something
end
end
function init(self)
if jstodef then
jstodef.add_listener(example_2_listener)
end
end
function final(self)
if jstodef then
jstodef.remove_listener(example_2_listener)
end
end
On JS side:
-- Any your async method
setInterval(function(){
JsToDef.send("ObjectEvent", {foo:"bar", num:16});
JsToDef.send("FloatEvent", 19.2);
JsToDef.send("IntEvent", 18);
JsToDef.send("StrintEvent", "str");
JsToDef.send("EmptyEvent");
JsToDef.send("BooleanEvent", true);
JsToDef.send("BooleanEvent", false);
}, 3000)
14 Likes
Hi all, I just wanted to showcase a little bit of progress on our Vulkan renderer that I’ve been tinkering with on and off for a while now. As you all might know we need to have support for a Metal rendering backend for iOS and MacOS due to the upcoming deprecation of OpenGL. Right now we are exploring the use of Vulkan with MoltenVK as a translation layer so that we could potentially have the same API for all platforms. Furthermore, this could give us (or you guys actually) a bunch of new tools to do some really stuff in the 3D space later on
The left window is a Defold ‘game’ using OpenGL and the right window is the same Defold ‘game’ but with a Vulkan renderer (actually it’s translated into Metal in reality, but written with the Vulkan API).
Disclaimer: As you can see, it doesn’t look exactly same right now, I haven’t really looked into draw state management so alpha blending is turned off for now.
25 Likes