Author Topic: Changelog - picture heavy  (Read 41843 times)

0 Members and 1 Guest are viewing this topic.

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 417
Re: Changelog - picture heavy
« Reply #315 on: April 22, 2020, 07:30:50 AM »
Game

Prototyping.

Finding the points the unit will pass through as it rotates.
I've started with the central point.
We will also - at least - need the outer point.
There are two potential complications:

Some awkward terrain might be somewhere part way but not in the arc either centre or outer points describe.
The unit wheeling will be considered disordered anyhow as it wheels and for a while after.
I might make that last longer depending on the extent of a wheel.
And it was standard practice for wheeling by company to allow for this.

The other possibility is  a wheel grazes impassable terrain.
I'm undecided on what to do about that.
I might count the number of impassable px crossed and allow a small number like less than 6 or something.



The dots and the output in the Orders panel are for my information.
They look a bit wiggly because they're integer based and the output is a temporary hack.
Why do we care?
This is because I need to look up the terrain and elevation for each pixel that rotation crosses.
The data for these are held in two arrays in the map. Each is two dimensional. Hence there's an array for each pixel in our map width of 0 through 1154.
In each element of that is another array representing the Y co-ordinate 0 through 804.
A cell = a px value is looked up using x and y co-ordinates of each array.
Y being the second, vertical dimension and 0,0 being the top left cell or px.

The co-ordinates used for a cell is therefore an integer.

To provide the values for each relative px in a circle I pre-calculate for a given radius and cache that so I only calculate it the once.
This circle of relative-points ( vectors ) is calculated using something called the Bresenham circle algorithm.
That's actually the easy bit.
I then calculate what bearing each will have to it's theoretical centre and this is used to decide if a given point falls within the rotation a unit would do whilst wheeling.
This is quite tricky.
Left rotation seems to be working for a simple case at the moment.

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 417
Re: Changelog - picture heavy
« Reply #316 on: April 23, 2020, 05:13:20 AM »
Game

De-selecting current selected piece when you press Esc.
The “rubber band” following your cursor from the piece you click gets annoying pretty quick if you click the "wrong" one.

Fixing the checks for multi-running wheeling calculations.
The wheeling points calculation seemed to be slower than I expected.
And there were some bugs.
I added some debugging output to the calculation and realised the whole thing was being run many times more than I expected.
Performance and bug fixed by one change.
Huzzah!

Added wheeling clockwise and beat the bugs out of this.

I put a stopwatch in to check performance.
Takes 9 – 12 milliseconds as it stands.
So far this includes:
Calculating the rotation points for the centre.
Calculating the points from that rotation to end point.
Validating those are ok for the piece.

I also need:
Outer edge rotation points.
Check all these rotation points are valid terrain.
Check slope is valid between all points.

And of course the debugging panel and dots I put together to show the points will need removing.

Wheeling is also currently applied to any unit you click and it's only appropriate for a close order unit in line.
Skirmishers and a unit in column won’t need to wheel and will need a slightly different ( but much simpler ) mechanism to work out the points they will move through.

You’re probably bored reading this but my dev pc is a not-new i5 and I’m running debug mode ( non optimised ) within visual studio. It’d be faster if I ran a deliverable version.

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 417
Re: Changelog - picture heavy
« Reply #317 on: April 23, 2020, 09:43:28 AM »
Game

Calculating the outer arc points.
Set the width of the "rubber band" line to the frontage of the chosen unit type rather than the previously hard coded value.



I mentioned it earlier but those bobbly spots are an approximate representation of the points to show me they're not some random point over the other end of the map and I got em all.

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 417
Re: Changelog - picture heavy
« Reply #318 on: April 25, 2020, 08:11:52 AM »
Map Editor

The next step in valid moves is to check slope.

That got me thinking about how slope is held internally.
The implications of that.
But also how it's represented.

Slope is the metres difference in elevation between cells (px) divided by the scale distance a cell represents.
And the difference in elevation is always going to be a minimum of 1 metre because elevation is an integer.
One of those squares on the map is 35 px across.
It must therefore be over 38 scale metres across or slope will always be at least 45 degrees from one pixel to the next when there’s an elevation change.
A scale of 70+ metres per square is preferable.
Having said that, as scale goes up you are likely to find engagement ranges between units mean they’re quite close together before they are in effective range.
Added a user message warning when a loaded map has map scale set too low.
Map scale under help will also turn red and bold
The map scale is a bit tricky to read with the fancy font because the decimal place disappears. I’ve made the metres per square appear rounded to an integer since 2 decimal places on a metre is a bit academic.

I also built another layer to show fake highlight and shading.
This compares elevation per pixel to the one above and to it's left.
If this pixel is lower you get a dark pixel, higher gives a light pixel.
This itself is set to a fairly low opacity.
There is then options to match the other layers.
You can check/uncheck to switch this on/off.
A slider sets the layer opacity.

