Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Chris Burrows

Member Since 17 Sep 2012
Offline Last Active Oct 04 2012 04:16 PM

Posts I've Made

In Topic: Representing an iso map in a 2d array?

20 September 2012 - 03:36 AM

no need for negative array indices; not sure where you got that idea


As I said originally, I require the entire visible map to be covered with tiles. Using a traditional square grid on a tilted on a 30 degree angle means that there are going to be tiles with negative array indices, shown in black.

Posted Image

Unless however, the (0,0) index is far off to the left somewhere, seemingly the preferred method. In the image below, the green rectangle depicts the desired visible map, it also shows the array co-ordinates within the map using the staggered approach. The giant blue rhombus, demonstrates the size of a tilted array required to cover the same size map with tiles.

Posted Image

As you can see, using the staggered approach cuts the size of the array in half, but as FLeBlanc mentioned, this is unlikely to have any impact on performance. Personally, I prefer the staggered approach for it's elegance. Positioning the tiles on screen is simple:

X co-ordinate: (X index * Tile width) + ((Y index mod 2) * ( Tile width / 2))
Y co-ordinate: Y index * (Tile height / 2)

I've already coded the pathfinding and movement with a staggered grid (here is a demo if anybody is interested), but I haven't come much further than that. I think I'll head the advice and re-write with the (0,0) offset method. Thanks for the help.

But your world representation does not have to be an array.


What other choices do I have? Hash table? My pathfinding code is pretty dependant on arrays, but I'm always open to suggestions...

In Topic: Representing an iso map in a 2d array?

18 September 2012 - 11:47 PM

Hmmm, interesting. Is that the general consensus?

I know in Starcraft 1, although it appears iso, it actually uses a square grid with square tiles. The Blizzard artists simply faked the iso. But in games that are "true" iso, with rhombus tiles, are you saying they use an extra large tilted array with thousands of unused cells?

In Topic: A* jaggard lines?

18 September 2012 - 10:02 PM

Not in Multimedia Fusion 2. The closest would be a string array, in which you would convert the float to a string before you store it, and then back to a float when you retrieve it. Obviously, this is not very efficient.

But, now I've solved the problem, I will re-write the code in c++, although that would have worked from the beginning. Silly integer arrays!

In Topic: A* jaggard lines?

18 September 2012 - 01:17 PM

VICTORY!

I re-implemented A* from scratch and found the problem!

I am using a 3d array to store the G, H, F, ParentX and ParentY values for each tile during the search. But the thing is, in Multimedia Fusion 2, arrays are unable to store floating point values. All non-whole numbers are rounded down to the closest integer. The Heuristic is rarely a whole number and that was the direct cause of my A* blues.

My solution was to use a cost of 1000 orthogonal and 1400 diagonal as opposed to 10 and 14 allowing for the equivalent of 2 decimal places of percision.

However, if you examine the G, H and F values for each square, you will notice they don't quite match 1000 and 1400. This is because I am multiplying every G value by 0.9925 and every H value by 0.0075 to break the tie between F values which would otherwise be the same for multiple tiles. This causes A* to favour tiles which are closer to the target.

Posted Image

Thank you everybody for your help.

Posted Image Yarrr! Until next tyme me hearty!

In Topic: A* jaggard lines?

18 September 2012 - 01:27 AM

Thanks Jefferytitan,

The formular for xadjusted is correct, but the yadjusted is a little off.

Posted Image

Both red tiles are 2 below the yellow tile. But, according to your formular, the leftmost tile is 3 below (2 - 5 = -3). However, I noticed a correlation between your two formulars, and this works:

x adjusted = x - floor(y/2)

x distance = (A.x - floor(A.y/2)) - (B.x - floor(B.y/2))
y distance = (A.x - floor(A.y/2)) - (B.x - floor(B.y/2)) - (A.y - B.y)

So, using pythagoras, I calculated the correct Euclidiean distance, but the strange thing is, it hasn't changed my paths. They still favour the same long straight lines shown in my original screenshot (in dark red). I've decided the staggered iso grid only adds an extra layer of compexity to my problem, so I will re-write the code for a square grid and see if I can achieve my desired zig zags there.

On a side note, Jefferytitan, you mentioned my staggered grid is unusual. The alternative of a titled square grid means that if I want the entire screen to be filled with tiles, then some squares with have negative co-ordinates, shown below (the top left and bottom left white regions).

Posted Image

And seeing as there are no negative array cells, this was not an option.

Thanks again! I'm open to all suggestions.

PARTNERS