This is a simple test with a lot of simple geometry (50,000 rectangles which uses some 86MB when fully loaded on my computer). Would it be better to stream in geometry? Probably. I haven't thought of way to do that. Why am I posting this? I couldn't really find any complete examples of using love events and threads so I decided to look into a non-trivial problem, that of physics simulation.
Left click to spawn a star.
The stars will try to follow you.
Right click to apply a random force to EVERY star.
This is useful if one of the stars is stuck.
It gets slow with a lot of stars for a number of reasons:
#0 I draw the entire map (all 50,000 rectangles) twice each frame.
1. I don't batch render calls to the star, or for that matter not draw them if they're out of view.
2) I have to send movement data to each star because right now I can't check if they're sleeping. This is the real killer.
C] I don't know how to use the physics engine at all, this was just a test to see if it was indeed possible to multi-thread the physics system.
IV: I have no clue how to program.
*5* Movement rate is dependent on frame rate. See number C]. The simulation runs on the last dt given until it receives a more accurate dt.
Beware: there are zero comments, I suck at coding, destroying actors doesn't remove them from the physics engine and I'm probably doing things incorrectly at every level. Running into invisible objects? That's because you can't have 50,000 items in a sprite batch in some version of love, and as such will only display the first 5,000 (or so?) rectangles. Any of the builds here will work.
My conclusion from this test? It might be possible but I should probably play around with the physics system in a single-threaded environment first.
Multithreaded physics test
Who is online
Users browsing this forum: Bing [Bot] and 3 guests