There is also a blur applied to this to smooth it a little.

With just the hypsometric representation:



Setting the Slope opacity to about 80% - probably more than you'd want as a background


Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 417
Re: Changelog - picture heavy
« Reply #319 on: April 30, 2020, 07:50:52 AM »
Map Scale and Slope

On further investigation this is tricky and (quite frankly) a complication the project could do without.
Originally, we had integer values for elevation.
The minimum step value of 1 metre is a problem for slope calculations since it's all too easy to have huge steps in the landscape our little men are going to have trouble climbing over.

Changing integer to float allows decimal places and was an obvious first step.
That's the easy bit.
A bunch of code in the map editor uses greyscale values.
Whether that's importing a base set of elevations or smoothing contours into rounded hills.
As it turns out, you're not going to get more than 256 steps out of greyscale no matter what you do.
Making the greyscale value a proportion of the difference between minimum and maximum can only mitigate that so much. If you want a map with a fair set of elevation changes and don't particularly want it to be 5km across then you're going to need help to smooth things out a bit.
And you're going to need help spotting potential problems.
This is what I'm working on now.

Map Editor.
Numerous changes associated with slope issues.
Changing elevations to float for decimal places.
Proportional calculation of elevation from greyscale.
This divides the difference between minimum and maximum to calculate what each step change in greyscale represents.
Hence if you have 0 - 256 that's a 1m step. And you're likely to see slope problems unless you have quite a big map scale.
0-128 would be a 0.5m step.

Note that the shapers are additive.
Hence you could potentially build a map using say a 0-50m range import initially.
Then add a sticky-up bit like the big rock at Isandlwana using a custom shaper which represented just the rocks additional elevation.
This isn't the whole solution but rather an option.

Change message on map scaling to more of a warning.
"Map scale is low, watch out for elevation differences giving a high slope between cells"
Base slope shader difference threshold on map scale

Terrain Visualiser
Make this window “topmost” initially and every time the user ceases dragging one of the sights.
This makes it pop up on top of the main window and reduces the (rather annoying) tendency for it to disappear behind that when you drag a sight around.
Added Slope to data for the point you have mouse-overed ( at top )
Added list of elevation differences with count.
Improved sizing so it gives a bit of a better impression of the terrain relative elevations.
Added a datagrid showing elevation differences between each point and the previous one and the count of each. This is in a tooltip and hence appears on mouseover of the updown grey arrow you can see top right. The idea of this is you can see if there are many big jumps or everything is smooth small nought point something changes.

You can't see it in the picture below but my cursor is over the grey up down arrow of the terrain visualiser window.
That means the datagrid appears.
Showing that 119 of the points along that line have an elevation difference of 0.2 metres.
There are several have differences of over 2 metres.
That's OK if we intend some parts to be too steep to cross.
It's not OK if we thought that big peak was just going to be a slight rise.
By definition, I don't have my mouse over the graph of elevations forms the black shape.
If I did, you'd seen details of that specific point in the heading.




Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 417
Re: Changelog - picture heavy
« Reply #320 on: April 30, 2020, 12:02:01 PM »
Map Editor

This is a work round for a bug which I think has probably been fixed but is still in some of the versions of the map editor that early adopters have.
When you draw a piece of terrain it is translated into an object.
Various things are calculated.
One of these is the list of points within the terrain.
This is used for things like telling what area a given contour covers.
We had a bug report off someone with a corrupt map.
This has no list of points for a couple of the terrain objects in it.
 
Under some circumstance, using an old version of the map editor, you could find the process working out the points contained in a piece of terrain had not finished before you saved the file or suchlike.
In this case you could end up with no list of points at all.
When you then try and do certain things with that file later the app crashes because it's expecting that list to work with and it ain't there.

My fix is to re-calculate the contained points for any object doesn't have such a list when you load any map file in the map editor.
This is transparent to the user.
Or largely so anyhow.
That recalculation is a change and you might find you unexpectedly get a message pops up saying you have unsaved changes in your map file.
You can just save it.

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 417
Re: Changelog - picture heavy
« Reply #321 on: May 01, 2020, 12:51:14 AM »
Map Editor

Added new shaper:
Squash.

The idea behind this is that should you find yourself with a map has impassable steps all over it you can "just" squash it and flatten things out so your teeny tiny little soldiers don't need ladders to move around.

This applies a factor to all elevations to sort of flatten or squash it down.
You could potentially input 1.5 and stretch elevations up.

The calculation applied allows for the minimum elevation:

((elevation - lowest) * factor ) + lowest original elevation * factor


Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 417
Re: Changelog - picture heavy
« Reply #322 on: May 01, 2020, 08:30:23 AM »
Map Editor

