Jump to content

game-dev-monkey

Members
  • Posts

    9
  • Joined

  • Last visited

game-dev-monkey's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. I think this thread might help you - Particularly the part about in regard to sensors
  2. Thanks so much for that. So that means if I have multiple pools for different types of sprites that all need to be layered on a given Group that I am using as a display object container, when I kill them I need to return them to the appropriate pool. Or it makes sense to have them all in the same Group and use a key of some sort to get the appropriate type of sprite. In that case I'd have to use forEachDead to check for the appropriate key when getting a new sprite from the children. So this does seem like it might be the reason for the split, by what you just said. Or would the children of the DisplayObject container still be used as the collection of pool sprites? The reason I was asking about add and addChild is because I was trying to determine if there was one or two arrays used for pooling/display tree. With only one array which is the children property of the DisplayObjectContainer, they are one in the same. Thanks so much again for pointing me to the code. Should have done that in the first place. I think I am going to go with a Group that has all different types of sprites so I can order correctly. So I'll need to write some code to grab sprites from the pool based on their key.
  3. Sorry to bump this, I won't again if no one answers. But hoping to get some clarity on the intended usage for add and addChild. I notice that Pooling being abstracted from Group is a potential feature for next update, is this the reason why?
  4. I believe that was deprecated at some point, check out http://phaser.io/docs/2.4.7/Phaser.ScaleManager.html#setGameSize
  5. I understand that a group functions as a pooler as well as a DisplayObject container, but I want to make sure I am understanding this correctly. If I use addChild, am I only adding the sprite to the DisplayObjectContainer? For example : I create a group called enemyPool for my enemies for the purpose of pooling I create a group called gameLayer that I intend to use as a DisplayObjectContainer for all my active sprites in the game If I get a sprite from the enemyPool and then use addChild as follows : gameLayer.addChild(sprite); Am I correct in assuming that the sprite still exists in the enemyPool for the purposes of pooling? Am I also correct in assuming that the sprite exists as a child of the enemyLayer DisplayObjectContainer , but is NOT a part of that group in regards to pooling? If so, does the children property contain group members or DisplayObjectContainer children? Is there a property that contains only group members? The group members that would be used for forEachExists() and other iterating methods? Or.... Am I completely understanding this topic incorrectly and the add(child,silent) and addChild(child) method essentially the same thing?
  6. I guess it's not gonna get fixed, based on what I just read. Kind of a shame.
  7. Does it have screen sharing? I couldn't find it on the feature list on their site. That's a feature I use often with Skype.
  8. I have a group of clouds and from what I understand groups work like sprite pools, but also their creation order specifies the render order in the scene. I have 4 groups that I use for layering : backgroundLayer playerLayer foregroundLayer UILayer I have a cloud group that has my clouds an it's currently a child of my backgroundLayer so the clouds get rendered behind the player. The issue is that is some situations I want to have clouds in foregroundLayer. what is the best way to handle this? 1---> Should I have two groups of clouds, one for each layer? 2---> Or should I have one cloud group and add a cloud to the appropriate layer when needed and then when killing it move it back to the cloud group so that it's back in the pool I am spawning from? #2 seems messier, but only requires one cloud group.
×
×
  • Create New...