Recent Posts

Pages: [1] 2 3 ... 10
1
General Staff Support Forum / Re: Changelog - picture heavy
« Last post by Andy ONeill on Today at 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.



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.



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.


2
General Staff Support Forum / Re: Changelog - picture heavy
« Last post by Andy ONeill on Today at 01:15:31 PM »
Thanks.
3
General Staff Support Forum / Re: Changelog - picture heavy
« Last post by Adraeth on Today at 02:21:06 AM »
This is going to be a Masterpiece

an usual italian would scream : "Mamma mia!!"  :notworthy:
4
DIY / Re: Links to Vendors or Manufacturers
« Last post by bayonetbrant on Yesterday at 08:58:37 AM »
5
General Staff Support Forum / Re: Changelog - picture heavy
« Last post by Andy ONeill on Yesterday at 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:


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.
 


6
General Staff Support Forum / Re: Changelog - picture heavy
« Last 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.




7
General Staff Support Forum / Re: Changelog - picture heavy
« Last 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.
8
General Staff Support Forum / Re: Changelog - picture heavy
« Last 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.

9
General Staff Support Forum / Re: Changelog - picture heavy
« Last 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.

10
General Staff Support Forum / Re: Changelog - picture heavy
« Last 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.


Pages: [1] 2 3 ... 10