Jump to content

Disabling antialiasing causes my programmatic animations to be quite choppy


Uncomfortable
 Share

Recommended Posts

Hi folks,

I've stumbled a bit on this issue - I've had to disable antialiasing on my game (via the game constructor) in order to fix some fancy shader magic I'm using elsewhere, but I recently found that this caused some tiles that I have animating programmatically to become very choppy in their motion. I've got an example of what it looks like here, with the intended effect on the right (with antialiasing enabled) and the current state on the left (antialiasing disabled).

One thing this video doesn't do a great job of showing is that the animation on the character (dumpy walk cycle as it may be) is considerably smoother than the water tiles.

If it helps at all, I'm using the isometric plugin from http://rotates.org/phaser/iso/ and the actual code I use for the programmatic animation is shamelessly pulled straight out of their example. It's definitely way more complex than I need - I'll get around to rewriting it myself later, but it's been low on my list of priorities. For context, the isometric plugin just adds isoX, isoY and isoZ properties, which work in the same way. It is placed inside of the update function.

var waterSpeed = 2.5;
terrainGroup.forEach(function (w) {
    if (w.family == 'water' || w.family == 'default') {
        w.isoZ = (-1 * Math.sin((game.time.now / waterSpeed + (w.isoX * 7)) * 0.004)) + (-0.5 * Math.sin((game.time.now / waterSpeed + (w.isoY * 8)) * 0.005)) - 1;
    }
});

If anyone's got any ideas as to why disabling antialiasing is causing this problem, or if you guys know of any workarounds, let me know. I've got antialiasing disabled specifically because of the character there - I use a colour-coded version of the animated sprite to colour different parts of the body independently so I can customize its clothing on the fly using a simple shader. Antialiasing was causing the edges of this colour-coded sprite to shift in colour slightly, causing little gaps between the regions. So, if this choppiness isn't curable, if anyone knows of a way to get around that colour-shift without disabling antialiasing, that'd be helpful too (though even as I write it out, it doesn't seem like that's an option).

Oh, one last thing I forgot to mention - I'm using Phaser 2.4.6 at the moment.

Thanks!

 

Link to comment
Share on other sites

  • 2 weeks later...

I set this one aside for a while, then came back to it today and was able to find a solution after a lot of experimentation. There are still some things that confuse me about it, but I seem to have reached my two goals, which were:

  • Having a smooth rise/fall of my water tiles (they were quite choppy with antialiasing turned off)
  • Being able to use a filter/shader on my character that applies a dynamic selection of colours to the colour-coded animated sprite (antialiasing was messing up the edges of my colour-coded regions)

My solution in retrospect is quite simple and obvious, but it was very finicky. It involves disabling antialiasing as a whole, and setting the smoothed attribute of my terrain sprites to true. This alone did not work, however - the linch pin to the solution was not obvious at all.

My character is made up of a few individual sprites that are grouped together as children of another sprite. The parent container is an isoSprite (from the isometric plugin I'm using), and the children are regular sprites (because nesting isoSprites breaks due to a bug in the plugin). In order to fix my problem, I also had to set smoothed=true on my character container isoSprite, which frankly makes no sense to me.

After a bit more testing, I found that setting smoothed to false on my character container or my terrain tile isoSprites causes the problem to occur. That said, this is not the case with my trees, which are also isoSprites - none of them need to have smoothed set to true, and setting it to false has no adverse effects.

So, long story short - I fixed it, but I don't really understand why the problem occurred.

As a side note, I found that switching from WebGL to Canvas also fixed the problem with no further messing around, but this workaround did not allow me use filters. Still, might be useful to someone.

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...