road movement and supply questions

[Guest]

Come on, it wasn't me who talked first about future patches here.

As I've already told to Davide, I'm not questioning the game's complexity and its design choices. They looks absolutely brillant! And I'm going to buy it on day-one just for them alone.

However, I was always a bit worried about the exact point you've raised: poor optimizations and more or less obsolete programming techniques (with all due respect) leading to oversaturation of resources, thus impossibility to code new features (= reduced realism) or to extend the engine's scope to bigger scenarios and campaigns.

That would be a huge shame to me as I was really waiting for the definitive Napoleonic Warfare's simulation this time. Maybe my expectations were just too high?

In all cases, I'm still hoping the development won't be locked up on 11th June. Take your well deserved relax time before, of course.

[con20or]

I dindt say anything about poor optimizations or poor programming?? I said the game was the best on the market.

[Guest]

That was mine obviously.

But you also replied to a request of adding a feature (road path following) with:

it requires a CPU/GPU and likes FPS - every in-game check a regiment makes reduces that

Which, pleasantly, I'd define as the typical "syndrome" of being short on CPU cycles.

You know, multithreading shouldn't be an optional in 2015 for such great/big projects, imho.

Anyway don't get angry. I appreciate your work.

[con20or]

Ask anything you like.

Threading was introduced in SOWWL.

[Guest]

Threading was introduced in SOWWL.

Moving some LOS computations to a dedicated thread is far from being considered an optimal technique, unluckily.
Synchronization's costs with the main thread (where I guess most of AI runs) might in theory even result in deteriorated performances...

The concurrency I did mean to exploit was along the lines of partitioning the commander BAIs updating, making them to scale onto all the available physical threads.
This kind of parallel execution would give great benefits in terms of speed, on the other hand.
Commanders can realistically take their decisions without inspecting any data being modified meanwhile, as past informations / orders / terrain analysis / etc. could be easily made read-only at that stage.
It would require "some" re-engineering of course.

I'm sorry to contradict Jim (from Matrix's forums: "...but only IBM/Watson could run a battle with 240K sprites on the battlefield")...
But another example may be implementing an "asyncrounous sprite renderer" (background resources preparation, animations LOD, HW Instancing, state changes minimization, etc.), which would perfectly cope with the demands of even biggest Napoleonic battles.
I offered myself to code a prototype about this subject for Norb.
Different priorities at the moment and I understand him.

[Jim]

The other issue to consider is that the game must run in full synchronous mode across 20+ systems for several hours in order for multiplayer work to our standards. Norb had to undo some of the multithreading attempts because it caused failures in MP.

I may have been exaggerating a bit about Watson, but with all of the tasks that the AI does, it is very difficult to get significant increases in performance.

-Jim

[Guest]

The other issue to consider is that the game must run in full synchronous mode across 20+ systems for several hours in order for multiplayer work to our standards. Norb had to undo some of the multithreading attempts because it caused failures in MP.

I may have been exaggerating a bit about Watson, but with all of the tasks that the AI does, it is very difficult to get significant increases in performance.

-Jim

Thanks for replying Jim and sorry for stressing again on these subjects.

I just dream so much to refight 1809/1812/1813 as well that perhaps I'm loosing contact with reality (Norb's free time, NSD's resources, release dates, etc.). :S

Davide told me about the floating-point determinism issue you faced. I think it's more MP-architecture-related than multithreading.

Having many AI tasks to "parallelize" is not the problem, quite the contrary (you'll gain more speed proportionally).
The interdependence between data those tasks are working on is.
You probably know simultaneous read/write on memory from different threads gives unpredictable results.
At this (rather advanced) stage of develpement it should be harder to spot these links and restructure the code around them. Yet, not impossible...

Excuse me again.
The point is I see so many concurrency opportunities to exploit in Napoleonic games I really cannot hold myself.
Anyway if it's worthwhile the effort now, is hard to say from outside of course.

Ciao.