Ashley's Forum Posts

  • Arima - that would undo the optimisation that handles entire rectangles of tiles at once, and degrade performance. Imagine a 2x8 tile section with only four tiles down one side. Either you extend by 1px, cover up the seam, and then the unexposed part is rendered too far over, or you don't extend and there's a seam.

  • Roccinio - I have no idea what to tell you. The seams issue is a normal result in computer graphics and I'm not currently aware of any convenient workaround. Some engines don't even support sub-pixel positioning, so at least you can do that if you want in Construct 2, although it can have side-effects.

  • What makes you think a normal user who regards renaming a file extension as black magic is going to publish a rival game making illegal use of the same graphics?

  • The bottleneck is almost certainly the upload rate on the host. Our multiplayer plugin imposes no specific limit, but due to connection limits the service will seriously degrade after a certain point (which will depend on the connection).

    The problem is the host has to send data for N players, to each of the N players. So if each player needs say 10 bytes of data, then each message will have a size around N * 10, and then that message will have to be sent N times. This creates an N^2 bandwidth requirement. For example:

    10 players = 10 * 10 * 10 = 1000 bytes per update

    20 players = 10 * 20 * 20 = 4000 bytes per update

    30 players = 10 * 30 * 30 = 9000 bytes per update

    ...

    100 players = 100,000 bytes per update

    As you can see even though the player count increases linearly, the bandwidth requirement increases proportional to the square. This means even with a significantly more powerful server or a much more compact update, it won't get you many extra players.

    The engine sends updates 30 times/sec by default, so the last case takes 3mb/sec up. Note then also that if the server has a 5mb/sec up capacity, then it will take 600 ms to send 3mb of data. This adds latency to every player. The game would likely become unplayable long before it was adding an extra 600ms of latency.

    So not only do you need lots of bandwidth for lots of players, to keep it responsive you need to significantly over-provision the bandwidth - say, by 10x.

    It's possible to make very large games with spread-out players able to send data only for nearby players (e.g. MMORPGs). This is one workaround which we might look in to with our engine.

  • Early versions of IE11 had bugs with some WebGL shaders, but the latest version should be OK. Check your system is up to date.

  • Maybe you want to use the existing support for savegames.

  • Nintendo are strict about who is allowed to access information and all developers have to sign an NDA. We don't want to get involved in that bureaucracy and a mistake on our part would break our own NDA, so we are not willing to risk that. I don't see why it's a problem, just post general Construct 2 posts here publicly or anything specific to Wii U on their forum.

  • See the manual entry on expressions, Construct 2's notation is: <>

  • While nimos100 might have posted good advice, I don't believe any of it will have any measurable effect on performance.

    For a pretty much exhaustive list of the things that can actually have a measurable impact on performance, see Performance Tips. Things not on that list are generally ignorable for performance.

  • No, it is working correctly and if you are using it properly you'll still get a steady and smooth result.

  • Firefox are adding support for gamepads soon (next two versions or so).

    We used to embed everything in to the EXE, but it made virus scanners suspicious, and probably made the loading times longer too. Besides, it would still have been relatively easy to get the resources out. Copyright law is a better deterrent than technical measures.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Yes, and there is nothing specific to Construct 2 here, it's a normal result in computer graphics. You have a tradeoff between smooth rendering with seam issues to pixel-rounded without seams.

  • To say browsers are more than a Javascript engine like V8 is something of an understatement. There are loads of APIs they provide like WebGL, audio and video decoding, the Web Audio API, device orientation/motion, inputs including gamepads, form controls, text rendering, geolocation, WebRTC, WebSockets, Web Workers, camera/microphone input, AJAX, storage APIs, even speech recognition and synthesis, and so on and on. Then they also do lots of clever optimisations like parallelism in rendering, loading, decoding, and so on. And then they have hundreds of engineers working on new features constantly, ranging from cryptography features to ambient light detection, battery status detection, MIDI support and more, as well as ensuring every platform works identically without any incompatibilities, and fixing all the bugs that inevitably crop up, often including platform-specific ones.

    If we made our own engine, to maintain compatibility it would essentially amount to writing a new browser. For an idea of how hard that is to do even with a larger team than us over a long period of time, look at CocoonJS - it has lots of problems ranging from bugs to compatibility issues and missing features like the Web Audio API and WebRTC. It does the job for iOS, but I doubt we'd do any better ourselves. Meanwhile Crosswalk (albeit with a few initial launch issues that are being worked on) is doing a much better job on Android, because it's a real browser engine. And hopefully iOS will soon get their act together and implement some decent browser technology for apps, but on the other hand Safari itself is already pretty good (just needs WebGL!).

  • Good point, fixed for the next build so you can also use strings. Note however your given example still won't work. | is a logical operator that returns 0 or 1, so you'll be comparing the object name (string) to 0 or 1 (number) which will never be true. You could instead do that (and this works already) using 'Pick by evaluate' with an expression like:

    (Object.Name = "Red") | (Object.Name = "Green") | (Object.Name = "Blue")