oosyrag's Forum Posts

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • I feel that using 1 less noise calculation could be very beneficial for performance in the long run.

    Not much to do with performance. Using the same set of inputs for different noises mostly just looks more readable on the event sheet for your own sanity.

    But you could try changing the seed using set seed instead of offsetting the input values.

    One of the few places it would matter is for cellular and Voronoi noise, since they correlate to each other at the same inputs.

  • Here's an example project with the basics - dropbox.com/s/4q45kbokanulfvo/LayoutsAndDoorsExample.c3p

    The key components of doors and portals are:

    1. Where are you going - Usually stored as an instance variable in the door. This is used to change to the correct layout.

    2. Where did you come from - Can be stored in a global variable or an instance variable in the player object. This is used for positioning upon entering a layout

    Optional - A second instance variable identifying door pairs if you have multiple doors that go between the same layouts.

    3. Active state - A triggered state so you don't "bounce" back and forth between doors. You can use a timer like you had (not recommended), user input (what I had in the example), or offset the destination/spawn location per lionz suggestion.

    I use a single object for all doors, considering they are all functionally the same. If you want to have multiple objects for doors, then put them all in the same family and use the family object for your event sheet logic to keep it just as clean.