Defold 1.6.4 Beta

Please pay extra attention if you use 2D physics (Box2D built into Defold) and you have collision objects with more than one shape. We had an old bug which has been fixed in this version. It’s possible that you’ll have to change the mass for your collision objects to keep behavior close to the old implementation, but only if they have more than one shape.

5 Likes

I’ve been looking forward to this feature! To get the desired scale right now I have to divide by the physics scale and a factor 2.

--this is what's set in game.project
local physics_scale = 0.01 

--sets the collision object's visible dimension to: (20, 20, 20)
box.dimensions = vmath.vector3(20, 20, 20) / (2 * physics_scale) 

Is dividing by 2 maybe necessary as box2d deals with half width and height?

Some very welcome additions this round, thank you!

I recall seeing several posts on the forums noting that the majority of physics engines don’t support something like this, and that if you need to change an game object’s collision properties, you should create multiple different collision objects. What was the catalyst for this feature to be added? Was the underlying Box2D engine modified to support it, or was it entirely a Defold limitation?

This is a fantastic change. Oftentimes I have hundreds or thousands of collide-able game objects that are dynamically spawned without a script to improve performance. Unfortunately, I still had to create separate script files for them because although I didn’t need to implement an update() function, I still needed to implement an on_message() function to handle collision messages. Now I will be able to do that without creating those additional script files.

(Technically, collision messages could be handled without a separate script, but if you have multiple different types of collide-able enemies but only a single collision mask shared between them, then it’s not so easy to differentiate which type of enemy you’re colliding with, hence having a separate on_message() function per enemy type.)

2 Likes

For those that wish to start testing with multi texturing, here is a very small example.
Our main focus for this first MVP was using animations with corresponding names like so:
diffuse.atlas:

hero_run:
    run1.png
    run2.png
   ...

normal.atlas:

hero_run:
    run_normal_1.png
    run_normal_2.png
   ...

Here you have to use the “rename patterns” to rename the normal images accordingly.
I don’t have a good example project of this yet.

Screenshot 2024-01-29 at 18.01.07 + Screenshot 2024-01-29 at 18.01.16 =

Update: I also added an embryo for a normal map example. Currently, the shader isn’t setup to do actual normal mapping, but it should still serve as an example:

Here is the download link:
SpriteMultiTextureNormal.zip (311.6 KB)

7 Likes

Oh wow, I totally missed this! This is huge, well done guys. Makes my next game idea much more viable… :eyes:

4 Likes

We’ve received more requests for advanced features in the physics engine and come to the conclusion that 1) we need to move the physics engines to extensions (one for 2d and one for 3d) and 2) we can’t fixate on having a 1:1 mapping between 2d and 3d physics (especially since we will move physics to extensions this year)

7 Likes

Great news, just checked it out on macOS - works as expected! :+1:

1 Like

I think it’s about a misunderstanding of terminology.

The first issue here is that developers were asking for scaling, and the problem of scaling isn’t that simple.
The most basic no-go case is scaling a circle, like so:

local scale = vmath.vector3(2, 3, 0);

This is still impossible to do, because physics can’t work with ellipse.
However, having this new feature makes these limitations clearer than simply scaling.

The second issue is that there is no such concept as scale for a physics shape in Box2D, for example. The only thing you can do is to remove one shape and create another one with the needed parameters. That’s what this new function does.

The third issue concerns applying transforms from the game world to the physics world for Dynamic objects. We partially solved this by adding Allow Dynamic Transforms. However, it’s important to understand that there is a special type of objects that exist, which users can change dynamically: Kinematic objects. Doing such things with dynamic objects may disrupt the physics simulation in strange ways.
For example, consider this case like the freshest one: Defold Physics Hinge Bug? - #9 by super_kimono
This happens because of bidirectional communication between the game world and the physics world for the exact same object (first, you apply an object’s transform to a physics collision object and then read values from the physics world for the same object transform)

So, in conclusion, there is no controversy between what we said before and the fact that we added this feature (and also Allow Dynamic Transforms feature a long time ago).

6 Likes

This is amazing. Thanks so much for this feature.

4 Likes

This point was missed in release notes, I’ve just added it.

7 Likes

Getting crash errors when building this project from editor> GitHub - defold/sample-normal-maps-2d

  • Defold 1.6.4 beta
  • editor SHA1 86d2d3d6cb9b963e623967d7bd67b3385183b5b5
  • engine SHA1 86d2d3d6cb9b963e623967d7bd67b3385183b5b5
  • Windows 10

