Re:Arma 3 – An analysis of recent multithreading improvement...
by dustbunny on Friday June 20, 2025 @06:26PM
(#44332692)
Another model may be that all actors read from frame N-1 and write to frame N. Then there's not many copies, just one.
[ Parent
| on HN ]
Re:Arma 3 – An analysis of recent multithreading improvement...
by akrotkov on Friday June 20, 2025 @07:49PM
(#44333200)
Two, surely? The previous one still being used and the new one being written.
(Note that this is how most rendering artifacts were fixed long ago - the on screen and the off screen buffers were swapped, so nobody would "see" in progress scenes)
Re:Arma 3 – An analysis of recent multithreading improvement...
by Retric on Friday June 20, 2025 @08:20PM
(#44333382)
1 copy + the original = 2 instances in memory.
Re:Arma 3 – An analysis of recent multithreading improvement...
by o11c on Friday June 20, 2025 @08:19PM
(#44333378)
That's fine if actors are not doing much (e.g. just pathfinding and shooting), but is likely to fall apart long before scripting becomes a thing, since there are a lot of tasks where different actors do want to mutate the same object.
Re:Arma 3 – An analysis of recent multithreading improvement...
by Retric on Friday June 20, 2025 @08:22PM
(#44333399)
This is AI, having multiple actors plan to gather the same resource etc isn’t necessarily a flaw. It does however result in meaningful game design decisions getting tided up in how the game engine is designed.
Re:Arma 3 – An analysis of recent multithreading improvement...
by dustbunny on Friday June 20, 2025 @10:24PM
(#44333988)
This is a great example. It's probably pretty insignificant from a players perspective in most contexts. And you could most certainly design some acceleration structures to specifically handle AI convergence specific to your use case.