GrogHeads Forum

Game Forge => General Staff Support Forum => Topic started by: Andy ONeill on January 02, 2018, 12:08:07 PM

Title: Changelog - picture heavy
Post by: Andy ONeill on January 02, 2018, 12:08:07 PM
Hi all.

The idea of this thread is to list the development work as it's done on the General Staff suite of apps.
This will be fairly low level stuff. I expect parts will not be very easy to follow unless you know the apps well.
Version numbers will eventually start appearing.
This way it should be easier for early adopters and beta testers to see what's in each change and Kickstarter supporters can see things are being done.
Higher level descriptions of work including significant milestones will be posted to Ezra's blog.

The thread is likely to get quite long and demonstrate just how dull most development work is with numerous iterations before you see Ta Daaa.... this bit looks like it's working... oh... well now it looks like it's working.... oh, wait a minute... better fix that bit.  And so on.

Much more of a crawl with occasional detours in the wrong direction than a sprint to the finish.

If you have questions, expressions of admiration  ;D or whatever then please start a separate thread.
Thanks in anticipation.
Title: Re: Changelog
Post by: Andy ONeill on January 02, 2018, 12:18:58 PM
Army Editor

These changes are intended to make it easier to work with the army editor when the window is narrowed. So you can work side by side with reference material, spreadsheets, Netflix or whatever.

Gridsplitter added between left treeview panel and right detail panel. Hover over the divider to see double headed arrow, click and hold to drag width left or right.

Items marked for copying now have saddle brown background and bottom border which is also increased to 2px.
The lime green selected item background overlays this but you can still see the bottom border and make out which are marked to copy without seeing the right part of the item.

Title: Re: Changelog
Post by: Andy ONeill on January 03, 2018, 12:48:29 PM
Scenario Editor

Minor changes to scenario info view.
Increased height of form so stacked controls have more space.
Scenario name textbox will wrap and grow if it fills but still limited to 50 characters so it fits on the main window OK.
Increase height of Scenario Description textbox and allowed it to grow as user types.
Added a little padding to number of turns textbox so victorian font numbers don't look cramped.

Title: Re: Changelog
Post by: Andy ONeill on January 05, 2018, 01:13:39 PM
Scenario Editor

Bug fix
For the victory conditions, you should see a list of target units to destroy under each army with a maximum based on how many are present.
These ought to be based on the enemy army.
Hence, if the red army has 8 light infantry units then under the blue army there should be a line which shows light infantry with a maximum of 8.
If you load just the red army and open the form, then you ought to only see a list of red units on the right side ( blue ).
This was previously the wrong way round - so you saw the blue totals under the blue army targets and the red under the red.
Very obvious once you know what to look for and load just one army, then open the victory conditions form.

Now fixed so the blue list of units appears under the red and vice versa.
Title: Re: Changelog
Post by: Andy ONeill on February 14, 2018, 05:05:06 AM
The current code base is still largely prototypical and some parts are pretty creaky. Bugged even.
There will be a lot of refactoring on existing code before it can be re-used in the game solution.

At the moment I'm working towards enabling re-sizing of the map board.
In doing this I'm also rationalising bits of code in order to simplify them.
Also with a long term eye on re-usability and multi threading for performance.

Scenario Editor

Refactored out all the "magic offsets" so the board, map pieces etc all go in one container within what looks like a frame you see in the right hand pane.
Removed several canvases that aren't needed.
Rationalised map background image loading.



Title: Re: Changelog
Post by: Andy ONeill on February 16, 2018, 01:21:02 PM
Scenario Editor

First iteration.
Refactor to replace drag drop of units.
I've ripped out the old drag drop code which was buggy and pretty nasty stuff.
The old version could not support stopping the user dropping units on invalid terrain or each other, which we want.
Started replacing with a simpler drag approach.
Further work is required.

The cursor isn't offset and unitvm isn't correctly added to the lists it needs to be added to ( I just realised this as I type ).
Maybe fix up with another iteration tomorrow.
Title: Re: Changelog
Post by: bayonetbrant on February 16, 2018, 01:24:20 PM
it's cool to track the development :)


Us non-game-dev IT weenies can appreciate the headache it can be
Title: Re: Changelog
Post by: Andy ONeill on February 17, 2018, 09:28:37 AM
Scenario Editor

Dragging units off the treeview and around the board is stable now.
I spent at least 2 minutes trying to break it and it just worked.
Way faster than the original drag drop and a LOT less code.
Buggy unexpected dropping - gone.
The improved performance is particularly pleasing. I can drag a unity as fast as I can move the mouse and it just copes.

Not quite finished yet.

To do.
Invalid location like off board in swamp or water or another unit still needs handling.
Probably stick a fews seconds red flashing border on the unit and then it's gone if the user doesn't grab it.

Title: Re: Changelog
Post by: Andy ONeill on February 18, 2018, 03:58:46 AM
Scenario Editor

Minor refactor:
Both retreat point and pieces now use their center X and Y for positioning and the same contentpresenter style.
This simplifies/improves some of the code used for positioning and pathing.
Also another minor step towards allowing the user to dynamically scale them.
Title: Re: Changelog
Post by: Andy ONeill on February 18, 2018, 12:03:41 PM
Scenario Editor

Added bad terrain and collision detection for unit locations.
When you stop dragging, it checks what terrain applies and whether that unit type is allowed in that terrain.
It also checks whether another unit is overlapping.
And whether the unit is entirely on the board.
If any of these fail then the border is set to red.
If you don't move it within 4 seconds the unit is removed from the board.
Title: Re: Changelog
Post by: Andy ONeill on February 19, 2018, 03:16:28 AM
Scenario Editor

Bug fix:
If you dragged a piece that was already on the board, it was being added to the PiecesOnBoard collection again.
Anything in there is templated into a piece meaning there were actually 2 pieces where you'd expect one. As they were all stacked on top of one another it looked just like one. But odd things happened.

Dragging a unit already on board seemed a bit sticky to start off with.
This was due to only starting drag when the user moved over 2 so many pixels at a time.
A piece is relatively small though and the tendency is to start slow. Too slow.
Removing the minimum move check fixed the problem and doesn't seem oversensitive if you just click.
Laptop mouse pads might be an issue but designing a scenario without a mouse doesn't seem very practical anyhow.
Title: Re: Changelog
Post by: Andy ONeill on February 19, 2018, 08:13:35 AM
Scenario Editor

I've added scaling of the map board.
There's probably more to do, but it seems stable at the moment.
Anyhow, as you drag the corner or edges of the screen the map "board" will scale to fit.
It retains it's proportions.
In the below, I've dragged the size of the window down, reducing height proportionally more than the width.
This means you'll get a gap either side of the board if you're not careful but gives you total flexibility.


