Changelog - picture heavy

[Andy ONeill]

Game

Direct move arrows are now red or blue depending on side of piece.
Fixed a bug which left a "rubber band" possible move line visible after you pressed Esc to stop inputting moves.

[Andy ONeill]

Game

Added places in.
These need more work though - the current style is far too big and clunky.
They get in the way and you can't really tell what point they refer to.

Moved show places into appsettings.
Appsettings is persisted and this setting is now used for both scenario editor and game.
Not the map editor.
Since you're likely to want to see the places in that by default whilst building a map.

Improved averaging of bearing for least cost path arrow.
This is used for the final facing of the piece and to rotate the end triangle around.
This being the arrow head.
Because a least cost path is necessarilly kind of wiggly, the arrow can still sometimes look like it's pointing in a strange direction.
That's unavoidable without smoothing out the path.

[Andy ONeill]

Game

refactor least cost path arrow building into a separate class.

Ignore last 4 points in least cost path for purposes of calculating averaged end facing.
This is because the angle is calculated from one point to the last.
The angle between points very close together is prone to anomalies.

[Andy ONeill]

Pieces
Kriegsspiel pieces in line now all have the same frontage.
Simulation pieces have different frontage depending on their unit type and previously game pieces also did.

Scenario editor in Game mode:

Simulation mode:


To highlight differences, here's a chunk of each. Notice how the Infantry unit is wider than the artillery whilst in simulation mode.
Game

Simulation


The game now respects game/simulation setting in a similar manner to scenario editor.
One difference being, no HeadQuarters pieces in game  mode.
Here's the game in game mode.


If you're thinking "Why does he keep on calling units pieces?"
We developers are forced to be pedantic and specific about names of things.
Code doesn't do kinda-right.
It's either precisely right or it doesn't compile at all.
When I mention a "Unit" this is an abstract thing in the army editor.
The clerk's notes on a Battalion whilst in it's barracks.
A "Piece" represents that battalion on the battlefield (or game board).
It is a different thing entirely because it has a load of other properties - eg location, facing, current stats, orders

[Andy ONeill]

Game

Added the option to choose a direct move for pieces which would usually use best path.
In the unlikely event you need a piece that would usually move using a least cost move, you may now do so by holding the ctrl key down.
I would imagine this will be very rarely used but it's there if you need it.


In the picture above, an infantry column would by default choose best path. Here it's using a direct (straight line) move.
The blue HQ has two move orders - the first to move least cost and then another direct.

[Andy ONeill]

Pathing

Fixed an oddity.
One of the changes I made to avoid wiggly lines had an unintended side effect.
A piece would be a bit too keen to keep on going in a straight line.
Hence sometimes ignore a road it should turn onto and end up choosing a bit of an odd route.
I removed the couple of lines of code reduced cost straight ahead and that problem seems to have gone.

Probably find pieces wiggle down some roads now or something but I'll worry about that when I see it.

[Andy ONeill]

New Pathing mechanism

I've replaced the pathing I was using for best path completely with a different implementation of spatial A*.
Like the previous version, this now relies on pre-calculated slopes within a map.
This is now done when you save a map - with the current version of the map editor.
This is a breaking change but easily "fixed".
You just open a map you created with a previous version of the map editor and save it again.
The calculations are done on save.

There is now another check in the scenario editor.
In the current version when you mouse over a HQ on the map it will try and calculate courier routes.
This uses the best path method and will error.
That courier route functionality might not be there in the final version, this is still TBD.



I have done some work on this to reduce memory overhead but this is a prototype version of pathing.
One of the things I've done is use a reduced set of nodes for a route.
This works out the centre point between start and end and uses a square around that which is sized to the largest difference in X or Y plus a third.
That means short "moves" are now much lighter weight since they're handed say a 200 x 200 array rather than 1155 x 805.
It's possible this could have introduced some oddity for some situations so I might have to reconsider.
But as it stands, if you have a piece on one side of a river and want to get to somewhere just on the other side then it's advisable to give orders in multiple steps. Choose the piece, click on a bridge or crossing and tell the piece to use that rather than try and swim.

[Andy ONeill]

Slopes

I've changed the way the calculated slope "slots" are held in memory.
This is a breaking change but we already had one of those so the fix is the same.
Open a map and save it before using it in scenario editor or the game.

