Ashley's Forum Posts

  • What I would be interested in knowing, is the performance cost of a sprite/tiledbackground that is doing absolutely nothing (aesthetic) versus an active sprite that is doing something?

    It depends on what it is doing. But if you mean controlling with events, that means it's running on the CPU. Most games are bottlenecked by rendering, so chances are those events finish before rendering anyway, meaning there's no impact to the framerate.

  • Hey all,

    In case you missed it on Facebook, Twitter or Google+, I've ported the old 'Rain demo' from Construct Classic to Construct 2 with a few tweaks, to show off the WebGL shaders that are coming in r100.

    WebGL shaders are really exciting - you can do some awesome stuff with them! If you look closely at this demo, you should be able to see several effects at work. You'll need WebGL support to see the effects so make sure you use Chrome or Firefox (Chrome does best on this one) and that you have up-to-date graphics drivers.

    The Rain Demo

    I know you'll ask when r100 is coming - hopefully in about 2 weeks now!

    Here's the equivalent exported as an EXE using Awesomium, also available in r100:

    Rain demo EXE

  • Don't forget in hardware accelerated platforms (most desktop browsers, and CocoonJS/directCanvas on mobile), scale and rotation of objects can be rendered virtually the same speed as unrotated unscaled objects. This means you can use loads of scaling and rotation to keep the same few sprites looking interesting. It's one of the technique Braid and Aquaria also use to make a visually interesting level out of a handful of sprites.

  • I read this article, but I was a bit disappointed by the description of C2. It was mentioned at the start which was nice, but the author doesn't seem to have used it at all, but still implied to have an overcomplicated UI. I really think it's different to other tools in that regard, especially GameMaker.

    e.g.: "Current tools are very concerned in presenting a coder-friendly environment." - I don't think that applies to C2 at all, especially since it doesn't even use code!

    "Blender ... gives little to no "premade" solutions for common game functions (any mouse-control needs to be scripted for example). Game Maker is better in this department, certainly better than Construct and Unity, yet it's still too simplistic."

    Again, frustrating since they clearly haven't used Construct, because its behaviors system fits the description of premade solutions exactly. In fact the behaviors system is so good it has been highlighted by others as an advantage over GameMaker, but this article says GameMaker is better in this regard. Hmm...!

    Anyway, here's to getting mentioned more regularly in game industry articles.

  • I can indeed occasionally reproduce this, but it seems sporadic and I've been unable to figure out what causes it. Are you able to find any particular thing in C2 that causes it to stop closing properly? i.e. if you start C2 and don't do it, it closes OK, but if you start C2, do something in particular, then close, it doesn't close properly.

  • Are you sure you don't just want to use an array of strings? It sounds like it'd be easier than doing a lot of string manipulation.

  • This can't (and arguably shouldn't) be supported for a number of reasons, but it's possible to implement a calculator without it anyway.

  • I don't think the engine supports sloped jumpthrus. It's very difficult for the engine to tell if it's a slope or just something it can walk through (e.g. a big background jumpthru which shouldn't affect collision).

  • — is right, it's not just on-screen objects that are in memory. The entire project is in memory, even off-screen images, and even images on different layouts.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Currently C2 loads the entire project in to memory on startup and that's it, it doesn't release any as the game runs. A feature for this is on our todo list, but it is only generally necessary with *very* large projects. If this pertains to your other thread, the fact you are making level-sized images is the problem. Most games won't have any problem with loading everything on startup, if designed well.

  • Cutting up large images does nothing performance wise, if the same pixels end up on the screen, except maybe make it a little slower.

    You should not design layouts as large single images. Make each part of the background a separate object (and a tiled background wherever possible) and build your background out of those objects. This will consume vastly less memory and allow for significantly larger levels.

  • Yeah, the 3GS should work OK but the hardware is a lot weaker than the newer devices. So if it's playable on a 3GS it should absolutely fly on the 4 and 4S. You'll just have to be even more careful with the number of on-screen sprites, memory usage, and so on.

  • There is no debugger in the editor, you can only debug the runtime in a browser. Editor scripts are also not minified. The ACE names just have to match what the runtime says. It's really not a big deal that it's minified, it doesn't break anything as long as you write your code carefully.

  • Please see how to report bugs. Can you share a .capx?

  • Tiled background is exactly the same as drawing a sprite if it only shows a single tile. However it is vastly more efficient at drawing large areas of tiles.

    Mobile devices have much more limited resources than desktops. It does not matter which engine or exporter you use if you have lots of large images - you will simply run out of device memory. You just have to design your game differently. The maximum tile size supported is 2048x2048 but bear in mind each tile that big will use about 16mb of memory.