Ashley's Forum Posts

  • I think I've come up with a fix for this. Let me know if it works for you in r118.

  • Thanks, should be fixed in next build.

  • Can you reproduce this in a new project? Generally complete games are too difficult to debug, and it means you can share your project publicly too.

  • Can't reproduce any issue using my dev copy of r118. Can you check this again when r118 is out and let me know if it's fixed for you?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Closing, this is definitely a graphics driver bug. If your drivers are already up to date, try the beta drivers; perhaps also try disabling vertical refresh and triple buffering in the graphics control panel if you can, or failing that, you'll just have to complain to your GPU vendor.

  • What do you mean by "group"? I tried importing a sound with the same name to both Sound and Music folders, and to two subfolders within Sound, and it worked fine.

  • It's hard to be sure this isn't just a mistake in your events. If there really is a bug in the Array object, it should be possible to demonstrate it in a new project made from scratch with just one or two events. Can you provide this?

  • I don't think we can make masks work together: currently it's pretty much by design that you can only use one mask per object. Masks work by returning an opaque image with the effect "baked in". Most mask effects also don't use the color of the image, just the alpha. So a mask followed by a mask naturally has the effect of using an opaque image on the last mask.

    Workaround: use a non-mask version of the shader. E.g. mask HSL, then ordinary hexagonal pixellate. This processes the "baked in" image from the mask, rather than masking the baked-in image with the background, and seems to achieve what you were after. If that's not what you're after, I think you might need to get in to writing some GLSL yourself.

  • I'm going to close this: I don't think we can officially support what you're trying to do. Perhaps you could look in to third party plugins to cover this.

  • Since most HTML5 platforms these days render on the GPU (including Safari for iOS), porting to a native app will probably not get you extra render performance. It will still render the same way on the GPU. (WebGL just helps reduce the CPU burden of rendering.)

    Logic performance is all that's improved by native tech. On desktop usually the logic accounts for 20% of the frame time, and the rendering accounts for the rest. On mobile it's tighter because of a more limited CPU budget, but a well-designed game should be able to get by. Native mobile game developers probably have deeper technical knowledge of the platform, and use very clever design and tricks to ensure they can make the most of the limited computational resources available. I think part of the problem with C2 is it makes it so easy to give a mobile device too much to handle.

    Think about render performance again. Consider leaving 'clear background' on, then creating two fullscreen tiled backgrounds laid over each other (or a screen-sized sprite for example). You have already reached 100% of the pixel pushing budget of some mobile GPUs (which can only write to every pixel on screen 3 times in 16 ms). A native app developer would know not to do that; set 'clear background' off, use one opaque tiled background to give the background texture (perhaps with an effect or artwork "baked in" to the image), and start building the game off that. Then you're starting with 66% of the GPU pixel pushing budget free, rather than 0%. I know this type of thing happens, because I have been sent .capx projects with users saying "it's horribly slow, C2 sucks" or whatever, and they've done something like overlay 3 full-screen sprites right off the bat, so a simple game seemingly runs slow. You just can't design games for mobile like that, not even with native technology.

    I think another big part of it is bad methodology: users create an awesome game using tonnes of effects that runs perfectly on a desktop, and then suddenly find it works slowly on a mobile. What you need to do is use preview-on-LAN right from the start, literally after clicking 'new project', throw in the FPS and object count in a text object, and preview exclusively on mobile while keeping an eye on the FPS. If the FPS takes a dive after a change, backtrack and find a more efficient way to handle it. Your desktop computer could literally be 100x faster than your mobile, no exaggeration - so it's just not sensible to design mobile games any other way. I get the feeling not too many people take that approach!

    HTML5 tech is still developing. I would encourage you to try Chrome Beta for Android, with WebGL enabled in chrome://flags. It's by far the best I've seen HTML5 games running on mobile. And I think it's clear Google's intent is to eventually have WebGL on by default and shipped with the stable version of Chrome (that is now pre-installed on new Androids). I think that's the best indication of what the future of HTML5 on mobile is.

  • I'm afraid we have no plans to add alternative themes at this time.

  • the levels are designed entirely in pictures of 2048 x 1080(2mb each) put side by side

    This is just about the worst way you can design a game in terms of memory usage. You will likely cause a lot of mobile devices to run out of memory making it impossible to play the game.

    From best practices:

    enerally the largest image size supported on all systems (including mobile phones) is 2048 x 2048 pixels. You should still avoid using images this size; a far superior way of designing levels is to use a few medium-sized Tiled Background images (e.g. 512 x 512) to cover the layout, then compose the level design from placing multiple instances of other Tiled Background and Sprite objects. Each instance can be freely stretched and rotated individually which can help avoid a repetitive appearance.

    Consider a single 10,000 x 10,000 image will use 400mb of memory, which will make all but the most powerful desktop computers run out of memory. On the other hand, a level composed of three 512 x 512 Tiled Backgrounds and 50 different Sprite objects sized 200 x 200 will use under 20mb of memory (20x less) - small enough to fit in to the memory of low-power mobile phones.

  • You should prefer adding multiple conditions to the same event, but not for performance: it tends to make your events a lot more readable. Anything not mentioned in performance tips is likely to have negligible effect on performance.

  • Obligatory link to performance tips