[FIXED][MEDIUM] Vertical displacement

[celebaglar]

OK, I'm asking this here as I haven't got any screenshots to illustrate it yet.

Has anyone notice how, when looking from certain angles, armies which are further away look as if they are closer than terrain features when in fact they are not?

One such example would be looking from Kumar to Utarg. The army at Utarg actually appears to be closer or level with the trees north or the keep, which are in fact quite a bit closer to Kumar.

Other similar diagonal views have caught my notice in a few games, and I wonder if that is because armies are perhaps placed lower on the screen than the terrain they inhabit?

Either way, has anyone else noticed this?

[Natmus]

Several times, and I have long wondered about reporting it as a bug, but didn't quite know how to go about it.

There are a few variations on this:

First thing is the vertical offset that seems somewhat wrong. I have noticed it especially when looking diagonally (SE, NE, NW or NE) and looking at armies that are placed next to each other on a straight line (NS or EW). The more distant army is actually placed below (and to the right or left of) the nearer army, giving the impression that it is nearer.

Another aspect is that armies are placed a little below other items in the view, and sometimes is visible below features like forests or mountains that should hide them. But often there's a vertical line visible below the forest or hill in from of them, and that gives away the army's presence. As an example of this last thing, try standing two moves NE of the citadel of Korkith, looking SW at it, when there's an army inside it. The vertical line below the hill between the viewer and the citadel is very obvious there.

[queex]

I've seen it too. The army graphic is drawn lower than the terrain, but a bit too low so it sneaks under the terrain in front. Should be easy to fix.

[sparrowhawk]

On to it. Thanks.

[Natmus]

I have a few screenshots to show the problem with displaced features. The shots is taken towards the keep of Blood and the army located to the west of the keep; not NW or N, but simply just west of the keep.

Fist picture is taken by the Hand, who is located just south of the Keep of Dragons:



Second one is taken by Korinel, standing inside the keep of Dragons:



But then Korinel moves just one step closer to the keep of Blood to investigate, observe what happens:



Things suddenly seems much more reasonable (ignore the smaller army in the background). So the problem only exists for some views at some distances, but I think we need to address this before going public.

[celebaglar]

OK, I'm about to upgrade my router firmware - so if I disappear you'll know it failed - in order to be able to put my screenshots on my site.

Just a small addition the the previous messages: the symptom is NOT limited to armies. Static terrain also suffers from the problem, usually regarding stuff that's 3 squares away or further. Screenshots and explanations to follow shortly.

Note: I have changed the title and gravity of this thread in view of the actual subject and the approaching public release. A problem that we LoM veterans barely noticed is likely to cause considerable confusion to new players unfamiliar with the map and quirks of the engine.

[celebaglar]

Yay!! I'm back, and the FTP uploads work too, (And I didn't have to boot into Windows to upgrade my router firmware - well done Netgear.)

OK, here's the first example. This is viewed from the Citadel of Kumar, looking south towards The Targ. The army in the picture is the Utarg in his keep.



Ignore the ruin in the foreground, and concentrate on the four items behind it: the army, the forest left of the army, the village left of the forest, and the lith to the right of the army.

Here's the relevant map section, which makes it easier to spot the problem:



Note how the army appears to be closer to the viewer than any of the other three named items? Yet the map clearly shows the army to be further away, by a considerable distance. Next, note how the village appears to be in front and nearer to the observer than the forest, when in fact the village is directly east of the forest and should be behind and slightly further away*. This means the displacement problem is not limited to armies, and may not be caused by the armies being drawn slightly below the terrain they inhabit.

* - Depending on the distance, the actual displacement of the village may need to be the same as that of the forest, but it is important to draw the village first and forest after to capture the correct masking effect.

Another example coming up shortly...

[celebaglar]

OK, same kind of thing, and similar to the one Mads showed, only it does not involve armies and is not taken on a diagonal.

The relevant map area (around the Citadel of Dawn) is this:



Amarin is at the bottom centre of that map, two squares south and one square west of the citadel. He is looking north, and the area of interest is between the mountain directly ahead and the keep.



Note how the downs appear to be closest to Amarin, then the lith, then the village. However, the map says the village is nearest, then the downs very slightly further away, with the lith well behind both of these.

Now, moving Amarin forward one square:



Note how the village is now nearer than the lith, which is correct, but the downs still seem nearer than the village, which is wrong.

There seems to be no difference to this effect whether it is viewed along the north-south or east-west axis, or along a diagonal.

