Unmanaged Sprites and hassel free sprite movement

Million Tile Engine
#1

With some of our logic running on a frame by frame basis we need to be able to make real time decisions related to position of our sprites within the mte world. So with this we really need realtime control over the player movements and transitions within the world. But retain the ability to query a sprites position as it relates to the various coordinate systems within MTE (i.e grid/loc, screen, ) and have the sprite still retain its relative world position when the camera is moved.

AT the minute MTE schedules repositioning requests and im finding this awkward to work around within my game ai.

it would also be very helpful to be able to optimise sprite movement by offloading our movement code to corona native apis.  but with this we would need direct control over those transitions so that we may register for events(like on complete) etc.

#2

Could you give me some more specific examples of what you’re trying to achieve?

You can already move sprites on a frame-by-frame basis with moveSprite(sprite, velX, velY), though this movement only actually happens when update() executes. I can see how this might cause problems. Transitions started with moveSpriteTo() can be ended with cancelSpriteMove(sprite). MoveSpriteTo also accepts an onComplete parameter for registering an event.

It is also possible to add a sprite directly to one of the layer displayGroups without calling addSprite(), by retrieving the group with getLayerObj(layer) and using it as the sprite’s parentGroup parameter. The sprite will move with the map, and you can use MTE’s convert() function to convert the sprite’s screen coordinates to level positions and location values. At the moment, however, this use is not well tested, and certain actions can break the synchronization between the unmanaged sprite and the map.

I’ve had people ask for this before, and it is something I would like to do, but it isn’t something I can whip up in a day.

#3

You can already move sprites on a frame-by-frame basis with moveSprite(sprite, velX, velY)

yes but with lots of moving sprites this can prove to be quite slow. (multiple function calls etc etc).

I think you may have answered my issue with :
 

It is also possible to add a sprite directly to one of the layer
displayGroups without calling addSprite(), by retrieving the group with
getLayerObj(layer) and using it as the sprite’s parentGroup parameter.

the question i have before i begin to test, is what type of synchronization problems are likely to arise from this?

#4

There are two situations where synchronization will break. First, calling goto() does not actually translate the display groups, and so the unmanaged sprites will not move to their new, correct positions in the map when a goto() is called. The initial goto() is of course not a problem because it is called before sprites are added. Looking at the code, this may be easier to fix than I originally thought. The code block responsible for moving managed sprites to their new positions starts at line 5025 in v0.918. It loops through the MTE array holding the sprites and moves each one. A quick and dirty way to move unmanaged sprites might be to loop through all the layer group’s children which are NOT a) tiles and B) managed sprites, and move those remaining children in the same way.

A second issue is related to layer scale. Using the reserved layer property “scale” to vary the scale of individual layers does not actually vary the scale of the layer group. If you add a sprite to a layer with a “scale” of 1.2, the sprite will move as if the scale were still 1 unless you adjust for this yourself. This problem does not effect mte.zoom, however, because that function does vary the scale of the whole parent group. This is a very old design quirk of MTE I’m planning to remove/correct in the future.

#5

I think that without the engine supporting parent display group translation, it can cause many problems to try to integrate unmanged sprites with native transitions when there is a lot of camera movement, this will perhaps result in more processing, than say just using the mte movement commands as each transition would have to have thier target and current position updated  for each step of the camera transition. this would mean pausing and restarting multiple transitions  in each frame.

#6

When you use native transitions, you are moving an object like a sprite in relation to its parent group. In this case, the sprite’s parent group is one of MTE’s layer groups. MTE’s camera movement functions translate each of these layer groups, which in turn causes all of their contents to move across the screen, but the relative positions of their contents do not change. If you put a sprite at x=100 in a group and move that group by 100 pixels, the sprite is still at x=100 within that group even though it appears to have moved across the screen.

The transition itself does not care whether its parent moves, or how many times. Its parent is its world and always appears to be stationary.

#7

i’m confused, I understand what you have said but unsure of how it relates to the context:

“First, calling goto() does not actually translate the display groups,
and so the unmanaged sprites will not move to their new, correct
positions in the map when a goto() is called. The initial goto() is of course not a problem because it is called
before sprites are added. Looking at the code, this may be easier to fix
than I originally thought. The code block responsible for moving
managed sprites to their new positions starts at line 5025 in v0.918. It
loops through the MTE array holding the sprites and moves each one. A
quick and dirty way to move unmanaged sprites might be to loop through
all the layer group’s children which are NOT a) tiles and B) managed sprites, and move those remaining children in the same way.”

is it that goto does not perform camera movement  the same way that the camera movement functions do?

#8

The camera movement functions do not call goto() unless the camera has to move more than blockScale * 4 in a single frame, and this sort of thing should not happen very often. However you are right that it would have to pause and update every transition when it does execute.

I am actually planning to rewrite much of the engine, and correcting for this limitation would be a part of that. The new systems will work equally well with managed and unmanaged sprites, and some of the MTE functions for retrieving sprite positions will become unecessary. For example, in the new system a sprite’s .x value will be it’s x position in the map. Calling sprite.getLevelPosX() will no longer be necessary. The new goto() will simply translate the  map to a new position, etc.

#9

aha, well, i think we will just have to work with what we have at the moment, we are getting ok framerates at the moment, and there are still oportunities at the application level to optimise further. one of the biggest increases in speed I found was to pool/cache sprite and physics objects. As adding/removing them is quite expensive.

