Ashley's Recent Forum Activity

  • Browsers have historically supported disabling pinch-to-zoom, and C2 does specify to disable that on export. However there are so many websites that disable zoom and yet have a tiny hard-to-read font, which annoys so many people (especially anyone without eagle-quality vision, which is more than most realise), that browser vendors are starting to ignore the "disable zoom" feature. This means these user-hostile websites become easy to read again, by ignoring the "disable zoom" instruction and letting the user zoom in anyway.

    That's all a good idea, but the downside is it affects anyone who really doesn't want the page zoomable... like C2 content. It's a tricky issue because the browser only provides a crude "do the default thing" flag for touch events, and it can only be on or off. So if you drag in a text box, the default action may be to move the cursor or make a selection - and also start a zoom. Often we can't disable one but not the other. So we could forcibly disable the zoom, but then you might not be able to select anything in the text box. So this is probably something we need to go back and talk to browser vendors about.

    FWIW the Android browser is falling out of use in favour of Chrome. Also I'm pretty sure Cordova is not affected, so mobile apps will stay the same. Anyway maybe post a minimal example to the Bugs forum and I'll look in to what could be done.

  • You can run the signalling server permanently on an offline LAN network, which means you only need to set it up once. But setting it up involves running a node.js server on a machine with the correct network configuration, e.g. setting up the firewall to allow server hosting, then identifying the machine's local IP address, and then using that address to connect to the signalling server with the Multiplayer plugin.

    It's definitely possible, but I'd guess most players probably can't be bothered to do all that configuration just to play a game. By far the easiest thing to do is just go online and use the Scirra signalling server.

  • Well from what I remember and was able to test using grid placement in the platformer template, it still requires a 32x32 player to be either slight smaller than 32x32 for it's collision box to fit in a 32x32 hole or have the hole be slightly bigger.

    This comes down to the math involved in the collision engine: two exactly aligned objects like you describe will have their edges at exactly the same position, and two things at the same position count as overlapping.

    Even if we changed that case to not count as overlapping, I don't think it would actually help much. All movement and calculations in C2 use floats, which is nice for precision and smooth movement, but as with the entire field of programming, float calculations are not exact. So you could easily end up computing the player's position as 32.0000001 or 31.999998999, and it will still no longer exactly fit inside a 32px gap, even if the collision engine specifically allows exact-fits. So I don't think there's really any easy fix to that - you just have to adjust your collision boxes to not require exact-fits. So shaving 0.1px off the collision box is a good workaround, and one you'd likely still need even if we changed the engine.

  • I do wish Scirra would introduce some sort of pixel-perfect collision or something similar as an optional alternative.

    I don't remember exactly which behaviors use it, but definitely the platform behavior does even better than pixel precision - it goes down to 1/16th of a pixel, IIRC. So it's actually kind of sub-pixel-perfect.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It comes with instructions, but if you're not familiar with running node.js servers, I'd probably advise against it. It's a lot easier to go online and connect to the Scirra-hosted one!

  • You still need a signalling server for that. It can be running on the same LAN though. Otherwise there's no way for the clients to find each other.

  • Most other game engines support spitting out a native APK that is not bundled with a web browser

    Construct 2 already supports this as well. Just target Android 5.0+, and it won't bundle Crosswalk, which is what increases the file size. It's only there for Android 4.x support, which is steadily shrinking.

  • The way this project is set up circumvents the collision cells optimisation. The cell size is the viewport size, so in this case by using a totally impractical size of 10000x10000 (honestly, surely nobody would ever choose that in practice?) forces all collisions to be made within one cell. So then you get the worst-case of all possible collision checks, plus the overhead of managing collision cells. That's probably why you're seeing it as slower.

    If you set the viewport size to something reasonable, it runs far faster. Even with a viewport size of 1000x1000 it runs several times faster for me.

    If you want a full view while using collision cells, set a reasonable viewport size, and then set a small layout scale so you can see everything. That way you'd get the same view but the improved performance too. I did this for some of the screenshots at the time. Also collision cells are an absolutely critical performance optimisation if used sensibly - in many cases they can completely eliminate 90% or more of all collision checks, which in many cases completely eliminates the performance overhead of collision checks. It's such a huge optimisation that it's definitely a good idea to work with it, not against it. Also I have to say reporting an issue about a change that was made over three years ago is not very helpful - the sooner you can make a report, the better.

    Closing as won't fix.

    • Post link icon

    Just to throw in one more post - Windows itself probably has far more bugs than Chrome. You just can't see them all on an easily searchable list. And you can't make your own reports to alert Microsoft to any issues that affect your software.

    So pointing at a normal bug tracker for a large software project doesn't really prove anything. In fact I have always counted this as a major plus - I can and do file bugs when they affect C2, and frequently Google fix them, and sometimes even within a few days. You can't do that with Windows or innumerable other software projects.

  • We're going to make all the versions of the editor available so you can roll back to an older version if necessary, just as you can with C2.

    Did you file a bug for the issue in r203? We've fixed probably hundreds of other bugs and issues since then, so staying on old versions can easily cause more problems than it solves.

  • We have weeks of updates scheduled. Please be patient!

  • That's not an officially supported case in C2 - you could easily break things, and we cannot accept bug reports unless you are using a 100% unmodified engine - and equally it won't be an officially supported case in C3 either.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,776,331 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs