AlexB
16.07.2010, 19:53:03
Fight 1
Multi-core support is hard to add to an application that is not designed with multi-core support in mind. And it should be up to impossible to add it afterwards via a bunch of hooks (and gain from it). It needs careful planning to even support doing the most simplistic things concurrently. The order things are done is not defined. Imagine two units shooting at each other. In scenario one A is destroyed by B first and B doesn't have a chance to fire in the same time because it's dead. In scenario two B shoots first. A may be destroyed by B and even if not, these scenarios are not the same, their outcome is entirely different yet equally possible. The propability to see a out-of-sync dialog approaches 1 quickly. But let's assume we're talking about campaigns and skirmish.
While it is a good idea to actually use the power of the entire processor, multi-threading will never be able to overcome shitty design. It's not supposed to do that. If you got four shovels, you just quarter the time needed (provided, you got four arms), but if you need to move a mountain, better get yourself a fricking big excavator instead. And don't even try to call for more cores as it deferres the limit of shitty design merely by a factor even though it has to be changed by magnitudes to make a difference.
Simple example (factually not 100% correct, as not every unit checks for targets every frame): For every unit (out of n) to auto-aquire a target, every enemy unit (out of n) has to be checked whether it is in range, resulting in up to n² tests. (Math guys expect 0.5n required tests for each run but that is only a factor.) Let's say n=8 (this could also easily be hundreds), then n²=64 tests. With four cores, every core gets 16 tests. If we only double the number of units (n=16, n²=256) every processor core again will get 64 tests. Instead of actually quadrupling the speed, we only accellerated it a bit. Mathematically spoken: for larger N, factors aren't worth shit if there are squares involved.
If the game runs slow with 30 units, for dual cores if will do so for about 42, for quads the limit will be 60. Ideally. Large amounts of processor power will have to be used to sync the cores. And not everything can be optimized, merely the tiniest parts. You wouldn't make your car run faster by choosing a much cooler fender sticker either. It's just not worth the hassle. While it might be hard to come up with a system to actually AI deploy stuff in reasonable places and not just once right after a unit has been created, i vote for the second issue.
Fight 2
Indeed, the custom foundations are implemented already to some degree, but I don't know what's working and what's not. And I don't know what it needs to fully support new terrain types (and to create maps for them), but as pd should have a way better grasp of Ares in general, this issue specifically and what he is capable of, the difficulty of this issue doesn't bother me. The veteran ammo issue seems rather limited and every case named so far might be sort-of resolved by having either Ammo on specific weapons (wouldn't support Veteran) or switching unit types on promotion (would support Veteran). Thus, new terrain types.
Multi-core support is hard to add to an application that is not designed with multi-core support in mind. And it should be up to impossible to add it afterwards via a bunch of hooks (and gain from it). It needs careful planning to even support doing the most simplistic things concurrently. The order things are done is not defined. Imagine two units shooting at each other. In scenario one A is destroyed by B first and B doesn't have a chance to fire in the same time because it's dead. In scenario two B shoots first. A may be destroyed by B and even if not, these scenarios are not the same, their outcome is entirely different yet equally possible. The propability to see a out-of-sync dialog approaches 1 quickly. But let's assume we're talking about campaigns and skirmish.
While it is a good idea to actually use the power of the entire processor, multi-threading will never be able to overcome shitty design. It's not supposed to do that. If you got four shovels, you just quarter the time needed (provided, you got four arms), but if you need to move a mountain, better get yourself a fricking big excavator instead. And don't even try to call for more cores as it deferres the limit of shitty design merely by a factor even though it has to be changed by magnitudes to make a difference.
Simple example (factually not 100% correct, as not every unit checks for targets every frame): For every unit (out of n) to auto-aquire a target, every enemy unit (out of n) has to be checked whether it is in range, resulting in up to n² tests. (Math guys expect 0.5n required tests for each run but that is only a factor.) Let's say n=8 (this could also easily be hundreds), then n²=64 tests. With four cores, every core gets 16 tests. If we only double the number of units (n=16, n²=256) every processor core again will get 64 tests. Instead of actually quadrupling the speed, we only accellerated it a bit. Mathematically spoken: for larger N, factors aren't worth shit if there are squares involved.
If the game runs slow with 30 units, for dual cores if will do so for about 42, for quads the limit will be 60. Ideally. Large amounts of processor power will have to be used to sync the cores. And not everything can be optimized, merely the tiniest parts. You wouldn't make your car run faster by choosing a much cooler fender sticker either. It's just not worth the hassle. While it might be hard to come up with a system to actually AI deploy stuff in reasonable places and not just once right after a unit has been created, i vote for the second issue.
Fight 2
Indeed, the custom foundations are implemented already to some degree, but I don't know what's working and what's not. And I don't know what it needs to fully support new terrain types (and to create maps for them), but as pd should have a way better grasp of Ares in general, this issue specifically and what he is capable of, the difficulty of this issue doesn't bother me. The veteran ammo issue seems rather limited and every case named so far might be sort-of resolved by having either Ammo on specific weapons (wouldn't support Veteran) or switching unit types on promotion (would support Veteran). Thus, new terrain types.