Do your maps look like they're built from leggo?
Need to give em a good rub down with some sandpaper?
Here's the answer.

New Shaper: Smooth.

This applies a Gaussian filter to the elevations.
A Gaussian filter is often used to process images - the greyscale contour process relies on a Gaussian filter to round off what would otherwise be a cliff edge per contour.
The algorithm works by doing a sort of an average for each cell across those around it.
It's a weighted average so the cell you are changing is influenced by those around it but the data in the cell isn't radically changed.
This essentially blurs a picture so it's often known as Gaussian blur.

Why would we want this gaussian stuff if we can do it using the greyscale processing?
An image greyscale render based approach is flexible and convenient but can only offer 256 levels because that's all windows will display.
This smoothing method applies the algorithm mathematically and therefore has no such limitations.
It should reduce slope and smooth out awkward transitions.

You can apply the effect several times - but anomalies are likely to creep in due to various things like rounding.

Like all shapers, it's best to try it out first on a scratch map you don't care about and familiarise yourself with strengths and weaknesses.
Even then I would advise you to save your file between processes and back up your work if you spent a while making a map.

Here I import the same greyscale image I used above.
I've chosen 0 - 256 so we would expect integer steps.
Which is fairly easy to confirm using the terrain visualiser.



A fair few of those steps are more than 1 metre so I've got some chunky steps and huge slopes in there unless my groundscale was pretty massive.

Applying Smooth twice I get:



Looking at the outline, this looks pretty much the same profile I started with.
Just that it's a bit more rounded out.
( Bit like myself )
You can immediately see from the list of differences that they're no longer all integer steps.
There are many non integer steps and lot of the "sharp edges" have been reduced.
It will also reduce any odd spiky bits somehow creep into a map's elevations.



 
« Last Edit: May 02, 2020, 09:20:27 AM by Andy ONeill »

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 417
Re: Changelog - picture heavy
« Reply #323 on: May 02, 2020, 09:08:18 AM »
Map Editor

We'll be doing another version of the map editor for distribution.
With that in mind I started doing some testing.

Entropy is a law of the universe.
Software development is a particularly fine demonstration of this.
The universe tends towards disorder.
Software tends to break.
As soon as you touch anything, things you forgot had anything to do with that code will break.
As soon as you let anyone else touch something you wrote, it breaks.
It's the law.

Fixed some small issues where data related to elevations hadn't been changed to float.

Add Floor to raise shaper.
This allows you to specify a minimum elevation for any and all cells in a map.
This is particularly useful if you want to remove any inadvertent “noise” out areas which should be flat – like water.
If your “set” value is a negative number when you apply an additive raise it will actually lower everything.

Redo Hypsometric image after any shaper is applied.
I found it confusing seeing no change after I did something.

Add Blue Minimum property for a Map.
If true, blue is used for the minimum level on the hypsometric representation.
Meaning sea or a lake doesn’t have to be green.
This is also useful set temporarily to check you have sensible levels for the sea or lake.

Still need to do some more testing and build the distributable.

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 417
Re: Changelog - picture heavy
« Reply #324 on: May 03, 2020, 05:26:12 AM »
Gaussian blur

Bug fixes:
Change to use original value for cell where weighted values would be based on cells which are out of bounds or "over" the edge and for cells don’t exist.
Previously, if your edge level was above zero you’d get a chamfer on the edge.

There was a potential memory leak in the way I was using my gaussian method.
Now obviating by copying the content of the array returned rather than setting map elevations directly to it.

Terrain visualiser.
I found the “sights” disappear when the background is dark or black.
Outlined the circle and arrow with a very narrow white line.
This now looks somewhat bitty - because your monitor dots don't exactly map to circular things.
But you don't just lose the things.

Pieces
Added a dropshadow to the nato symbol. 
This is something Ezra asked me about some time ago.
Back then the "wheels" on a supply symbol protruded out the bottom of it's symbol and would have made the approach I've used impractical.
Everything is now in a neat rectangle so I can work with what that is presented by.
Might not sound like much but those map symbols are tricky stuff.

In order to make the map symbols crisp, they're built in quite a complicated way using vectors.
This change is applied to the thing which contains all the fiddly bits.
It therefore could now be one relatively simple change.
As a plus it effects pretty much everywhere you see such an icon.

As well as:


Also:


Something which might not be too obvious is that the drop shadow has to rotate as the piece it's inside rotates.
If those blue units above were rotated so they face "up" then the dropshadow would still be pointing off in the same direction as it is now.

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 417
Re: Changelog - picture heavy
« Reply #325 on: May 05, 2020, 08:35:40 AM »
About window
Put the copyright notice onto 2 lines and changed the font.