(https://i.imgur.com/4n7vH8k.jpg)

I've also (since taking that screen shot) horizontally centered the elevation and terrain textblocks.
Title: Re: Changelog
Post by: Andy ONeill on February 19, 2018, 01:32:55 PM
Scenario Editor

Minor refactor on piece dragging to reduce overhead.
Narrowed the scope of the piece dragging routed event handlers.

Refactored a load of mapping orientated code out of the mainwindow code behind into modellib.map.
Needs to be re-used in the game exe. Eventually.

Refactored out a number of public variables from mainwindow.
Title: Re: Changelog
Post by: Andy ONeill on February 20, 2018, 04:07:28 AM
Scenario Editor

Added user notification mechanism.
Textblock in menu bar shows a new message which then fades out.
Neatened up the "busy bee" which is used to show a long process is busy - during pathing calculations at moment. Now yellow with fine black outline rather than red.
Moved map scale and size to help menu

Added user messages explaining why drop location of piece is invalid.
Refactored some code around pathing.
Fixed pathing error when you drag HQ which is off board.
Title: Re: Changelog
Post by: Andy ONeill on February 20, 2018, 09:23:47 AM
Scenario Editor

Added Scaling of Pieces and Retreat Points.
There's a new slider in the preferences menu which you can drag. It goes from 20px to 80px, the default size is 35px. A px is a "device independent unit" and in theory 1/96 of an inch. Windows user settings alter that though.

The combination of Window resizing and Piece scaling should mean the game is usable on most sensible set ups.
At the risk of stating the obvious, there is only so much you can do on this.
Scaling units can make them bigger and they could then in theory overlap each other.
Bad things are likely to happen if you played a game like that.
In the below picture, I first reduced the size of the window down so it's pretty small.
That scales everything on the board down, which makes pieces tiny.
I then maxxed out the piece scaling.
The screen shot is just to kind of give you the idea, it's resized to 60% of size in case anyone cares about bandwidth.

(https://i.imgur.com/mMQ0xZA.jpg)
Title: Re: Changelog
Post by: Andy ONeill on February 20, 2018, 12:10:02 PM
Map Editor

Marching ants prototype.
This is a proof of concept animating dashes around a polygon.
Title: Re: Changelog
Post by: Andy ONeill on February 21, 2018, 03:09:56 AM
Scenario Editor

Minor adjustments on menu items formatting
Changed piece size slider to use brass pointer template
Removed all allowdrop settings out the UI - dragging things round is now all using non standard approaches ( for performance) rather than "proper" drag drop.
Title: Re: Changelog
Post by: Andy ONeill on February 21, 2018, 05:10:32 AM
ModelLib & Scenario Editor

There are several libraries ( dll ) which are intended to be used in the various exe.
One of these is ModelLib, the "model" in programming terms is the data being represented and this contains a class called Map. Which is (surprise) all about the map. This is where what terrain is where is stored and has methods to read that data.

In order to give orders to units we want the user to choose a unit and drag to a waypoint.
With a "rubber band" showing the line it would take. Just a line from start point to where you're dragging or moving the cursor.

This is gaming stuff ( I'm a business app developer ) so Ezra designs this sort of thing and knows about game specific things like working out what terrain a line crosses.

Maybe this is interesting to someone reading.
There's this thing called a Bresenham line algorithm https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm (https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm).
Which Ezra "just knows" about and explained is very fast.

I've been prototyping something to see whether this'll work or not.
I grabbed this guy's code:
http://ericw.ca/notes/bresenhams-line-algorithm-in-csharp.html (http://ericw.ca/notes/bresenhams-line-algorithm-in-csharp.html)
Which is nice and efficient, I particularly like the use of yield.

We don't have a game solution yet so I've temporarily bolted this onto scenario editor.
I needed 2 points. Somewhere to go from and to, so I used a retreat point as starting point.
Turns out that algorithm is very fast and takes less than a millisecond.
My machine has a fairly recent i5 processor so it's reasonably fast but I'm testing this in debug mode so which is slower than optimised code.

(https://i.imgur.com/S2IE6sE.jpg)
(https://i.imgur.com/F2LLLvU.jpg)

I'm using faked terrain checking with woods, water and swamp as invalid for anything.
On the top image you can see the line crosses woods and is an invalid move.
On the bottom image the line crosses nothing invalid and is OK.

You can also see some debug info I've put in top right.
I'm using a stopwatch to check performance and you can see the milliseconds and "ticks" elapsed. ms 0 means less than one ms which is fast.

Conclusion
The experiment shows excellent performance.
I'd expect even an old i3 and maybe atom would be fine with this.
Title: Re: Changelog
Post by: Andy ONeill on February 22, 2018, 03:49:10 AM
Map Editor

I've been looking into the work which needs doing on the Map Editor.
This is very much a prototype stages app.
Some work will see it stabilised, improved and sharing common code.
Short of dedicating my life, this is always going to be a relatively basic sort of a drawing tool.
I think also that drawing the map is by far the hardest part of scenario design.

Which got me thinking.

Some of you may of course be graphics designers so it'd be nice if you could use specialised software.
Others may want more sophisticated functionality but don't want to pay a couple of grand and spend 2 years learning how to use it.
Maybe some are like me - a developer but not so much of a designer.
Some others will be OK learning a little and doing some manual editing for something to work
Maybe some are even wpf designer/developers and already know XAML.

My plan is to try and include all these groups and offer more.
More is always good.

There's a free piece of software called InkScape.
This allows you to produce "vector" graphics by drawing or tracing.
I use it a fair bit for tracing stuff.
You can also convert graphics files to InkScape friendly format.
Once finished you can save the result as a .XAML file.

That can itself be edited and previewed in xamlpad or visual studio.
Xamplpad is a very lightweight self contained exe you just copy onto your machine, it's free.
You text edit in one pane and see the results in another.
Visual studio community is a pretty big install but also free.
I develop using visual studio.

As an experiment I modified the map designer so you can optionally load such a file.
I then fired up my copy of InkScape.
Because someone already expended some years working on InkScape there are a huge number of options available.
I picked a "pen", width and fill colour.
I then drew a wiggly blue line in inkscape.
When I drew this freehand it gives me totally smooth curves.
There's huge flexibility.
I could move, rotate or manipulate that little drawing in almost infinite ways.

I didn't bother with any of that because I'm just experimenting now.
I just saved my wiggly line as xaml.

This gives a bunch of stuff in a text file which I had to eyeball.
From that I picked the "Path" out of my saved file and put it in a canvas tag of a new .xaml file.
I did this in NotePad as a .txt file and then renamed to .xaml.

Ran my modified map editor and clicked the button.
The result was as expected and I get a line on top of my picture.
Because it's a control of sorts I can add some functionality to the map editor to work with it.

You might be thinking "If it's just about editing a picture then can't I just use a scan and be done with it?".
That'd be fine except the map isn't just a picture
Each pixel is a type of terrain - a field / road / woods etc.
Each pixel has an elevation.
With such a path I can write code works out which bits of the map it covers.
Allowing the user to say this area here is water.

Conclusion

This looks to be a good way to offer optional functionality for the power user.
Not everyone will want to bother but those that do will get a very powerful tool with huge flexibility.

Title: Re: Changelog
Post by: Andy ONeill on February 22, 2018, 08:56:13 AM
Scenario Editor

Investigating optimisation of pathing.
Pathing uses spatial A* and is a very expensive operation.
At the moment it's only used for couriers which will be an end of orders calculation.
Hence it doesn't really need to be super fast.
This is just as well because it can take a while.

I have this on a background thread and have experimented with multi threading the process.
The problem with that is it's no faster due to the expense of creating the necessary arrays per search.
I've neatened up the code but it's just on one thread.

Title: Re: Changelog
Post by: Andy ONeill on February 23, 2018, 07:33:19 AM
Scenario Editor

Refactor on place and points labels.
This improves the look, uses a more sophisticated approach for the objects.
Added mouseover effect on these which increases their z-index so they can be overlapped and still readable.
There's an anomaly in the way these were positioned, but this is cosmetic and can be resolved as part of the map designer work.

Now with rounded borders, a faded drop shadow and will respect the size of the text within.
With Victorian fonts:
(https://i.imgur.com/iDFJRAL.jpg)

With plain:
(https://i.imgur.com/m1WBW0z.jpg)
Title: Re: Changelog
Post by: Andy ONeill on February 24, 2018, 12:59:09 PM
Scenario Editor ( but will really only be used in the game ).

Replaced Pathing.
The original approach was a prototype but bugged, slow and could not be multi threaded.
It also only used very simplistic terrain efffects.

After trying several alternatives, Ezra gave me a bunch of links to investigate.
One of them eventually led to this library:
https://roy-t.nl/2017/08/01/A-Star-Pathfinding-nuget-package.html
This initially showed some promise.
It turned out to be bugged and prone to running out of memory.
This is a bit of a problem in a live game.

Title: Re: Changelog
Post by: Andy ONeill on February 26, 2018, 08:05:25 AM
Scenario Editor

Some improvements to place labels and points plaques.
Replaced the bitmap images with clearer, easier to read vectors.
Although not implemented at the moment, the new approach would allow us to use different backgrounds or fonts for the numbers on the plaques.
Anyhow, this should make it easier to read for those of us with less than perfect eyesight and or when running on a small display.
(https://i.imgur.com/aT7npoM.jpg)
Title: Re: Changelog
Post by: Andy ONeill on February 26, 2018, 09:18:11 AM
Map Editor

Improving handling of empty place names.
It's inordinately easy to add one. The whole cannot-fix-mistakes-you-make needs replacing but in the meantime at least don't read empty ones in.
Title: Re: Changelog
Post by: Andy ONeill on February 27, 2018, 06:57:08 AM
Scenario Editor

Stabilising pathing.
Also made some changes to terrain costings, simplified maths for diagonal moves and changed some types to integer for faster maths.

Title: Re: Changelog
Post by: Andy ONeill on February 28, 2018, 09:14:19 AM
Map Editor

Planning new approach to map editing.
When you draw thoings on screen they will be retained as objects which you can then select, move round and probably adjust  points on them.
You'll be able to fix mistakes at any point.

Created new Solution and started.

Title: Re: Changelog
Post by: Andy ONeill on March 02, 2018, 10:23:37 AM
Map Editor

Standardised and optimised grid line drawing.
Styled up the various drawing options.
Added fancy divider control
(https://i.imgur.com/o4vdqZX.png)

Shooting

Ezra and I have been discussing shooting.
And cannons actually, but let's just talk about effectiveness of shooting.
This is pretty good at short range then drops off.
Graphed effectiveness vs range should look something like:

(https://i.imgur.com/CrjiGOG.png)

Rather than try and work out an equation representing this, I think the most practical approach is to have an array with a multiplier per percent range.
It's probably a bit different one weapon system to another as well so maybe there's two or three curves to represent.
Since our aim is to make as much as possible user configurable, such an array is likely to be user editable.
Title: Re: Changelog
Post by: Andy ONeill on March 03, 2018, 10:32:44 AM
Map Editor

Experimentation with patterns for a tree fill.
The prototype uses random combinations of png which is kind of limiting and so I've been working on using dynamically constructed objects.
A few of these look like:
(https://i.imgur.com/DX0zE71.png)

The advantage of this approach is flexibility - the user would be able to pick colour and size of what fills a piece of terrain.

Title: Re: Changelog
Post by: Andy ONeill on March 05, 2018, 09:53:07 AM
Map Editor

First iteration: drawing a forest.
The way drawing areas works is you select your tool ( or you will once things are beyond prototype stage ).
You decide where you want your area ( forest ) to start. Click and hold the mouse button, drawing an area as you move the mouse.
When you release the button, the shape completes automatically. It's a polygon.
It's very difficult to "close" a shape precisely, so this approach means you just need to get near the start point and stop rather than absolutely hit it.

After some experimentation, I reckon the most "natural" looking way to do this is to randomly place the trees.
I do this by hit testing, within the area and not on a tree.
The size of trees is varied randomly and I'm using just one of several tree options.
Hit testing is quite a processing expensive process and of course as it progresses, there's less and less area it can drop a tree in.
As a result, it takes a few seconds to fill large areas.
Maybe I'm a bit weird or maybe it's because I wrote the code does this but I find it quite satisfying watching my forest grow.

This isn't going to give you trees perfectly up to the edge so I apply a background.
This is a texture generated at run time. The way this works, we could allow a user to pick the colours and proportions ( or not bother ).
So if your forest floors should be transparent then no problem, if you prefer a mix of browns or greens or everything sepia then this is all do-able.

As you draw an area you get an effect called "marching ants" the dashes animate around the outside. This will be used to denote the "active" selected area when you have multiple pieces of scenery on the map.
Once you finish you'd de-select your last piece and the finished map would have no dashes.
Unless of course you like em ;^)

The complete effect at 60%
(https://i.imgur.com/8NsH0uC.png)
A chunk at 100%
(https://i.imgur.com/B4DUELx.png)
Title: Re: Changelog
Post by: Andy ONeill on March 06, 2018, 12:59:50 PM
Map Editing

More work on the algorithm used to place trees. The size is now reduced as the process runs.
Put a panel over the various options whilst the process is busy.
Added a quill-in-ink-pot indicator which shows how far through planting trees the proces is.
This runs quick for small areas but for large complex ones it can take a while.

"Spinner" wait indicator.
This is similar to the fairly common spinning petals used on web apps and appears on the right of the toolbar.

Line optimisation routine.
As you draw any sort of line on screen it generates a bunch of points. These are x y co-ordinates.
The aim of the optimisation is to remove unnecessary points.
It considers sets of three points in the line and uses some rather geometry to decide if they all line up.
It removes the central one if they do.
There's a 2 degree of variation allowed.

Title: Re: Changelog
Post by: Andy ONeill on March 07, 2018, 06:21:28 AM
Map Editing

Experimenting with drawing smoother lines in a separate solution just intended for this purpose.
To some success.
This would just be for "line" drawing such as rivers and roads.

If you take a look at some of the roads in images above you will notice there's a lot of jaggies going on.
This experimental method uses "ink". This is intended for purposes like drawing your signature for the postman. To smooth out drawings this tech uses some very tricky smoothing stuff with Bezier splines.

(https://i.imgur.com/5iYkRv6.png)
(https://i.imgur.com/wNPIyqa.png)

The above 2 pictures are crops of part of the window and the road/river is 5 px wide, so on my monitor they're magnified in the forum preview compared to the app running.
They're drawn as two lines on top of one another.
The dark wider one is "below" the lighter top one so it looks like an outlined shape.
We could allow selection of colours and width of both.

In an ideal world I'd write a more flexible algorithm, but that looks like it'd take way too long.


Title: Re: Changelog
Post by: Andy ONeill on March 08, 2018, 03:24:04 AM
Map Editor

More work on "line" structures.
The graphics you see on the screen are only part of the map story.
The game "knows" what terrain a unit is in based on a matrix ( a two dimensional array ).
That means once you draw something I have to work out what cells the shape covers so I can mark them as road or river ( forest / fields etc for other tools ).
Once you draw something it's shape is defined by a sort of series of points like join the dots.
With that fancy spline stuff, smoothed out shapes aren't just plain straight lines though.

My first attempt uses a sort of brute force hit testing around each of the points in the line.
Hit testing is quite an expensive action and there are thousands of such points.
The result is a bit slow really and I'm going to try plan B.

Title: Re: Changelog
Post by: Andy ONeill on March 08, 2018, 09:42:51 AM
Map Editor

New shiny improved way to find all the points inside a line.
This uses a different technique which is faster and can also be multi threaded.
Also worked out a couple of bugs in my code.
Still experimental but can be ported into the real app.
With a bit of neatening.


Title: Re: Changelog
Post by: Andy ONeill on March 09, 2018, 10:00:13 AM
Map Editor

Refactoring prototype drawing process towards production ready code.

Title: Re: Changelog
Post by: Andy ONeill on March 10, 2018, 05:33:47 AM
Map Editor Prototype

Many rivers aren't the same width along their length.
Today, I did a quick experiment with making a river widen from start to finish.
This seems pretty effective so I think I'll be adding this as an option.

(https://i.imgur.com/NjiGI9s.png)

Title: Re: Changelog
Post by: Andy ONeill on March 19, 2018, 03:01:55 PM
Scenario Editor

Fixed a minor bug with the place names display.
Changed pathing to take into account elevation changes. Climbing is harder except on a road. It's assumed a road takes best path going up and down hills.

Map Editor

I've done a fair bit of experimentation with stylus support for ink - this is definitely a good option and I'll be adding support for a stylus and "pressure".
I've also been iterating towards allowing the user to select terrain already drawn.
Using the prototype, you draw something and commit it. That's it.
My version will allow you to select objects you have drawn and delete or edit them.
There's only a load of code to show for this at the moment.

I've also done some investigation into storage options for the various pieces of map data.
This needs to be made secure for PBEM games in order to stop an opponent cheating.
It'd also be a good idea to drive down the size of files.
I'm thinking of zipping up and encrypting all the files into one.
Title: Re: Changelog
Post by: Andy ONeill on March 20, 2018, 02:19:34 PM
Map Editor

More work towards allowing you to switch between drawing modes.
You can now actually draw a forest and get it to appear.
Terrain objects are now numbered with an Id so the app knows which are what.
"Children" of these eg the trees which appear to go inside a forest are allocated this id so you can tell which trees are associated with a particular forest.

Prototyped a tabcontrol which allows you to arrow through it's tabs ( less intrusive than clicking tabs ) for the left panel.
Added the templates etc for this into the map editor.
Moved the existing drawing list into this.
Second tab which will allow you to pick a terrain object already on the map is as yet just a stub.

In the picture below, Drawing Options is the current tab.
Click the chevron to the right and it switches out to Edit Terrain

(https://i.imgur.com/x8O2aWN.png)
Title: Re: Changelog
Post by: Andy ONeill on March 21, 2018, 05:55:03 AM
Map Editor

First cut of the Edit Terrain tab.
In the screen shot you can see I've drawn a bunch of woods and the list to the left refers to these. The number is their ID and incremented as you add each terrain object.
Selecting one of these on the left gives the corresponding terrain on the map a "marching ants" animation. The dashes in the screen shot are moving in the real thing.

(https://i.imgur.com/dyhuzrt.png)
Title: Re: Changelog
Post by: bayonetbrant on March 21, 2018, 05:57:32 AM
The marching ants effect is a nice suble way to suit what's selected
Title: Re: Changelog
Post by: Andy ONeill on March 21, 2018, 09:58:01 AM
Thanks.
The marching ants idea was Ezra's. 
He thought it couldn't be done though  :D  ::)

It's obvious which one you're working with, but you can see the content and it doesn't cover other stuff impact image quality like eg a dropshadow would.

I was going to make the animation work in all "modes" but it's quite processor intensive and I want to keep the hardware threshold low. ( Within reason, functionality and time expended developing are also important ).

If the animation is running whilst you're drawing there's a noticeable gap between the pen and the ink appearing following it.
Ink offers smoothing which is huge for anyone isn't some sort of graphics ninja.
Presumably that smoothing is also quite processor intensive.

Rather than spend weeks optimising things nobody cares about, the simple fix is to just do the animation whilst in edit mode.
If you just drew a lake or woods then you know which one you just drew.
The effect is also a bit distracting so I think this is a plus all round.


Title: Re: Changelog
Post by: Andy ONeill on March 21, 2018, 02:15:28 PM
Map Editor

clipping canvas so you don't get weird stuff happening when you draw outside it's bounds.
I found it kind of funny the first time I drew a forest over half the options in the left tab but...

Choose a terrain in edit mode and hit the delete button. The terrain and any children (trees if it's a forest) are removed.

Stop user drawing unless they're in drawing mode

The outline of woods isn't as definite as I'd like.
Added very fine dotted line round them, which seems to work.

Reclassifying some of the drawing types and removing pluralisation

First iteration of drawing Lakes.
Title: Re: Changelog
Post by: Andy ONeill on March 23, 2018, 01:19:00 PM
Map Editing

Shook out some bugs and added waves to Lakes.

(https://i.imgur.com/QbRy8aT.png)
Title: Re: Changelog
Post by: Andy ONeill on March 24, 2018, 10:50:48 AM
Map Editor

Setting the colour of the ink you draw with depending on what terrain you've selected to draw.
Water is blue, for example.
Title: Re: Changelog
Post by: Andy ONeill on March 25, 2018, 01:35:28 PM
Map Editor

Added swamp.

(https://i.imgur.com/1XTKqLt.png)
Title: Re: Changelog
Post by: Andy ONeill on March 26, 2018, 04:23:53 AM
Map Editor

Added Fields.
(https://i.imgur.com/ztdJJWR.png)

The fill on these is randomised using the same mechanism as the woods background. I could potentially allow a user to customise the colours and frequency used for both.
Title: Re: Changelog
Post by: Cyrano on March 26, 2018, 09:22:51 AM
GIVEITGIVEIT #GIVEIT

That is all...

Title: Re: Changelog
Post by: Adraeth on March 26, 2018, 09:44:40 AM
It feels like an excellent engine ... i am here wonder how many battles i will edit with this new UMS .... work hard and bring it to us  O0

thanks for every update
Title: Re: Changelog
Post by: Andy ONeill on March 27, 2018, 05:20:14 AM
Hi guys,

Good to see people are keen.
I hope that lasts  :)

I'm still a while off completing the map editor.
This version will have some ( I guess quite big ) files associated with a map that you use just to edit them.
As you draw there are many points define the line you draw. These will be saved to files and of course "many" anything means big.
I plan on zipping these though.

The prototype you may have tried only has the areas you drew until you click that commit button. They're then copied onto a picture and gone.
You make a mistake then you have to live with it or start again.
This is the nature of prototypes.

The new version will retain all the data so you can edit later and retain the quality.
It is planned to allow you to export vector pictures ( probably pdf ) so you can print a high quality map to poster size.
When playing the game, these terrain objects probably won't be used and you'll instead effectively use a picture of the map as a background.
I might think about giving the option to retain those objects instead but the large size would mean we couldn't support transfer from a pbem / live server as is planned. There's also a fair bit of overhead in stuff like arranging all the trees in a forest.

Then there's the actual game to write.
The pace probably looks pretty glacial from an observers point of view but it's pretty quick for development generally.

Another thing worth mentioning is that the apps will also be improved after release.
As we see issues, receive do-able suggestions or I think of stuff then they will be added.
This is a suite which is intended to have a long life time.

Title: Re: Changelog
Post by: Andy ONeill on March 27, 2018, 09:54:49 AM
Map Editor

Added City.

I spent a while thinking about how to draw a convincing looking city.
This works with a sort of vector scan of a real map.
The user will be able to pick from a number of such models but they don't really scale so well.  I have three. I did what I felt was the least convincing first as a proof of concept.

(https://i.imgur.com/egXR7aU.png)

The image I see in preview is about 1.3 x the original. It'd also probably look better if I was more careful about drawing the shape.
If it looks a bit abstract, that's intentional.
Title: Re: Changelog
Post by: Andy ONeill on March 28, 2018, 03:34:43 AM
Map Editor

Here's another option.

(https://i.imgur.com/L3fEXH2.png)

I'll do a couple more pre-built ones.
Clearly, it's impossible to offer something for every single sort of city people might want and we want flexibility to encourage people to get creative.

I'm going to allow the user to add specific buildings.
You can't really beat the human brain for working out sensible layouts.
This will offer the flexibility required to place a house next to a road or river and another next to it.
Villages will work better that way and if you have the time and energy for a complete city then you can go wild.
Those that don't care and are happy with an abstract rectangle kinda looks like buildings.... well they're already covered.

There will be another option to import a picture. You would draw an area on the map set it to your picture and allocate a terrain type  to that. City will be one option. This will be necessarilly rather fiddly but is the only realistic way to cover some possibilties. Bear in mind the entire map can also be a picture if you want buildings scattered all over a massive city.
Title: Re: Changelog
Post by: Andy ONeill on March 28, 2018, 09:16:20 AM
Map Editor

First cut of contours ( for hills ).
(https://i.imgur.com/c7b9QRE.png)

Not terribly exciting I'm afraid.
I still need some way for the user to say what elevation each contour is to be and decide how to  display that for review. Probably when selected.

When I did this I drew several contours inside one another and found a bug.
Pretty nasty one actually.
The animation which does the marching ants wasn't always stopping and that's very bad because it's a resource hog.
Fixed that.
Title: Re: Changelog
Post by: Andy ONeill on March 30, 2018, 12:57:42 PM
Model

Added Square to formations.
After some discussion we came to the conclusion that Infantry will be able to form square but light infantry will not.

Map Editor

Added setting height to contours.
This is in "units". There's a factor which converts these to metres.
Elevation units vary from 0 to 255.
The reason for this is due to how elevations are held and the way we intend most maps to be built.
Contours are intended as a fallback because drawing a map using these can be pretty tedious and there is no gradation between layers.
The preferred approach is to use a picture with white throug shades of grey to black.
255 shades of grey.
We're the team that just keeps on giving.
More than 5 times the grey of those colourful books  ;)

In case you missed earlier posts.
The contour with the black dashes corresponds to the one selected in the left and it has a "marching ants" animation makes those dashes move round. You will not miss which piece of terrain you selected.

(https://i.imgur.com/FxaoHXW.png)

I might hide the id over on the right since it has no particular meaning to the user. That's what internally identifies the piece of terrain but you will never have to actually know that. It should quickly be obvious to any user that the most recent terrain they drew appears at the top of that list and the first at the bottom. It will scroll if you draw a lot.

Title: Re: Changelog
Post by: Andy ONeill on March 31, 2018, 09:19:52 AM
Map Editor

Added roads.
I'm undecided about the colour of the outline and fill.
Because black looked a bit harsh I've made it fairly fine ( 1px ) and dotted.

You will notice that a road always has a line all he way round it. That's because it's not clever, it doesn't know part of it is on top of another road.
I will probably give an option to combine all roads into just one shape for making the map "picture" at the end of the process to avoid that effect.
I'd have to try it and see but I can't think of any bad side effects from doing that.
Doesn't mean there aren't any.

(https://i.imgur.com/6aoLdwk.png)

I hope everyone is enjoying Easter.
 <:-)
Title: Re: Changelog
Post by: Andy ONeill on April 01, 2018, 09:55:06 AM
Map Editor

First cut of Rivers.
When you draw them initially they're a line the same width like a road.
On the edit tab there's currently a prototype button with a > on it.
This applies ink "pressure" along the stroke you drew for the selected river.
It does so from the end you started drawing.
There'll be a < button to do from end to start. Although drawing a river that way just seems wrong to me.
I'll do some better symbols for the signs rather than lt and gt signs.
We also need a way to specify width since rivers will vary a fair bit.
If you use a stylus to draw a river then you can alter the pressure yourself manually.
For anyone unfamiliar with stylus - the higher the pressure the thicker the line you draw.

(https://i.imgur.com/NfnB4Zh.png)

Similar to roads, you'd currently get a line round any bit of water. I'll allow the user to combine lakes and rivers into one compound object which will avoid that line across joins I talked about in the roads above.
Title: Re: Changelog
Post by: Andy ONeill on April 02, 2018, 08:46:31 AM
Map Editor

Finished the buttons for setting widening on rivers programmatically.

(https://i.imgur.com/gMAzljn.png)

The chevron pointing  to the right will make the narrowest part the end you started your ink stroke from.
The one on the right does so from the end ( which seems weird to me but maybe someone will want to draw that way ).
The rectangle makes the width equal all along.
Title: Re: Changelog
Post by: Andy ONeill on April 02, 2018, 11:46:26 AM
Map Editor

Prototyping combined water.

Before

(https://i.imgur.com/nQu0SsG.png)

After

(https://i.imgur.com/kdmZZne.png)


Note that the waves on the lake are in a layer below the combined result. They're still there, you just can't see them. I'll fix that once I've shaken the bugs out of this method.
Title: Re: Changelog
Post by: Andy ONeill on April 03, 2018, 05:48:04 AM
Map Editor

Another iteration on combining water.
You can now combine and split water.
When you combine it hides the separate objects, when you split it will show them again.
Combined water appears in the "correct" layer so waves are on top of a lake once combined.
It's actually a separate object and the process of working out how the various shapes combine is pretty expensive but only takes a couple of seconds on my i5 machine in debug mode. It will be faster in the real thing - debug code is not optimised by the compiler and Visual Studio (the development environment) isn't exactly lightweight.

(https://i.imgur.com/hedrfeM.png)
Title: Re: Changelog
Post by: Andy ONeill on April 04, 2018, 04:13:36 AM
Map Editor

Added roads to combine / split logic.
They go on top of water.
Submerged roads aren't terribly practical.
I reckon some people will want to dash off a quick map as quick as possible and this allows you to not bother with bridges.

Fixed a bug which was eating processing.

(https://i.imgur.com/KRQBOja.png)

Title: Re: Changelog - picture heavy
Post by: Adraeth on April 04, 2018, 06:16:08 AM
Roads (instead of bridge) over troubled water  ;) ... excellent idea; yes i am one of those to make a fast map to play almost immediately
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 05, 2018, 03:28:41 AM
Map Editor

I might have explained this earlier but maybe at the risk of repeating.
Which terrain is on "top" isn't just a visual thing.
There's a 2 dimensional array of terrain type used for spatial A* navigation and for tactical movement.
This will need to be calculated at the end of drawing a map.
Whichever piece of terrain is top wins and that's what the square terrain is.
There are 1155 x805 "squares". They're 1px x 1px  - and very small.
The grid you see on the screen shots is 35x35px.

A road over a river makes the cells it crosses road and a crossing point. Your courier might decide to swim across if the alternative is a very long distance and a river is narrow. Combat units will not.

Development work, largely internal:
Changed background colour of swamp to green (from light blue) so it is more clearly distinct from water.
I've refactored the "marching ants" animation process. This was to avoid repeated storyboards ( the thing that does the animation moves the dashes ). There's a very technical reason why this was worth doing that only wpf developers would be interested in.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 07, 2018, 09:59:43 AM
Map Editor

Added Fortifications.
These are necessarily somewhat abstract.
There are numerous things you might want to classify as fortifications during our period. They come in all sorts of shapes and sizes and it's not practical to give a way to draw any of these dynamically.

If you want something that looks like trenches, breastworks or a star fort then you'd use a different mechanism and import your path or picture, then tell the editor that is fortifications.

(https://i.imgur.com/1L0UEee.png)
Title: Re: Changelog - picture heavy
Post by: Adraeth on April 09, 2018, 02:53:09 AM
About trenches, fortification:

do you think Red is the right color for them? might them be confused with red army units?

However i can't think about a different color, maybe grey?
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 09, 2018, 06:19:31 AM
I don't think you'd confuse this red with units, they're a paler sort of red.

Red is extremely intrusive though.
They are going to be fairly important things but maybe we don't want them to stand out quite that much.

There's actually two parts to this. Probably clearer with a picture.
The dashes and center can be different colours.

If you think in terms of castle wall sort of things then this'd look a bit too much like just a stone wall ( one of the boundary options ).
Dark and light gray
(https://i.imgur.com/yYYvRxN.png)

I think I prefer Sandy brown and Sepia.
(https://i.imgur.com/Ue3QJ9O.png)
Title: Re: Changelog - picture heavy
Post by: Adraeth on April 09, 2018, 07:58:03 AM
Sandy Brown and Sepia is excellent, reminds me of old battle maps  ;)
Title: Re: Changelog - picture heavy
Post by: bayonetbrant on April 09, 2018, 08:39:46 AM
FWIW - the obstacles and engineer works appear in green on modern-day US/NATO graphics overlays, with friendlies in blue and enemies in red.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 09, 2018, 10:23:30 AM
Green is an interesting thought.
Another boundary type will be hedge though and that'll involve green of course.

Hedges and walls can be quite substantial things in the European countryside.
Not often quite so substantial as in the bocage but still significant defense against small arms.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 09, 2018, 10:28:14 AM
Scenario Editor, ModelLib and Map Editor

Added new area terrain type, Mud.
(https://i.imgur.com/aEAU7ND.png)

At the moment, all unit types can move through mud.
Some do so very slowly.
Since this is new ( I realised we'd want mud a couple of days ago ) we may decide to make it impassable to some units.
As it stands though, you could just use swamp if you want really really bad mud that most unit types can't move through.
Title: Re: Changelog - picture heavy
Post by: Adraeth on April 10, 2018, 08:14:38 AM
Mud is excellent to slow and "disorder" horses and artillery, and can portrait easily  bad weather (rain)
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 11, 2018, 09:34:12 AM
Mud can be used for any zero height terrain which will impede movement.
You will be able to decide by how much it effects each type of unit on a scenario by scenario basis.

I think mud was quite significant at Waterloo.
There are other similar types of terrain though like moorland or just somewhat marshy ground. Either is very difficult going as anyone who's ever done any hiking walking will tell you.
This can add interest to some battles would otherwise be somewhat featureless.
Maybe Culloden ( I don't know offhand ).
You might consider some "swamps" in French Indian/1812 etc might be more appropriately set to mud.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 11, 2018, 09:46:04 AM
Map Editor

Added Boundary as a first iteration.  The first version is intended to be fence.
(https://i.imgur.com/DPDytDq.png)

I'll probably go with red brick walls and of course green hedges.

This particular one led to some discussion about how fence, hedge or wall should work.
These are all slightly different boundaries.

You might think horses can jump fences so they cross them.
It seems they proved too much of an obstacle for some formed units. Maybe the average cavalry nag isn't much of  a jumper and large bodies of men/horse don't do so well with any obstacle.
There is also the issue of the likes of enclosure walls. Often not strong enough to stop a cannon ball so not a fortification really. But if the French could just walk into hougomont then things would have gone rather differently.

At the moment I have fixed "hard coded" settings control who can cross what terrain. This is as well as rates.
It has to be an on off thing because it'll be used real time as you drag a move order "puck" round. No you can't cross one of the pieces of terrain in that direction or yes you can cross all of them.
I'll make this editable per scenario in a new view within scenario editor.
It's then up to you to decide what fences do in a specific scenario stop.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 11, 2018, 12:32:59 PM
Map Editor and ModelLib

There are now 3 different boundary terrain types -  fence, hedge and wall.
Boundary is just a logical grouping of these though.
A boundary is drawn as a fence and you can then switch between the three options using 3 buttons in the editor for Boundary:

(https://i.imgur.com/rftbK17.png)

Drawing boundaries works slightly different from most other drawing objects in that the tendency to smooth to a curve is suppressed.
That's because these are one of the few things in the countryside where you may well really want a straight of wiggly line.

Hedge and wall will block line of sight to a height of 2 metres.
To use these as cover, you put a unit on the piece of terrain.
This represents your unit lining on one side of the wall but using it as cover.
If you are not on it then it blocks los for you, unless you or your target are somehow higher than 2m than the wall.

Fences just block movement. Or not - depending on your preferences.
 


Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 12, 2018, 10:38:52 AM
Map Editor

Added Bridge.
Drawing a bridge works somewhat differently from everything else so far in that you're not actually drawing an area or a line. As you mouse down and then up this defines the two ends of a straight bridge between.

(https://i.imgur.com/TJ255UL.png)


Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 13, 2018, 05:51:04 AM
Map Editor

Added Ford.
Since bridges are way better than a ford (in the real world) they count as mud for speed of travel and whether they block some unit types.
(https://i.imgur.com/VEq3OMT.png)

In the above picture I've drawn sort of along the river and back in order to show you can do an irregular shape if you want.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 16, 2018, 04:46:43 AM
Map Editor

Added first iteration of Place.

(https://i.imgur.com/UWi19eE.png)

In order to do this I've moved a bunch of things round such as the view for places which is now in a common library.
I also resolved a number of issues to implement just clicking to add a point differently from everything else with it's Ink support.

I'm still considering whether to allow multi line names for places and a combo box for the points value. At the moment if you typed a number I've not set a geometry up for, you get nothing in the plaque. I will probably just set up paths for 0-9, force only numeric input and leave it up to the user if they feel 99 is really a sensible VP for a place.
I still have to allow the user to pick which side the place is currently associated with.

In the picture, you will notice that the "marching ants" rather mysteriously continues some distance below the plaque rather than just under it. By default, you get the place name above a plaque. If you position a place close to the top of the  map then of course there is no space for the name above, so it appears below instead.  There are two of the labels in the control. I hide the bottom or top one depending on position. The control positions itself so the centre of the plaque is where you click. In order to do that reasonably easily I divide the width and height by 2 as part of the position calculation. Hence there are always the two labels there in the control, it's just one is hidden but still contributing it's height to the calculation.

For this one, "Top Place", I've clicked close to the top of the map. The label you see is the one below the plaque and hence those ants are marching off the top of the board. 
(https://i.imgur.com/U1UBH9t.png)
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 16, 2018, 10:15:05 AM
Map Editor

Another iteration on Place.
You can now have multiple line place names.
VP are limited to 0-100
You can't type anything but numbers in the vp box.
There's a combobox allows you to pick which side initially "owns" a place that's worth points.
You just get the text (no plaque) if a place is worth zero points.

(https://i.imgur.com/IxK2MCV.png)
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 17, 2018, 10:11:30 AM
Map Editor

First iteration of Building. 
I've gone with terracotta tiling because it looks nice and bright, it's appropriate to most of Europe and it's not the same colour as units.
No buildings will have little arrows on them so even if the viewer is colour blind it should be pretty clear a building is not a unit.
Red vs orange colour blindness is also pretty rare.

Functionality still outstanding includes:
Rotate ( a bit ) *
Resize
Add a number of alternative styles to pick from.

(https://i.imgur.com/ste67lh.png)

Like all the other visuals, this is built using vectors and will scale.  Should you want to print a huge version of the map (once I write something allows you to export to pdf ) you will get a high quality picture.  I've not made the shadow and outline of shapes scale yet but at a larger size, that looks like:

(https://i.imgur.com/8U8MyiM.png)

I'm thinking of doing some building parts as sort of components. You add a basic kind of cross shaped church then you pick a spire or dome and stick that on top.
This is one of those things I could pretty much spend forever on and still come up with new options styles and things to do. 

*
Rotation will probably have to be rather limited because these aren't going to be lightsourced 3d meshes. 
Certainly as it stands, the gradients aren't going to change as you rotate. I can rotate the shadow so they point in the same direction, but if you rotate a house 90 degrees it'll look like it has a lightsource in a different direction to everything else. You'll get away with 20 odd degrees but anything more than that would mean a different building option.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 18, 2018, 10:10:26 AM
Map Converter and Scenario Editor

For various reasons, we need a new format for the map data.
That meant that the old maps we have already would of course be incompatible.
I've put together a utility which converts these.
The new format will come as two zip files. There will be:

From the user's perspective you get one or two zip files rather than several per map.

I have the first cut of the utility working.
The scenario editor now uses the new format and loads the data OK.
Still some work to do on that as I've not yet done some things like place names and the px to metres scale. 

The utility is just for our internal use and the ui is what you might call minimalist.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 19, 2018, 04:32:58 AM
New Map Format

This is now firmed up and the converter produces a new format zip file.
Scenario editor now shows places.
The converter is stable.
Stable enough for one map at a time internal use, anyhow.

The map editor is not yet saving state at all, so that's probably next up.
I'll get this end to end working before returning to mere details like rotating houses and different options for terrain and...
There's still a fair bit of work to do on the map editor.

Title: Re: Changelog - picture heavy
Post by: union square on April 19, 2018, 12:22:02 PM
Thanks for the Changelog, Andy.  It continues to be fascinating stuff for those of us interested in the project!
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 20, 2018, 04:31:57 AM
Thanks, I appreciate that.

Like Ezra says, watching software development is usually on a par with watching paint dry.
Hopefully this is slightly more interesting but it's a slow process.
Quality takes time.


Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 21, 2018, 09:16:23 AM
Map Editor

Started on save map process.

First part of this to do is to work out what terrain type is where in terms the game understands. There's a cell per px in a 2 dimensional array 1155 x 805.
To do that I need to hit test a point for each of these.
That's a lot of points.
Since hit testing is fairly slow, this takes a while.

I started with a proof of concept doing one point where I click. That meant a bit of jury rigging since clicking usually does other things but enabled me to prove what I was getting for a point was what I expected.
As it turns out there was a bit of a complication.
The piece of framework I'm using is bugged and stuff that shouldn't be returned from a hit test was.
I worked out how to filter these out and got the proof of concept to work.
Refactored that into something more re-usable.
I can now fill a 2d array.
This takes some time - around a minute whilst in debug mode.
Should be faster in an optimised compilation release but you're never really going to want to sit there watching it work.

I think I'll do a separate game map and design map save so you can save the design faster and then do the game save once you're totally happy with your master piece.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 22, 2018, 10:04:06 AM
Map Editor

Map saving - applying contour elevation.
This is kind of tricky because a contour can be under some other terrain object and you still need it's effect.  If I'd included contours in the hittesting for every single px that would not be able to stop at the top object hit, it'd need to get any and all objects under that point. That would have slowed down something which is already pretty slow.
The approach I took converts each contour to a new geometry which can then be processed on a background thread whilst the hit testing takes place.
Not only is this on a separate thread so it can be done at the same time as hit testing, it's inherently faster.
The reason I use hit testing at all is because it's the simplest way to work out what is the topmost terrain.
I could impose an explicit z-order and do everything that way. That's a possibility for a later refactor.

Note that contours are all one level. They're like those weird warhammer hills where someone just cuts an oval out of polystyrene and the top is horizontal, the slope vertical.
OK for a casual game where you want to dash off a quick map.
You will want one or more of the alternatives for anything more sophisticated.
The choice will be either or. You use contours or you use the alternative options.
I'll explain these at a later stage.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 23, 2018, 12:05:30 PM
Map Editor

Further experimentation with the hit testing approach uncovered a rather strange issue.
It appears that microsoft's hit testing component is more bugged than I realised.
It becomes ridiculously slow under some circumstances.
Unacceptably slow.

This is one of those un-fun situations that happen every once in a while in development.
I'm now exploring whether there's a practical work round retaining hit testing.
If not then I move to a similar approach I use with contours.
That has some complications but could well be a more elegant solution.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 24, 2018, 12:43:02 PM
Map Editor

I've replaced the way hit testing is done. It now runs for each piece of terrain on a background thread as you finish drawing it.
This still takes some time for some complicated drawings but you can carry on drawing other things.
Proof of concept is now sort of working.
I can save maps and open them in the scenario editor and it doesn't take all day.

(https://i.imgur.com/UbLU18s.png)


Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 25, 2018, 06:24:29 AM
Map Editor

Various improvements to the terrain detection process which is now stable.
You can keep on drawing pieces of terrain whilst the app works out exactly which area your previous pieces cover.
I've added a visual indication to show this is still going on. It appears top right in the toolbar and you get an icon per terrain being processed. Most recent left to right.
I drew a river and then a road for this:
(https://i.imgur.com/dkT6LWY.png)

Small pieces of terrain process very quickly.
What's called the "bounding box" is used to decide where to look. This is the rectangle a piece of terrain fits in. A building is therefore a teeny tiny bounding box and almost instant.  A road stretching from one corner to the opposite diagonal corner has the whole map as it's bounding box and is the slowest.
I should think few people will often want to draw roads like a giant X on a map but if you do then it's going to take a while to process and you should do them first.
When I did the screen shot above, this is what I did with a road and river.  Both took 30 seconds to process.
Your experience will vary so this is ballpark indication only. The time it'll take to run will depend on machine, processor other processes running etc. This is running alongside my development environment and in debug mode.  Visual studio is memory and processor hungry itself and the final deliverable compile optimised code will run faster.
In the vast majority of "normal" use I expect all this means usually no wait at all.

The actual game map save to disk is a couple of seconds on my machine.
This has an SSD and your experience may be a little slower but the game map save is not a particularly large file by the standards of today.

If you look closely at the above picture you will see there's a bit of an odd anomaly like a circle on the end of the road.
These are noticeable initially on any "line" type of terrain. They disappear a while after you draw one and i've deliberately took a screen shot before that happened.
I use one geometry type initially for speed optimisation.
I then later replace it with a nicer looking but more process intensive one which is (again) created on a background thread.
 


Title: Re: Changelog - picture heavy
Post by: Adraeth on April 26, 2018, 02:21:06 AM
This is going to be a Masterpiece

an usual italian would scream : "Mamma mia!!"  :notworthy:
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 26, 2018, 01:15:31 PM
Thanks.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 26, 2018, 01:23:49 PM
Map Editor

Added option to choose colour for the text of places.  This is because a place name on a dark background like a forest just disappears if it's black.
The two mysterious little squares on the right of the place are combo boxes.  The top one does which side "owns" the place and the bottom one the text colour.

(https://i.imgur.com/vbBnapr.png)

New "Tab" in left panel ( which will be shown initially ) for map details. You can now enter name, description and pick the DPI the map png will be generated at. 96 dpi is likely to be enough, 300 dpi more than enough but if you wanted to print at high resolution there are higher options. These produce bigger files of course.

(https://i.imgur.com/vbBnapr.png)

I also changed the way the terrains are held internally which improved performance a little but also introduced a bug.  Almost nothing works first time when you develop. Even if you tried to, perfection is way too time consuming so we go for kind of working and see what needs fixing.
(https://i.imgur.com/lDvvpIG.png)

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 27, 2018, 12:04:35 PM
Map Editor

Hide left chevron when first tab selected and right chevron when last selected in the left panel tabcontrol.

First iteration of saving and reloading design.
Save design.
When you choose load map you see a new view which lists maps and their descriptions. You pick one and then it's reloaded so you can carry on editing it.
It all kind of works but losing ink at the moment which would be limiting on "line" terrain. Just needs some more coding to handle ink.

Avoid terrain adding extra children (trees for forest, waves for lake) when reloading.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 28, 2018, 11:46:20 AM
Map Editor

First iteration of save and load designer data. 
This includes the "ink" for line objects such as rivers meaning you can reload a map and still change the width of rivers.
Stable but still needs a refactor or two to neaten up the code.

Added "Work" folder within Maps folder and Ink folder within that.
This now holds all the files which will be zipped up into the current <yourname>.zip and <yourname>.design.zip
They are deleted each time you "save" a file to be replaced with the new files.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 29, 2018, 12:41:27 PM
Map Editor

Disable input on map until drawing option is selected.
Refactor of map save and reload.
This is both to improve code quality and a step towards enabling separate save of design map and game maps.
Title: Re: Changelog - picture heavy
Post by: bayonetbrant on April 29, 2018, 02:44:23 PM
Are there options to change the font if someone's got hard time reading some of the period-appropriate fonts?

I'm a big fan of them b/c of the atmosphere they provide, but I'm just thinking of accessibility issues.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 30, 2018, 02:44:56 AM
There will be.
You'll be able to change font in all the modules.
You can already in the scenario editor, I've just not done that in the map editor yet.
Incidentally,   
If you don't install the font files then it won't fall over or anything, it'll fall back to segoe ui.

I think this is one of those user preferences you probably have for all modules. 
I'll probably let the user set this in the menu module. 
When I get round to writing it :^)
 
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 01, 2018, 03:23:12 AM
Map Editor

Added load map background option.
This gives you a file picker which is looking in the appdatalocal/GeneralStaff/Backgrounds folder.
At the moment, this background will be included in the png created by saving the map and so would be used in scenario edtor. And the game if I'd written it. 
This will be changed so the user can pick background in any of the suite.
One option will be a hypsometric representation of elevation.

Google Maps API

I am currently writing a proof of concept which gets elevation data from google maps. 
I get the data and I'm exploring the practicality of filling the 2 dimensional array which is used for our maps.
Looks like it'll work. So far.

You will input the two co-ordinates ( lattitude and longitude ) for the top left and right corners of your map area.
These can be obtained externally by any means you like but you can just use google maps. Right click the map and choosing "what's here" gives you the data.
Current elevation will of course include some "anomalies" like eg the mound at waterloo but some battlefields remain pretty much like they were during our time of interest.
Users will need to register for a key. The map API is free for up to 2,500 calls a day. 
Since it's limited to a certain size of data returned you will use this up with two calls. 
It is also throttled and will block your IP if too many calls are made in a second.
So it's a bit slow.

Anyone with a google account will find the process of registration almost trivial. You just click and it gives you a key which looks rather like a GUID to me.

This is just an option and you will still be able to translate the grey scale of a graphics file.
Once you have the data you will then still be able to edit it later.
Even if you're not doing a specific historical battle you could pick some random bit of the world and use the data from there to get you started.
Title: Re: Changelog - picture heavy
Post by: Cyrano on May 01, 2018, 09:44:07 AM
The Google Maps option is very exciting.

There's a great thread somewhere here on the fora pointing to a bunch of GMaps battlefields.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 01, 2018, 01:31:23 PM
Google Maps proof of concept

Gets data successfully.   
In order to cut down on the number of web calls I get every other px elevation. 
Hence the map is 1155x805 and I get elevation data for  578 x 403.
This is 578 calls which return the data for a line on the Y or "vertical" axis. 90 degrees relative to your two co-ordinates.
I will be able to use these to set the metres per pixel as well so you don't need to go measuring points against a legend.

Since you can rotate a google map and put persistent "favourite" pins in it you can potentially use a screen dump to trace from.
That would then give you consistent scaling which I think can be an issue in historical sketch maps.

I will show the  co-ordinates for the "bottom" left and right corners so you can put pins in for those as well.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 02, 2018, 12:38:05 PM
Map Editor

Rotating buildings. 
There are now two buttons in the edit tab which allow you to rotate a building by 5 degrees each click clockwise or counter clockwise.
This is limited to 30 degrees because the shading would look weird if you rotated more.
The drop shadow also rotates as the building does.

Google maps integration.
I started the first iteration adding this to the map editor.
This is quite fiddly because if you push too many requests through google's elevation api it does weird stuff first and then locks your ip for a while.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 03, 2018, 03:32:55 AM
Google Map Data

I have the first iteration working. 
Beat several bugs out of it and it seems stable. 
It has to be throttled back to wait between each call to the API and there are 578 calls to make so it takes a while.
 
I'll give some thought to how I could let a user carry on working in the map editor whilst it trundles along.   
We need some UI for the user to input co-ordinates, initiate the calls and see progress.   
I will probably put that into another tab in the left panel.
The calls are threaded, so you will be able to carry on working whilst this does it's thing. 

Currently, the hills and valleys can be checked in the scenario editor because it shows you the elevation where the cursor is. 
What's needed is some sort of visualisation background or layer that shows you the "big picture".
This will be a hypsometric background.
That's a fancy name for those colours you see on larger scale maps or atlasses where they work up from green valleys through browns, greys and eventually white on mountain tops. 
This is more readily understandable and prettier than contours which would in any case be harder to automate.

That in turn should make it easier to understand which bits you want to do some more work on. 
For a "quick" game ironing out a motorway is probably not worth the effort. 
For a more serious game you may want to flatten those out. 
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 03, 2018, 01:08:35 PM
Google Map Data

The new panel is now there and working, with a couple of superficial issues. 
The green rectangle is a progress bar which creeps along... fairly slowly.
Maybe not slowly enough since the api will still occasionally decide you're not getting anything and you then have to leave it a while or you've had it for 24 hours.  I have no idea what criteria they use but it's inconsistent.
You're best advised being quite careful about where you want your two points to be as the first run will almost always work whilst a second is more likely to crash and burn.

(https://i.imgur.com/wUAhpxC.png)

Font size needs reducing on the bottom locations and the number of decimal places rounded to 6.
The average variance needs rounding.

I think I'll probably also add a button to calculate the two bottom corners without doing a "run".
That way you can put pins in the (google) map, take a screen shot and compare to another map or whatever.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 04, 2018, 08:04:57 AM
Map Editor

First iteration of Hypsometric background. 
In case you're thinking Hippo what? 
This is using colour to denote elevation, an approach which is more usual in large scale maps like atlasses.
Green is low, working up through brown to sort of sandy.

And this is a chunk of France.

(https://i.imgur.com/AhhheTk.png)

How this works is I take the minimum and maximum elevation.
Any value will be between them and I translate this into a colour somewhere on a gradient where 0 is the left hand value and minimum and 1 the right and maximum.
The colours used are fixed at the moment but could in theory be made configurable.
The gradient looks like this:

(https://i.imgur.com/d3yOL4p.png)
 
The whole process of first grabbing elevations and processing them needs a good bit of testing to ensure what I get makes real world sense.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 07, 2018, 03:04:35 AM
Map Editor

Tidying up the google maps elevation api process.
If you don't have the file set up when you navigate to the obtain elevation panel you will just see the message:

In order to use the Google map data API you need to provide a key for Google.
Register with Google for the maps API key.
Put the key provided in a file called googlekey.txt in %localappdata%/GeneralStaff/
Close and re-start the GeneralStaff Map Editor.

Registration with Google is entirely separate from the GeneralStaff suite. 
Creation of the file to place your key in is intentionally manual as a reminder to emphasise this.

Although the process is as smooth as I can make it, calls to their elevation data API are subject to whatever drives Google's decisions.
If you run the process more than once in a day then you're likely to see a message saying:

Google rejected call.
You can probably save and resume later.

Presumably to stop denial of service attacks, they have a mechanism which will block an IP for several hours if they decide it's being used to "automate calls".  Quite why anyone would want to use that API in any way that wasn't automated I don't really know.  In any case, despite having to register to use the api they still have this mechanism in place. 
There's absolutely nothing I can do about that other than work round it.

If you get this message but you can see the process has got some data you can save what you have.   
When you reload the save file you'll see a "Resume" button appears.
Don't just try this again straight away.   
I get the impression this increases the time you can't use it for.
All this could change because the registration process just got rather more involved and logically you might imagine they're way less likely to suffer DoS attacks from people who registered with credit card details.

(https://i.imgur.com/qADjeBX.png)

If you leave it long enough then the process will complete and you've got a full map's worth of data.

Despite the hoops you need to jump though I think most people who want more than a few manually drawn contours will find this way easier than the alternatives. 

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 07, 2018, 01:06:16 PM
Obtain Elevation Data

Option to set 0 as minimum elevation.
Google returns negative values for seabed which you're probably not going to want.
On the other hand.... Some areas of the world have land which is below sea level.
Hence you can switch this on or off.

Scenario & Map Editor
Allow toggle visibilty of elevation map
Optimised generation of elevation map to avoid it freezing the UI.
Title: Re: Changelog - picture heavy
Post by: Grecco on May 10, 2018, 04:53:38 PM
There are several sources of elevation data out there that are free and allow bulk downloading. You might want to take a look at USGS's earth explorer website (https://earthexplorer.usgs.gov/) for bulk downloading 1 arcsec elevation data (around 30m resolution) with nearly world-wide coverage.

Another website with good free elevation data is this one: http://viewfinderpanoramas.org. Here you can find a full earth-covering elevation dataset at 3 arcsec resolution (around 90m at temperate latitudes).

I would suggest processing these and shipping the battlefield elevation with your game, the google API's sound a bit too restrictive to me (I don't like waiting)  :) .
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 13, 2018, 04:32:57 AM
Thanks, I'm aware of the alternatives.

The google api is fairly easy to use and flexible.
You can pick any two co-ordinates and it "just copes" with any angle between them and reconciles whatever scale the elevation is held at internally.
 
Of course, buying a pre built scenario will be even easier.
These will also have excellent graphics.

We won't be using google's elevation data for our scenarios. Partly because of their terms of use.
Any utilities which I build in order to handle satellite data are likely to be passed on in one form or another. That could be either as a separate utility or within the map editor.
Since doing the same thing several different ways is inherently inefficient I'll probably add the facility to upload a file with the data in to the map editor.  That is then ready to take data from any external source you want to use.

It's much more likely any such utilities would require a user to download data from source rather than us re-packaging data already publicly available.


Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 14, 2018, 12:27:32 PM
Map Editor

Menu toggle visibility for grid and places.

Allow stylus pressure to affect width of rivers.
It's only rivers where a different width on a "line" terrain is considered to be a plus.

Collapse point canvas unless drawing options selected
This is to allow user interaction with terrain objects already on the map.
First of which is:

Buildings
Mouse scroll to rotate a building ( so long as drawing options aren't selected ).
This is limited to 30 degrees like the arrows in the terrain edit as the shading of the rooves would look very odd if you rotate like 90 degrees.
Making buildings 3d objects would be more elegant but they'd then take way longer to design and be way too expensive to render in numbers. 3d objects are very expensive to render.

Started re-templating menu items.
The default WPF template is very complicated and has space for things like a checkbox and icon.  It doesn't suit anything but quite simple items.
As I have sliders in menu items this needs some work.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 15, 2018, 07:00:50 AM
All modules
New Menu item template

Review and add/fix Shortcut/"hot" keys

Map Editor

Visibility toggle and opacity slider for

(https://i.imgur.com/U083iC3.png)

In the screen shot both the elevation map and terrain opacity are dialed down a little.
You can see the shortcut keys underlined because I've pressed the alt key.

Experienced Windows users will be used to seeing underlines like these showing shortcut or "hot" keys.
This is standard windows behaviour.
Pressing Alt, holding it and pressing another key matching one of the shortcuts invokes it.
Hence Alt+L then Alt+B would toggle the visiblity of any Background you have loaded.
You can also press Alt, L, B.
Again, this is standard windows behaviour for a menu.
You can use Notepad or office apps in this way.
Recent versions of Office give you a little black square with a white letter on it when you press alt to make these shortcuts clearer.
I may implement that later.

You can't see where the mouse is on that screen shot but it's over Elevation Map which makes it's sub menu "pop out" showing the opacity slider.

Rationalising geometry resources.
Geometries are used to define all the vectors used in the iconography.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 16, 2018, 05:20:51 AM
Map Editor

Added groundscale.
You set this in an overlay which is toggled from the layers menu.

(https://i.imgur.com/daokrRT.png)

The two sort of rifle sights can be dragged around over two points you know the distance between.
You enter that distance in meters and click the save button.
The meters per pixel and overall size of the map are then calculated.

(https://i.imgur.com/hcUzJVe.png)

When you save the design of a map, the position of those two points and the amount you entered are saved.
Re-load such a map and toggle the overlay and you'll see the sights in the saved position.

When you use the google elevation data there is a known distance between your two map co-ordinates.
This is used to calculate the scale.
If you calculate the bottom co-ordinates or load the elevation data then this new data will be used for groundscale.
The positions of the sights will then be calculated.
This will over-write any data you already entered.
Meaning if you wanted to use real world elevation data but at a different scale then you would first load the elevation data and then later change the scale.
Don't reload the elevation data or re-calculate the corners (if you forget then don't save your changes).

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 16, 2018, 01:04:56 PM
Map Editor

Working towards allowing the user to "shape" elevation using drawing-app-like tooling.
This is not intended to be the primary way for anyone to input elevation but rather to "fix up" imported elevation data, for simplistic use in a "quick" scenario or as a back stop for someone who really doesn't want to use an image editor.

The original way of drawing the hypsometric elevation image takes a couple of seconds to run. This is OK for a one-off load but would require the whole image redrawing again in order to show any change.
It cannot be made more efficient without using a different approach.

I've added a new method which is a bit more efficient and will allow writing to parts of the image.
This is rather lower level stuff and hence tricky.
If necessary there's the potential to use pointers and "unsafe code" to make it faster again.
You might be thinking "Well just make it faster then!".
There would be a trade off though.
Such techniques come with an inherent higher risk of nastier bugs.
These might be necessary to get acceptable speed but a risk is a risk and best avoided.

 
Title: Re: Changelog - picture heavy
Post by: bayonetbrant on May 16, 2018, 03:11:57 PM
OK, so the important question - WHEN DO WE GET TO PLAY WITH IT?!?

;D
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 17, 2018, 02:07:21 AM
My guess is December.
Still quite a bit of work to do.

I've started a separate thread.
Title: Re: Changelog - picture heavy
Post by: bayonetbrant on May 17, 2018, 04:09:14 AM
I've started a separate thread.

O0
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 19, 2018, 10:15:41 AM
Map Editor

I've added a quick n dirty prototype method to view and change the size of the area you paint with in the map editor.
Choose Drawing options and hover over one.
You will see a tooltip with the current size and a representation of that.
There are two rectangles.
The upper one is at 0.5 pressure which is what you get from a mouse.
The bottom one is at 1 pressure which you get if you press hard with a stylus or use the widening option on river.
Scroll the mouse wheel up or down in increase or decrease the size by 1 px.
This currently "works" for all of the options but is only meaningful for line.

Researching options to improve contour drawn elevations - so they give a gradual slope rather than a step.

All
Minor improvement to bevelled frame.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 22, 2018, 04:14:52 AM
Map Editor

Fixed Bug failed to reset isbusy flag/indicator on re-opening saved map

Prototype greyscale calculation.

This uses the data from contours.
You need to set low and high so it "knows" the expected range of black through to white.
Set all the parameters, click the calculate button and you get a grey layered effect initially.
(https://i.imgur.com/RyA1V8M.png)

Checking the blurred box adds a gaussian blur effect which will then result in a slope rather than cliff when converted to elevation values
(https://i.imgur.com/v710vX0.png)
Note that the contour line will be towards the edge of the gradient rather than the "top" and hence the expected elevation will be somewhat inside it.
Often the exact elevation at a point isn't really going to matter so much so that few metres won't have any noticeable effect.
If this will be an issue for a map you're drawing, you can either draw your contours slightly further out or give them a higher value.

Hiding the terrain ( which is just contour lines in this case ):
(https://i.imgur.com/f1C6Bck.png)

I then have some code which grabs the pixels and translates the grey scale into metres.
Then redoes the hypsometric elevation picture

(https://i.imgur.com/B9p59nV.png)
This is still very much a prototype and needs more work.
But.
The results look pretty good. Certainly way better than cliff edges.

Note:
This is never going to be as sophisticated as you can do using the likes of photoshop. On the other hand, probably good enough for most purposes with an almost zero learning curve.
And... this is just one option. 
You'll still be able to import an image created externally.
Or at least you will once I write that part.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 23, 2018, 04:30:56 AM
Map Editor

Remove "old" code which set elevation based purely on contour height when saving a map.
Save new generated elevations
Respect default height
Limit input of (GreyScale elevation) values to numbers

Bug fixing and refactoring greyscale code.

Greyscale image import.
You now select between using Contours or Picture to generate a greyscale based set of elevations.
You can do both but whichever values you save last will be used.

Although a greyscale picture of the right proportion is advisable, this should handle any image you have.
That includes coloured ones.  These will be translated to greyscale based on tone.
If the picture is the wrong sort of shape it will be stretched.

(https://i.imgur.com/MSxlGME.png)


Note that no particular validation is done on what you enter in this view.
If you set a low higher than the high then bad things are going to happen.

The interval is not used for anything yet.
The plan is to speed up allocating a value to contour height.
I may instead move this to the contours option settings.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 24, 2018, 03:21:19 AM
Hypsometric Elevation Image

Optimising algorithm which creates the bitmap.
Exactly how this works is pretty technical stuff involving building a huge array of bytes with 4 per pixel holding blue, green, red and alpha values.

Rather than working out each colour to use for an elevation dynamically I've built a collection of 255 colours.
I then work out which of those 255 "bands" any elevation would be in and use that colour.
The downside of this is that I can't now easily make this user configurable.
OTOH the processing savings are significant.

This may read as pretty dry stuff but it's huge.
Overall, the changes cut building one example picture down from a rather stately 2.68 seconds to 4 milliseconds.
That makes rebuilding the entire image as someone "shapes" a hill or valley practical and should just be a brief flicker rather than noticeable wait.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 26, 2018, 04:11:37 AM
Scenario Editor
Use new optimised hypsometric routine

Map Editor
Improving background file picker selection filter
Changed font used for drawing options to reduce number of different fonts on screen
Ephinol font as default for the left panel (tabcontrol) 
(https://i.imgur.com/73rJR4i.png)

Rationalised elevation storage ( it was stored in both designer and map data ).

Started Shapers.
These are intended for a bit of "fixing up" rather than drawing an entire map.
That's the plan at the moment anyhow.
Having said that.
Due to the optimisation work, I can redraw the entire map very quickly.
That has removed one of the obstacles to somewhat more ambitious shaping.

The tooling needs more styling work but the idea is you pick one of the shapers from a list.
The various attributes of that shaper can then be set in the area above the list.
These will vary from one shaper to another.
There will (obviously) be more than one once I write them.

What I've done is the first iteration of flatten.
This allows you to set the same elevation for an elliptical area.
The two sliders allow you to adjust the size vertically and horizontally.
If they both have the same value then the ellipse is a circle.

In these pictures I'll remove the lion's mound from the waterloo battlefield.
https://en.wikipedia.org/wiki/Lion%27s_Mound

(https://i.imgur.com/6sNajhY.png)

You then drag the ellipse over the area you want to set.
Right click somewhere on the map to "pick up" the elevation from there
Or
Over type in the set elevation textbox.

(https://i.imgur.com/cxAH1Mu.png)

Either right click the ellipse, press return or click the apply button.
The elevation is applied to all the points under the ellipse and the map redrawn.

(https://i.imgur.com/qYcx6sr.png)

In the final picture, I've then dragged the ellipse back off the map.
The mound is no more.
You can't see the redrawing happen immediately because the ellipse is on top of the area changed.
The processing and redrawing the map is so fast it appears to be pretty much instant.

I then changed the ellipse so it's transparent with a white outline.
(https://i.imgur.com/fDKoFvN.png)
You can then see the bit of terrain you're about to change.
Counter - intuitively it seemed to me to be a bit harder to work out exactly where the edges of what I was about to change were.
Having said that, you can easily drag the marker round a bit and right click to do a bit more.
This was part of the idea of the right click to apply.

I could potentially allow the user to pick fill and outline.




Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 28, 2018, 08:11:08 AM
Map Editor

Added small brass slider templates
(https://i.imgur.com/2Tdn1Pn.png)

Started work on Hill shaper
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 29, 2018, 07:54:44 AM
Map Editor

Hill shaper, first iteration.

You define an ellipse and drag it round like flatten but hills are assumed to be bigger.
I did this with an otherwise totally empty map.

Enter an elevation for the peak of the hill
(https://i.imgur.com/TwF4Ukt.png)

Clicking apply gives:
(https://i.imgur.com/zPHTBgq.png)

I'm smoothing the values from high to low using a formula called smootherstep.
You can read more about that:
https://en.wikipedia.org/wiki/Smoothstep
The idea is to give the top and edges a curve rather than straight line trend.
Like a real hill.

All Shapers ( other than flatten ) will be additive.
The calculated values for the hill are added to whatever elevation each qualifying "cell" already has.
Hit apply twice and you'd get double the set height.

You can enter a negative number to scoop out a hollow.
(https://i.imgur.com/CtigVvd.png)

I also need to allow the user to rotate the hill, the current approach only gives you vertical or horizontal ellipses.
Or a circle.

Refactoring flatten code to make it more generic and re-usable
Fixed a couple of bugs in flatten
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 30, 2018, 12:41:09 PM
Map Editor

Allow rotation of hill shaper.
This turned out to be much harder than I expected.
The problem is that the grid of elevations I need to work with is integer based for x and y co-ordinates.
However, when you rotate a point it gives you a non integer result.
When you round to an integer this leaves gaps
Plan B turned out to be an extremely expensive process which I then had to multi thread to reduce the time it takes.

(https://i.imgur.com/0hFvJAM.png)

Note the effect of adding an overlapping hill.

There are a couple of issues including speed ( ~4 seconds ).
More to do.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on May 31, 2018, 03:34:24 AM
Hill shaper.

Avoid rotation interfering with dragging.

Speed optimisation ( via threading and reducing lists used ).
Now roughly 2 seconds on my machine for the hill you see above.

Bigger hills take longer because there are more calculations.
Title: Indiegogo half off about to end
Post by: Dr D Ezra Sidran on May 31, 2018, 03:41:53 PM
Our Indiegogo half off pre-release sale is about to end. To take advantage of reserving the General Staff Wargaming System (Army Editor, Map Editor, Scenario Editor + Game) for half off the retail price (i. e. the Steam price) please see:
https://www.indiegogo.com/projects/general-staff-wargaming-system#/ (https://www.indiegogo.com/projects/general-staff-wargaming-system#/)
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 01, 2018, 08:20:35 AM
Hill Shaper

Fix ( rather nasty ) bug in calculations when X dimension was bigger than Y.
Avoid error when part of hill is off map.
Give a warning the hill process can take a while to process.

Experimental work on drawing ridges / valleys.
Assuming I can get a practical version working...
The idea is you would define a width for the ridge and where the ridge line is in relation to that.
And a peak height.
You then draw a ridge line.

All

Added Compass Rose.
(https://i.imgur.com/CNVm32A.png)

As usual, this is a first cut.
It's in one of the shared libraries but as yet only used in MapEditor.
The google process now also calculates the angle to north.
Still need to allow the user to rotate in map editor, use in scenario editor and decide when it's appropriate to be shown.
Title: Re: Changelog - picture heavy
Post by: bayonetbrant on June 01, 2018, 08:46:29 AM
Hills look nice.  Not necessarily the most realistic, but appropriate for the game :)
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 01, 2018, 11:48:41 AM
Thanks.

You raise a good point there.
It's worth bearing in mind there are different audiences with different expectations.
We want to support all of them as well as we can.
These hills will not be for everyone.
There again, real hills won't be for everyone.
These aren't the droids hills you're looking for?
Then there are other options.

Shapers... most of them... aren't really intended to be used for complicated "realistic" maps.
If you just want a big valley and or 3 or 4 simple hills for a quick game then wham bam they'll do that fairly painlessly.
If you want to "fix up" slightly a set of elevations you have already drawn or imported then they'll do that.

The only shaper I think I'm personally likely to use would be the flatten.
Erasing motorways and lions mounds.
I think I'd rather pick a random piece of the real world rather than draw stuff.
But that's just my personal preference.

The "best" way to get a realistic map elevation-wise is google data.
There will also be an interface allows you to import data you obtain from any other source.
At best that is likely to be way less convenient than google.

Different people have different expectations or real though.
If you want maps that match historical maps you see in books then you will find some of these are sketch maps and don't match reality so well.
People have probably been "making stuff up" about battles ever since someone tied a sharp rock on the end of a stick.
Reality changed as well - some battle sites are now heavily urbanised, drained and developed or whatever and the landscape has changed a fair bit.
If current reality doesn't match expectations then photoshop and a greyscale image are your best bet.
You need skillz to use that stuff properly though.
Not my thing.
Ed-the-graphics-guy is a whizz at that sort of stuff though.

If you don't do photoshop then there's drawing contours.
I should think most people will only be using contours for fairly simple requirements.
Title: Re: Changelog - picture heavy
Post by: bayonetbrant on June 01, 2018, 12:57:31 PM
I was just commenting on how they looked on the screen, which I think will make them imminently playable.

I'm totally fine getting detailed with maps

(see attached sample from one of my older games :) )
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 02, 2018, 09:30:13 AM
Compass Rose

Now fully implemented in both map editor and scenario editor
(https://i.imgur.com/tgtAb48.png)

The angle defaults to straight up.
Angle to north is calculated for you when you use google data.
You can (also) rotate it using the mouse scroll wheel (only) when the edit terrain tab is selected.
Uncheck the menu option and it's gone.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 03, 2018, 01:25:38 PM
Ridges

Proof of concept. This is in a totally separate experimental solution.
This works using greyscale which will then be interpreted into elevation to add ( a negative peak will give valleys ).

You draw a line which is then processed to add progressively bigger layers of the same shape.
You can choose to have just a rounded end or "pointy" and narrowing from where you start drawing to the end.
Pointy ones also need to have the narrow lines shortened. This is because ink draws using numerous circles, whose diameter is the width of the line.  Reduce the width and you increase how steep the narrow end would be.

The layers's z index is adjusted so later lines don't have "lower" layers on top of higher ones.
In this way you can draw a set of connected ridges or river valleys.
The layers will then be blurred like they are in the contours processing.
That would also even out some of my wobbly drawing.

The sliders in my proof of concept control how blurred everything is ( zero for this screen shot so you can see the layers ).
Also how wide the line is drawn.
I had to reduce the width to draw the two pointy ridges connected to the bigger main one.

(https://i.imgur.com/BO6RS6D.png)

When you draw in the map editor, there will be no visible black background. That'll be added very briefly as you commit.  It's black in the proof of concept so I can see what it'll look like.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 03, 2018, 01:49:23 PM
Improving smoothness of drawn ridges.
(https://i.imgur.com/ZbweHHp.png)

Ink is a bit strange.
There's a two stage process. If you watch closely your line is initially drawn with whatever squiggles and jiggles you draw.
Once you finish a line it is then redrawn with any smoothing.
If you watch closely you can see it seems to move.
In order to grab that smoother ink I need to defer processing input until after that smoothing is finished.
Which I've now done.
I deliberately tried to add jiggly awkward bits when drawing those ridges and they're still smoothed out.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 06, 2018, 09:06:23 AM
Ridges

First iteration of ridges in map editor.
You draw a ridge line.
The settings you have are then used to build ten layers in greyscale black ( for low ) through to white ( for the peak ) for a ridge.
One of the sliders lets you control how blurred the picture you're drawing is.
You adjust that until you can't see any steps in the greys.
This has to be manual because there are way too many variables to attempt to do it automagically.

You can choose to have just a rounded end on a ridge.
Which would probably do for simple stylised hills.
Alternatively, you can make it tapered - much more natural.

If you choose a negative value for the peak then it'll gouge out a valley.
You'd want to raise the base level first of course...  coming soon.... you'll be able to do that with another shaper.

I've not been particularly careful with these, you can easily do more natural looking shapes.
You can draw any number of shapes you like.
There's an undo button which will remove them last first.
Meaning you can try something and see what it looks like, undo, give it another go.
You'll definitely want that when drawing a ridge attached to another in order to get it looking good.

The sliders have tooltips that say what they do.
I left off headings to save space but I may add small headings as well.

(https://i.imgur.com/6QgBWVm.png)

(https://i.imgur.com/bfIZtge.png)

Once you commit by clicking Apply then the hypsometric representation is recalculated.
Note that these hills valleys and the like don't have any "look" other than this hypsometric representation.

(https://i.imgur.com/Tmxuq3U.png)
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 07, 2018, 02:26:36 AM
Bug Fix Scenario Editor
Close button on edit movement rates was left justified.
I have no idea how that crept in.

Map Editor
Added labels on ridge shaper sliders
(https://i.imgur.com/ZmTSv5k.png)

Raise Shaper.
This applies the value across the whole map.
If you check the checkbox, it will add to all cell values.
If you un check the checkbox it will set all cell values.

You can therefore reset the elevations completely if you've made some sort of a mistake.
You need some elevation before you can "gouge" anything out of it.
Negative elevations are not supported and something to be avoided.
You would therefore want to use this before using any shapers with negative values for dips or valleys.
(https://i.imgur.com/hSEL8t7.png)
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 08, 2018, 08:27:05 AM
Map Editor

Cone shaper.

This is an ellipse shape rather like a hill, but way faster.

The downside being it's kind of cone shaped rather than the more natural rounded shape of the hill shaper.
By maxing out the blur you can effectively alter that shape by blending everything in and get a more rounded effect.

You can alter height and width, the mouse scroll wheel rotates the ellipse.
You click and hold - drag the ellipse to where you want it and right click to add one.
You can add any number.
Apply then uses greyscale manipulation and the value you set as usual to add the various elevations to the relevant cells.

(https://i.imgur.com/C3AkuWa.png)

Because these are additive, you can use shapers together to give more complicated results.
EG
Several connected ridges are best done in one go but you will have the same height along them, tapering off towards the end.
If you draw several connected.

(https://i.imgur.com/TFjXvvA.png)
Here I've drawn tapered ridges from the center out.

I then position a large sized cone in the middle and add that.
(https://i.imgur.com/wcbEpFK.png)

I now have a mountain with reasonably realistic ridges.

I can then refine that by gouging out valleys or do another one.


Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 11, 2018, 04:05:53 AM
Map Editor

Bug Fix.
Avoid error if you try and drag a shaper you can't drag

Gradient Shaper


This applies a linear gradient in the direction of the arrow.
By linear  -  this would be a straight line in cross section.
This shaper is intended for fairly gradual changes in elevation across the entire map.  For natural results you should probably only use it the once on a given map.
If you used this from the top down and then from the bottom up, you'd get a rather unnatural sort of V shaped valley across the map.
If the values added were relatively low and or you then did a bit more land sculpting you may not particularly notice how unnatural that was.

You can rotate the gradient using the scroll on your mouse, whilst over the gradient on the map.
White is always highest so in this picture I've rotated through 130 degrees or thereabouts.
The highest part is the white and bottom right corner.
Lowest is top left.

(https://i.imgur.com/kClQp20.png)

When you click apply the gradient still covers the map so you can't really see it's done anything much.
The hypsometric representation for this looks like:

(https://i.imgur.com/8Iajtmv.png)

This is additive so you could draw a river valley and apply a gradient to that before or after so the water is flowing downhill.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 11, 2018, 09:27:18 AM
Brow Shaper

This is intended to give you a long hill brow which can extend at any angle across the map.
You can use two of these to give you a valley.
 
The Breadth of the brow is how far it is between the bottom and top of the brow.  If that's a low amount it's steep, larger distances mean a more gradual slope.
The slope itself is calculated using smootherstep as explained in a previous shaper. It eases off the slope at the top and bottom.
You can rotate using the mousewheel and drag using click and hold.
It's possible to position the brow in a way doesn't cover the whole map - it's up to you to ensure that doesn't happen.

Let's create a brow across the north part of the map.
Drag the brow up.
(https://i.imgur.com/TBBcw0h.png)
Click apply.

Rotate it and drag down.
(https://i.imgur.com/nXCG9Ui.png)
Apply that.

Giving

(https://i.imgur.com/YeRbrd3.png)


Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 12, 2018, 08:22:42 AM
Custom Shaper

This works using a picture file you create. Since this is converted to greyscale internally you could theoretically use a coloured picture but I'd recommend drawing in grey and white.
It can be any size you like.
Clicking the open file button lets you select your file.
The Scale slider lets you scale it up or down.
You can rotate your loaded picture using the scroll wheel and drag it around.

For demonstration purposes I created a file in MS Paint.
I started by flood filling in black.
I then used the spray can to draw an interesting sort of ridge in white, outlined that in grey and then dark grey.
I then opened the file in paint.net and flood filled the background black as transparent.
Saved the file as png.

This is the result:
(https://i.imgur.com/EytQXmj.png)

Because the spray can sprays loads of dots this is fairly heavily textured.

Opening it in the map editor , I can then set blur on it which smooths out that texture:
(https://i.imgur.com/ZeaHK6H.png)

Blur is effectively optional since you can set it to zero but I'd want a cleaner picture if I was doing that.
This way I can work quick and dirty.

I then clicked apply, moved the shape off to one side and scaled it down a bit.

(https://i.imgur.com/9QMQ1aX.png)


Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 12, 2018, 08:45:53 AM
In seconds you can knock together a picture with some small hilly bits in it.
(https://i.imgur.com/eBCeaCI.png)

Applying these a few times, you can rough up the map for a bit of interest.

(https://i.imgur.com/jdvBtsd.png)

You'd maybe want bigger hills or lower values - there's a lot of valleys to hide in there.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 13, 2018, 12:10:50 PM
Fonts

Overhauling the font preferences mechanism.
Changed some fonts and views to make them fit (better) with the different options.
Added font preferences to map editor.
(https://i.imgur.com/b7Si5r1.png)

Preferences
Persisting ( and read on run ) user preferences,
If you pick plain style then next time you run one of the apps, you get plain style.

The Army Editor also has a preferences menu item and will respect the settings.

Rationalised the shapers internals.

Added min and max to shapers panel.

Buttons

Replaced the button template.
The old one looks too much like a mirror frame and it was a nightmare getting it to look OK with different font formats in all the different views.
The new version's fancy bits are less distracting and now cannot impinge on the text.
Reducing the space necessary to left and right of the text also makes this version a lot more flexible.

(https://i.imgur.com/KXYgUJn.png)
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 15, 2018, 12:08:14 PM

Terrain and elevations visualisation.

(First iteration)
This is a sort of vertical slice through the map showing both elevation and terrain type.
The terrain type is represented by colour - but you need to save a map before this is actually set.

Showing this is controlled via a checkbox on the layers menu.
When checked you get an overlay with two sights defining start and end points
You can drag these around
(https://i.imgur.com/YS0DOOW.png)

Another window appears showing the visualisation.
This is a regular window so it can disappear behind the main window if you let it.
As a result you're best dragging it to one side or your second monitor.
(https://i.imgur.com/viGTSBO.png)

Black is the default colour, I've no terrain other than elevation on this map.

This is constructed from a number of rectangles.
Each rectangle is a cell between your two chosen points.
As you mouse over each of thes rectangles, there's a spot which moves to the appropriate position on the map.
You can see that on the top picture.

Although only used in the map editor at the moment this is designed for re-usability.
I can potentially show it whilst you're issuing move orders for the terrain you're moving over, when you're checking for sightings etc etc.

Currently stable, but still some more to add.


Shapers - evaluate min and max elevations on map load.

Bug Fix
One of the shapers layers was interfering with drawing anything.

All
Standardising storage of elevations and terrains across modules.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 16, 2018, 10:00:17 AM
Terrain Visualiser

Fixing bugs and improving the behaviour.
Close the menu as the terrainvisualiser is shown.
Usually you want a menu to be on top of anything and the fact that's how they work is great.
In this case something on top of our new window is a bad thing.
Persuading the new window to stay on top of the main one.
Retaining previous positions and data when you re-open.

The sights overlay now initially appears with it's "spot" off map.
Spot is also moved off the map when you drag a sight so it's not left hanging about in the middle of nowhere.

Added elevation and terrain type in text to visualiser.

In the below screen shot I've done a screen capture using windows problem steps recorder.
This captures the mouse so you can see where it is at the time of capture but has adds that rather interesting green border to the window.
I've added a hill and two cones plus some other terrain.
These are pretty steep hills.
The left one is a hill which is a relatively natural shape but slow.
The middle (cone) demonstrates why a cone is called a cone.
The right one  is a cone with a lot of blur applied.
Quick to generate but blurring reduces the effective overall height.
If you can live with that though, it's way quicker than a big hill.

(https://i.imgur.com/8JzYxO6.png)

Notice also the colouring showing terrain types.

I wasn't terribly careful with placement of my river and road so they're not in particularly logical places.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 17, 2018, 08:09:03 AM
Map Editor

Styled up the Elevation Shapers options so it's similar to the drawing options.

(https://i.imgur.com/psjjtqg.png)
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 18, 2018, 11:52:40 AM
Map Editor

Building options.

I've added a mechanism which allows me to define different buildings.
A Building row has a combobox in edit terrains which allows you to pick from the defined buildings.
I've added another building. 2 so far.
You click a building picture in the combo to pick it and the building on the map changes.

(https://i.imgur.com/BPPmkP1.png)

You can still only rotate a maximum of 30 degrees either way.
That is because of the shading, which could look weird otherwise with the shadow on the wrong side and different to everything else on the map.
These are not light sourced 3d objects, because they get very graphics expensive very quickly AND they are harder to build.
They're built from shapes which have a gradient on them.
Although the shadow outside the building can be rotated the shading on the roof panels is fixed like a picture.

This limitation isn't necessarilly going to apply to all building so I'm thinking of making each define how far it can be rotated.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 19, 2018, 08:50:18 AM
Map Editor

List of terrain in terrain edit:
Removed display of id ( this uniquely identifies the piece of terrain but is only internally meaningful ).
Standardised font used.

Buildings

Added another house and courtyard to building templates.
The templates now have a value for default height and width they set as they're chosen.
Hence the latest house can have a bigger height than width and the courtyard is much bigger.

You can now use the mousewheel in combination with a modifier key to alter the size of a building.
You need to have edit terrain selected ( like with rotating a building ).
Mousewheel scroll + Ctrl alters width
Mousewheel scroll + Shift alters height
Once you alter the size, the building will remain that size even if you change to a different template.
( This is necessary so when a saved design for a map is reloaded any altered sizes will be respected ).
(https://i.imgur.com/T6pZLVv.png)
Title: Re: Changelog - picture heavy
Post by: Dr D Ezra Sidran on June 19, 2018, 10:21:26 AM
I would just like to point out that that is an accurate Order of Battle Table for the Continental Army at Trenton and, yes, there really was a Colonel Sargent.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 20, 2018, 02:40:20 AM
Trees

There are now several different tree shapes.
Each tree randomly picks which shape it will be as it's created.

Change drop shadow to sepia ( was saddlebrown ).

(https://i.imgur.com/u720QD5.png)
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 20, 2018, 09:02:51 AM
Buildings

Added 3 more building types.
You can use these separately of course but I built a church with these as an example of combining buildings.

(https://i.imgur.com/BY144LD.png)

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 21, 2018, 07:16:18 AM
Terrain Visualiser

Added minimum and maximum elevation to the left of the terrain graph.
This is min and max for the whole maps for context - so you get an idea how whatever slice you're looking at fits in.

You now get a pink line above the part your mouse is over.
I considered adding some sort of a scale but that'd be very complicated because the user can pick whatever elevations they like.
I'm also not so sure about how useful that would be without a load of horizontal lines across the whole thing.
I may come back to that later but.... shelved until and unless I can think of a good way to do it.

(https://i.imgur.com/15S8Mv3.png)

The window tries to size itself to fit what you pick. If you pick a very long slice then the window could be quite wide.

My experimental map which has some terrain on it only has those three hill/cones on it.
This is with a map of the northern lake district.
(https://i.imgur.com/1dAAaml.png)

And Isandlwana
(https://i.imgur.com/OMlKetG.png)

A friend of mine has South African links and has visited the battefield on several occasions.
It's well looked after and pretty much as it was back in 1879.
Other than the things like the memorial, cairns, fence round the site and the car park.
I was surprised when he mentioned the car park.
There are now a couple of zulu villages nearby.

https://www.google.co.uk/maps/place/Isandlwana/@-28.3513158,30.6442408,14.93z/data=!4m5!3m4!1s0x1ef1bbc774f6dc39:0xf740fe2436bd3a34!8m2!3d-28.3586111!4d30.6513889!5m1!1e4 (https://www.google.co.uk/maps/place/Isandlwana/@-28.3513158,30.6442408,14.93z/data=!4m5!3m4!1s0x1ef1bbc774f6dc39:0xf740fe2436bd3a34!8m2!3d-28.3586111!4d30.6513889!5m1!1e4)


Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 22, 2018, 02:36:08 AM
Map Editor


Alter line width.
As the heading suggests, this is only applies to line types.  Even then it's probably then only really useful for rivers.

You alter the size using the scroll wheel when over a particular drawing option.
There is also a tooltip appears with a representation of the width.
The upper rectangle is what you'll get when drawing with a mouse ( this becomes 0.5 pressure ).
The lower rectangle is  the maximum width which you'll get at the widest if you click one of the widening buttons for a river ( 1 pressure).
In this picture you can see the tooltip and a few rather random bits of river I've scribbled just to prove you can do the different widths.
It works this way because you can set it prior to drawing and it's relatively quick to set rather than adding extra post processing via a context menu.
The tooltip only appears for line type drawing options.

(https://i.imgur.com/oHRLxWL.png)

Terrain Visualiser
When you drag the start "sight" you'll see the (X,Y) location appears as a user message.
This is intended for advanced user customisation scenarios and debugging.
As a sort of side effect, if you somehow got the two sights mixed up then moving the "end" one gives no message.
(https://i.imgur.com/QeM6wx1.png)
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on June 22, 2018, 06:46:35 AM
Map Editor

Added support for custom resources.
This is a first cut at the moment.
This is a thing called a resource dictionary which is in plain text. You can edit it in notepad and it's then read at run time.
It's located in your user appdata / generalstaff/maps/CustomResources.xaml

Always find you want more?
Then this might be for you.
You can override many of the resources used within the map editor using this functionality.
What do resources do?
They define pictures, shapes, and colours used through the app.
Want a different background to woods?
You could do that.
The various building colours and shapes are all resources.

There is a teeny tiny catch in that you will probably need some help from me to know what to change.
I'll put guides together on how to do some stuff - eventually.

CustomCanvas
There is also a new layer - "CustomCanvas" which you can add anything you can define to.

Basic stuff is pretty simple once you get past the fact you're doing mark-up.

Say you want a star fort kind of a thing and of course there are no star fort buildings in the editor.
You could potentially "just" incorporate a picture in your background image in one way or another and go with that.
Maybe that doesn't suit though.

You find a suitable picture in a book or online and start with a picture.
You can then convert that to xaml using Inkscape. This is a little fiddly but not far from rocket science.
As a flavour:

You paste your picture into inkscape.
Choose trace bitmap.
Click the button and it generates vectors for you.
It just looks like another layer.
In this case I clicked the "simplify" button which loses a load of fiddly bits. Some of which you might have kind of wanted.
Drag that aside. delete the original layer and save as xaml.
Go grab the data from the path (or paths) in there and you can use that as a Geometry in the custom resource dictionary.
A geometry is a long string of co--ordinates which looks kind of weird but you're just cutting and pasting it.
The longest part of this process is likely to be finding a suitable image.
In my case I pasted in, surrounded that in a geometry tag and I could then use it

(https://i.imgur.com/hekwQ84.png)


To get the above, I filled in some of the walls and erased some twiddly bits from an online picture.
I just used Paint for that step.
I wasn't terribly careful but the import process smooths bits out a little anyhow.
It will also probably lose some detail but maybe that doe

The custom dictionary has angle brackets in it, so I can't post the content.
It looks like:

(https://i.imgur.com/TYU0HWV.png)

The string in the geometry tags defines the shape of the fort. It is way bigger than that, I've substituted ... for most of it for clarity here.
The Canvas.Left and Canvas.Top define where the fort goes on the canvas - which fills the board.
If you want precision, you can use the measurements from the start terrain visualiser as described in the last post.

I intend processing paths using their "Tag" in order to apply terrain types to them.
Assuming I get that working, this would be a significant advantage to the approach.
Still probably not everyone's cup of tea but if you really really wanted a specific shaped fortification then you can do it.