Ashley's Forum Posts

  • You do not have permission to view this post

  • Ratty - you only have .ogg files for your audio. You need both .m4a and .ogg formats to cover all systems, because there isn't one format that works everywhere. More information in the manual

  • You can choose a subfolder for images when exporting a project, doesn't that do what you want?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I almost made the picture editor use 0-100 as well, which I do think makes more sense, but in the end I went with what other image editors do. Everywhere else I try to use a percentage where possible, such as with opacity which I feel should definitely be 0-100 and not 0-255.

    The reason everyone's used to things going 0-255 is simply because it's common to store pixel data in an 8-bit unsigned byte, which has that range. Early graphics software simply displayed these values directly to users, and I guess it caught on.

    The thing is an 8-bit byte is just one of many ways to represent color values, and it's possible to have 1-bit, 4-bit, 5-bit, 16-bit, 32-bit and even float 16-bit and 32-bit variations, or mixed-bit integer representations like a 16-bit color storing 5, 6 and 5 bits for red, green and blue respectively. In fact many modern graphics processors process everything as floats from 0 to 1 in a variety of bit widths and multiply by 255 just before displaying them on the screen.

    In short 0-255 is not "the" way of entering color values, and may in fact be totally unrelated to the real representation inside the computer, so it's actually kind of an arbitrary choice these days. It's just everyone's used to it and probably assumes colors are still 8-bit values even if they aren't so much any more. So IMO it makes more sense to make it 0-100, like many GPUs really use but multiplied by 100 for convenience, but I went with convention for the image editor because it seems to be a de-facto standard there.

  • Please see how to report bugs, we usually cannot do anything about reports that are missing a .capx file. A quick check with a trivial recursive function to calculate factorial shows it's working in r111, so I need a .capx to see what isn't working. Moreover, it may be that your events relied on a bug that was actually fixed in r111; it might be worth double-checking all your events are really correct.

  • Closing as won't fix: this is not an issue with C2, it is because different browsers render web fonts differently. There's nothing we can do about it. It's a known issue as described in the Text object manual entry:

    b]Text rendering

    Different browsers render text in different ways, and Construct 2's layout view also renders text differently to other browsers. This means you should expect the appearance of the Text object to vary slightly across browsers.

    You should test your game in a range of browsers to ensure text objects display how you intend for all users. For more information see Best practices.

  • Wow, I had no idea anyone used the Platform behavior like this - I designed it for running along flat platforms that don't rotate. So I'm actually kind of impressed it works.

    I tried it in Chrome with r111 and it appears to be pretty smooth. Can you explain more about precisely what you think is different?

    Note the Platform behavior in r111 supports sub-pixel precision now - perhaps setting Pixel Rounding on or Point sampling in project properties will help it appear smoother? (since it won't have any sub-pixel jitter)

    Jaydon - that does not sound related to this thread, and I checked and jump-thru platforms seem to be working OK in r111. Please post a separate thread taking note of how to report bugs if you think you have another issue.

  • This is currently by design due to the way objects are created. I know it's a little unintuitive, but it really has to be that objects only really exist at the next top level event, otherwise some projects with certain events can end up crashing. Closing as won't fix.

  • Please use Dropbox, Google Drive or just email the .capx directly to me (ashley@scirra.com), I don't want to have to enter my email address to some service to download a file... will check this out when I get the .capx.

  • IE8 and older don't run HTML5 games. Practically every other browser today can though.

  • AIR doesn't run on the web. Also, AIR beats canvas 2D by a small enough margin that if the devices in question supported WebGL, I think Construct 2's WebGL renderer would beat AIR as well - on desktop WebGL gets at least double the performance of canvas 2D.

  • I'd go to Ludei for support for now - we simply call the functions they provide from our plugin, and for help on how to set it up and use it Ludei are the best ones to explain.

  • Try putting a text object visibly on the screen and every tick set it to tickcount. This forces the screen to be redrawn every tick. Some old versions of Chrome had timing bugs when the screen was not redrawn every tick, and Awesomium is stuck on an old version of Chrome, so it might still be affected.

  • Can you share your .capx?

  • I haven't seen any evidence anyone can beat Construct 2's automatic spritesheeting and PNG recompression with other tools. If you can show me something that beats it by a significant margin I'd be interested to know which tools you used. As the blog Knifegrinder linked to says, C2's automatic spritesheeting on export is very good, and there is not much to gain by doing anything differently. For example putting two completely unrelated images in the same spritesheet usually has little compression benefit, because there is not anything in common between the images that PNG can compress away. Compare that to animation frames, where there is often a lot of in-common image sections which can be compressed away, and it's more likely that PNG-8 can be used for further savings, whereas unrelated images may nudge it over 256 colors and use PNG-32 which can double the filesize.

    Also have a look at Image compression in Construct 2, a separate post detailing Construct 2's PNG recompression strategies. It's fairly sophisticated and includes automatic color counting to losslessly switch to PNG-8 where possible, giving significant savings for free. People occasionally try to use online services or standalone tools like PNGCrush, but I have tested all the ones I can find and none of them beat the way Construct 2 uses several tools in tandem.