When building to html5, project builds with no errors.

LOG:
editor2.2024-01-30.txt (1.5 MB)

1 Like

Hmm, very strange. The error seems related to Add new default filtering keyword for material samplers (Engine support) by Jhonnyg · Pull Request #8419 · defold/defold · GitHub.

2024-01-30 14:14:35.955 43153 [clojure-agent-send-off-pool-0] WARN  editor.defold-project - {:line 92, :msg "Unable to load resource '/assets/sprite_normal.material'"}
com.google.protobuf.TextFormat$ParseException: 70:15: Enum type "dmRenderDDF.MaterialDesc.FilterModeMin" has no value named "FILTER_MODE_MIN_DEFAULT".
	at com.google.protobuf.TextFormat$Tokenizer.parseExceptionPreviousToken(TextFormat.java:1363)
	at com.google.protobuf.TextFormat$Parser.consumeFieldValue(TextFormat.java:2175)
	at com.google.protobuf.TextFormat$Parser.consumeFieldValues(TextFormat.java:2015)
	at com.google.protobuf.TextFormat$Parser.mergeField(TextFormat.java:1961)
	at com.google.protobuf.TextFormat$Parser.consumeFieldValue(TextFormat.java:2086)
	at com.google.protobuf.TextFormat$Parser.consumeFieldValues(TextFormat.java:2015)
	at com.google.protobuf.TextFormat$Parser.mergeField(TextFormat.java:1949)
	at com.google.protobuf.TextFormat$Parser.mergeField(TextFormat.java:1818)
	at com.google.protobuf.TextFormat$Parser.merge(TextFormat.java:1804)
	at com.google.protobuf.TextFormat$Parser.merge(TextFormat.java:1715)
	at com.google.protobuf.TextFormat$Parser.merge(TextFormat.java:1687)
	at com.google.protobuf.TextFormat.merge(TextFormat.java:1480)

Could you please clear the build folder and try again?

I cleared the build folder and tried to build, again got the same crash results.

text from console:

INFO:CRASH: Successfully wrote Crashdump to file: C:\Users\\AppData\Roaming\Defold/_crash
ERROR:CRASH: CALL STACK:

ERROR:CRASH:  0 0x7FF6B7D85EC0 dmCrash::GenerateCallstack D:\a\defold\defold\engine\crash\src\backtrace_win32.cpp:144

ERROR:CRASH:  1 0x7FF6B7E7CC1C _seh_filter_exe minkernel\crts\ucrt\src\appcrt\misc\exception_filter.cpp:219

ERROR:CRASH:  2 0x7FF6B7EC17D4 `__scrt_common_main_seh'::`1'::filt$0 D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:304

ERROR:CRASH:  3 0x7FF6B7DFDE5C __C_specific_handler D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\riscchandler.cpp:389

ERROR:CRASH:  4 0x7FF945DD2290 __chkstk <unknown>:0

ERROR:CRASH:  5 0x7FF945D81030 RtlRaiseException <unknown>:0

ERROR:CRASH:  6 0x7FF945DD0E90 KiUserExceptionDispatcher <unknown>:0

ERROR:CRASH:  7 0x7FF6B7AB9EF0 dmGameSystem::ResolveUVDataFromQuads D:\a\defold\defold\engine\gamesys\src\gamesys\components\comp_sprite.cpp:998

ERROR:CRASH:  8 0x7FF6B7AB5110 dmGameSystem::CreateVertexData D:\a\defold\defold\engine\gamesys\src\gamesys\components\comp_sprite.cpp:1232

ERROR:CRASH:  9 0x7FF6B7AB8C70 dmGameSystem::RenderBatch D:\a\defold\defold\engine\gamesys\src\gamesys\components\comp_sprite.cpp:1321

ERROR:CRASH: 10 0x7FF6B7AB93A0 dmGameSystem::RenderListDispatch D:\a\defold\defold\engine\gamesys\src\gamesys\components\comp_sprite.cpp:1732

ERROR:CRASH: 11 0x7FF6B7B8F680 dmRender::DrawRenderList D:\a\defold\defold\engine\render\src\render\render.cpp:782

ERROR:CRASH: 12 0x7FF6B7BACCD0 dmRender::ParseCommands D:\a\defold\defold\engine\render\src\render\render_command.cpp:175

ERROR:CRASH: 13 0x7FF6B7B9B670 dmRender::UpdateRenderScriptInstance D:\a\defold\defold\engine\render\src\render\render_script.cpp:3509

