@ivanpopelyshev yaay bug fixed ^_^ i'll post my code up somewhere now so you can see it

@ivanpopelyshev http://jsbin.com/zugopowixa/edit?output

that's not the best way of working with isometric map

it is kinda clunky.. how would you propose it?

the same approach i used on hexagonal map

got a link?

did you ever play chess?

yep

imagine a chessboard

now take only black cells (x+y)%2==0

that's centers of your tiles

points that have (x+y)%2!=0 are corners

that way map is actually rectangle and not something from Age of Empires :)))

X map coordinate is the same as on screen

Y is twice less

I used that approach in https://github.com/ivanpopelyshev/railways too, but code is difficult

it doesnt have tiles but basically its isometric

if you use rectangular grid many things will become very easy

you're rotating them

ok, let me draw it

45 degrees, yeah

which is what makes it isometric

part of it anyway

you see red grid? that's coordinates i use

points with (x+y)%2==0 are centers of tiles, while (x+y)%2==1 are corners

ah

so in tilemap you store only every 2nd point

*2nd cell

whats in (x+y)%2==1 doesnt matter

yes, thats 2x memory for tilemaps but that's not important :)

i understand the screenshot - but that explanation, i don't know why.. i just don't follow. doesn't the (x+y)%2==0 entirely depend on the size of the tiles?

ok, lets make (U,V) coords in tilemap

(u+v)%2==0 are centers, (u+v)%2==1 are corners

on screen X = u * half_tile_width, y = v * half_tile_height;

ah, right

and moreever

when my objects are something in-between of tiles

I use screen coordinates :)))

I just remember that distance between (x1,y1) and (x2,y2) is sqrt(sqr(x1-x2) + sqr((y1-y2)/2))

so my transition matrix from world coords to screen coords is trivial

I dont need to rotate it

so - the whole ignoring (u+v)%2 == 1 is only relevant when the screen coordinates are the same as in your picture. as they're stored now for the rotated map, it's the same amount of points as it is when you ignore half in your approach

true

i guess that's the biggest point

That's how I store them too :)

then the ignoring of (u+v)%2 == 1 is for an optimization so you don't end up with double the memory

no

we just dont create tiles for them

they are zeroes

its totally ok if your tilemap uses 2x memory

you dont need "rotation" at all

fair... it's easier to reference if the 0s are in there, since the x, y would match up with the tilemap storage indexes

yep

and that way whole map looks like a rectangle, not a diamond :)

you mean the storage of it? or the actual rendering

both

i like the drawing the way it is though

that's what i was aiming for

i mean that space between (0,0) <= (u,v) <= (width,height) where (u,v) are tile coords will look as rectangle on screen

and in your approach its a diamond

hmmm

do you know that many methods for tilemaps generation and other stuff are using both squares and diamonds?

not really that familiar with this area of things

its ok if your map is rectangle but tiles are diamonds

I worked with that kind of map in massiveassaultnetwork.com

i honestly can't think of what it would look like with rectangles..

looking for a google image currently

its only about code, render will look the same

that way you completely remove all problems with "ok, i know coords on tilemap, now, how can i find screen coordinates..."

or " now , what's distance between two points on screen"

right

isometric map is just rectangular map that consists of diamonds, and Y axis is scaled 0.5 times :)

you mentioned it was to do with rendering before, i got confused :p

its all about coordinate system.

also, I have that patch in pixi that wasnt accepted yet

with texture rotations and D8 group

D8 group is connected to rectangles-diamonds approach

Its a math that helps with all tile-based topologies

not the best explanation, but i'll write an article on that later :)

o.o

basically, its all rotations by 45 degrees

and reflections too

yep

If you look at tile (0,0) , its corners are West, South, East then North

of that point

In case of square tiles, its North-West, North-East, South-East, South-West

all that stuff can be rotated and reflected

something like that:

dx = [1,1,0,-1,-1,-1,0,1];

dy = [0, 1,1,1,0,-1,-1,-1];

dy = [0, 1,1,1,0,-1,-1,-1];

if point is (x,y) then its k-th neighbour is (x+dx[k], y+dy[k])

there is no way i'm gonna be able to remember all this, lol.. i'm gonna save this conversation to reflect on

in square tiles corners are obtained by odd k , in diamond by even k :)

yep, that's difficult to grasp , but I hope i'll teach people that stuff :)

it saves a lot of time

and reflections. I love reflections i dont know why people arent using them. probably because they are too hard

please try to switch to rectangular coordinates :)))))

dont be greedy, tilemaps will be only 2x times bigger

yeah, i'm not worried about the memory use. i'll probably switch over - but it'll take some doing as i didn't write the tile creation code currently, lol

though now that i've got the stuff working the way i want, i may just re-write it so it's in my own style

thanks for taking the time to explain it to me ^_^ it definitely helps to understand the concept explained with diagrams and whatnot

any tile in gameofbombs can be rotated or reflected. And portals are following that logic too :)