Spring RTS Engine

I didnt say (or mean) that.

You may not notice it because you dont know the lag might be caused by ground deformation, in large games where people are constantly shooting something, it really starts eating your CPU.

I think spring engine should allow you to build 1k peewees move them and not lag if your on an avarage market pc by now...i mean spring was made while thinking of ota but it should expand further and allow for even bigger force movments.
I guess moving units is all about pathfinding though and nobody wants to touch it?

smoth wrote:gimping the engine because of ....

I don't think TM is trying to suggest gimping the engine, I think he's trying to work out a way that it could be improved.

I agree with him that the path calculations would not need to be done instantly, perhaps this is an area where the functionality for reworking the paths could be pulled out into a child thread? (I'm not suggesting this is trivial, just possible).

Acidd_UK wrote:perhaps this is an area where the functionality for reworking the paths could be pulled out into a child thread? (I'm not suggesting this is trivial, just possible).

No, the entire sim must remain in one thread in order to preserve sync.

Staggering the process of re-pathing might help if its done in chunks across game frames in a deterministic way.

Dont matter if this gets solved or not i think fusions should deform the ground much less.Its just annoying as hell.
Not only fusions also nukes and berthas etc..Less deformation pleas.It doesnt serve much purpose anyway,its effects dont really make any differance for you as a player(in OTA mods).

Gota wrote:Dont matter if this gets solved or not i think fusions should deform the ground much less.Its just annoying as hell.
Not only fusions also nukes and berthas etc..Less deformation pleas.It doesnt serve much purpose anyway,its effects dont really make any differance for you as a player(in OTA mods).

This is something to ask in the BA thread, not a thread about general engine behaviour.

Gota wrote:Dont matter if this gets solved or not i think fusions should deform the ground much less.

It doesnt matter how deep it deforms, still it lags as much as almost flat crater creation.

Peet wrote:

Acidd_UK wrote:perhaps this is an area where the functionality for reworking the paths could be pulled out into a child thread? (I'm not suggesting this is trivial, just possible).

No, the entire sim must remain in one thread in order to preserve sync.

Every machine could do the calculation in a child thread, then once the have all got the result, the server tells them which frame to apply it on. Come on, don't be so negative!

AFAIK repathing is already done in a delayed manner (FIFO queue + fixed number of blocks per frame processed from it).

Tobi wrote:AFAIK repathing is already done in a delayed manner (FIFO queue + fixed number of blocks per frame processed from it).

So when you blow up 50 units in a single frame, that lag is just from one re-pathing, not from all the individual re-pathings after each explosion? Ouch.

I think the "ouch" comes from the per-pixel deformations of the mesh. It gets painfully slow when it's dealing with thousands of modifications- even at the edge of a standard explosion, the falloff != 0, so the deformations are slight, but cost just as much.

There has to be a better way to deal with that.

Maybe deformation calculations should be stored in an array for every weapon that causes deformations?

Changing the ground height is pretty much trivial (the calculation is unlikely to cost more than storing the thing in an array), the hard part is to adjust the pathing and you can't precompute that.

argh mesh deformation is not that expensive, it is used for cloth and animation..

PATHING is where your cost comes in.

I disagree. Doing the math to find the amount of deformation every time has to be very wasteful, compared to fetching the numbers from an array. Sure, matching the explosion to the array's probably slow, but after that it should be almost no cost at all, compared to the math it's doing now. Go read the code, you'll see what I'm saying I think.

I'm open to arguments that I'm just too stupid to get it, but I honestly think that the math that's being performed is quite a bit slower than the simple add / subtract that would be necessary if using the array approach.

Now... pathing... the pathing algorithm doesn't need to run over the entire map for every explosion, does it?

I assume it just updates the sectors that have been changed, so that's why multiple explosions produce a crisis. Maybe it could only be allowed to update N number of pixels per frame, and if there are too many, then they get queued for the next frame?

In theory, this could lead to absurdities, if enough giant explosions were happening constantly, but the vast majority of the time, waiting even a dozen frames to update all of heightmap pixels changed by a giant chain explosion, for example, would not be noticeable.

Incase you havent noticed I already suggested delayed processing bit by bit and tobi said its already being done.

Oh, wait, I'm stupid, you're right

So... the question then is how many blocks to update.

Yeah, you're right, my bad.

Well guess what, it already stores it in an array.