ERROR:CRASH: 14 0x7FF6B79DC670 dmEngine::StepFrame D:\a\defold\defold\engine\engine\src\engine.cpp:1648

ERROR:CRASH: 15 0x7FF6B79DD3C0 dmEngineUpdate D:\a\defold\defold\engine\engine\src\engine.cpp:2150

ERROR:CRASH: 16 0x7FF6B79DD5F0 dmEngine::RunLoop D:\a\defold\defold\engine\engine\src\engine_loop.cpp:83

ERROR:CRASH: 17 0x7FF6B79D5A60 engine_main D:\a\defold\defold\engine\engine\src\engine_main.cpp:148

ERROR:CRASH: 18 0x7FF6B7DF2254 __scrt_common_main_seh D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288

ERROR:CRASH: 19 0x7FF945897330 BaseThreadInitThunk <unknown>:0

ERROR:CRASH: 20 0x7FF945D82690 RtlUserThreadStart <unknown>:0

ERROR:CRASH: 

INFO:CRASH: Successfully wrote Crashdump to file: C:\Users\\AppData\Roaming\Defold/_crash
ERROR:CRASH: CALL STACK:

ERROR:CRASH:  0 0x7FF6B7AB9EF0 dmGameSystem::ResolveUVDataFromQuads D:\a\defold\defold\engine\gamesys\src\gamesys\components\comp_sprite.cpp:998

ERROR:CRASH:  1 0x7FF6B7AB5110 dmGameSystem::CreateVertexData D:\a\defold\defold\engine\gamesys\src\gamesys\components\comp_sprite.cpp:1232

ERROR:CRASH:  2 0x7FF6B7AB8C70 dmGameSystem::RenderBatch D:\a\defold\defold\engine\gamesys\src\gamesys\components\comp_sprite.cpp:1321

ERROR:CRASH:  3 0x7FF6B7AB93A0 dmGameSystem::RenderListDispatch D:\a\defold\defold\engine\gamesys\src\gamesys\components\comp_sprite.cpp:1732

ERROR:CRASH:  4 0x7FF6B7B8F680 dmRender::DrawRenderList D:\a\defold\defold\engine\render\src\render\render.cpp:782

ERROR:CRASH:  5 0x7FF6B7BACCD0 dmRender::ParseCommands D:\a\defold\defold\engine\render\src\render\render_command.cpp:175

ERROR:CRASH:  6 0x7FF6B7B9B670 dmRender::UpdateRenderScriptInstance D:\a\defold\defold\engine\render\src\render\render_script.cpp:3509

ERROR:CRASH:  7 0x7FF6B79DC670 dmEngine::StepFrame D:\a\defold\defold\engine\engine\src\engine.cpp:1648

ERROR:CRASH:  8 0x7FF6B79DD3C0 dmEngineUpdate D:\a\defold\defold\engine\engine\src\engine.cpp:2150

ERROR:CRASH:  9 0x7FF6B79DD5F0 dmEngine::RunLoop D:\a\defold\defold\engine\engine\src\engine_loop.cpp:83

ERROR:CRASH: 10 0x7FF6B79D5A60 engine_main D:\a\defold\defold\engine\engine\src\engine_main.cpp:148

ERROR:CRASH: 11 0x7FF6B7DF2254 __scrt_common_main_seh D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288

ERROR:CRASH: 12 0x7FF945897330 BaseThreadInitThunk <unknown>:0

ERROR:CRASH: 13 0x7FF945D82690 RtlUserThreadStart <unknown>:0

ERROR:CRASH: 

INFO:CRASH: Successfully wrote MiniDump to file: C:\Users\\AppData\Roaming\Defold/_crash.dmp

I’m able to reproduce this too. We fixed one issue related to this, but apparently the update didn’t fix it completely. Odd. @JCash this one is for you.

2 Likes

Would you be avle to share a repro case project?

Sure , I was testing the new normals multi-texture project found here - GitHub - defold/sample-normal-maps-2d

2 Likes

Thanks, I’ve updated that example with a fix.
The problem was that the “Rename patterns” for the normal map atlas wasn’t set, so none of those frames could be found. Remember, the names must match.

I’m also fixing the crash, which shouldn’t occur of course.

UPDATE: The fix is not published in the beta as well.

2 Likes

extension-imgui no longer builds (on Mac M1). Probably related to the GLFW change? Errors include:

/imgui/src/extension_imgui.cpp
	Line 35: unknown type name 'GLuint'; did you mean 'uint'?
    GLuint             tid;
    ^~~~~~
    uint
1 Like