Ashley's Forum Posts

  • Thanks, should be fixed in the next build.

  • The manual is wrong in this case, so I've updated the manual. -1 is the correct "raw" value; it's the plugin that multiplies it by 100 when returning the value with the non-raw expression.

  • Closing as won't fix. It's true the getPairedInstance() call does not match up the correct instances in this case. However it's to do with the fact the action takes an object parameter instead of relying on the normal event engine pairing. If you use either the ordinary 'Set position' and pass Sprite.X, Sprite.Y, the pairing works; alternatively just add 'For each Sprite' above the clicked condition. We won't add that workaround code because it would need to be applied to any action using an object parameter, and applying it to just one action would introduce an inconsistency in the engine.

  • Thanks, should be fixed in the next build.

  • The collision check conditions only need to be the first condition that picks for that object type. (It's just easier to phrase the advice as "make it the first condition".) You can actually have any number of conditions either in the System object or unrelated object types, so long as the first condition in the whole event branch that picks from that object type is the collision check event - then it still uses collision cells.

    You can still get away with picking instances before the collision check, as long as you pick a few instances. For example:

    + Sprite: pick a single instance

    + Sprite: test overlap with Sprite2

    -> actions

    This doesn't use collision cells, but only needs to collision check a single instance, so is fast anyway. However if you did:

    + Sprite: pick 1000 instances

    + Sprite: test overlap with Sprite2

    This doesn't use collision cells and forces 1000 collision checks. If you put the conditions the other way round it would likely have done fewer collision checks based on objects in the same cell. Whether or not you can get away with this depends on how many instances you pick and whether it's less than the number of objects in the collision cell, which is pretty hard to estimate. Therefore the recommendation is to always put the collision check first, since it removes the worst-case possibility of forcing a large number of collision checks.

  • You should report any issues to the Wine developers; it's not our responsibility to fix them.

  • Just to note I noticed yet another Safari on iPhone bug when changing orientation. Sometimes when you go landscape there's a weird grey bar at the bottom of the screen. It seems whenever a new iOS update comes out there's a new viewport bug in Safari. I found a workaround and the next build fixes it.

  • Well if you want something now, a commercial-grade native exporter is certainly not going to happen overnight either.

  • Yes, you should report them as bugs to Mozilla and Google.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • As far as we are aware audio works just fine on IE9+. The most common reasons audio doesn't work after publishing is that you either forgot to encode or upload all the sound files, or your server MIME types are incorrect (described more in the manual). If it works in preview mode this makes it very likely to be to do with your server.

  • The Browser object handles actual audio playback and is responsible for keeping parallel tracks in sync. Does this happen in all browsers?

  • Construct 2 doesn't detect it, the browser does. For example open the browser console in Chrome (ctrl+shift+J) and you'll see status updates as it checks for an update and downloads one if it is found.

  • Please report issues like this to the bugs forum following all the guidelines (and note bug reports must not contain third party plugins).

  • Oh, and Arima - you argue "there's too much uncertainty", but with a native port you'll have uncertainty over supported features instead. As I said before, a native engine is not going to be a magic bullet where everything works perfectly, it will tradeoff performance for other porting incompatibilities.

    I also absolutely cannot see why examples of single bugs like memory management is an argument for the extraordinarily expensive and time consuming development of native engines. It is *obviously* much easier to fix those problems first before even considering it. This is an ongoing work in progress, but we will get there.

    With modern devices with an up to date browser and OS, performance is already outstanding: as I said before my Nexus 5 can outperform some of the desktop machines in our office on some benchmarks. There's an argument to make a native engine to support older devices, but a native engine could easily take so long to develop to maturity that the next generation of phones and software updates would have already filtered down and far reduced the problem. This already happened with desktop. I dread the idea that we spend a year holding up everything else to write a native engine, and then by the time we're done HTML5 performance on mobiles is not a problem. What a colossal waste that would be!

  • Sound events currently can only be fired during each tick, so assuming you're running at 60 FPS there's up to a 16ms error. Apart from that there should be no drift. However three timer behaviors effectively means you're keeping three separate times, when you want one audio clock - try basing all audio timing events off just 'wallclocktime' or some single source like that.