Defold 1.2.128 teaser and an update on the roadmap

[britzl]

We know that many of you want better insight into the long term plans for the Defold engine. I wholeheartedly support that plan and I am actively working on how to best share a long term roadmap with you guys. I would also like to somehow involve the community more, perhaps by opening up for voting on things in the backlog or through live Q&A sessions.

While we’re not ready to share a roadmap yet we will start to share what we have planned for the next release. As soon as we have more information about the long term roadmap this will be shared, but for now please make do with what the team planned for the 1.2.128 release:

ENGINE
DEF-2918 Resource component properties - Reference materials, models, textures, fonts and other resources as script properties and use go.get/set to change these at run-time.
DEF-2830 Spine skinning. Change spine skin on individual slots.
DEF-3275 iOS crashes when using certain combinations of extensions
DEF-2747 Cancel local push notifications
DEF-1183 Engine provided timer functionality
DEF-3056 Spine events in gui scenes
DEF-3198 Need to click twice in HTML5 builds

EDITOR
DEFEDIT-1235 Edit JSON files in the new code editor
DEFEDIT-1345 If you move nodes using alt+up it breaks layouts
DEFEDIT-1373 Improve font compiler (for decreased build times)
DEFEDIT-1381 Saving a large project on Windows 10 can take several seconds
DEFEDIT-1382 Hide/show visual guidelines

While this is what was planned this morning we all know that software development doesn’t always go according to plan. Unforeseen things can pop up, bugs in the live product may be discovered, team members can become ill and so on. Please take the above plan with a grain of salt. Not all of it might make it into the next release.

[tacklemcclean]

I’m curious about DEF-1183 Engine provided timer functionality

I’ve rolled my own timer solution, using (abusing?) __dm_script_instance__ knowing full and well it’s not officially supported.

Right now on my trello board I have one card reading “Timer-issue if changing timer solution”. So my curiosity is based on whether I will have to change my current solution, and if so how big of a change.

So I basically wonder two things:

• Any current plans on changing the access to __dm_script_instance__? How “risky” is current use. (I’m guessing you can’t say much more than it’s unsupported, I get that )
• Will the new timer solution be able to “call as certain instance”?
  - What does the api look like?

Edit:
Just saw the video now regarding this, so the api question is somewhat answered

[dapetcu21]

Awesome initiative with posting the current sprint! I know making these posts takes time away from your work so, at least speaking for myself, I’m really grateful that you’re doing it.

Two questions about the timer functionality: Is its timing based on dt or on some other timing mechanism? Also, does it respect a collection’s time scale?

As, @tacklemcclean mentioned, I had my own timing solution based on __dm_script_instance__ and I’d be super glad to be rid of it.

[britzl]

@engelbrecht.dan should be able to answer about the details of the timer solution were developing.

[inactive-vilse]

@tacklemcclean and @dapetcu21, your existing solutions with accessing “dm_script_instance” should not break with the new timer implementation although I would not recommend building anything relying on that global variable since it is only intended for internal use.

The first iteration of the timer API will be two api functions:

local id = timer.delay(delay, repeat, trigger_callback_function)

local was_cancelled = timer.cancel(id)

The delay is given as a time in seconds, the timer trigger will fire with the resolution of the game loop so higher FPS means better precision.

A repeating timer continues to fire the trigger with the interval until it is explicitly cancelled with timer.cancel(id). If repeat is false it will only trigger once and then get automatically cleaned up.

In the callback you get the instance, the id of the timer and how long time has elapsed (in seconds) since either the timer was created or the last time it fired so you can do correct calculations based on elapsed time.

The timer.cancel(id) functions return true if the timer was still active at the time of the call - it is legal to do timer.cancel(id) on a timer that has already been cancelled or if it is a one-shot timer that has already triggered in which case it returns false.

The timer is tied to the script instance so when the script is unloaded the timer is cleared, if you want to have timer across script boundaries you need to resort using to msg.post() inside your timer callback function.

Hope this answers you questions!