In conclusion, I'd say the whole table of displacements needs to be reviewed. You could either do some direct calculations in real time, or stay with a pre-calculated table.

For a quick overview of how I've covered this issue, keep an eye out on the Coding section of this forum. You may or may not find it helpful.

[merlin]

I have placed here 3 comparisons from TME.







The later two are harder to see the downs because of their whitness!

Anyway these are done with the landscaping code on www.icemark.com and the tables that I sent to Jean-Yves recently.

One point to note, images should be cropped and the coordinates from the table are for the bottom middle of the image.

[Natmus]

And while we're at it, here's how a mountain look when an army is hiding behind it. Same thing as forests and hills, but I just wanted to show it.

[sparrowhawk]

OK chaps and chappesses. I'm running out of time for coding MU, so I'm putting out a plea to all of you coders out there to try to help MU development by fixing this bug for me. Think of the fame, fortune and my gratitude. OK, 1 out of 3 ain't bad.

Here are the cuplrits. First, the array that holds the terrain data and sizes:


//Midnight Terrain Data

 //Define terrain types, names and sizes (armies are defined as terrain for display purposes)
 //Terrain type, preposition, filename prefix,
 //         pixel width & heights for all 8 sizes from 0 (largest) up to 7 (smallest)

 $terrainData = array(
   " " => array("Plains",    "on"     ,"", 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0),
   "A" => array("Army",      "n/a" ,"", 103,35,72,25,51,18,45,16,34,12,26,9,21,7,17,6),
   "C" => array("Citadel",   "within"  ,"", 125,74,89,52,63,38,56,33,43,24,31,18,24,15,18,12),
   "D" => array("Downs",     "on"     ,"", 128,22,90,16,63,12,57,11,43,9,33,7,25,6,21,4),
   "E" => array("Lake",      "by"      ,"", 110,11,77,8,55,6,48,5,36,4,26,3,19,2,16,1),
   "F" => array("Forest",    "within"  ,"", 128,41,90,29,65,21,58,19,43,15,32,12,25,10,20,8),
   "H" => array("Henge",     "within"  ,"", 73,23,51,16,36,12,32,11,24,9,18,7,15,6,11,5),
   "K" => array("Keep",      "within"  ,"", 53,34,38,24,27,17,24,15,16,12,13,9,9,6,6,5),
   "L" => array("Lith",      "by"      ,"", 121,49,85,35,61,25,54,22,41,17,31,13,25,11,20,9),
   "M" => array("Mountains", "amongst" ,"", 128,78,90,55,64,39,56,35,43,26,33,20,26,16,21,13),
   "N" => array("Cavern",    "inside"  ,"", 92,20,65,14,45,10,40,9,30,7,22,6,18,5,14,3),
   "R" => array("Ruins",     "amongst" ,"", 87,34,61,24,44,17,39,15,29,12,22,9,18,7,14,6),
   "S" => array("Snowhall",  "inside"  ,"", 33,18,21,13,16,10,14,9,11,6,9,5,8,4,7,3),
   "T" => array("Tower",     "by"      ,"", 53,78,37,55,26,40,23,35,17,27,13,21,10,17,8,14),
   "V" => array("Village",   "within"  ,"", 83,19,58,14,41,10,36,9,27,7,21,6,17,4,14,3),
   "Z" => array("Frozen",    "in"  ,"", 128,35,90,25,64,18,57,16,43,12,33,9,26,7,21,6));




Next, the North view offsets:


// N View data
// Size, MapRow, MapColumn, PixelY, PixelX

//Size 0 is nearest, Size 7 is farthest away
//THE ORDER MUST BE PRESERVED (ie size 7 down to 1, and within each, furthest row defined first, nearest defined last)
//OTHERWISE DISPLAY WILL BE INCORRECT

