Ashley's Forum Posts

  • No. There are no fixed limits in Construct 2 as far as I can remember, you can generally just keep going until you run out of memory.

  • Please, if you have this problem, report it to the bugs forum following all the guidelines.

  • troublesum - based on those log messages it doesn't look like you're using the official Multiplayer plugin. Are you involving your own code or library there? I never saw that issue with the official Multiplayer plugin.

  • Note the front-to-back render doesn't actually draw any pixels to the screen, it only fills a depth buffer. The back-to-front renderer is still necessary for anything to appear on-screen at all.

  • My last post was kind of wrong actually, I found out about a technique that does make it possible to partially render front-to-back. It's possible to do two passes: a front-to-back pass that basically fills opaque areas in a depth buffer, and then a normal back-to-front pass that skips overdraw in the opaque areas.

    The problem is my early experiments have shown so far that it does not really make a big difference to performance, which is especially disappointing because it involved lots of work It might be that I did something wrong, I don't know. I'll probably release it experimentally in the next beta cycle anyway, and just see what people say about it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Construct 2 only minifies c2runtime.js, not any other script files, so the sfs2x_api_js.js file in your picture will not have been touched by Construct 2.

    If code in c2runtime.js refers to the external script, those terms will also be minified unless you write code which is compatible with Closure Compiler's advanced mode. This is all documented.

  • Our own data vindicates what we've read elsewhere: about 90% of users can successfully make peer-to-peer connections. So actually most users can make connections, and a minority cannot.

    The main reason the minority cannot is because of stupid network-address-translation (NAT) middleboxes on the Internet. Basically IPv4 addresses more or less ran out years ago, and the workaround is to hide multiple separate devices on different ports behind a single IP address. The NAT box figures out which ip:port combinations go to which devices. However there are lots of ways of doing this, and not all of them allow direct peer-to-peer connections.

    In principle, peers ask a STUN server for what their ip:port looks like from the outside Internet, because they don't know themselves when behind the NAT. Basically it's a simple "tell me my IP address" request. The STUN server sends it back, the signalling server exchanges the ip:port for each peer, then they try to connect to each other. However here's an example of one kind of particularly annoying NAT: a large office where say 1000 computers are actually hidden behind not just one IP address, but 5 different IPs, which are chosen semi-randomly for each connection. So a peer from that office asks the STUN server for its IP address, it returns one of the 5 IP addresses, that is sent to another peer, then it tries to connect to them but the NAT chooses a different IP out of the 5, and the connection fails. There are a few other kinds of NAT that break peer-to-peer connections in similar ways.

    You can work around this for the 10%: run a TURN server. This is just a relay - both peers connect to the TURN server, and the server forwards data between them. That brings the total connection success up to something like 99%, but then you have to pay the bandwidth bills for everything running through the server. We already pay hosting fees to run the signalling server and we do that for free, but racking up bandwidth bills for actual gameplay data is a bit beyond what it's sensible to offer for free. So if you're worried about the 10%, you can run your own TURN server.

    Another good workaround is run the host on a dedicated server which is not behind NAT. That should also work for a wider audience since some problems come only when both peers are behind NAT, but it still costs money.

    That's all more to do with the architecture of the Internet than WebRTC, HTML5 or Construct 2. Native apps are affected identically AFAIK, because it's the same network they're connecting through. This is why we need IPv6!

  • The same as you would with WebStorage: fetch each value, then compare them.

  • I think different browsers may take a moment to realise there is an update. Since it loads everything from disk when coming back a second time, everything loads more or less instantly, while it checks the appcache file in the background to see if there is an update. So the game may start with "not downloading update" state, and then after a moment change to "downloading update" state. So this event:

    3) Browser | Is NOT downloading update -----> System | Go to Layout 2

    ...likely switches layout before the browser has found out there's an update, and then the "is downloading update" condition becomes true while on Layout 2, which I'm guessing you're ignoring.

    I'd just start the game on the menu, and if it detects an update, jump to the progress layout. You could make the jump less obvious by having a black screen fade in, a brief logo on startup, or something like that.

  • In 1st case we will have 1 instance of sprite object with, for example, 3 different animations, and in 2nd case we will have 3 sprite objects instances instead, which with 1 different animation. So the question is wouldnt it take the same amount of memory?

    Only if everything is loaded in to memory at once. Option 1 forces the engine to load everything at once. Option 2 allows it to only load say one of the three objects if that is the only one being used.

  • No, you just need to install the latest version of Construct 2.

  • NW.js v0.13 is based on Chrome 43, so hopefully that will be the end of it...

  • Old versions of C2 use a different export format for the old version of the Scirra Arcade which did not include c2runtime.js. The new arcade works differently, but to export for it you must have the latest version of C2.

  • "Compare value" is the same thing as "Compare key value" IIRC. "Compare key value" is a confusing name because it mentions both the key and the value, but it really only compares the value.

  • The fact the layout-by-layout texture management works by loading entire object types in to memory (all animations, all frames, per object type) is a good reason to go with number 2. If you use number 1, you can only either load all the images in to memory, or none; with number 2, only the objects used on each layout are loaded in to memory.