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

0 Members and 1 Guest are viewing this topic.

Offline Andy ONeill

  • Moderator
  • Viking
  • *****
  • Posts: 358
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: 358
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: 358
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: 358
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: 358
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: 358
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: 20
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: 358
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: 358
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.