Ashley's Forum Posts

  • Yes, you get black bars. If you don't want them, choose 'scale outer' or 'scale inner' instead, but now your game has to work with different aspect ratios which is trickier to design. The 'supporting multiple screen sizes' tutorial covers this.

  • Pode — - rendering work on a CPU is usually so slow as to be not worth the bother at all, even with SIMD. GPUs do that way better, and already do in WebGL mode! Also, what makes you think WebGL mode is slow? It benchmarks upwards of twice as fast as canvas2d in most cases.

  • It makes no sense to use dt in 'Every X seconds', it's already measuring in seconds!

    The simple answer is to make fewer collision checks. Only collision check objects which really need it, and try to only check every few ticks if possible. Alternatively try to spread your objects out over a larger area and collision cells will reduce the collision checks for you.

    BTW if that's 1600 a second, that's almost nothing to worry about at all. A single collision check is near-instant, and 30 a tick or so will have probably zero impact on performance (not counting poly checks).

  • It's a complicated feature, you should read through all three multiplayer tutorials or you'll likely have no idea what is going on.

  • Crosswalk should support speech recognition soon. I think Chrome for Android already supports it too.

  • Would it really be useful? What kind of alerts would you want a game to bring up?

    Also currently the engine stops running when it goes in to the background to save CPU and battery, so it would probably only be able to alert when you're already looking at it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You shouldn't need to do anything at all. Just use letterbox scale mode and the game will automatically scale accordingly when changing orientation.

  • This is an interesting feature but is unlikely to produce significant performance improvements in a game engine like C2's. SIMD works best with basic arithmetic over very large datasets, such as changing the gain of a large audio buffer. This type of use case does not really crop up often in a game engine. Browsers probably already use SIMD in their native code to speed up things like audio processing and image decoding, so it's already been used in browsers for some time. Construct Classic only ever used it to speed up pixel-perfect collision tests, but then I still think polys are faster and a better choice anyway, so I'd still prefer not to add that to C2.

  • Do not use an iframe for that. What's stopping you designing it in one project only?

  • pennaneac - we receive a large volume of emails and there are currently several .capx files in our email inbox. I'm not sure I got the right one, you should refer to the forum thread when emailing us, but I found an email talking about DX/OpenGL and it had 23 layers.

    It runs at 60 FPS on both my laptop and Nexus 5 phone with Chrome for Android, despite the fact there's a tonne of overdraw across the 23 layers.

    You use lots of very large textures, including one that is 2560px wide. This is over the 2048 texture size limit for many GPUs and will either seriously degrade performance or simply cause your game not to run. (The Nexus 5 does complain about this, but the game still ran with just that image missing.) Be sure to read Remember not to waste your memory

    You turned off WebGL, which usually halves performance.

    Some objects have sizes in the tens of thousands of pixels; one is 44,444x242, another is 55,000x169, one is even over 100,000 pixels wide. This is generally not a great idea since some GPUs may struggle with such extraordinary size quads. It looks like you're doing this to allow the impression of scrolling past. This is the wrong way to do it: make it only double width, and reposition it back to the right every time it travels its own width to the left. (The infinite runner example's background shows how to do this.)

    In short, it seems to run just fine, even with some dubious design decisions that will surely push the limitations of the hardware.

  • It would probably be very slow, not because there's anything particularly inefficient about iframes, but just from the fact a typical game will use up a fair bit of CPU/GPU/memory, and running several at once will use a multiple of the system resources. Desktops might get by but I'd imagine it'd choke mobile devices.

    What are you trying to do? Why are you asking the question? If you want to make a menu in an iframe, it's a very inefficient way to go about it since you get the overhead of an entire game engine just for the menu by itself. It'd be better just to design it in-game itself. However if you're making some kind of arcade, it would of course be better just to run one game at a time!

  • That's by design. Can't you do the same thing using solids at the edges?

  • szymek - that is surely software rendering. Either the device has no GPU or the driver is blacklisted so it's not being used anyway. Either way, it's not to do with Javascript performance.

  • WP8 depends on what IE does (and I don't know what their plans regarding WebRTC are), but I think BB10 and Tizen have Chromium-derived engines so would be likely to support it in future providing they keep their browser engines up to date.

  • Share a .capx so we can take a look. Did you also try asm.js physics mode?