Ashley's Forum Posts

  • Closing, please follow the bug report guidelines. You need to provide exact steps to reproduce the problem as well as the complete text of any error messages.

  • CrudeMik - that is far too big a performance difference to be attributable to Javascript execution speed. It sounds like you're getting software rendering due to buggy drivers.

  • Construct 2 definitely does not blur moving sprites, but they might appear very slightly softer due to floating-point positioning with linear sampling. Pixel rounding or point sampling would fix that.

  • It's impossible to write software without relying on third parties. All modern software development requires relying on additional libraries written by other people. It is actually quite a difficult challenge to write some software that does not rely on any third party code, and it would look something like a custom-written OS that boots to a DOS-like prompt and would not really do anything useful. A native exporter would just rely on different third parties. In particular I'd anticipate buggy graphics drivers as a particular weak point of native platforms; browser vendors to a lot to work around driver bugs where possible in their engines, and where not possible the GPU blacklist ensures things at least work. (While the resulting poor performance can be frustrating, the alternative often means maddeningly mysterious crashes and glitches that can totally ruin the game, so slow but working is actually the better option.) Then there's OS fragmentation (very problematic particularly on Android), compilers/development tools to rely on, more OS-level libraries that may have various issues, and so on. So I don't really agree that a native engine relies any less on third parties at all; it just relies on different technologies, and that doesn't prevent you from getting screwed by the crappy work of some other vendor, graphics drivers being the perfect example of that.

  • We're not planning on supporting this during the beta phase, but we aim to make it possible some time after the stable multiplayer release.

    BTW our own signalling server is running on a dedicated server with a gigabit connection, so you'd have to have a pretty serious server to beat that.

  • Both Chrome for Android and Crosswalk should support WebRTC. (Crosswalk is a version or two behind Chrome IIRC so may take a while to catch up to the version that works.) It won't be supported in CocoonJS or Ejecta (neither are real browsers).

    Peer to peer connections can happen just fine through cell data - there's nothing special about that type of Internet connection, except it transmits by long-range radio instead of cables or wifi. However restrictive types of NAT are probably more common with cell providers. We did test the multiplayer object with a phone connecting over HSPA and it worked fine, with only 20ms extra latency, so it's perfectly possible. I don't know if it would work well having cell data working as host though, especially since cell data can be more unreliable. It's the kind of thing that it's hard for us to test, especially since cell data varies from country to country, so it's interesting to hear how it works for people round the world.

  • A "room" in the Multiplayer object doesn't have to correspond to a "room" or "zone" in your game. Why not just put everyone in the same room?

  • 1. I don't see why you'd need this from the Multiplayer plugin itself - it's designed to run the actual game, and if you want to handle data via a different server, wouldn't an ordinary WebSocket serve just fine for that?

    2. I don't understand why you need to be in multiple rooms at once for this. Why not do everything through the same room? For example the real-time game example runs both chat and multiplayer data in the same room.

  • Re: players unable to join host - looks like a possible browser bug, but it's worked around for the next build. It seems sometimes Firefox sends spurious blank messages which the host isn't expecting, but those can just be ignored. I think it might depend on the connection or NAT setup, since we've never had any issues with Ghost Shooter Multiplayer running on a dedicated server, but hopefully all will be sorted from r165 anyway.

    Re: node-webkit - not sure what the issue could be but it's a version behind Chrome (node-webkit is v32, Chrome is currently v33). Development is moving quickly and it's possible it won't work until node-webkit catches up with Chrome.

    Re: signalling server - the server crashed yesterday due to a bug. This is to be expected during beta. Being a weekend it took us a couple of hours to notice and restart it. We'll try to get some kind of auto-reboot set up so we don't have to have manual restarts with extended downtime, and perhaps publish a page with server status.

  • No issues here, and the stuff in your log is suspicious. Nothing beyond the "NoUpdate" line appears here, and those are strange domains in the log messages that are nothing to do with us or the game. Looks like a browser extension/adware/spyware is breaking it. Try disabling all addons in the browser and try again.

    • Post link icon

    I'm going to close this thread because it's turned in to a proposal for a competing commercial product, which I don't think is appropriate to discuss on these forums. tomsstudio and any other interested users should take this to another site.

    I also really want to emphasise to any users who may be interested in this that the technical challenge is truly extraordinary; consider Ludei have ~20 employees and a great deal of funding and struggle with this, and they still get to work with a Javascript engine, so they do not have the additional responsibility of porting all our JS engine code to another language. We regularly change our engine code as well, and keeping up with our weekly updates is likely to be full time work in itself, let alone other development. We have been making complicated but compatible algorithmic optimisations to our engine for years now; if another engine does not implement them all to the same degree of quality, it will likely still be slower than our JS engine in many cases, and if they are done incorrectly, they will break games. Finally maintaining compatibility with all features in our engine amounts to writing a new browser engine comparable to Chromium, which means competing with the might of Google's vast engineering resources. If I thought we had any chance of doing this ourselves internally, we would already be doing it; any third party who decides to try this anyway will have the additional hurdle of lacking our internal knowledge of how the engine works. tomsstudio, good luck, you will most certainly need it.

  • These days it should "just work", except that on iOS Safari and Chrome for Android music might not start until the first touch.

  • Most of the examples we see of poor performance on mobile are GPU-bottlenecked, not logic bottlenecked, so a native engine with faster logic wouldn't improve performance. If you have logic-bottlenecked games I'm happy to run them through a profiler and make any optimisations we can to the engine.

    BTW we've decided to force ignoring the GPU blacklist in node-webkit on Windows only in the next build. This might break games on systems with crappy drivers, but it may be that it's overall better than not having hardware acceleration on XP or Vista at all.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Thanks, should be fixed in the next build. The saved file does not appear to be affected thankfully, so you should be able to just close and reopen C2 to fix it.