Pixel inaccuracy

[lewster32]

There seems to be an issue that as far as I can tell is not related to the projector which is causing awkward and inconsistent rounding of pixel art. The problem may be related to anchors (both sprite and the projector offsets) the dimensions of the assets used, screen positions or some combination of all of these factors.

[rdzar]

Is this the same problem as below?

And less-visible colored tiles from above;

[rdzar]

Also, as it seems the cos transform is just way off. It seems a cause of the projectionAngle implementation from what I've found. Why didn't you choose for the basic isometric math if I may ask?

http://clintbellanger.net/articles/isometric_math/

[rdzar]

Written some code that corrects the transforms (round down the X and corrects Y with rounded X part). It works pixel-perfect up to 225 tiles (shown below is just 100 tiles)

From 225 tiles up, it starts to do the same over again, because of the Y not being correct. I'm able to modify it a bit to make it possible, but I'm wondering if you agree on apply'n a correction to the transforms or better modify the isoSprite to allow tile-w/h so we could make the tiles render based on the tile width/height instead of the projection angle.

[lewster32]

Originally I had a basic isometric projection implementation, however it only worked for pixel art style isometric projection. The newer, more complex approach correctly projects, however I have a feeling that maybe the accuracy of JavaScript's Math.atan(0.5) result may not be enough to support large tilemaps. There may need to be an alternate way of calculating the isometric projection when explicitly wanting to use pixel art...

[rdzar]

Ah, that sounds like a logical explanation I didn't think of yet! Awesome! The projection is somewhat correct as you could see in the first image, with some corrections it's already way better for med-size maps. I could go that road if you'd like? :)

[lewster32]

The alternative may be to try the old projection code - the commit where this changed is here: 01819fe31bfe8c25214395b5b78086fc30a06039

[orangeswim]

Is this still an issue? I don't notice any pixel issues. Screen shot of http://rotates.org/phaser/iso/examples/interaction.htm

[lewster32]

As far as I'm aware this is still an issue (certainly there has been no further work on it) though maybe some of Phaser's recent changes could have fixed the rounding errors?

[nouknouk]

I had the same kind of issue.

If I understood well (and I'm not sure I did):

• the isometric plugin is following the (mathematical) way an isometric projection is computed: with an initial angle, the x and y projection factors are computed.
• but the 'isometric' projection in video games is not exactly an isometric projection, it's an APPROXIMATE one: for convenience (and computation's complexity), an single (integer) factor between x and y coordinates are used (typically 2:1) ; it would be something like a 'variation of a dimetric projection' ; cf wikipedia "Isometric graphics in video games and pixel art"

In the plugin, the projection values are computed with cosinus & sinus of the projectionAngle the property projectionAngle is setted:

`game.iso.projectionAngle = Phaser.Plugin.Isometric.ISOMETRIC;`

... which does internally (in haser.Plugin.Isometric.Projector#projectionAngle):

`this._transform = [Math.cos(this._projectionAngle), Math.sin(this._projectionAngle)];`

... and results in:

`game.iso._transform = [ 0.8660254037844387, 0.49999999999999994 ]`

To fix it, I bypass it by setting manually the values stored in the (private) variable '_projector' with a hardcoded 2:1 factor (actually 1.0 : 0.5):

game.iso._transform = [1.0, 0.5];

The result looks better:

Hope it helps !

Note: you'll find below the tile sprite used in my examples (a 64x32 tile):