Arima's Forum Posts

  • I think what you want are families. They're basically a group of objects that acts like an object itself, meaning you can also give the family a variable, resulting in all of the group's objects getting that variable as well.

    That way you can check the variable for a bunch of objects with one condition.

  • An idea I had was to use the sprite bank and array plugins, dividing the area of the layout at runtime in a grid (by basically checking if environmentsprite x/y is within a square, then looping through all the grid sections in the layout) then saving all the objects in each section of the grid via the sprite bank plugin as a JSON string into a cell in the array.

    Then you can compare the location of the player and each time they move out of a grid section, create and destroy objects that are in/out of range.

    I haven't tried this yet, and it might be more complicated than it sounds, but it seems like it should work.

  • Please keep it to one thread, thanks!

  • Yeah, keep in mind that the 1st gen ipad only has a mere 256mb of ram that's used simultaneously by the os, cocoonjs, images and sounds (which take a lot more space in ram than they do on disk because they have to be decompressed), so it's not much to work with!

  • Please stick to English on the forums or provide a translation, thanks!

  • Another issue is that cocoonjs doesn't yet support retina mode on iOS devices, if that is in fact what you're running. They've announced it's coming in an update though.

  • You do not have permission to view this post

  • Objects using delta time, like behaviors, can do things like "jump" through walls when the framerate stalls, because movement is basically a series of teleports that happens every frame. If the framerate gets too low, as delta time results in pixels per second moved, the gaps between "teleport locations" can jump entirely over obstacles, meaning the collision detection doesn't catch them.

    The easiest solution to this is to set a minimum (or maximum, I can't remember how it's labeled at the moment) dt in the project properties (I think it's under some advanced section). Set it to something no higher than 0.1, and if the framerate stalls lower than 10 fps, the gameplay will slow as well, preventing the player from jumping through obstacles.

  • Yeah, I guess I was thinking a popup could appear explaining that the original had been deleted, but you're right about duplicating them, I hadn't thought of that. I guess it is better the way it is.

  • We might eventually add something like mesh distortion from Classic back in, but it's a very complex feature to get right. Users expect the collision mask is distorted the same way and so on, and used incorrectly it can cause performance problems too.

    Very much please add this feature! Even with the collision mask not distorted with the image, it's very useful and awesome and I utterly loved it in CC. I also found ways to make my own distorted collision mask using invisible sprites.

    What do you mean by "used incorrectly" though? For reference if it ever gets put in, so I can know what to avoid.

  • Ashley - what about having copying and pasting them work as well, so when you paste the previous global is deleted, and the removing/reappearing of code part doesn't have to happen? It's a little nerve-wracking to have the code relating to it disappear.

  • You could also do something like have all the real gameplay sprites running as normal but made invisible, then every x seconds or ticks update the locations of visible display sprites. Or use rojohound's canvas plugin and paste to that every x seconds or ticks. Or even possibly turn off the background for all the layers, set it so c2 doesn't clear the background, and then make the gameplay layers visible every x seconds or ticks instead.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Collision checks are two tiered - first there's a simple bounding box check, then if there's an overlap, it does a second check using the collision polygons of those picked instances.

    You can reduce the collision checks by setting conditions to filter out some of them beforehand. Such as:

    Sprite.variable=1

    Sprite overlaps sprite2

    • rotate sprite

    Then only the sprite instances with variable=1 are checked, saving performance.

  • I haven't tried it, but you might be able to achieve this by checking the device's orientation by comparing if windowwidth>windowheight and change the layout angle accordingly.

  • On mobile, I have found that performance is actually worse if objects are rotated. Not sure why.