Looks like an interesting game by the way. Has it been released yet?
1 Like
Thx you. This is old abandoned project. You can play demo prototype with first 20 levels at Save Your Cogs Demo HTML5 by DrunkChipRobotics (DMiroshnychenko) . Partitial support gamepad + mouse for menu navigation.
Now i am working on another 40+ levels to publish game for Steam. This is hard in a war zone but i know - all be good.
5 Likes
Hi! Is anyone else experiencing huge build times when bundling with bob with this beta? I just looked and the last GH Actions workflow run took 1h instead of the usual 10mins (with 1.2.192). I am doing a HTML5, Android and iOS build in that same workflow, so 3 builds in 10 minutes went to 3 builds in 1 hour. I started another build right now and it does seem to hang a lot after outputing this (at the Building... step):
Working...Cleaning... 1% ...done!
Build Remote Engine...
Building engine... ...done!
Reading classes... 2147483647% ...done!
Reading tasks... ...done!
UPDATE: Yes, I can confirm, building takes much longer now, but doesn’t fail.
UPDATE2: Wait, no, what? Apparently this uptick in build times happened 5 months ago when the Spine extension got split out of the engine in the first place. My bad. Somehow I didn’t notice. Still, it went from 20 mins to 1h. (It’s a project with a lot of Spine scenes)
2 Likes
I haven’t noticed anything special in terms of increased build times.
Also, for the new Spine extension, we only copy the spine files, so they should really take less time than before.
If something takes ~1 hour, I would start by checking if it’s using texture profiles (e.g. texture compression)
3 Likes
Oh, yeah, you’re right, thanks. Apparently some commit between the 20m and the 1h builds enabled texture profiles. Sorry for the false alarm.
4 Likes
Thanks!
And the last thing left to test is… collection proxy!
I suppose that a collection inside a proxy with the default time step settings should behave the same way if you load it as the bootstrap collection. Right? Correct me if I’m wrong.
It looks like collection proxies have their own update loop or their own time accumulator or something like that. And that update loop causes jittering. I’ve been fighting with the jittering all the week (I even implemented a transform interpolation for physics objects but it didn’t help). So, please take a look at the updated project to understand the problem.
- In this version, the
maincollection is loaded as a proxy if you set theMain Collectionoption to/bootstrap/bootstrap.collection.
- Both collections have
update_order_test.script, which prints a message on eachupdateandfixed_updatewith the following information:- Frame number
- Collection name
- Function name (update/fixed_update)
- value of
dt
- Press key
Rto reload the collection. Reload the collection a couple of times to see the jittering in physics.
Run the game to see the log in the editor:
The problem is that the collections do their updates differently. The bootstrap collection never has double updates or double fixed updates, i.e. it runs smoothly. But the main collection sometimes skips fixed updates and does fixed updates double times per frame.
9 Likes
Thanks again @aglitchman for your thorough testing!
Yes, the collection proxies has the possibility to have a time scale.
It allows you to slow down or completely stop a collection proxy.
(See the set_time_step message)
So, in order to support fixed updates, each collection has its own accumulated time.
Each collection has its own physics world, and as long as the fixed_update is called at the right interval, the correct number of times, I believe this is correct?
I don’t know why that would cause jittering in this case though 
We were planning to release this version today, but I’ll postpone this until tomorrow so we can think about it some more and possibly come up with a clearer bug description/repro.
8 Likes
Maybe, that is the point of the issue: each collection has its own accumulated time. Proxied collection starts with a zero value of accumulated time, but the main timeline (I don’t know how to name it right 
) has a non-zero value, i.e. there is the remainder from the previous frames.
4 Likes
display.swap_interval works only with opengl.
Is there an vulkan equivalent to setting vsync?
Vulkan doesn’t have that functionality.
1 Like
Well, that is another setting isn’t it?
Imho, I don’t think it’s very useful to merge two such specific settings together into one. I think it’s better to keep them separate.
We can probably add a setting to game.project if it’s requested (please add a feature request to our github repo).
Currently, we initialize it with VK_PRESENT_MODE_FIFO_KHR
Since our Vulkan backend is still fairly new ground, I’m curious:
- What mode are you looking for
- and what is your use case?
First, i´m complete new to defold.
I was just looking for defold features.
VSync on is the only thing i wish.
Don´t know if it is per default in the game.project setting in case of vulkan.
A question btw. how to set the renderer to vulkan? (with a fallback to opengl if vulkan is not available?!?)
I know i must have a deeper look into the settings 
If you read the documentation you linked, about VK_PRESENT_MODE_FIFO_KHR, you’ll see that it enables vsync. So that is the default.
You need to use the extension-vulkan.
Follow the setup there.
Some platforms use the Vulkan by default. Currently it’s only Nintendo Switch, but later this year, we’ll migrate macOS/iOS to use the Vulkan backend as well.
1 Like
Thanks alot.Yes i will do read the whole docs.
I only use Windows.(maybe later export for web too)
Do we have to use a specific defold-spine extension with this update?
I’m getting an error:
Cannot play spine animation on a non-spine node
when building the project with extension: https://github.com/defold/extension-spine/archive/refs/tags/2.0.8.zip
No, the spine extension shouldn’t need to be updated afaik.
Did the message say anything else?
What was your url?
More info?
I just added new release with a fix for cloned gui nodes:
1 Like
So, I prepared the another test project - https://github.com/aglitchman/defold-fixedupdate-131-test
If you run it, you will see three sprites (“anchors”, again) that infinitely fall from the top to the bottom. Look at the test2/test.script to see how they are animated - the script adds fixed step every fixed_update.
- Left: it is created from a collection factory and runs on the main timeline.
- Center: it runs from a collection proxy.
- Right: the same as the central sprite, but with interpolation of position and rotation.
Plus, I captured a video (it’s slowed down x2 for convenience):
From the start, the left sprite falls smoothly, but the central sprite falls with jittering. And interpolation doesn’t help at all (actually, it works well - it can be tested if set fixed update frequency to 30hz).
Then, on the second run, the proxy’s time accumulator catches up with the main timeline and the animation starts running smoothly. But still jitters from time to time.
10 Likes
same problem with platypus
2 Likes
I filled the issue for an easier follow-up - https://github.com/defold/defold/issues/6535
(Offtopic. While doing that, I stumbled upon a great resource - “jitternator - Lessons learnt from hunting jitter issues!” 
)
7 Likes