Ashley's Forum Posts

  • There's probably no performance difference between 'Is overlapping' and 'On collision' if you immediately destroy the object, since it then doesn't require any tracking since it doesn't exist any more. However you probably want to use 'On collision' for correctness since it picks instances for individual collisions. For example:

    + On collision between A and B

    -> System: create explosion at A.X, A.Y

    -> Destroy A

    -> Destroy B

    Note the use of a system action. This always works like you expect: an explosion is created with every collision.

    + Is A overlapping B

    -> System: create explosion at A.X, A.Y

    -> Destroy A

    -> Destroy B

    This has a nasty edge case: if two different A-B pairs overlap each other for the first time in the same tick, it will run the event with both pairs picked. The system action then runs once, creating only one explosion (and the A.X, A.Y expressions will return the position of just one of the two objects involved). Both sets of objects are correctly destroyed, but you only got one explosion. You can fix that again with "For each", but then you may as well just use "On collision".

  • Closing, please follow the bug report guidelines: we can't fix bugs from watching videos. The multiplayer example is working fine here. This problem could easily be caused by your network configuration as well, and we're not hearing any other users reporting problems, so that seems likely.

  • 'On collision' does more work than 'Is overlapping', so it makes sense that it's slower. It's probably not obvious to you what the extra work is though. It has to fire once per pair of overlapping instances, and not fire again until they separate and touch again. This tracking work is pretty complicated and has to track things over time, since it has to remember if it's fired 'On collision' for an existing pair of instances that are already touching. On the other hand 'Is overlapping' just makes a collision check on the spot and doesn't need to remember or track anything.

    Both ways still use collision cells though so scale well to large layouts.

  • We haven't made any changes at all to the multiplayer engine for quite some time now, so it would be strange. Are you sure it's not your connection?

  • Post this to the Bugs forum following all the guidelines if you want it investigated.

  • I checked and the signalling server is running fine today (I had to reboot it for a Windows Update though so it was down for 1-2 min). Besides if you read the multiplayer tutorial you'll see that the signalling server is not involved in syncing objects, that is done by the room host.

  • Surely it's the results, not the tools, that matter? Maybe show them some of the top C2 games (The Next Penelope, Airscape etc) to show them what it can really do.

  • In general, enabling or disabling features depending on the browser is a very bad idea. You want to enable features depending on if the browser supports it, not if they are using a specific browser. For example suppose in 2012 you detected if the user was on Chrome, and only enabled Web Audio effects for that browser. Later Firefox adds support for Web Audio, and soon IE will as well, and you've unnecessarily crippled those browsers because you detected Chrome instead of Web Audio support.

    You can detect the browser based on the user agent string, but all browsers pretend to be all other browsers because developers keep making that exact mistake over and over again. For example IE now pretends to be Chrome so developers who wrote browser tests instead of feature tests get fooled and enable the features which IE also supports. This makes it pretty hard to actually tell which browser it is from the user agent string. It's possible, but then if you do so, you're making exactly the same mistake all over again!

    So don't do it. Think about the problem you are trying to solve and how to make it based on available features rather than the type of browser.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The save feature by design saves everything. I'm sure someone has an opposite use case where it is important to save the layout size.

    One workaround would be to enable unbounded scrolling and implement the scroll bounds through event logic.

  • I wrote about this topic in some detail in this forum post.

  • This won't get investigated unless you provide a .capx demo or at least a link to a working game. Please add some links. For anti-spam reasons the forum has removed links due to your low rep, so just post them again without the http:// or parts.

  • This thread is nearly a year old and the original .capx is nontrivial. Make a minimal demo in a new project, post it to the bugs forum, and I'll take a closer look.

  • A little more info on this change:

    For v-synced rendering the runtime calls a function to request the next frame (requestAnimationFrame). Previously the runtime would run its entire tick logic, and request the next frame right at the end of that. Now in r198 the very first thing it does each tick is request the next frame, then go ahead and process that tick's logic.

    This should in theory give the browser more time to accurately schedule frames. Consider an intense game where the logic takes 15ms. If the runtime requests the next frame at the end of the tick, the browser has just 1ms to schedule the frame in time. Now that the runtime requests the next frame at the beginning of the tick, it has the full 16ms frame to schedule the next frame in time. This could improve the predictability/stability of the framerate.

    TBH I don't know much about the internals of browser frame scheduling, and it's difficult to know for sure if this helps, so it was kind of an experimental change. It seems to be a good idea though and feedback seems to be either no change or positive, so I think we'll keep it!

  • Construct 2 has very good lossless image compression built in - see Construct 2's export-time optimisations. If you can get significant gains using some other tool, it's probably lossy (degrading the image quality).

  • Closing, please follow the bug report guidelines otherwise there is nothing we can do.