Hi,
I’m generating tile edges at runtime and drawing them to a RenderTexture that overlays my Tilemap Layer. I just upgraded phaser from 3.60 to 3.70 and lines are now appearing around the edges of the drawn frames on the RenderTexture. Below are a couple of examples of how this renders:
Could this be a bug in 3.70? Using Image or Blitter game objects do not cause this problem.
Thanks.
I got the same issue, all my tiles in map display weird, character’s texture frame of the animation running wrong position (add or subtract 1 pixel)
Disable roundPixels in the game config. In these cases, the sprite/tile needs sub-pixel rendering for some reason.
So disabling roundPixels in the game config actually makes it worse:
In 3.60 I actually ran into this issue and set this.game_scene.cameras.main.startFollow(this.ship.sprite, true); which fixed the problem - this was using RenderTexture.
However, In 3.70, even using Blitters I need to keep this true otherwise the lines still appear, even if roundPixels is true in the game config. For Blitters to work, both my camera startFollow() and the roundPixel game config need to be set to true.
What could be causing this? My tiles (all of my art) have been created as vectors but I export to png, so all my art ends up becoming pixels anyway, right? I’m not intentionally trying to render something with sub-pixel data.
I’ve also tried to keep all my camera/player sprite (position, movement) at Integer precision, but I am using Arcade Physics so, maybe that’s not possible if I can’t force scene.physics.moveToObject() at Integer precision? After movement ends I can reposition the sprite, flooring the x/y values, but that doesn’t appear to help.
I’ve been trying to isolate the problem and recreate it to share an example, however, so far I’ve been unable to reproduce the problem.
Thanks for all the help!
Hi @rich
I believe I’m able to reproduce the problem with an example: GitHub - rb1147x/phaser-3.70-vs-3.60-RenderTexture
It looks like the edge frames are drawn with a 1px gap vs. what happens when it’s drawn in 3.60. Also, it appears to happen when using other game objects (which originally I thought was not causing the issue) - Image and Blitter are the ones I tried in addition to RenderTexture.
As a note, I use Haxe to generate JS, but I’m happy to port it back to handwritten JS if that makes the code easier to read.
Pretty sure this is two separate things here. If you roundPixels: false, then it will create Dynamic Textures exactly the same as 3.60 did. Should be able to confirm this by drawing something to a DT, copy the image off the canvas (i.e. right-click the canvas and ‘save image as’), stick it into Photoshop and zoom in and inspect the pixels. Then repeat with round pixels true. You can actually toggle it on the main camera (this.cameras.main.roundPixels = false) right before drawing to the DT, then turn it back on again after-wards if you want. Depends how you’re drawing to the DT though - if it’s a stamp/texture key then that will work, if it’s a texture frame it won’t.
Thanks for the suggestion. I was using rt.draw() to draw the frames from my texture. Switching to stamp() seems to have solved the problem, whether or not I’m using roundPixels.
I’m guessing the code to actually execute these functions is different from each other? Maybe because draw() can accept a large number of different entries? But still, why would draw() have this 1px gap thing going on when I try to draw a frame from my spritesheet texture?
Unfortunately, I still run into this issue if my camera (centered on my player sprite) is hitting the top or bottom bounds of my physics world - which is just aligned to the tilemap. Any thoughts as to why the lines would still appear if I’m hitting the bounds? scene.cameras.main.worldView shows rounded values (although I have no idea if that would be indicative of the issue 
). And, if I set the camera bounds beyond the tilemap, but clamp my player’s position to stay within the tilemap bounds, then the problem does not appear to happen, so I’m guessing there’s still something I might be able to do with the camera positioning when I hit a top/bottom bound?