[Warhammer Dark Omen Forum]

Warhammer Dark Omen Forum | Warhammer Dark Omen | Tactical wargaming and other Warhammer games
Hangover Cure...

[olly]

enlightening about the multi-core support and loving the battle. What language are you coding in and any other tech specs, as interesting to learn the different stages of creation (only if u have time, as don't want to slow the rapid progress)

[Smurf]

Well the rapid progress has been somewhere hindered by a memory access violation somewhere in the threading system, and seeing as you asked - let me go put the kettle on and I'll impart some weary wisdom from the world of multi-threading - which will probably suggest you spare your sanity and never try it.

Right coffee in hand...  Multi-threading is the devil.

And frustratingly this game needs it, because there's a lot of logic that needs processing to have lots of units.  The biggest issue with doing multi-threading on the Windows platform is that only the main thread can talk to the graphics.  So all the 3D stuff has to be done on the main thread.

This means the other threads are doing game logic, which in this game is the decision making engine that makes the soldiers run around in accordance with their orders.  The heaviest part of that calculation is when the soldier has to be positioned in 3D space, I do this entirely in maths from a memory bank that holds topography data for the map.  Because the topography data only has reference points every n units of space in the 3D world I have to do a calculation that works out the height at a given co-ordinate between the neighbouring reference points, rather than raycasting in 3D which is both slow and can only be done on the main thread.

There's also a lot of range calculations involved in the logic of the decision tree, and that involves some power of and square route maths, as well as some 2D movement over the terrain surface which involves some cosine and sine maths.

Basically, range = sqrt( (destination.x-source.x)^2 + (destination.z=source.z)^2 )
x = x + cos( facing ) * speed
z = z - sin( facing ) * speed

So basically there's a lot of maths to do which aren't direct 3D operations, which is why this game benefits a lot from threads.  I am toying with the idea of pre-caching some of those sums, ie: having a databank of cos results.

The problem with threads is that if one part of the software is writing some data whilst another thread reads it then the software crashes - and because this is parallel processing you have little control over when events happen.

To combat this there are a number of approaches, the first thing I did was create a working copy of the data in use, so that the render just works with a final output of a few key pieces of information, specifically:

A boolean true/false flag for each soldier that gets switched to true when it is time to render.
An x, y and z position
A bearing for the units direction
And the current animation sequence and frame

Basically the threads get all of this information ready and then set the boolean flag to true, the rendering thread then draws it and sets the flag to false.  Once the flag is false the thread processing that unit will then reconsider the logic for that soldier.

In addition - because of the current crashing problem - I do something called mutex locking on the threads which creates a "pause" for processing of a unit whilst that unit is in it's rendering cycle, so that the rendering cycle and the logic cycle for a given unit never occur at the same time.  I dislike mutex locks as they hinder the performance benefits of using threads, and in this case they don't seem to have fixed anything so they might not stay, but they're here for now.

Now somewhere in this flawless logic is a floor, and this is the bug I am trying to stomp right now

The difficult part is that when a crash occurs from within a thread you get absolutely no debug information at all, and when I run the software outside of a thread the crash never occurs.  So debugging is done by a process of trial and error.  Which is bloody painful.

-*-

As for tools, I am using the Xors 3D engine which is a DX9 engine.  I use this because it is very similar to engines with which I was already familiar from "back in the day" but has the addition of shader support and DX9 features, I have a shader which drives the landscape texture which I wrote myself ( technically: A 7 way splat shader that does not use alpha channel thus maintaining shadow support) - and a couple of shaders on the water which was public domain code.

I compile in BlitzMax/GCC which is a superb combination for rapid development, it'll compile multiple platforms and multiple languages but its own language constructs make for easy and rapid development and I use them almost exclusively.  However, because the 3D engine I am using is DirectX this particular game will be Windows only.

[Smurf]

Right, seems my problem debugging threads turns out to be a bug in my compiler.  Luckily it's open source and actually compiles itself (which is a brainfuck in itself), and people have posted various solutions so I'm trying them out and seeing what this new level of debug information turns up.

[Smurf]

Well that's typical, made the changes to my debugger code files, recompiled, then saw the problem and fixed it without needing the debugger.

*rolls eyes*

I think i'm going to go to bed before I find another bug!

[Smurf]

Well the good news is I managed to get rid of the mutexes on the rendering thread, so the only mutexes now are in relation to mouse clicks and the unit processing logic.

And there's more good news, I am about to begin work on the mesh units and their special attacks   I just have to fix their navigation first as they seem to never march through their list of waypoints, and then it's time to get their special moves in .

[Smurf]

Figuring out the behaviour of flying units, here's the first implementation

Flying Units - Early Implementation	powered by Aeva

Off shopping soon, so will be a slow day.

[Smurf]

Getting there

[olly]

Sounds very complicated but really appreciate the overview of the engine and required logic and maths. The flying units are also looking fantastic.

[Smurf]

Made good progress on the monsters tonight, but I'm taking a break. I feel the need to vegetablise myself infront of the telly for a few hours

[Smurf]

Beginnings of a UI



The Dragon has two special moves, to fly and its breath weapon, these are controlled by a "dragoncharge" indicator, a kind of mana bar if you like that forms part of the portrait.  Of course those buttons don't actually work yet, that's for tomorrow .

[Smurf]

Work in progress, but I've begun the breath weapons

[olly]

Cool!

[Smurf]

OK so, I've done the black dragon which fires off a bilious green cloud of poison, and I'm about a third done on the red dragon which breathes fire.

The question is, what should these dragons breath:

Gold
Brown
Green
Blue

AD&D gives some inspiration, but we need not follow that:
Blue - lightning
Green - acid
Gold - fire / weakening gas
Brown - acid (line not aoe)

In this game all the dragon breaths need to be AOE for gameplay reasons.  It kinda works at the moment, that as the player you get to fire off the breath weapon with two choices of attack (left/right mouse buttons) to try and catch as many soldiers as possible - and if you fail you get overwhelmed by troops and whittled down.

I like the idea of having a cold attack, so blue could be cold.  Although i'm not sure how to represent it graphically yet.  Green being acid is fine.

But that leaves Gold and Brown.

[olly]

Gold could be utlimate dragon and have combined weapons such as flame and ice, since I would like to see lightning effects kept for blue dragon.

Brown could be putrid stomach contents to demoralise the enemy (-2 on Leadership and movement), generated by sucking on the corpses of the dead.

[Smurf]

Gold could be utlimate dragon and have combined weapons such as flame and ice, since I would like to see lightning effects kept for blue dragon.

Brown could be putrid stomach contents to demoralise the enemy (-2 on Leadership and movement), generated by sucking on the corpses of the dead.

I quite like the idea of the Gold dragons attack being indirect, a kind of buff/debuff character. Perhaps it could resurrect fallen soldiers with its breath weapon. That would make it very powerful but at the same time it would be less capable in its own right.

If I do lightning I'll need to move cold onto another dragon, perhaps black - and move it's poison onto Brown. That leaves green as acid.

I'm not sure how I'll tackle these things graphically yet. Lightning is certainly a challenge, I can't just plug it in to the particle system I wrote today, it'll need something new.