For each Pixel (px) this is a measure of how steep the movement to an adjacent px is.
There are 8 adjacent px for each and a map is 1155 x 805 px.
The number of values held in memory is therefore 1155 x 805 x 8.
I've reduced the memory required by storing two values in each byte rather than one per byte.
Previously, I had a class holding an array of 8 values per px.
I now use "just" a plain and slightly more efficient 3 dimensional array of bytes.
This reduces memory pressure a little and speeds up spatial A* in my benchmarking process.
I'll probably soon mess that up by using up that memory on something else.
But I'll take that win whilst it's there.
The pre calculated supercell data will take up a chunk of that memory BUT greatly reduce the memory required by that greedy old spatial A*.
That thing just loves eating memory up.

And what else...
Oh yes.

I started on the new supercell precalc app.
Yayy!
Shiny new... what's it look like?
Well.
Nothing much to see actually.

The way this is going to work is you launch it from the map editor for your map.
Like one of those services - OneDrive or suchlike.
It'll grind away doing the calculations giving your RAM and processors a work out.
And save them to disk.
This will have no window of it's own.
That's so it has more memory available to do it's thing and because it's not something you're really going to want to sit and watch.
You'll see it running in the system tray.
I plan on it sort of transmitting progress data.
The map editor will receive that data and give you some indication of progress.
I'll probably need to add a wind down and save option so you can do a bit of a map and persist to disk. Then another bit another day.

Remains to be seen how long this thing will take but I'm thinking probably hours per map.
There are 759 supercells in a map and I wouldn't be pre calculating them if route calculation was quick.
I "cheat" and most routes are ok to reverse one you find for the return route.
If they weren't though this would be 759 * 759 routes.
It depends on your map as to how long would be an average sort of time for a route.
A fair few of my test cases are .3 to .5 seconds apiece but 1 to 3 seconds is not unusual and there's the odd 4 second one I see.

[Andy ONeill]

Super Cell Calculator

The prototype is now calculating routes.
It spins up a number of threads which simultaneously do pathing but from a different supercell each.
This is fixed at 8 at the moment.
As modern machines can have numerous cores I will let the user choose how many threads they want to run with.
On a fast 64 bit machine with many cores like a ryzen (and lots of RAM) then you could maybe crank this thing up to 30.

The calculator communicates back to the map editor on what it's doing.
This is then displayed as number of target cells pathed in each of the starting cells.
These numbers creep up until all possibilities are pathed for all of the set of 8 starting cells.
It then does the next batch of 8.
As it goes it will find more and more routes already calculated and it should speed up.

[Andy ONeill]

As I refined this prototype I broke something.
This is a particularly un fun sort of bug in that I can see my old version multi threads OK.
I can see my new version does just one thread of work at a time.

The calculator is now an odd sort of an app which is called a system tray app.
Not quite a service - which are totally invisible and run in the background on your pc.
No window - you "just" see an icon in the system tray.
Feedback is via the map editor or log file.
These things have some subtleties regarding threading which I rarely have to deal with.
And I think it's some aspect of that suddenly made a thing runs with 7 or 8 threads run just the one thread.

Not sure I mentioned this previously.
One of the reasons to make this a separate app is that it gets it's own memory allocation.
That would not be an issue if we only distributed a 64 bit app but that's not the case.
Some of you will have 32bit machines.
For a 32bit windows app there's a 2Gb ram limit.
By having low minimal resource  requirements of it's own, the calculator gets more ram to play with.

Since it takes hours to process a file I also intend building a console app version of this thing.
That can then be run from a batch file or command line on a secondary pc.
EG I have a media pc in the living room I can run this thing on.

But first things first.
I best get this initial version back on the rails first.

[Andy ONeill]

SuperCell Calculator

Tracked down the threading issue and this is now stable.
For a prototype anyhow.
The proof of concept calculates one cell at a time and the path is shown in the map editor as a dot in each cell the route passes through.
That was great for checking things were working but one at a time would take a very long time to complete.
You could keep your pet amused all day with the ever changing pattern maybe but otherwise it's not how you'd want this to work.
This version works out the paths from a given cell to all others but can do a number at once.
Rather than showing you the path it just worked out for each it shows you how many it's done.
To do that maths again for you there are 33 by 23 supercells which means 759.
Less the starting cell and up to 8 which are directly adjacent ( and probably pointless to pre calc ).
That makes 750.
Less super cells with a water or swamp px at their centre.