$offsetViewData = array(

 //Size 7
 array(7,  -6,  -2,  99,   77),
 array(7,  -6,  -1,  99,   97),
 array(7,  -6,   0,  99,  118),
 array(7,  -6,   1,  99,  139),
 array(7,  -6,   2,  99,  159),
 array(7,  -5,  -4,  99,   32),
 array(7,  -5,  -3, 100,   49),
 array(7,  -5,   3, 100,  187),
 array(7,  -5,   4,  99,  204),
 array(7,  -4,  -5,  99,    4),
 array(7,  -4,  -4, 100,   18),
 array(7,  -4,   4, 100,  218),
 array(7,  -4,   5,  99,  232),
 array(7,  -3,  -5, 100,  -13),
 array(7,  -3,   5, 100,  248),

 //Size 6
 array(6,  -5,  -2,  97,   67),
 array(6,  -5,  -1,  97,   90),
 array(6,  -5,   0,  98,  115),
 array(6,  -5,   1,  97,  140),
 array(6,  -5,   2,  97,  163),
 array(6,  -4,  -3,  98,   33),
 array(6,  -4,  -2,  98,   56),
 array(6,  -4,   2,  98,  174),
 array(6,  -4,   3,  98,  197),
 array(6,  -3,  -4,  98,   -3),
 array(6,  -3,   4,  98,  233),

 //Size 5
 array(5,  -4,  -1,  95,   81),
 array(5,  -4,   0,  96,  112),
 array(5,  -4,   1,  95,  143),
 array(5,  -3,  -3,  95,   12),
 array(5,  -3,  -2,  97,   37),
 array(5,  -3,   2,  97,  187),
 array(5,  -3,   3,  95,  212),
 array(5,  -2,  -3,  97,  -13),
 array(5,  -2,   3,  97,  237),

 //Size 4
 array(4,  -3,  -1,  92,   66),
 array(4,  -3,   0,  93,  107),
 array(4,  -3,   1,  92,  148),
 array(4,  -2,  -2,  93,    7),
 array(4,  -2,   2,  93,  207),

 //Size 3
 array(3,  -2,  -1,  88,   41),
 array(3,  -2,   1,  88,  159),
 array(3,  -1,  -2,  88,  -41),
 array(3,  -1,   2,  88,  241),

 //Size 2
 array(2,  -2,   0,  86,   96),

 //Size 1
 array(1,  -1,  -1,  78,  -17),
 array(1,  -1,   1,  78,  183),

 //Size 0
 array(0,  -1,   0,  66,   64),

 );

Now NE view offsets:

// NE View Data
// Size, MapRow, MapColumn, PixelY, PixelX

//Size 0 is nearest, Size 7 is farthest away
//THE ORDER MUST BE PRESERVED (ie size 7 down to 1, and within each, furthest row defined first, nearest defined last)
//OTHERWISE DISPLAY WILL BE INCORRECT

$offsetViewData = array(

 //Size 7
 array(7,  -6,   2,   99,  59),
 array(7,  -6,   1,   99,  39),
 array(7,  -6,   0,   99,  18),
 array(7,  -6,  -1,   99,  -3),
 array(7,  -5,   4,   99, 104),
 array(7,  -5,   3,  100,  87),
 array(7,  -4,   5,   99, 132),
 array(7,  -4,   4,  100, 118),
 array(7,  -3,   5,  100, 149),
 array(7,  -2,   6,   99, 177),
 array(7,  -1,   6,   99, 197),
 array(7,   0,   6,   99, 218),
 array(7,   1,   6,   99, 239),


 //Size 6
 array(6,  -5,  -1,   97, -10),
 array(6,  -5,   0,   98,  15),
 array(6,  -5,   1,   97,  40),
 array(6,  -5,   2,   97,  63),
 array(6,  -4,   3,   98,  97),
 array(6,  -4,   2,   98,  74),
 array(6,  -3,   4,   98, 133),
 array(6,  -2,   5,   97, 167),
 array(6,  -2,   4,   98, 156),
 array(6,  -1,   5,   97, 190),
 array(6,   0,   5,   98, 215),
 array(6,   1,   5,   97, 241),

 //Size 5
 array(5,  -4,   0,   96,  12),
 array(5,  -4,   1,   95,  43),
 array(5,  -4,  -1,   95, -19),
 array(5,  -3,   2,   97,  87),
 array(5,  -3,   3,   95, 112),
 array(5,  -2,   3,   97, 137),
 array(5,  -1,   4,   95, 181),
 array(5,   0,   4,   96, 212),
 array(5,   1,   4,   95, 243),

 //Size 4
 array(4,  -3,  -1,   92, -34),
 array(4,  -3,   0,   93,   7),
 array(4,  -3,   1,   92,  48),
 array(4,  -2,   2,   93, 107),
 array(4,  -1,   3,   92, 166),
 array(4,   0,   3,   93, 207),
 array(4,   1,   3,   92, 248),

 //Size 3
 array(3,  -2,   1,   88,  59),
 array(3,  -1,   2,   88, 141),

 //Size 2
 array(2,  -2,   0,   86,  -4),
 array(2,   0,   2,   86, 196),

 //Size 1
 array(1,  -1,   1,   78,  83),

 //Size 0
 array(0,  -1,   0,   66, -36,),
 array(0,   0,   1,   66, 164)

 );


