Teaser Fridays and Roadmap talks


Here is a little preview of a work in progress…

The video demo both a new “buffer” resource type and a new “mesh” component. The buffer resource is essentially a resource version of a dmBuffer::HBuffer, and the mesh component is a very simple component that uses buffers and renders them as vertex buffers. Combining these should open up a lot of new possibilities; custom meshes, implementing the official Spine runtime as a native extension, or why not write your own custom particle/sprite system? :slight_smile:

Buffer resources, just as runtime dmBuffers , can include any combination of streams and types. This means that you can supply positions, multiple uv coords, normals, tangent vectors etc… Essentially whatever you like, as long as the material attached has attributes for them. For this demo I wrote a simple script that convert OBJ files into .buffer files. Together with our plans for editor extensions, I think this can result in some really awesome Defold libraries.

Also, since .buffer resources turns into dmBuffers at runtime, we already have a runtime API to modify them (shown last in the video above where I modify the position stream for the buffer when dragging the mouse pointer).

As always, I want to point out this is an early WIP and things might change drastically. It’s currently being prototyped together with the design for custom meshes and has already gone through a couple of different ideas, but I have a feeling we are on to something here. :wink:



Love it!



looks great. only problem I see at first glance is that then we’ll have both a model and a mesh component that roughly do the same thing and might be confusing when to use either.



Model can be replaced with a mesh, but not the other way around.



Models will later be expanded upon (one model can have multiple meshes, support lod levels etc), whereas meshes are just that, a single mesh.



This is what happens in our project when switching screens while any audio such as music is playing when using built in sound components.

Most of those larger gaps are switching screens with “async” loading enabled. Latest engine version.

You can hear / see that even small hitches in the game sim mess up the audio. This highlighted section isn’t even a screen change. You can heart in the audio sample above.

This is with keeping all sound components loaded at the same time too. If I only keep a single sound component loaded (based on collection proxy loading/unloading) it makes the game sim hang while changing songs too (and any other audio which happens to be playing sound glitchy).


Faerie Solitaire Remastered

Yet a small teaser for comp_mesh + res_buffer, showcasing;

  • fixes enabling resource properties
  • correct batching when rendering in world vertex space (will batch meshes that has same vertex declaration, ie same stream setup in the buffer resource).
  • added property for primitive type in the mesh component

Why does the Defold Website not show upcoming features

It was supposed to be Teaser Friday, but I totally forgot about it. A small Teaser Tuesday:
HTML5 multitouch



Whowa, multitouch! Also, great fake 3D feel. Is the table top an angled 2D plane?



This is open-source slasher prototype by @Dragosha Slasher-prototype [open source]
I used it as a good example to show multitouch



Had missed it. Bloody gorgeous it is. :slight_smile:



It works surprisingly great on my mobile phone! In a browser! Amazing times :smiley:



Update on our Vulkan support:

  • Added MSAA support
  • Fixed rendertarget support
  • Fixed the font rendering
  • Added PVRTC support (not shown here)
  • It now works on Windows(!)
  • Massive amount of refactoring

Small Vulkan roadmap:

  • Fix particle rendering
  • Fix async texture loading
  • Fix asset reloading

Here’s my simple shadow mapping demo that didn’t work previously, so that’s a little bit of a milestone at least :slight_smile:



Vulkan support would be a great christmas present. Great job!



Cocos relesed a 3d game engine based on 2d creator. Will Defold be a 3d engine?



Defold is a 3d engine! :smiley:

These are Defold projects



Defold is a 3d engine. Our tools and APIs are however more focused towards 2d. We hope to find the time and resources to improve certain 3d features, but our goal is not to compete with Unreal, Lumberyard, Godot and Unity in the area of AAA 3D games.



The sprite trimming feature has been paused several times due to other pressing matters, but it’s been shaping up this last week.

With the help of @mats.gisselson, we now also have a working pipeline inside the editor as well, allowing you to press Build and Run and see you trimmed polygons in the engine.

There is some cleanup to be done, but I expect we ship this in the 1.2.165 release.



This task has been side tracked a few times, but it’s now ready for the next release (I need to do some more testing to be sure ofc).

Here is yet another small example of the sprite trimming feature.

This first MVP will contain

  • sprite trimming in atlas + tilesource
  • Sprites
  • Gui Box Nodes (9-slice not supported)

This first MVP focused on overdraw, but it was also the first natural step towards texture packing,
which is a highly requested feature to reduce texture sizes in the game.
And, once we have texture packing in place, it should be very easy to add support for external formats like TexturePacker.



There is a small synthetic test.
I run it on y macbook.

One sprite without trimming:

And one more with trimming:

500 rabbits (I know, they are huge. But I test it on mac, I need something heavy)

Result, for no_trim sprite (~20FPS):

Result for trim sprite (~39FPS):

Looking forward to the next release! :sunny: