Colludium's Forum Posts

  • Have you read the manual entry on this?

  • Because when you resize an image the pixels are averaged according to the change in size / ratio and their neighbors influence the calculation - pixels at the edges don't have neighbors on one side... Create a sprite of, say 32x32 pixels and fill it with a pure color. Resize the image to 8x8 and see the compression effect on the edge pixels. I have no idea what random image you downloaded and so cannot comment....

  • That depends on whether or not you've incorporated cryptography into your app....

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Put all of your solids into one family and check for overlap with that family. You could even give the family the solid behavior... If you have some solid sprites and some solid tiled backgrounds, though, you'll have create two families because these types of object cannot be contained together in the same family group.

  • Glad it works!

  • Spawn_count = Spawn_count + 1

    if Spawn_count = 5

    -- spawn object,

    -- set Spawn_count = 0

    or

    If object.count not= int(number / 5) then spawn object

  • It's a bit of a guess - it might require a string variable. Either Go to layout (by name) = str(Sprite.Exit) or even ""&Sprite.Exit.

  • I think I know why it's not happening as you intend.... (I'm a bit max'd by the color scheme ) As you have it, in the last condition group C2 is only considering the one thought object that was last created. So, just add a system 'Pick All - thought' at the top of that condition group. That will ensure C2 will pick from all of the thought objects that meet the subsequent conditions.

  • Psynaptik - Creating an object takes up system resource (albeit small) and doing so a number of times in one tick can cause a slight delay in the game play, especially on mobiles devices. By unnecessarily creating and destroying sprites you will kill your free memory pretty quickly and cause slowdowns. Imagine that the while loop example above has to loop 100 times before finding a suitable position for the enemy object. In the attached example, one function group moves a sprite 100 times per tick and the other creates and destroys 100 sprites per tick. There's no collision checking here - this is just an example of how much resource is required to create and destroy a sprite. Enable/disable each group and run in the debugger to compare cpu utilization.

    So, if you want to destroy an object on collision then it would be far better to create only one new sprite and then use a while loop as above to position it. The OP was asking about moving a sprite hence the answer was to move the sprite - which is also the most efficient on your memory.

  • Not an option - the container only lists the sprites that are associated with each other. You've still got to tell the physics engine how to connect them together.

  • I'd just be guessing - it would be better if you could post a capx example if possible.

  • The Is Overlapping triggers the event and Trigger Once ensures it acts only once. You want an overlap check for this because if you use a collision I think it might be possible for a collision to trigger when there is no overlap (I am not sure and could be wrong), I elect to use the same check for both conditions to ensure that the while-loop tests for exactly the same condition (and there is no Is Colliding check). The last thing you want is for the collision to trigger but then the move to fail because there is no overlap. The while loop then works until the overlap condition no longer exists - this could loop once or many times depending on the likelihood of an overlap for each random position change, so there will be a small cpu load associated with this - but as long as your player is not huge and there is a lot of free space then it should be ok. As soon as the enemy moves to a non-overlapping space the while loop stops because the other condition is no longer met.

  • Resizing is the problem - it's compressing/stretching the image and creating the line. I am not familiar with Photoshp's capabilities for making seamless tiles, so I can't help there - but there are quite a few free programs available that will properly create seamless tiles of any size for you (quick google search and loads will appear).

  • One way would be to put all of the rag doll elements into one Container. Then have a Function that is called when On Create RagDollHead is triggered (assuming RagDollHead is the parent of the container); you only then need to place/create the RagDollHead sprites on your layout and the Container will take care of the rest. In the On Create Function you'll have to code the positioning of the limbs and creating the joints etc, but you'll only have to code it once in your game.

  • I know you said that it's not a problem with the image - does this also happen if you insert the image into a tiled background? What software did you use to create the seamless texture and did you resize the output to fit into your sprite? If you resized it then that line could be an artifact of the compression.