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

0 Members and 2 Guests are viewing this topic.

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 418
Re: Changelog - picture heavy
« Reply #300 on: August 11, 2019, 09:23:54 AM »
Bug Fix

Map Editor

The binding was failing for description so it was never saved.




Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 418
Re: Changelog - picture heavy
« Reply #301 on: December 07, 2019, 09:57:27 AM »
All

I've upgraded the target framework from "regular" .Net 4.7.2 to .Net Core 3.1
This is rather a fiddly process for any substantial code base and particularly for ours which contains things I don't use in business app development.
And some stuff is probably quite unusual in any wpf app.
I've only had enough time to do a quick smoke test through the suite.
Not much more than spin it up and try a couple of options.
It seems stable.
Usually the problem is simply failing to compile at all.

Some particularly expensive process like the pathing seem faster.
One "free" improvement to expect is in the garbage collector.
OK, garbage isn't usually associated with instant excitement and this probably sounds pretty dull to non developers.
But.
The garbage collector runs all the time in the background of a .Net app and re-cycles unused objects which are in memory.
In .Net core 3.1 this runs faster and uses less memory.
Meaning the app your running runs faster and uses less memory.

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 418
Re: Changelog - picture heavy
« Reply #302 on: February 02, 2020, 08:46:14 AM »
All

I've removed dependencies on mvvm light from the app since there's no WPF friendly .Net core version available at the moment.
This may well change and I'd rather use the standard library but that's not practical. Yet.
The framework introduced a dependency on .Net old so some parts used core and some the old dll, which would have meant mysterious failures to run and error reports from some users whilst others would have been fine if we had delivered.
Anyhow, bug squashed.
Everything should be OK with .Net core only now.

Launcher

This is Ezra's menu / launcher which you can see on his blog http://general-staff.com/
When you choose to start a game it now writes a file to disk containing the parameters you chose.
This will in turn be read by the game when it starts.
The file represents a PlayState object.
This contains enough data so the game can "just know" what you were doing last time you ran it, what turn you're up to when you've  restored a game save as well as what scenario you're beginning when you start a game from the menu.

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 418
Re: Changelog - picture heavy
« Reply #303 on: February 08, 2020, 09:51:17 AM »
Game

Now looks for that PlayState object the launcher writes to disk.
If there's one there where it's expected to be.
It loads that
The scenario
The armies
And selects the appropriate side as the current one.

This would also allow you to resume your last game.
Potentially anyhow.
There'd have to be some actual game in the game to change anything and some code to do a save.
One thing at a time though.

Bugfix

As part of my last change, I refactored so that a generic approach was used to serialising and deserialising objects to disk.
( Serialisation is the term for a process turns an in memory object into a string that can be saved to disk. )
I broke that.
This became apparent when I tried to deserialise my playstate into an object and it didn't work.
Fixed that now.

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 418
Re: Changelog - picture heavy
« Reply #304 on: February 09, 2020, 10:05:36 AM »
Scenario Editor

When saving scenario, capture image of map as byte array to scenario file.
This can then be used in the launcher to give a preview picture of the scenario map with all pieces visible.
This is the first iteration and I've yet to do any testing on it so there are likely bugs and changes.

I think I also fixed a bug whilst rationalising some code.
You only want one piece of code for any sort of operation because when you change anything or have some sort of problem there is then only the one place to make changes.
I had duplicated code in scenario save and scenario save as.
Almost duplicated.
Save as didn't have all the code save had and I think would have missed copying "Places" into the scenario.
Both now use common code in a new method to do a bunch of things including this.
« Last Edit: February 09, 2020, 10:16:11 AM by Andy ONeill »

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 418
Re: Changelog - picture heavy
« Reply #305 on: February 12, 2020, 01:39:51 PM »
Scenario Editor

Improve generation of scenario "thumbnail".
There are complications to capturing an image from this view.
One of which being some pieces of UI such as Retreat Points can extend out of the logical frame.

Launcher

Use standard method to load scenario data.
Show this thumbnail in select scenario.

Offline zu Pferd

  • Hoplite
  • *
  • Posts: 22
Re: Changelog - picture heavy
« Reply #306 on: February 28, 2020, 05:13:12 PM »
Watched the latest video. Very impressed with it, the process to get into a game is friendly, the maps are superb.
I can only ask when ?  Cheers !

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 418
Re: Changelog - picture heavy
« Reply #307 on: February 29, 2020, 02:49:41 PM »
Tricky one to answer, that.
I've changed jobs and my new one is pretty much all consuming so i don't have much time to spare on this.
I get to eat and still have a roof over my head though.

Ezra is working on the game now.
I think if you read his blog you will find some numbers.
You'll also find a post he explains how he's always been known for extreme optimism in his estimations.
Personally, i think there's still a lot of work to do.

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 418
Re: Changelog - picture heavy
« Reply #308 on: March 07, 2020, 09:52:27 AM »
Installers

Although I'd upgraded the dotnet version the apps depend on to Net core 3.1, the installers still had a pre requisite of Net 4.6.1 ( which is older ).
I've un-checked that box and the installers don't think any dotnet is a pre-requisote any more.

There is a complication to adding a pre requisite of net core 3.1 in the installer projects.
MS, in their infinite wisdom, have greatly complicated net core framework installs by having numerous separate smaller exe. You need to pick desktop and the appopriate 32 or 64 bit version. To spread the joy further, installer projects don't easily support adding net core as a pre requisite.
Spending a disproportionate amount of time on these installs is not a great plan.
For now, if you're installing something targets net core then please download the desktop install from:
https://dotnet.microsoft.com/download/dotnet-core/3.1
Currently 3.1.2

