Ashley's Forum Posts

  • This type of plugin is really bad for compatibility for all the reasons described here.

    I know people need these features, and sometimes people need them sooner than we provide them. However if it is remotely possible, the plugin should be minimal code to patch code in to another plugin. It's not always possible, but when you take this "copy and paste" approach and copy the entire plugin wholesale, you can easily create worse problems than the plugin aims to solve.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Thanks, that confirms it's to do with audio memory management. I must point out turning the "preload sounds" option means you are explicitly telling C2 to load and decompress all sounds in to memory on startup, which if you use a lot of sounds, can be a very great deal. But the fact it doesn't release any and still ultimately crashes is a problem. I'll try and get audio unloading in the next build...

  • Blurs and glows are by far the most GPU-intensive effects in the C2 engine. It sounds like an effect-specific quality setting could help a lot there. I'd much appreciate a demo .capx (even something simple created from memory) to see what kind of thing you were working with so I can understand what the engine ought to do to optimise for that.

  • Google Play Game Services should function entirely independently of the rest of the game. It sounds like it could just be a mistake in your events. Unless you share a .capx it's pretty much impossible to comment further.

  • See memory usage in the manual.

    In short, the source image dimensions determines the memory usage (i.e. number of pixels). However the download size depends more on the content of the image itself - e.g. a solid red image will compress to almost nothing, but a detailed image will take more data.

  • >

    > > In native-based engines you have much more control over resolution, so we can render the effects and things on a smaller screen space, then use one clean up-scale render-to-texture to make that "HD" using a simple one-pass shader.

    > >

    > We could do something like that, because we can do everything a native app can do with OpenGL ES 2 (soon 3).

    >

    That would be incredibly helpful, especially if later on we get the control to actively resize the resolution of the desktop (which is a dying trend, but is sometimes the only hope for the many gamers on older hardware on Steam).

    Are you aware that the existing "low quality fullscreen mode" is effectively identical to switching resolution on a modern display? The only difference is the last-step stretch to physical resolution is done by the GPU rather than a chip in the display, and the performance impact on the GPU ought to be minimal. So you can already get low-res rendering for improved performance by setting a small viewport size and using low-quality fullscreen mode.

    Beyond that it's possible to add a shader where you can turn down the quality of individual shader effects, which can be useful. However I suspect it would only help with certain intensive shaders like blurs. It also has the trade-off of (obviously) reducing the visual quality. So something like screen blend is typically very fast (no extra fill rate on top of normal rendering, it's 1:1 to normal rendering but with a different calculation), and as you turn down the quality, it gets noticably blurry/pixellated. On the other hand a low-quality blur can still look good and save performance. So, which effects are you using heavily and are you sure they will be improved by such a quality setting?

  • Turning off preloading sounds should help it start up (if it's enabled), but can indeed still crash if the game ultimately ends up loading every sound. However the main reason I asked was because the answer would help prove if it really is audio memory or something else. I've not seen this confirmed though - is it enabled?

  • Crowd avoidance is another incredibly difficult problem with lots of nasty edge cases. But you can make a reasonable simple approximation. One example is to have a rule like: if two enemies are overlapping, pick the one further away from the player, and make them slow down. This means if enemies bump in to each other, the one behind waits to let the one in front ahead. It's not perfect though, especially if you end up with a large crowd, but it can help a lot with simple cases.

  • This is actually an incredibly difficult problem. I would recommend not trying to handle collisions with the walls, because then you open a new can of worms where objects constantly get stuck.

    The main problem is the rotate speed is relatively low compared to the acceleration and speed. So the enemies can only turn in very wide arcs, while chasing you down a narrow corridor with very tight turns and corners. The pathfinding behavior does try to slow down objects so they can make the turn, but I guess it doesn't work that well, and if it did, your enemies would spend most of their time going slowly to make sure they can make the tight turns. This would probably spoil the game as they would easily get left behind.

    Basically if you set all of them to have a rotate speed of 3600 they follow the player just fine, but sticking to 45 degree angles. You probably just want to find the best rotate speed to compromise.

  • Do you have "preload sounds" enabled? Does it work better if you turn that off?

  • In native-based engines you have much more control over resolution, so we can render the effects and things on a smaller screen space, then use one clean up-scale render-to-texture to make that "HD" using a simple one-pass shader.

    OK, but that's more of a feature, not an inherent limitation of WebGL. We could do something like that, because we can do everything a native app can do with OpenGL ES 2 (soon 3). WebGL does not prevent that.

    [quote:2pwyj2mf]The problem here is that it's really more than just Construct 2 being so frame-dependent (despite use of dT like crazy)

    You can turn off framerate dependence if you want, or adjust the dt cap to limit frame skipping, by changing the minimum framerate. But if you disable it completely then you have to deal with the game running at different rates depending on the display refresh rate, e.g. it will go twice as fast on a 120Hz gaming monitor, which I've always thought was a worse result.

    [quote:2pwyj2mf]Support doesn't mean it's fully working. A laptop from 2006 might have a version of Chrome that "supports" WebGL, but it'll run DirectX 9 faster than it every time.

    Do not assume native DirectX or OpenGL are perfect for everyone either. I've done a lot of native coding with both DirectX 9 (Construct Classic) and OpenGL (C2 editor) and there is a total minefield of horrible driver bugs, crashes, and even poor performance. The situation is so bad it can even ruin major game releases. The GPU driver situation is totally awful and that affects the whole industry, not just WebGL, HTML5, or Construct 2. I know people get annoyed when I point the finger at other companies like those responsible for the terrible GPU drivers, but it really is that bad and everyone in this industry is dealing with it.

    [quote:2pwyj2mf]Unity has the funds and staff to do extreme optimization on both native and WebGL, and here's their results:

    https://blogs.unity3d.com/2014/10/07/be ... -in-webgl/

    Despite the title, that blog appears to mainly be testing CPU performance with Unity's WebGL exporter, which means it's basically running asm.js and WebAssembly vs. native code. Their own analysis says: "When you are mostly GPU-bound, you can expect WebGL to perform very similar to native code."

    Even then, other games, both 2D and 3D, made in other engines, perform significantly better on Intel embedded GPUs than games made in C2. Whether that's due to usage of WebGL or not is debatable (I say probably not)

    Maybe you're actually testing CPU-bound games where the GPU performance doesn't matter. That explains why you could see differing performance even on a system with a super-powerful GPU. CPU performance is another topic entirely. My point is that since there is a 1:1 mapping between WebGL calls and OpenGL calls, the GPU performance should be identical to a native app making the same calls. There's no reason for it not to be. Maybe different engines do some special optimisations or something, but there's nothing stopping us doing that in WebGL as well, since the same features are there. So it's not actually WebGL's fault or some fundamental limitation of HTML5.

    If you have a CPU-bound game, as I always offer, send it to me and I'll profile it and see if the C2 engine can be improved.

  • It already reboots once a month - it installs Windows Updates every Patch Tuesday.

  • Safari doesn't support invoking downloads yet. I think they're adding it in the next version though.

  • See the manual entry for how it works.

  • You do not have permission to view this post