Ashley's Forum Posts

  • The problem is browser layout performance. I already described it in some detail in those earlier linked issues and pointed out some related Chrome bugs that have been filed, so I won't repeat all that here.

    Collapsed events/groups don't do layout for their children - so if you tend to keep most things collapsed and only expand the content you're working on, it should be faster. Additionally spreading content across different event sheets will also help. In the longer term, most browser vendors (including Google) are currently in the process of completely rewriting their layout engines to be faster, more powerful and more flexible. I think this will do a lot to help once they start shipping the various parts of that. Keep an eye on LayoutNG for updates on Chrome's side.

  • Nepeo don't backups to the "Browser" location also go in IndexedDB? The only thing I can think of that would get clogged up with gigabytes of local storage is if there are endless local backups that aren't being cleaned up. Additionally I've no idea where the OK dialog with the "serialized value too large" error message could come from - it looks like a dialog that simply displays the contents of an error as its message, which we should avoid (it makes no sense to the user and can't be translated). In fact if people are saying it appears randomly, maybe that's the backup timer kicking off at periodic intervals...

  • See the manual entry on expressions for a comprehensive list.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I think the difference will be negligible if there are only a few sprites, so you should choose the option that is easiest for your game design. As ever you can answer your own performance questions with measurements; if the options make any meaningful difference to performance then you can measure it, else it's not important.

  • The events are constantly true, so every tick you schedule a new 'Wait' with all those actions after them, which probably causes all the actions to conflict with each other. Try adding 'Trigger once' to the events so it only does 'Wait' once.

  • Are you using the latest release? The latest versions already group different objects on to the same spritesheet if they are consistenty used together on layouts across the project.

    Either way, it's a common mistake to put too much artwork in to one object - we've seen a number of cases where that was to blame for unnecessarily high memory usage, so it can definitely be a bad thing. Perhaps if you group a small number of large images together that can be a benefit, providing they're always all used together.

  • Taximan

    > To save memory you can group many objects in a single sprite

    I must say that it has already crossed my mind and I'm thinking about doing this. Although that would require some major changes to my event sheets. So you really had advantages with this?

    This is actually worse for memory management. Construct can only load or unload entire objects in to memory. If lots of objects are combined in to one it forces Construct to load everything, making it likely memory is wasted. If they are kept as separate objects there is better granularity to load some but not others, saving memory.

    But there is one thing I can't find info on is the Project property Max Spritesheet Size.

    It's only available on the beta channel at the moment. We only update the documentation when it makes a stable release.

  • FYI that is mentioned in the signalling server description:

    purchasing an SSL certificate to encrypt the connection to the signalling server, which improves connectivity for some devices

  • I'm afraid I'm not telepathic - the reason we have all the bug report guidelines is to ensure there's enough information to actually be able to help. If you don't provide that all I can do is guess, and if you don't like my guess, then I suppose I should insist on the full details set out by the guidelines.

  • However, some more insight into how Construct manages memory would be a great fit there.

    That's also covered in the manual.

  • See Performance Tips. This is up-to-date advice documented in the manual.

    I must note that people often make games that exceed the hardware capabilities of their device and then blame Construct. You can't do more than the hardware specifications of the device allow - no software or tool will save you from that.

  • The problem makes no sense. The trigger fires before changing the "is connected" state. I would guess this is simply a mistake in your events. I can't tell any better without more information.

  • The project is corrupt because the object "smfighter" has two animations named "Animation 10". I deleted both and it opens again - here's the recovered project: https://www.dropbox.com/s/ex33ca1sbuvch09/somari-recovered.zip?dl=0

    We definitely want to fix any project-corrupting bugs but there's nothing else we can do unless we know how it happened in the first place. If you can figure out a series of steps to create the problem in the first place, please do file a bug report.

    While working with that project I did come across another bug in spritesheet building... it may or may not be related to this case, but I managed to fix it for the next release. So you should probably wait until the next beta (r135) before continuing to work with the recovered project.

  • It looks like you define a function but never call it. So the code will never run.

  • No idea. My best guess is a third-party addon with a missing or unavailable file.