what the plan in terms of timeframes for the rewrite?

/s

#10

Unfortunately the closest I can get is “by the end of the year.” It’s going to be one hell of a rewrite, and there are a few loose ends and user requests I’d like to take care of before the long haul commences.

#11

Could you give me some more specific examples of what you’re trying to achieve?

You can already move sprites on a frame-by-frame basis with moveSprite(sprite, velX, velY), though this movement only actually happens when update() executes. I can see how this might cause problems. Transitions started with moveSpriteTo() can be ended with cancelSpriteMove(sprite). MoveSpriteTo also accepts an onComplete parameter for registering an event.

It is also possible to add a sprite directly to one of the layer displayGroups without calling addSprite(), by retrieving the group with getLayerObj(layer) and using it as the sprite’s parentGroup parameter. The sprite will move with the map, and you can use MTE’s convert() function to convert the sprite’s screen coordinates to level positions and location values. At the moment, however, this use is not well tested, and certain actions can break the synchronization between the unmanaged sprite and the map.

I’ve had people ask for this before, and it is something I would like to do, but it isn’t something I can whip up in a day.

#12

You can already move sprites on a frame-by-frame basis with moveSprite(sprite, velX, velY)

yes but with lots of moving sprites this can prove to be quite slow. (multiple function calls etc etc).

I think you may have answered my issue with :
 

It is also possible to add a sprite directly to one of the layer
displayGroups without calling addSprite(), by retrieving the group with
getLayerObj(layer) and using it as the sprite’s parentGroup parameter.

the question i have before i begin to test, is what type of synchronization problems are likely to arise from this?

#13

There are two situations where synchronization will break. First, calling goto() does not actually translate the display groups, and so the unmanaged sprites will not move to their new, correct positions in the map when a goto() is called. The initial goto() is of course not a problem because it is called before sprites are added. Looking at the code, this may be easier to fix than I originally thought. The code block responsible for moving managed sprites to their new positions starts at line 5025 in v0.918. It loops through the MTE array holding the sprites and moves each one. A quick and dirty way to move unmanaged sprites might be to loop through all the layer group’s children which are NOT a) tiles and B) managed sprites, and move those remaining children in the same way.

A second issue is related to layer scale. Using the reserved layer property “scale” to vary the scale of individual layers does not actually vary the scale of the layer group. If you add a sprite to a layer with a “scale” of 1.2, the sprite will move as if the scale were still 1 unless you adjust for this yourself. This problem does not effect mte.zoom, however, because that function does vary the scale of the whole parent group. This is a very old design quirk of MTE I’m planning to remove/correct in the future.

#14

I think that without the engine supporting parent display group translation, it can cause many problems to try to integrate unmanged sprites with native transitions when there is a lot of camera movement, this will perhaps result in more processing, than say just using the mte movement commands as each transition would have to have thier target and current position updated  for each step of the camera transition. this would mean pausing and restarting multiple transitions  in each frame.

#15

When you use native transitions, you are moving an object like a sprite in relation to its parent group. In this case, the sprite’s parent group is one of MTE’s layer groups. MTE’s camera movement functions translate each of these layer groups, which in turn causes all of their contents to move across the screen, but the relative positions of their contents do not change. If you put a sprite at x=100 in a group and move that group by 100 pixels, the sprite is still at x=100 within that group even though it appears to have moved across the screen.

The transition itself does not care whether its parent moves, or how many times. Its parent is its world and always appears to be stationary.

#16

i’m confused, I understand what you have said but unsure of how it relates to the context:

“First, calling goto() does not actually translate the display groups,
and so the unmanaged sprites will not move to their new, correct
positions in the map when a goto() is called. The initial goto() is of course not a problem because it is called
before sprites are added. Looking at the code, this may be easier to fix
than I originally thought. The code block responsible for moving
managed sprites to their new positions starts at line 5025 in v0.918. It
loops through the MTE array holding the sprites and moves each one. A
quick and dirty way to move unmanaged sprites might be to loop through
all the layer group’s children which are NOT a) tiles and B) managed sprites, and move those remaining children in the same way.”

is it that goto does not perform camera movement  the same way that the camera movement functions do?

#17

The camera movement functions do not call goto() unless the camera has to move more than blockScale * 4 in a single frame, and this sort of thing should not happen very often. However you are right that it would have to pause and update every transition when it does execute.

I am actually planning to rewrite much of the engine, and correcting for this limitation would be a part of that. The new systems will work equally well with managed and unmanaged sprites, and some of the MTE functions for retrieving sprite positions will become unecessary. For example, in the new system a sprite’s .x value will be it’s x position in the map. Calling sprite.getLevelPosX() will no longer be necessary. The new goto() will simply translate the  map to a new position, etc.

#18

aha, well, i think we will just have to work with what we have at the moment, we are getting ok framerates at the moment, and there are still oportunities at the application level to optimise further. one of the biggest increases in speed I found was to pool/cache sprite and physics objects. As adding/removing them is quite expensive.

what the plan in terms of timeframes for the rewrite?

/s

#19

Unfortunately the closest I can get is “by the end of the year.” It’s going to be one hell of a rewrite, and there are a few loose ends and user requests I’d like to take care of before the long haul commences.