Avoiding 3rd Party Bugs

So.. one of the recurrent issues, and one I may have mentioned in passing was the game's tendency to throw SystemAccessViolations, particularly when I was trying to do anything with changing the Direct2D brushes (which was a bit of an issue, since I was creating new brushes every time the screen changed.)  This wasn't as noticeable on high-end machines, but particularly on old, slower machines, the game crashed a lot.

As that particular violation is an unmanaged code violation (i.e. not something C# can generate) I couldn't really go deal with the problem directly (I guess it's something in the SharpDX code)  However, I got around it by just keeping a collection of brushes (Since I'm only altering the color) and only creating brushes if a combination doesn't match existing brushes.

This appears to have completely eliminated the problem, or at least made it very rare.  While there's nothing quite as infuriating as the very rare crash, at least in that case I should be able to emergency save to prevent the player from losing progress (as only the rendering is corrupt, at that point.)

No illustrative GIF on this one, the rendered result is the same as before (although faster on older computers)

Better Rivers

Well, River generation looks more natural now, but I'm still not terribly happy with it:

Even with some randomness, it's still way too clearly a sin-wave... which river systems frequently are in nature, just not that uniform.

Adjusted the rendering frame rate downward to see if that helped with flickering issues, and it did... a bit (and didn't hurt anything) but I think that issue still needs further work:

Terrain generation and Z levels

So, for the moment, the level builder is an external program, which makes some aspects of it easier to debug.  As I'd left off the main program for a bit to go build levels with a bit more Z interaction, I managed that relatively quickly:

The colored zone edges you're seeing as I pan up are the up-down ramps, where they are absent you're seeing more than 1 z level of separation, so essentially a cliff.

Technically I could go back to the main program and finish testing movement up Z levels, but there's still a bit of work to do with level generation, in terms of making more realistic terrain and some non-ruined cities, so that'll be next.

LoS the conclusion

So I enabled the tile hiding for unexplored zones, made a few more modifications (buildings and such were changed to bright red, so the out of sight areas being gray was a bit more noticeable)

At this point, I need to add Z-axis navigation (stairs, where it asks you to ascend, ramps where it automatically does so) but I'll come back to that.  For now, I'm going over to the separate test-bed program for level generation, to finish out the initial generation of all the terrain boards.  Once we have some levels that are more organically 3D, I'll finish up the last of the navigation.

Line of Sight

With the pathfinding working, it shouldn't have been too much effort to implement some player line of sight... and indeed it wasn't.  Per usual, I'd say about 70% of the time required was due to dumb mistakes.

I does have a bit of artifacting around the corners caused by allowing for diagonal circle circumference points.  I'm not sure, given the larger sight distance I plan on using, that I'll do anything further with that.

Hidden/discovered terrain also works, although it's turned off for the above demo.  It does need to allow for the first view-blocking terrain to be discovered, though.

Now I have to decide whether I want to tackle the rest of map building, or try and flesh out the user interface a bit more to look like the eventual game product.

Z Axis

So, in order to represent a ruined, post-apocalyptic city, you need properly generated vertical maps, I'd argue.  I already had the generation part done some time ago (although it has a bug with doors past the first floor, as you may glimpse in the below GIF)

However, I don't plan to have inter-level interactions.  Although it might be realistic to have someone sniping at you from the second floor, it'd be frustrating from a game play perspective, as you don't have a true 3D view.  As demonstrated below, what I've done is made air transparent, and had lower tiles darken as they are further below you in Z levels.

After a bit of moving around, I move the camera up through the Z levels, and then down underground, below:

A month without updates

Real life got... significantly in the way of doing much, but I did change how the camera, such as it is, tracks the player.  Instead of adjusting to always keep the player in the center, now it only moves when it needs to.  Given that this isn't an action game, I think this probably is how it needs to be.

Dangerous Tangents

So.. I wasted an inordinate amount of time trying to add an animation capture feature to show the path-finding success.  To briefly incapsulate:

You can use the WIC Library via it's SharpDX wrapper to capture output, but only after you had quite the hand-off of devices, from your Direct3D device, to a DXGI device, to finally a Direct2D device.  Only once I got there did I realize that WIC doesn't fully implement the GIF standard, meaning you can save a bunch of frames to the GIF, but they won't be animated.

Anyway, long story short, ScreenToGif is free and works great.  It pretty much did exactly what I wanted:

...which is show off the path-find movement.  It also shows off that I probably have some implementation problems that you can see in the GIF, with wonky colors in some frames.  That's likely because the thread timer for animation isn't in any way synced with rendering thread. 

I also got font loading to work, which took me down an interesting path regarding font licenses.  Fortunately, Consolas, which is used for all the tiles, is bundled with Windows, and Neurpol, the title font, is free to use.

Pathfinding Success

Well, that took a little longer than it should have, mostly because real life interfered with coding.  So, direct line drawing of paths:

...and then, pathfinding paths, based on the movement cost of individual terrain:

I'll still need to work a little bit on some edge cases that'll result from truly impassible terrain, since I'm taking a mini-map approach to it, rather than pathfinding on the (prohibitively large) entire map.  Also, I might offload it to another thread if it seems to be an issue, but so far, the computational cost seems pretty reasonable.