Manipulating mesh and contentWidth/contentHeight is not updating

Solar2D Advanced Graphics
#1

Bug or normal behaviour?

I’m working on a racing game and using meshes for my road tiles.

The good thing is I only need one texture, just manipulating the mesh to make curves, and I’m very satisfied with the results.

The bad thing is, once manipulated, the mesh will display correctly, but contentWidth and contentHeight remain the same.

ex:

|     |                   \     \

|     |                     \     \

|     |                      |     |

|     |                      |     |

The width of the curved road tile should now be greater than the original one.

It means that when the mesh is about to go off screen, it will be culled even if a portion is still visible on screen. The result is parts of the road near the edges of the screen will just disappear, and it’s bad.

Should I look for another way to draw my road tiles (like one image for each curve), or is it just a bug?

#2

It’s a documented behaviour, even though not a good one - I have mentioned it in previous discussions but not written a full “bug” report and/or feature request as I wanted to write a bigger request because the mesh interface could benefit a lot by a few more, pretty simple to implement API features (I really should sit down and write a proposal as I use meshes all time).

A reasonably simple workaround that I use, is to just create your initial mesh with 4 vertices displaced into positions marking the maximum dimensions you might change the mesh of your roadtile at any time. Then create the mesh and set these 4 vertices to their correct position. This, of course, will result in slightly less optimal culling but that’s hardly an issue.

#3

Since you know the real width of the adjusted mesh, could you use those measurements to keep the curve “on screen”

adjustedWidth = width + mesh adjustment

then use adjustedWidth for object placement

Something like that?

#4

Thanks Michael, I did a quick search last night but found nothing. I’ll try your workaround, it will certainly work in my application.

sporkfin, I don’t think it would do the trick. It would work only if the background is static, or always moving in the same direction, which is not the case in my game.

The problem with resizing a mesh is like scaling a physic body. It will display as expected, but the physics calculations are still based on the unmodified image. So if you offset the image to get accurate collision on one side, collision detection is getting worst on the other side. Since I use large meshes, the problem is just more visible when the Corona engine cull the image when it’s not supposed to do it.

#5

It’s a documented behaviour, even though not a good one - I have mentioned it in previous discussions but not written a full “bug” report and/or feature request as I wanted to write a bigger request because the mesh interface could benefit a lot by a few more, pretty simple to implement API features (I really should sit down and write a proposal as I use meshes all time).

A reasonably simple workaround that I use, is to just create your initial mesh with 4 vertices displaced into positions marking the maximum dimensions you might change the mesh of your roadtile at any time. Then create the mesh and set these 4 vertices to their correct position. This, of course, will result in slightly less optimal culling but that’s hardly an issue.

#6

Since you know the real width of the adjusted mesh, could you use those measurements to keep the curve “on screen”

adjustedWidth = width + mesh adjustment

then use adjustedWidth for object placement

Something like that?

#7

Thanks Michael, I did a quick search last night but found nothing. I’ll try your workaround, it will certainly work in my application.

sporkfin, I don’t think it would do the trick. It would work only if the background is static, or always moving in the same direction, which is not the case in my game.

The problem with resizing a mesh is like scaling a physic body. It will display as expected, but the physics calculations are still based on the unmodified image. So if you offset the image to get accurate collision on one side, collision detection is getting worst on the other side. Since I use large meshes, the problem is just more visible when the Corona engine cull the image when it’s not supposed to do it.