Ashley's Forum Posts

  • The expression is constant so is actually evaluated by the editor at preview/export time.

    The editor (like the Javascript engine probably also does) uses double-precision floats for calculations. In this case the expression 32 / 5 evaluates not to 6.4, but to 6.4000000000000004. This is a normal result in computers: they do not perform calculations to infinite precision, and small rounding errors usually occur. It then calculates 416 % 6.4000000000000004 which is 6.3999999999999773. Somehow this gets rounded to 6.4 during export or display, which is unfortunate, but again not unexpected due to the fairly imprecise nature of floating point numbers in computers.

    So, closing as won't fix - you can't ever expect floating point calculations to be exactly precise in computers, using any framework or language on any system. You need to make sure you build in tolerances.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • See also: Construct 2's export-time optimisations.

    "Minify script" itself does not do what you suggested, but a bunch of similar optimisations happen anyway. "Minify script" actually means to run c2runtime.js through Google Closure Compiler's advanced mode. This makes the script much smaller and much harder to reverse engineer in to a project (which would have been very hard to begin with anyway).

  • jlisenbyjr - thanks for reporting those errors. It looks like a bug in IE's WebGL renderer that only shows up when the engine thinks it's running on a mobile device. I've added an attempted workaround for the next build - hopefully that will fix it.

  • Javascript engines perform best when objects have a consistent shape (i.e. the same properties). If we shared objects between unrelated plugins which used different shape objects, that could actually reduce performance. It seems better to make a separate recycling cache for each shape of object, since you get both GC recycling and high performance. Still, perhaps we could have written a library to make this easier...

  • Ashesh,

    You begged us for a free license. Out of kindness, despite possible embarrassment if anyone else found out, we gave you one. Then we found it on a website under a title something like "Free Construct 2 Personal License" with screenshots of your license and our private email communications.

    According to the 'About Us' section (http://www.catbolt.com/about-us.html), the people responsible for running the site are (correct at time of posting):

    eveloped by - Ashesh Kumar

    Managed by - Ashesh Kumar

    Created by - Ashesh Kumar

    Managed by - Ashesh Kumar

    Updated by - Ashesh Kumar

    Game Made By - Ashesh kumar

    Chat Supporter By - Ashesh Kumar

    Email Supporter - Ashesh Kumar

    Everything Else By - Ashesh Kumar

    This is the same name as is on the license. Implying the website is not yours seems to be an attempt at further deception.

    We take piracy very seriously. Further, the fact we had donated this license to you for free seems quite a betrayal. Your license has been revoked and we will not reinstate it.

  • You do not have permission to view this post

  • Even if that file is missing, it shouldn't stop the game working in Chrome. Are you sure there aren't any other files missing? Can you link us to your game?

  • Event 2 sets Pauze_Number to 1, then because events run top to bottom, event 4 runs just after and sets it back to 0. Use the 'else' condition instead.

  • Can't reproduce any issue in Chrome, seems to play just fine. Did you test Firefox and IE? You should always test as many browsers as you can, since it can be important information about the problem. It's especially important in this case since Chrome uses a different audio engine to Chrome and Firefox right now.

  • We don't want to support any new non-browser engines, because they are a massive pain in the ass. They are generally missing loads of useful features that browsers have, and have subtle and incredibly annoying pitfalls like really dumb memory management compared to even the simplest of lazy loading schemes which every desktop and mobile browser already implements (which is still a problem in CocoonJS, and Ejecta doesn't fix this AFAIK). We are only interested in real browser engines from here on out. We really wish we could even drop CocoonJS, but it's the best thing there is for what it does right now (even with its serious flaws).

    I'm pretty sure a Chromium-based wrapper will turn up soon (if not, we'll make our own). That will provide far better support than either Ejecta or CocoonJS.

  • Performance, as in the framerate, is largely unrelated to the filesize/memory use and depends on other factors such as quality of the Javascript engine, CPU speed and memory bandwidth.

    Whether or not the game will run out of memory depends on the system. Mobile devices use a different memory architecture to some PCs: they share RAM between the CPU and GPU. So textures are stored in the same memory as everything else. However and old desktop machine, or a system with a low-end dedicated chip, might have 128mb of dedicated video memory (VRAM). In that case textures are stored in VRAM for better performance. Sometimes images can also be stored in RAM as well, but I'm not sure about the specifics - I think some systems don't support that. So if you have 2GB of RAM and 128mb of VRAM on your graphics card, you might only have 128mb of memory to use for images. Compare that to a tablet with 1GB of shared memory, 256mb of which is free - you can use all 256mb for images.

    So in some cases a low-end desktop might have less image memory available than a mobile device, because it has limited discrete VRAM for textures. I think most modern desktop systems either share RAM with the GPU like mobiles do, or have ridiculous amounts of VRAM (2GB+). So in practice you'll probably be fine, but it's best practice to keep image memory down to ensure old systems don't run out of VRAM, and to improve performance (since any images spilling over to RAM will render slower than those in the faster VRAM).

  • Thanks, should be fixed in the next build.

  • Closing as not a bug. The bottom row of pixels are wrapping back round to the top. This is a normal result of tiling images in computer graphics.

    Workarounds:

    1) make bottom row of pixels transparent

    2) use point sampling & pixel rounding

  • Can't reproduce, runs just fine in Firefox and Chrome here. Make sure you don't have any broken browser addons that change the javascript in pages.