Arma 3 Engine - What would have been a better option and what can we learn? in ARMA 3 - GENERAL Posted December 29, 2013 1) The simulation game world updates take a long time. For whatever reason the game world updates frame to frame can take well above 15ms, which if the game were targeting 60fps would be 2/3's of the CPU time per frame just for that activity. That is enormous and the bigger the game the bigger that grows, it also seems to grow with time as well so even if the frame rate starts good once a game has been running for a while it starts to pull the frame rate ever low. The simulation is also entirely single threaded and it only runs in the main thread before the rendering to DX. Thus despite being large and essential before rendering the single threaded nature of the updates means it takes enough time to cause severe performance problems. For the game to achieve 80 fps or so this would need to drop to 1-2ms maximum, instead of the sometimes up to 25ms it takes today.Why not render the last sim step at the start of the frame while starting to calculate the next sim step at the same time. Perhaps this would cause issues for all the additional overhead, since every object/etc would need 2 states saved - current and "last full frame", and the renderer would only access "last full frame". You still have to wait for both to finish each frame, but because they both start at the same time, it should be considerably shorter.Hell, couldn't you split the render part up into multiple threads for different parts of the screen? So you have 4 cores: one for sim, the other 3 get horizontal thirds of the screen to compute geometry, make draw calls, deal with DX and the GPU (perhaps this is not so straight-forward though, and some aspects would need to be single-threaded). You can scale this up with cores. The sim also still needs to be scalable and multithreaded eventually, preferably with AI functioning independent of other sim aspects on multiple threads, using a similar "two frame" approach, with them always acting on information from the previous frame, and starting to compute their desired actions at the same time the rest of the sim starts, then their final state changes are made at the end of the frame once the rest of the sim is run - if the important aspects of each AI unit's state hasn't changed (like they died or were wounded to not be able to walk), then they proceed along with their planned change, otherwise they follow a predetermined process for each sort of "action interrupt" which is calculated and then applied. Perhaps I'm oversimplifying the sim/AI interaction, though (but then this NEEDS to happen somehow, certainly for A4, so perhaps streamlining of that interaction is required if it's currently impossible). Core investment in really changing their simulation and rendering backend is required at this point and if the situation doesn't change soon they may find Arma 4 isn't even possible and certainly doesn't sell. The target should be 60 fps, period. Right now it seems the target was 15 fps, and that isn't acceptable.Yeah, I am willing to deal with this single threadedness for this one final release, but I won't buy A4 if it isn't seriously improved in regards to CPU/thread usage. It needs to be priority #1, along with working in 64-bit (non-hackish).