oosyrag's Forum Posts

  • Here's the thing, your actions are different in either case. If you don't collapse the group (not necessary), you can see it clearly.

    Clicking an event (or group) selects the event and its sub events.

    Dragging an event will leave only the dragged event selected.

    This doesn't have anything to do with groups in particular, nor top level or sub level events. It will happen if you drag anywhere, from top level to sub or vice versa, and it happens with sub events as well.

    If you drag a group to the top level, then click it, it will select all sub events as well.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Set a global variable upon reaching a checkpoint.

    On start of layout, check if global variable is set. If it is, position the player object accordingly.

    Use Local Storage to persist across play sessions.

  • Hundreds of objects should not be an issue. With the perftest, my phone only starts losing frames at 100,000 objects and my computer at 150,000. And that's just from max frames per second, it probably wouldn't even be noticeable until significantly more.

    You should definitely isolate your events in scope though, there's no reason for any events to not filter out only the things they should be affecting.

    On that note, even creating/destroying hundreds of objects at the same time normally wouldn't cause any noticeable lag, so there was probably something else acting on it in that case as well.

  • While I'm not familiar with the tutorial you linked and I don't plan on spending hours watching it, I assume the swing speed of a sine based grapple would be based on the period, not the magnitude, which determines how far/wide the swing is.

    Granted if you've been using a constant period, then a larger magnitude will be faster as it has to cover more distance in the same amount of time. Anyways, wouldn't it make more sense to adjust the period based on your starting velocity instead? Then you wouldn't have to fiddle with the cycle start position either, which I'm guessing works fine if you follow the tutorial.

  • Use whatever size of tile of the tileset you like the look of and want to utilize.

    If you're creating your own assets, same idea. Are you happy with the look of what you can fit into 8 pixels, 16 pixels, 32 pixels, or whatever?

    Scaling doesn't really have anything to do with performance. What is worth considering is your total VRAM usage - higher resolution assets will use more VRAM, limiting the total amount of assets you can have in a single layout. It's still a huge amount available though, so you probably won't have to worry about that unless you're making a humongous game. Even then, you can use multiple layouts to manage your memory.

  • Your issue is not diagnosable with the information you have given. Try uploading a minimal project with only the problem.

  • You could just make your inventory layer invisible and add conditions to disable relevant events when it is not visible.

  • Modern desktops with dedicated GPU's generally have have 4-8 GB of vram. Mobile devices don't have dedicated VRAM, but I'd say they generally also have 2-4 GB avavilable. If you don't go nuts with huge levels with thousands of unique sprites, or giant sprites that span areas larger than your viewport regularly, you're going to be fine. Long animations can also be a source of heavy VRAM usage.

    If you see your estimated VRAM usage going up over 1GB, then you might want to reconsider your approach and think about optimizing.

  • Also try using a tiled background object instead of a sprite object.

  • Based on your video, it looks like you have the scroll to behavior on both your character and that box you stretched at the bottom.

  • Any parallax settings?

  • Also if you have loads of global variables, maybe you could use some other techniques to better organise them, like local static variables, use global Sprite instances with instance variables, use a Dictionary, etc.

    This is what you should really be focusing on... I think traditional programming wisdom also discourages using any sort of global variable that doesn't have to be a global variable.

    This kind of keyboard mapping probably belongs in a dictionary. Yes you lose autocomplete, but setting up controls should be a one time thing, and there's a certain point where dealing with a mess of global variables is even more frustrating as you continue working in the project and need to use globals for other things.

    Alternatively, you might want to reconsider your naming system, that could make things go a lot smoother in the future. Two approaches is to change from Detailed-General instead of General-Detailed, or to use much shorter or abbreviated "General" prefixes

    Don't worry about performance penalties for using subevents/groups. If you can't measure it, it doesn't exist. Also I don't know how you get away without using groups for a big project in the first place...

  • I'm not familiar with 3d noise at all, but it makes sense to me, since the noise distribution should be similar to x and y as it is on the z axis.

    If you map points on a sphere or cylinder in 3d space to correlate to points on a 2d plane (a monitor screen's pixels), then you'll have wrapping noise. A cylinder would wrap one way, while a sphere would wrap both ways.

    So the algorithms given should be answering "For each x/y pixel/position, where is the proper x/y/z position in 3d noise to get a value from?".

    Function part 1, mapping coordinates on a sphere or cylinder - input x/y, return x/y/z

    Function part 2, 3d noise - input x/y/z, return noise value

  • I put up a bug report, it's being looked into.