Map and Army editors.
Change version numbers and rebuild ready for distribution.
Ezra should be putting these up on his site soon.

Game
Improving the rubber-band throttling process.
As you move a mouse there’s an event fires. This is used to drive the rubber band calculations.  Those calculations are quite complicated and expensive. Which means running this for every mouse move event would mean several could overlap and cause problems.
I get round that using a mechanism avoids running that process many times.

That throttling (aka de-bouncing) process had a subtle fault.
Previously, you could sometimes end up with your mouse in a different position to where it decided to calculate to.

Started prototyping a move arrow and it’s mechanism.
After you click to select a piece to move you see the line “rubber band” following your mouse position which gives you an indication whether that move is valid and what terrain the piece will travel across.

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 417
Re: Changelog - picture heavy
« Reply #326 on: May 06, 2020, 03:26:16 AM »
Installers

As it turned out the installers that had been working previously mysteriously failed to work.
Why could that be?
Net core introduces a number of extra options for builds and to cope with that the authors of the "installer project" I use introduced different functionality.
An installer project previously targetting the "old" dot net frameworks is now incompatible.
Fixed that.

These installers are not what we're going live with.
We'll be partnering Steam and a software house - to deliver disk based media.
Both have their own ideas on installation.
Steam is a "file copy" based approach which ends up in the user's app data folders and has a mechanism which will automatically detect and copy upgrades.
Any established software house has their own installers with standardised delivery mechanisms.
Our current installers are therefore "just" beta delivery methods and spending time on making them super-polished would be a waste.

I don't think the current versions will prompt you if you don't have net core 3.1 runtime installed.
You will therefore have to install it from (right column ):
https://dotnet.microsoft.com/download/dotnet-core/3.1


3.1. anything
Should be compatible.
Currently 3.1.3 but 3.1.4 will probably be published eventually and that will be an in place framework install over previous 3.n frameworks and compatible.

Apologies in advance if this seems inconvenient.
If I put time into the installers I could probably work out how to direct you there from the installer.
But there's only me and it's a case of do that or work on the game.


Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 417
Re: Changelog - picture heavy
« Reply #327 on: May 06, 2020, 09:47:49 AM »
Army Editor

Bug fix.
In the accuracies editor.
When I clicked on one of them I couldn't set it to anything but 0 or 100.
I suspect this is due to a subtle difference between .net old and .net core.
I've not changed anything in this area for quite some time.

I can now drag one of the X around up or down and clicking on the repeat button above or below sets it +- 0.01 each click.
What looks like white or pink track above or below each X is actually a repeat button like you have on a browser slider.... very likely to the right of this.
If you click and hold a repeat button it repeatedly fires the click event.
Or you can drag the "thumb" up/down.
In the accuracies editor that's the X.
For a browser, the thumb is that darker rectangle.


Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 417
Re: Changelog - picture heavy
« Reply #328 on: May 08, 2020, 01:04:50 AM »
Game

More work prototyping move arrows.
I now have the "rubber band" line disappearing and an arrow appearing once I click.



That's actually crossing a river and hence an invalid move.
You won't be able to commit that move in the finished version.
I need to add more checking - including slope - to the rubber band code and then stop the arrow process if the move is invalid.
Remove those debug wheel spots.

And.... a bunch of other things including the odd bug is probably lurking in that code.

The wheel itself will take time and temporarily disorder the unit.
If it gets into combat part way through then that will have an effect.
That needs to be translated into one of the steps which will appear in the list of orders and the like.
Maybe a circle segment indicates it's a wheel rather than turn.

Like commanders of this period, players will want to get their units into a position so any assault onto target involves a straight forward move.
All part of the period simulation, flavour and skill the player will apply.

Loader

Win 10 templates for wpf have mouse over effects for buttons built in.
You see a light blue rectangle appear, similar to mouse over effects in ms office, paint etc.
This appears on top of the pictures used as the fancy bits around the loader buttons so you instead see a light blue rectangle.
I've built a replacement template which doesn't have that mouse over effect.
The loader now behaves on win10 the same as win7.

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 417
Re: Changelog - picture heavy
« Reply #329 on: May 11, 2020, 10:00:49 AM »
Loader

There were some side effects to my first go at button templating on this.
Think these are now fixed.

Game

I've been trying to fix a couple of bugs in the move rubber band and arrow code.
They are resilient little rascals and I've spent some time chasing them round and round.
Time to reach for the BIG bug swatter.
I think I will need to change the technique I'm using fundamentally so there is one piece of code deciding what to do about user input and calculating where the unit is to go, whether that's ok and adding the arrow... removing the rubber band.

Along the way, I added a line around the move arrows.  Now units have a drop shadow the arrows looked very flat by comparison.