Loader

On my machine the scenario and picture is and was an instant load. This isn't a particularly powerful machine but it does have ssd.
Ezra's machine is very old and I think probably below the minimum spec we should give as necessary to run the game.
He experiences a delay.
I've multi threaded the code that sets up these pictures which will hopefully address this.



 

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 418
Re: Changelog - picture heavy
« Reply #309 on: April 10, 2020, 09:54:15 AM »
Save As

This is a new dialogue used across the app suite.
Previously, I took a short cut and "just" used a standard windows file save dialogue.
The problem with that is you could decide to navigate to some other folder and pick a location could never work.
A standardised file structure is necessary for a game to find a scenario which can find it's armies and map.

The new dialogue "just" shows you file names and stops you saving elsewhere.
This first iteration is not fully styled up yet.
As usual... it's probably also not completely stable.
I'll show you pictures once I've done some more testing and styling.

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 418
Re: Changelog - picture heavy
« Reply #310 on: April 11, 2020, 07:54:17 AM »
Save As

Fairly stable and styled.
Still needs a bit more testing.
I know there's at least one minor bug lurking in there.

Since you could potentially change the name to something already exists - intentionally or unintentionally - there is a "Replace" button appears if your name matches something already there.
In which case, the "Save" button disappears.
Otherwise, the Save button saves as whatever you have in the textbox.

If you've used the open screen you might have noticed the listbox styling there is default win 10.
I've put together a more suite-suitable styling for this which I will probably use across the suite.
Instead of the light blue gradient for a selected entry and blue border I've got brown ( saddle brown ) with white text for contrast and a sepia border.
These are colours used throughout our suite.

Here I'm using Save As in scenario editor and have antietam open.
Initially I had File Name "Antietam".
I type "not " in front of that.

 

I then hit save.



Tech talk:

I know there are one or two devs read this so some aspects of making a generic save as...
The viewmodel takes an an anonymous Action delegate via it's constructor which is built in the parent and captures variables from there.
This then allows it to generically run something which does quite different things.
EG "Saving" a map is pretty complicated stuff since there are components like ink "strokes" persisted, a picture of the map needs to be grabbed and everything is then zipped up.
Army saving is simple by comparison with an army object serialised to xml ( using datacontractserialiser ).



Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 418
Re: Changelog - picture heavy
« Reply #311 on: April 17, 2020, 02:41:16 AM »
Game

Rename to Engine.
The idea here is to make it clear you're supposed to run this via the loader which lets you pick settings and options.
Those are passed indirectly via a file written to disk.
As you run the game it reads this file and loads whichever scenario you chose with whatever settings.
Running the game directly continues whatever you were playing last time.

Prototyping unit wheels.
A battalion in close order didn't just spin on the spot to turn.
It pivots around one corner until it faces the direction it is to move in and then moves forward.
I am therefore using some maths to work out where a unit has to turn to in order to face a given point.
Not something a commercial developer does usually - so this led to a bit of head scratching.
Looks like I have a left wheel calculation is working though.
I "just" need to:
Get right wheel working.
Prove it's really really working ( in programming if something works first time you probably spent too much time on it ).
Then refactor to make it maintainable when I come back in a week or two and can't recall where the atan2 of the wossname came from.

As a historical note:
Pretty much all maneouvers and changes in formation were done by company.
Wheeling was no  exception and is non trivial.
A battlefield was rarely a completely flat expanse so one or more companies might well encounter some obstacle like a tree or rocks and have to break up and then reform once past it.
Cavalry formed up quite close to each other and a horse is a sort of long rounded rectangle or ellipse so as each turns they risk bumping into the horse on either side.
It took a fair bit of training for a close order cavalry unit to be able to turn at all.

Offline Adraeth

  • Hoplite
  • *
  • Posts: 23
Re: Changelog - picture heavy
« Reply #312 on: April 17, 2020, 05:11:26 AM »
thank you for the updates

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 418
Re: Changelog - picture heavy
« Reply #313 on: April 18, 2020, 06:05:30 AM »
Game

Got the formula working generically so it works with left or right wheels.
I've done a minimal conversion ( AKA bodged ) of the visualisation code I had already.



Here you can see the unit will wheel to the right.
You click the unit to select it for move and then the line follows your mouse move.
You currently get a red line from the first invalid point.
I think I'm going to change that so it's one line that turns red if you're crossing invalid terrain.

When you click, more checks will be done and it'll become an arrow with it's point where you clicked.
At the moment it's a bit of a nuisance if you decide you don't want to move the unit you just clicked.
A bit like chess maybe.
You touched it so you've got to move that piece  :)
You can click it again to de-select but I think I'll add another way - maybe press esc or right click also abandons the move order.
 

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 418
Re: Changelog - picture heavy
« Reply #314 on: April 20, 2020, 09:38:06 AM »
Game
Beating the bugs out my angle calculations.

Output user message indicating what terrain makes a move invalid.
This is just the first invalid terrain.
Only terrain type is used.
Hence slope is currently ignored for this and whilst you’re dragging just the line directly from start to finish is used. A more sophisticated and hence time consuming routine will be applied once you click.

Avoiding running the calculations every time the mouse move event fires. The process is reasonably efficient and is “only” done for the one piece but this change should reduce the stress on lower powered machines.

Multi threading the calculations and terrain testing.
This will improve UI responsiveness.

Together with the above, calculating the rotated “start” point and drawing the line from that to the cursor point is now smooth and totally responsive.
This is on a dev  machine which is not particularly powerful for a gaming machine and running in debug mode at the same time as visual studio so I’d expect it to run fine on even fairly low powered machines.