Personally, I need to do other things on my development PC.
I will want to run this thing on a different pc than I work on and dial down the number of threads a bit since my "spare" is an i3.
Hence I'll build a stand alone console version and add an import file option onto the map editor so I/you can copy the output file and load it separately.

Here's one of my test runs will give you an idea.
The supercell calculator itself is only visible by a little grid appears in the system tray.
Currently, if you click that icon it kills the app.

Here's what the map editor looks like with this running.
The window on top is debug output which you might find interesting.
It's set to do 6 at a time and is on the third batch of 6 after 35 minutes.



This is the debug version running.
The release version will run a bit faster.
As it runs, it will speed up.
It will find more and more paths are already calculated so each cell's calculations will decrease from that 750 down and down until pretty much all are calculated already whilst doing the final column.

[Andy ONeill]

Experiment

Yesterday I had a brainwave. Or a bad idea. I'm not sure which yet.
How about if...
Instead of calculating from each supercell to every other one.
How about calculate to it's 8 neighbours.
Then run spatial A* on a 33 x 23 grid.
Way less nodes and pre-calculation means that would be very very fast.
The pre calculation would be far quicker and way less datal.
I thought it worth a try.

Well...
It is very fast.
I can dynamically mark the supercells a route will pass through as I move the mouse.
There is no perceptible delay.

However.
I think there are some bugs in my calculation routine.
Some of the calculated costs I've looked at seem very strange.
Some routes it'll pick are good. My hopes were raised quite high.



Some are less good. Oh... dear.


I think it's worth trying to thrash the bugs out this thing though.
I'm currently including diagonal neighbours and probably should not.
Which would be 4 neighbours rather than 8 for each supercell and even faster to pre calc.

Pretty sure I've explained this previously.
But just to recap.
The purpose of this is to show you the rough route your unit will take before you click and commit the order.
I can work with that and highlight a bad route eg one that's going to mean your unit marches past enemy.

This will also allow me to greatly reduce the nodes the detailed spatial A* works with.
That will both reduce memory cost and make the detailed calculation far faster.

[Andy ONeill]

Map Editor

I've prototyped a 3d mesh representation of a map's elevations.
Conversion to a mesh takes in the order of 16 seconds and the idea is to give you a better idea of what the slopes look like.
It's quite difficult to make out where there might be particularly steep bits.

I've used the more common "rainbow" colours for this which are used to highlight height differences.
I'll also try with my hypsometric version and see which is clearer.
First-try prototype gives this for antietam:

[Andy ONeill]

Map Mesh

I changed the mesh overlay to use the hypsometric image.
Sorted out the camera positioning and lighting.
And added a slider so you can rotate the whole thing 359 degrees.

Antietam.




First Bull Run is very dramatic.
Maybe I should add a vertical scaling mechanism.
But the whole purpose of this is to visualise how steep everything is rather than to give a 3d playing area.
Exaggeration is arguably a plus.
It does look like it could probably do with a "smooth" or two run on it though.
Those visible contours are the sort of things likely to make some parts inordinately steep.



These are "proper" 3d meshes composed of many triangles.
I could probably export so you could 3d print or something.
eg Bull Run
929775 points
1855632 triangles
Which is why they take a while to build.
Totally smooth rotating though.

[Andy ONeill]

3d map

Divide elevation by groundscale so they're both to the same scale.
That then makes the maps look a lot less dramatic and much more sensible.
Also added controls to move light source up and down.
These are the triangular buttons above and below the sun.

I could maybe add a spotlight to make it easier to see particular parts.
But I'll change back to other stuff for now.

Antietam:


The area around Austerlitz - this is google maps data.


I've made no effort to remove the modern structures which are the blocky lumpy bits in some of the valleys.
Which raises an interesting point.
What would you do if you wanted to use google elevations as the basis for a scenario map?
Two obvious options:
Work round that stuff: set initial dispositions to avoid them.
Only really viable if they're not going to interfere.
Or
Level them out.