Well, in your example, you still didn’t correctly multiply your projection matrix with the view matrix. And the matrix calculation seemed a little strange.
Also, the visualization was based on some scaling that I’m not certain about.
I rewrote your example to use the draw_line instead, to better track the actual movements:
frustum-test-codermaster.zip (545.4 KB)
All in all, I still think it works correctly 
Thank you so much Mathias, you are a great guy!
Your test works perfectly and I found the error in my own test as well. I did not multiply by the view matrix because in this case it is a unit matrix. However, I made a mistake there when setting the scaling of the frame:
go.set_scale(vmath.vector3((500 - frustum_margin) / 500), “frustum”)
On this line, I should have subtracted twice the frustum margin. With this modification, my example does the same as yours.
Thanks again, this is an excellent feature! Let’s work!
I built frustum culling into one of my projects and noticed something special. Some sprites weren’t culled at the right time and I couldn’t find an explanation for it. I later observed that this occurred only in sprites with a height greater than a width.
I put different sized sprites into Mathias’s test program. This shows that non-square sprites disappear at different times, not when they are outside the frustum. And the one with the highest height won’t even disappear. From what I have seen, I conclude that the sprites are culled out based on their largest enclosing square area. Do I think correctly? Thanks!
frustum-test-codermaster-2.zip (546.3 KB)
It’s because the bounding volume for the sprite isn’t a rectangle, but a circle:
Ahhh. I looked at this and the process of rendering sprites in the engine source so everything became clear and understandable. Thanks!
Is that setting not available yet in the editor? I don’t find it.
I updated my test project for the fixed physics update. Everything is fine, but in the 3D physics, the “anchor” object falls slower than it should. It looks like 3D physics doesn’t use proper DT for physics step. Could you please look into it?
Use the settings:
physics.type = 3D
engine.fixed_update_frequency = 15
I might have forgotten it 
I’ll add it now.
I’ll checkout the 3D physics issue as well.
If I set display.update_frequency = 60, I get 40 fps in the HTML5 build on 60hz display. Plus, the demo runs much slower, i.e. look at dt sum that doesn’t equal 1.
I have a PR for this issue, and I’m currently looking at the 3d physics related issue.
Edit: I found and fixed the 3D physics update issue as well.
The PR is merged into the beta now, and a new build should be available within the hour.
I updated the test project:
It turned out that, in 1.3.1 BETA,timer.delay triggers x2 times faster (the value should be 5 seconds, not 2.5):
Plus, in this update, 3D physics runs too fast, i.e. the speed of the anchor should be about 250 px/sec:
The fix for the timer issue should be available in the latest beta build.
I do have a PR with a partial fix for the 3D physics here.
The problem is that I just couldn’t get it to produce the same velocity as described, when using 30Hz for the physics. It’s strange, but I’m out of ideas there…
Update looks very awesome. I replace all update() calls with fixed_update() and use next parameters
display.vsync = 0
display.swap_interval = 0
physics.use_fixed_timestep = 1
In game physics looks stable, no glitches, even player movement look more smooth now.
In engine version before 131 turnoff vsync make game full unpredictable. Looks like physics objects accumulate small forces and explode through time. To see more usefull case - make win build, catch game window for the header and randomly move around - all physics objects falldown in chaos 
Now all is good for my PC conf with 60Hz monitors.
Also before 131 version Android build looks very slow when turnoff vsync. Slow on phones with display at 90Hz. I recheck this case in next 2 days.
Some screens:
Looks like an interesting game by the way. Has it been released yet?
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.
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)
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)
Oh, yeah, you’re right, thanks. Apparently some commit between the 20m and the 1h builds enabled texture profiles. Sorry for the false alarm.
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.
main collection is loaded as a proxy if you set the Main Collection option to /bootstrap/bootstrap.collection.
update_order_test.script, which prints a message on each update and fixed_update with the following information:
dt
R to 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.
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.
