Ashley's Forum Posts

  • 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.

  • We fixed a bug with text positioning in Tizen in r148. Have you tried using that?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The OP seems confused between file size and memory use. They're not the same thing.

    I doubt file size is much important for anyone on broadband these days. Steam regularly delivers games in the gigabytes.

    However memory use is always important - if you completely ignore it you can design a game so badly it won't even run on a high-end desktop. 32 images at 1024x768 all on the same layout is about 100mb of texture usage alone - not including the rest of the game - which is probably enough to rule out some low end systems already.

  • How come they're still selling the iPad 2? I guess that's to cover the cheap end of the market, using the old model as the low-cost option. Still it's strange they didn't use the iPad 3 or 4 for that.

  • Both the installer and Construct 2 executable files are digitally signed. If a virus had somehow infected them the digital signature would become invalid, which would probably throw some warning in Windows. So I doubt it really is infected at all, unless it got infected before we signed it, but that seems highly unlikely (I'm sure we'd have heard more about it!)

  • To be fair, Windows 8.1 is a free update if you already have Windows 8. But Windows 8 itself isn't a free update.

    If Mavericks is free, isn't that annoying for everyone who paid for Mountain Lion? Instead of spending money for that update, you could have just waited and got Mavericks for free...

  • greatimposter - are you sure you tried everything in the troubleshooting guide, such as setting up preview-over-wifi, trying different ports, and so on?

    SgtConti - the preview server should work fine on Steam even without admin privileges providing you're only previewing on localhost. We are not aware of anyone else who has described issues with this. You can also still launch in admin mode if you need to, by running from the Steam install directory.

  • Nobody else has reported this so far, so it seems like a one-off false positive. The file should be digitally signed which ought to indicate to the antivirus that it's trustworthy, but I guess AVG has gotten over-suspicious in this case...