Ashley's Forum Posts

  • The desktop build still uses zips for NW.js exports, because extracting the files on a Windows machine breaks Mac and Linux exports, because Windows doesn't understand the special file permissions needed for executable apps on those systems. The zip file is configured to set the right permissions so it works if you extract it on the target system. See the tutorial Exporting desktop apps with NW.js.

    That doesn't apply to any of the other exporters, which let you export to a folder in a desktop build.

  • I tried, but it's not clear exactly what to do. See The best way to get help - tips for this forum

  • So the only way to do this now is to paste the image onto Drawing Canvas, save image, request image url with AJAX, feed AJAX response to Binary Data object, then save data as BASE64 string in Local Storage.

    It's actually easier than that in the latest C3 releases:

    1. Load the snapshot URL to Binary Data using AJAX
    2. Save the Binary Data using Local Storage

    No need for canvas or base64 encoding.

  • This page has a list of new features C3 has over C2. We also recently launched a completely rewritten runtime for C3 which has massive performance improvements and major new features

  • I don't think it's possible to work out the correct texture co-ordinates to use from GLSL alone. Construct doesn't currently support using additional textures as inputs to shaders. Currently the workaround is to use a sprite positioned exactly on top of another one, and implement the shader as a background-blending effect, combining the foreground and background shaders. It's a bit of a hack but it does work, it's how the normal mapping shader works.

  • Cloud services already let you do that. You can roll back the version of the same file.

  • Cloud storage services like Dropbox usually offer 30 days or so of file history, so you can roll back a file to any time in the past few weeks. So if you set up backups to cloud you can use their rollbacks.

  • Issues should be reported to the bug tracker following all the guidelines otherwise they won't be investigated.

    FWIW I tried the project and it appears to be working just fine.

  • The screenshot shows an Android System Webview that is 3 years out of date. Are you sure you correctly updated it? Does the message change after you have updated it?

    You should start a new thread to continue this discussion since it is not related to the original post.

  • Please only post in English on the forum.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Some posts in this thread mix up CPU and GPU performance. Construct with WebGL 2 basically uses native grade OpenGL ES 3, and once it's on the GPU it's hardware-limited. So I think it's fair to say Construct has native-grade GPU rendering performance and capabilities.

    Also, I must point out Construct supports publishing to Xbox One! For some reason most people don't seem to pay that much attention...

  • That screenshot shows a device that has not had its software updated for 3 years. It needs to be updated to work with modern software. Most devices do this by default. If they do not, the instructions shown on that screen will fix it.

    That is also not related to this thread, which is about an issue specific to WebGL 2 (which is probably the original report about a GPU driver bug on Mali devices that is now worked around).

  • The term scriptElt does not occur anywhere in the Construct runtime. So I believe the problem occurs in Facebook's side so should be taken up with them.

  • The project file appears to actually be a Scirra Arcade game export, zipped, and then renamed .capx. This is obviously not a valid Construct project so cannot be opened. You'll need the original project. If something has gone wrong, restore a backup; if you don't have a backup, you just learned the hard way why you need to keep backups.

  • It's possible, but Construct's spritesheeting algorithm is non-deterministic so you don't know ahead of time which images are on the spritesheet. However you can simply set the texture and draw it via its texture co-ordinates for a different image; if it happens to be on the same texture Construct will batch it in to the same draw, otherwise it will switch texture.

    Still it's a weird question and asking the user to enter UVs is definitely not the type of thing you should be doing, especially since spritesheets can be completely rearranged at the drop of a hat, so any user-inputted UVs will quickly become invalid. As ever, it's best to explain what your overall goal is, rather than the specific details of a particular approach that might not be the right one.