Defold roadmap H1-2019 - Q1 summary

Roadmap
1

Beginning of the year we posted our roadmap for the first half of 2019 and now that we’re halfway through it’s time to summarise what we’ve done so far:

Engine

  • Resource properties
    • Not finished yet. Work planned to start beginning of Q2.
  • Multi-texturing
    • Not started yet. Plan is still to ship this functionality in H1.
  • Modularization
    • Webview moved to a native extension.
    • Push and Facebook soon to follow.
    • IAP sometime during Q2.
  • Audio
    • Design for an improved audio system is on-going.
  • Bug fixes and improvements
    • The source of one ANR has been identified and fixed.
      • os.exit() (hard exit) vs sys.exit() (clean exit).
    • One other ANR source has been identified and will be fixed soon.
      • HTTP requests and blocking calls to getaddrinfo while engine is shutting down.
  • Platform compliance
    • iOS SDK 12 support has been added.
    • Migration from GCM to FCM done.
    • Android 64-bit support in progress.
      • With upgrade to LuaJIT 2.1-beta3
  • Metal and Vulkan
    • Very good progress is made.
    • Shaders are now cross compiled using SPIR-V.
    • Proof of concept with Defold running Metal via MoltenVK and Vulkan on iOS.
  • Improved 3D support
    • We released local vertex space support in 1.2.146.
    • Custom vertex formats planned for end of Q2.
  • New platforms
    • iOS simulator support has been delayed.
      • New plan is to release it early Q2.
  • Google Play Game Services
    • Plan is to start working on this early in Q2.

Editor

  • Unified build pipeline
    • This has been down-prioritized with a new plan to release before end of Q2.
  • Improved undo workflow
    • Will be released early Q2.
  • Editor extensions
    • A design for editor script extensions has been made.
    • Editor script extensions will be released in Q2.
27 Likes
2

Awesome! :+1:

Will the old GLSL shaders work or will we rewrite everything on SPIR-V?

Just wondering- why not just use MoltenGL?

5 Likes
3

The old shaders will still work. We’ll transpile them between compilers.

We wish to build a more modern graphics api, and we believe Vulkan is the way forward there.

9 Likes
4

This means both of them will work? In one project?

2 Likes
5

You must still write your shaders using OpenGL ES SL. We will not support any other shader languages in the beginning at least.

3 Likes
6

That means that we could define plane, quads and other hexagons without loading a .dae ?

Nice ! :+1:

3 Likes
7

Actually, it’s a benefit for me, because I recently have been working with a lot of OpenGL shaders :smiley:
And I think a lot of users got used to them too :wink:

1 Like
8

Is there any other plan for the editor other than those big tasks?
I feel there’s a lot of usability fixes/addition that the editor could benefit from, and that would help streamline the workflow

2 Likes
9

We are constantly improving the editor. Our recent release notes shows that we’re doing quite a few things in the editor currently.

The roadmap lists high level larger tasks and not the nitty gritty details. We will continue to make improvements to both editor and engine. We will work on more things than those in the roadmap.

Could you please give some examples?

10

Thanks a lot!

Most of these are already in tickets but just to give an example:

  • drag and drop. Would love for example to add a script to a go by just dragging it from the assets list into the outline
  • keybindings. I test a lot on both desktop, mobile and html5. I really miss an hot key for the build html5 option :wink:
  • reordering of animation frames by drag and drop in the editor. Currently I have to open the text file and change it there
  • maximizing the code editor window
  • go.property support for table of index+string pairs, that would result in a drop down menu in the editor
  • remove a project from the long list of previously opened projects at the start of the editor. Sometimes you test things but you don’t want to delete it just to clean up that list
  • mute a script or a go in the editor for testing purposes, without having to remove it from the outline
  • be able to collapse groups of options in the project settings window. It has become a really long list of options that you need to scroll through.
4 Likes
11

Actually, you can use Alt+Up/Down for that :wink: . The only issue there is that even changing the order of the frames triggers atlas re-generation, which hangs the editor ~1s, making larger reordering tasks still require a text editor.

2 Likes
12

Yes oh yes, I agree. It’s on our list of things we’d like to do. Can’t promise when though.

This will happen.

Alt+up/down works. But slow as @dapetcu21 points out.

You’re in for a surprise soon! (oh, dang, I ruined the surprise!)

Nice, but complex. Involves the engine as well. This will not happen any time soon I’m afraid.

This should be a quickwin I guess. @mats.gisselson, @vlaaad, @markus.gustavsson?

When you say mute, what do you mean specifically? Disable it? Suppress print()?

We will add search to the project settings and other similar views.

3 Likes
13

Didn’t know this. Will try thanks!

1 Like
14

Thanks a lot! This is indeed really good to hear.

The mute script/components is like the eye option in photoshop if you will. Component is still there but is being ignored completely :wink:

1 Like
15

Will multitexturing allows something that @Pkeod proposed here https://github.com/defold/editor2-issues/issues/844 ? Or is it something different?

1 Like
16

It is exactly that. An atlas will have multiple layers with the images per layer laid out in the same arrangement in the texture(s).

3 Likes
17

Yeah! :smiley: so then, lighting with normal mapping will be possible to implement easier? Will you guys, please, add some explanation or tutorial about multi texturing after the release? :wink:

3 Likes
18

Isn’t that an unnecessary restriction? Maybe I have a common layer that want to use as a second texture in multiple shaders? Say, like a noise texture. Why not each atlas is a texture, except components/materials can accept multiple texture slots.

1 Like
19

If you have multiple atlas files, say one with a diffuse and one with a normal images, how would you then connect the two? You still want to be able to do things such as sprite.play_flipbook() with an image/animation name and not have to worry about the sprite using a multi texture atlas.

4 Likes
20

Hmmm… Yeah. I see it now. That’s a good way of doing it. Though I’d like to have the option to also have detached textures that I can use separately in a material. A burning paper tresholding shader with a noisy texture comes to mind, as an example. You’d want to use the same noise texture everywhere you apply the material, regardless of the actual sprite texture.

(Something like this: http://kylehalladay.com/blog/tutorial/2015/11/10/Dissolve-Shader-Redux.html)

4 Likes