Multithreading for pressure?
-
I saw a thread that said screen was divided into 4x4 areas for pressure and walls because it increased performance (I don't remember which one.) Why can't you just do multithreading for pressure and stop dividing the screen into 4x4 areas (Not walls)?
Also from what I remember newtonian gravity also uses multithreading. I know you can't just mark a piece of code as "multithreaded potato" and it takes some time to do it but I don't think it takes more time than it takes for my game to process some explosion.
-
Newtonian gravity is mostly fast because it uses dark magic (Fast Fourier Transforms), which can be used to efficently solve n-body systems.
-
Also to clarify more things on how newtonian gravity's multithreading works:
The gravity thread is constantly simulating in the background, independent of TPT frames. It takes in input data about the location of gravity sources from the most recent frame, generates the gravity map, then whenever the next frame starts it will get picked up. It's easy to multithread because it's not associated with frames.
Air simulation has to be run exactly once a frame, before the rest of the simulation stuff. You can't skip a frame if the air sim is slower than the normal sim, because then the air sim would appear slow or inconsistent. But with newtonian gravity, it can sometimes skip several frames before each update (especially on the Android port, where I was unable to get fast fourier transforms to work).
With the air sim, you also can't easily multithread individual parts of it. You might think, what if we just divided the screen into 4 parts and simulated them all at once. That's not very simple, because the air sim is 6 for loops that scan over the entire screen. The first 5 could probably do something like this safely, but the last loop does some more "far-reaching" updates if the air has high velocity. There's some type of fancy processor stuff I've heard of that can automatically multithread loops for you, and I heard it had good success for the air code. I've never tested this though. And I'd kind of prefer to add the threading explicitly.
What we could also do is simulate the air in parallel with the main simulation. This contradicts what I said in the 2nd main paragraph. But I still think it could work. The air sim would have to operate on a stale copy of the air data (1 frame old). Then the next frame, the simulation picks that up. So reactions that generate pressure wouldn't show up for a frame. This might not have too big of an impact. All the code that accesses or sets air would have to change though. It would be similar to how Newtonian Gravity works, main difference is that we can't start the next frame until both the air and the main sim have finished.