The N and NE views are rotated so that they are used for all the other views. If necessary I can provide the rotation script, but if that were broken then we would have noticed by now!

The arrays within arrays are PHP's way of implementing multi-dimensional arrays, BTW.

Many thanks in advance for any help.

[merlin]

JY, What dimension for the landscape window? Same as a spectrum 256x192?

I will run some code on my machine at home tonight, I can then probably give you the exact numbers as per the original in the format you are using.

A quick look over your arrays and some of your numbers look wrong... I'm not sure how, but they don't seem familiar. - yes yes, I shouldn't have LOM landscaping coordinates in my head!

[sparrowhawk]

Merlin said:

JY, What dimension for the landscape window? Same as a spectrum 256x192?

I'm using numbers as provided ages ago by Peter Armstrong (whatever happened to him?), along with the gfx which he also provided. I think that he used these on his Amiga and games console (dreamcast?) LoM. If you compare one of the MU gfx with the ones that you use for DOS/LoM, you should get the ratio.

Here's the code that actually generates the styles in 0.2 (in 0.1 the styles are generated earlier as classes, but essentially the calcs are identical - 0.2 just uses one loop rather than 2 so is quicker)


 reset($offsetViewData);
 $count = 1;

 while (list($key,$value) = each ($offsetViewData)){

   $size       = $value[0];
   $rowOffset  = $value[1];
   $colOffset  = $value[2];

   //Get the terrain type at the current offset (adjusted for current view)
   $tt = getTerrainTypeAhead();

   $width  = $terrainData[$tt][3 + (2 * $size)];
   $height = $terrainData[$tt][3 + (2 * $size) + 1];

   //Get Frozen Wastes width as this is equal widest - will be used to calc offset for centering narrower graphics
   $frozenWidth = $terrainData["Z"][3 + (2 * $size)];

   //If not plains, create image tag (plains are blank, so no need to create them)
   if($tt != " "){
     echo "    <img src='" . $gfxPath . "gfx2/" . strtolower($terrainData[$tt][0]) . $size . ".png'";
     echo "style='position:absolute;";
     echo "top:" . ($TOP_Y + 100 - $value[3]  - $height - (7 - $size)) . "px;";
     echo "left:" . ($LEFT_X + $value[4] + ceil($frozenWidth/2) - ($width/2)) . "px;'";
     echo " alt='?'>\n";
   }

$TOP_Y and $LEFT_X are constants that are used to position the top left hand corner of the view.

Hope this helps - thanks for the assistance.

And fancy not remembering your LoM offsets. Shame on you!

[merlin]

ok, if you check the landscaping document at

www.icemark.com/tower/landscaping.htm

you will see that the y coordinates run from 32 - 64. 32 being the biggest object and 32 being the smallest.

using a screen of 256 x 192, the y coordinate is calculated using

(192 - 16) - y

The graphic is drawn from bottom up so the above becomes.

(192 -16) - y - height.

176 - y - height

Your code does, assuming top_y = 0

100 - y - height - ( 7 - size )

Now your numbers are different, now all your furthest graphics are y 100 or 99, surely they should be the same? There is no curve on the distance terrain in LOM. Which is what that is possibly doing.

the (7-size) means that as the images get bigger they start to offset on the y!!!

- I'll have some more thoughts in a moment... got to go somewhere...

[celebaglar]

I haven't had the time to peruse the actual offset values too closely, but one thing sticks out: the order in which items are drawn.

If I understand your code correctly the order in which the items are drawn is determined by the order of the arrays as you have listed them. However, what seems obvious from that is that items which have a higher offset - and are therefore further away - are sometimes drwan after items with a lower offset, which are presumably nearer the observer.

You should draw your graphics in strict offset order, and if the offsets are correct then this will automatically mean you are drawing them in scale order too.

Just a quick note on Chris' mention that all scale 7 graphics would be at an offset of 100: that's not necessarily the case. There are in fact 18 different radius values for viewable terrain features if you follow the landscaping technique on www.icemark.com. Some of the furthest ones will merge together in actual application, meaning they will all seem to be on the horizon, but you still get more than 8 actual offset values, so the result is that sometimes you will have the same scale but differing offsets. This will happen with the smaller scale features, where the offsets are closer together.