I think all USB gamepads work, so long as they're detected as a game pad. XBox controllers are the "default" controller and tend to work correctly right away. If you connect a controller and find the buttons are all mixed up, then you could program a "Choose your input" menu system, where the player can click on, for example, jump, and then press a button on their controller to assign jumping to a button.

I've tested PS4, third-party switch controller, third-party dance mat, and all work fine in Construct.

The only example of something NOT working, would be a non-gamepad item, like a MIDI piano keyboard, as these are detected as MIDI devices rather than USB game pads.

All Windows computers should be fine, tho Linux and MacOS won't have an "appdata" folder. Whether it auto-creates the folder structure or not, I'm not sure, but worst cast you can always have some events to check & create each subfolder, just to be safe.

Thanks for the reply, Ashley. Definitely sounds more complex than I thought it might be.

And R0J0, wowww this pixelate effect is a game changer!! Even ignoring drawing canvas for a moment, just throwing pixelate onto a sprite and setting pixel size to 1, and then using "set colour", works fine with linear filtering!! This opens so many doors for me!

The only issue being when zoomed out far away with 3DCamera, the set colour struggles to apply (I guess the pixelate effect is struggling to apply too), and another issue with pixelate effect not applying at all on non-square images, but these are minor issues (and might be related to scaling which I need to wrap my head around a bit more). Beyond this, you could bake the colours/changes to a sprite by utilising drawing canvas to paste the clean pixelated sprite, make changes to the drawing canvas, load back into a sprite via Load URL, then there's no need to worry about the effects applying correctly anymore. Amazing!!

I always thought the pixelatte effect was more for smaller little effects or screen transitions or something, but now I perceive it differently and see it as a tool to allow you to use linear filtering in your project, whilst still allowing you to choose individual objects that you would like to have point sampling applied to.

Many thanks for unlocking many new ideas in my mind, and thanks for the example c3p. I hadn't explored the "using mouse to draw on canvas" aspect yet, so this helped a huge amount!!

Ayy, similar to how there is a system action to "set pixel rounding", would it (hopefully) be a minor addition to add a "set filtering option" system action?

I have a project that uses Linear sampling, but the sprites are pixel art. The project aims to be very customisable/moddable. I use linear sampling as it helps with making everything look smoother with rotations and 3DCamera and such. I messed around with point sampling but it looks too jagged and not good, doesn't look retro or cool, just looks distorted and eh.

With an option to change filtering to point/linear at runtime, this would allow the player to do pixel art editing with drawing canvas. It would be acceptable to have the project change to Point sampling during this time, paste some stuff and make some changes to the drawing canvas, save it, then switch back to linear sampling when finished. This could also allow pallete swaps, as you could loop through each pixel on the drawing canvas to change a specific colour (whereas if you did this with linear sampling, then upon pasting a sprite, the colours in the drawing canvas are blurred between each other and it would not be easy to change 1 or 2 specific colours).

Currently when linear sampling is on, I'm not sure it is possible to load clean pixel art into drawing canvas as you cannot "Load from url", and pasting a sprite will paste the linearly filtered sprite and not the original non-filtered pixel art.

I originally wanted to use "set colour" to allow players to change the colours of parts of their character. However, effects only apply after the sprite has been linearly filtered, making the results of "Set colour" look unusual as it doesn't set the colour of the inbetween blended colours that appear from linear sampling, even if you mess with the tolerance parameter.

If it's not minor, I'll pop it on the suggestions platform for sure.

Thank you for your time!

I think collision checks now are pretty well optimized and not as bad as they used to be. You shouldn't worry too much about running a few hundreds or even thousands overlapping/collisions checks on every tick or making complex polygons where needed.

Creating many objects on every tick is also not that bad by itself. It's loading textures what's usually causing lags. So if the images are already in memory and the objects don't have many behaviors, spawning them shouldn't use a lot of resources. In my project I'm periodically creating and destroying thousands of small objects, and most times the lag is not noticeable.

Ahh that's good to know, thanks! Admittedly I'm a bit out of the loop with collision stuff due to working on a rhythm game that pretty much never relies on collision detection, but it's good to know as I assumed to avoid complex polygon shapes whenever I did return to this.

With creating objects, perhaps in my case, I have some objects that, when created, run an function to initialise the object, which does a whole heap of stuff to them to get the objects prepared (creating further objects to attach to the original object, setting a bunch of variables, etc.). Sometimes many of these objects get created at once and creates a jolt of lag. That might explain why I've needed to explore different ways of approaching the creation of objects, but now I'm wondering about optimising the initialise function... Hmm...

Ooh I love this kind of thing!

I try to keep a mental note of what is considered an "expensive" event, and what is not - There's no list that I know of, but I mostly memorised a lot of it over the many years. Some expensive events being: Changing an object's Z order, collisions (especially if it has a complicated collision polygon, but still expensive even if it is a 4-point box), creating many objects in 1 tick, calling functions many times (especially if the function has an objects UID sent across and there are many instances of that object - Perhaps the new Custom Actions helps with lowering the need for C3 to check every object to find the correct UID).

If something IS expensive but required, and is running every tick, you can try to think "OK, when do I actually need these events to run?". In some cases, it is required to run some events every tick, but sometimes you only need to run events occasionally, E.G. Only when a player's position changes - In this case, you could track the LastX and LastY of the player, and then every tick, check if self.LastX is NOT equal to self.X (same with LastY in an "Or" block), and then throw your events into here as sub-events, then at the very end of these sub-events, set LastX and LastY to self.X and self.Y (Note: This has the added benefit of allowing you to check distances travelled in pixels since the last tick). So overall, this creates another check every tick where it checks the players position compared to LastX and LastY, but this could significantly save on performance if the sub-events within this are quite expensive. I may not have chosen the best example as you may only have 1 or 2 player instances that are usually always moving around, making this slightly more expensive overall, but the same concept could be applied to anything that has multiple instances existing and each instance could be either moving or stationary, such as many interactive items scattered around the map and such.

With collisions, I find this can vary significantly - Sometimes it is best to filter the object picking first, and try to keep the collision event at the very end, so that less collision checks are occurring. But, sometimes utitilising the collision cells in C3 works well, so it can sometimes be more performant to keep collisions at the very top of an event block - Definitely worth experimenting and measuring CPU performance each time to see what is best for your situation.

With effects, particularly 1-frame objects with a non-animated effect (such as AdjustHSL on a scenery object) if you do not often need to adjust the effect parameters, then consider using the drawing canvas - You can paste the object with its effects, then hide/disable the original object's effects, which helps with GPU performance. If you must use a sprite for this object, you could implement a system to load the drawing canvas result back into the sprite via "Load image from URL", which if you make this system, you could do this for each animation frame. Again though, this is only for non-animated effects such as AdjustHSL, and not for effects such as warping water or noise effects.

With effects on objects or layers, try to disable them when not needed, even if you have AdjustHSL or Contrast and they are at their default values that show no visual difference - At the end of the day, it is still generating the effect, so disabling and enabling effects when needed is key.

Similar to the above, but for behaviours - If objects are offscreen or invisible, their behaviours simply don't need to be active when the player cannot see them or their behaviour is not important to anything else that the player can see, although be careful and always test thoroughly (E.G. You may not want physics disabled when offscreen, as this could cause issues with other physics objects colliding with it, if any. Thankfully, physics objects "sleep" when they don't move for a while, but I perceive this as "they are asleep, but they're actively awaiting an unexpected object to smash into them, so it must be doing some form of collision check even when sleeping").

If you must spawn multiple objects quickly, try to spread this out across multiple ticks if it won't cause issues for what you're trying to achieve. If you need to spawn objects onscreen that the player will instantly see, then it is not recommended to do this as this could be visually jarring, but sometimes it would not have any visual impact at all (E.G. If you had 10 objects explode and 3 particle objects are spawned for a fire & smoke effect, you could wait a tick for each of the 3 particle effects to spawn in, so that you only have 10 objects spawning in 1 tick, rather than 30 spawning in 1 tick - a fire effect sort of gently appears and fades in, so this would not look visually jarring if the smoke particle spawns in a tick later). Again, this is very situational, but always worth considering. Anything for dem sweet performance gains.

Further to the above, you could create the objects earlier and have a "pool" of objects to pick from, so that you are not creating many objects per tick. If you can determine a minimum amount of objects that would ever need to appear at once, and it's not over like 50 objects (50 is a random number, could be lower on mobile), then you could create these at start of layout and keep them invisible, make sure everything about the object is disabled (no behaviours enabled, particles not spraying), and have a Boolean value in the object called "IsActive", then upon needing one of these objects, you can simply do an event for "IsActive = False" and "pick nth instance 0" to get an object, and then set IsActive to true whilst it is in use (and set it back to false and hide it again when no longer needed - don't "hide" the object every tick, do it in the event where the object is becoming inactive).

With particles, if you are a heavy user of particles, consider dynamically adjusting the rate/lifetime whenever many particles exist (rate is probably more appropriate, since lifetime could visually ruin an effect, but still worth considering). E.G. If you had to spawn in 10 confetti particles effects, then upon creating these, check how many other active particles exist and lower the particle rate, and also pick other existing particles to lower their rate too. It is best to determine the lowest rate that looks visually appealing, so that you don't set the rate too low and ruin the effect. If there's many particle objects, it may be expensive to have to loop through all objects to lower their rate, so be careful and mindful about this, and always measure performance.

Try to not have too many layers with "force own texture". I always thought many types of effects required "force own texture", but it's surprisingly few and far between - In my effect-heavy game, out of about 30 layers, I only need 2 layers with "Force own texture" enabled. It is mostly needed when using blend modes such as "destination out", "source in", etc, and whenever you want to blend two additive objects without taking into account the layers below. If you require blend modes such as destination/source, then it may be worth exploring the drawing canvas plugin, as you can paste objects with blends into the drawing canvas and it can "carve" shapes out of the drawing canvas and such. Pasting objects can be more expensive overall, but if its between using "force own texture" on a layer, compared to pasting 2 objects on a 100x100 drawing canvas, then it might be worth going with the drawing canvas (again though, measure CPU/GPU performance to see if it was truly worth it!)

When using the Preview Debugger to watch event CPU usage, you may find that a specific group is reaching high CPU usage. If you are unsure what could be causing it, you can create many small groups in this group, name them A, B, C, D, etc., and then put only 1 event in each of these groups (don't accidently reorder your events!). Then upon checking the debugger again, you are likely to discover which specific event was causing the high CPU usage, and you can figure out a solution from here.

It is worth having a SpriteFont always onscreen with a few variables displayed, such as FPS, CPU utilisation, GPU utilisation, and Object Count. Recently, I found that my large project was lagging after long play sessions, but I realised the "object count" was increasing way higher than it should, which gave me the clue that I was not destroying objects correctly - After realising this, I could then use the debugger, play the game for a while, check the list of all object counts in the debugger, and discovered which specific object was not getting destroyed and resolved the lag issue.

That's a few thoughts off the top of my mind, hope someone finds any of this useful. I'm interested to learn more and am curious what anyone else will post.

I understand, and I shared the same frustration when CA was first announced, but after thinking about it, I don't really feel that way anymore. I mean, whether they're working on CA, or more 3D features, or whatever new C3 feature, then this could always be perceived as "why spend time on these features, when there's major bugs to fix, such as the jank issue?". I personally wish they would focus on the event sheet editor as top priority, but many would disagree (and for good reason, since jank is an unacceptable issue when releasing a game). When there are major bugs with C3, you tend to see hotfixes get released ASAP, which is good to see, especially if it is a bug that affects saving project files or something, but some bugs are either not clear to Scirra (hence them asking for bug reports, I know this jank topic comes up a lot, but I don't know if anyone has posted a bug report), or Scirra are at the mercy of those chrome bugs being answered.

I agree with the "employing new staff" point, hopefully that's incoming, as this seems like a win win, allowing staff to focus strongly on specific areas of programming or research and such.

Hypothetically, let's assume they stopped focusing on CA and even new C3 features, and let's assume they got some new staff, and then they focused 100% of their attention on this jank issue - Judging by what has been said, I think we would still be stuck, as it relies on these chrome bugs to be answered(?) If there was a solution or workaround, I like to believe that Scirra would be trying that solution now, or at least working towards it, and Ashley mentioned they have indeed done work towards this (although the issue continues, so yeah, get dem bug reports out there). If it is the case that we truly are at the mercy of those chrome bugs being answered, should Scirra find a completely different approach? Maybe, maybe not. Do other HTML5 engines like Phaser or GDevelop suffer the same issues? I have no idea, but this could be good to demonstrate to Scirra.

I 100% agree with having choice for vsync and frame limits, and I definitely can see the benefits for both PC and mobile if this was implemented.

I do agree that a frame limiter would be great, and I do see other engines that have this (you mentioned Phaser, also GDevelop allows you to choose a maximum FPS). I trust that Scirra haven't implemented something like this for a fair enough reason, whether it's chrome interfering with how C3 is designed, or whatever it may be. But at the end of the day, I would love to give people the ability to choose to have vsync/frame limiters on or off, much like all games allow you to (I always have vsync off whenever I play games, especially rhythm games or quick-reaction games such as platformer or FPS games).

On my own project, a desktop rhythm game, I have different settings for visuals, and when on "Ultra", I do see jank when cpu and gpu usage are both about 60% and the FPS is always stable, maybe dips lower by 1 FPS now and then. Whilst I could optimise my game and visuals, the thing that teases me is that, the jank is significantly lowers when vsync is set to "ticks only". I have not been able to reproduce this in a minimal project though. But when I can just flick a switch to turn vsync off and get the smoothest experience, it makes me wish we could just set a max FPS cap and be done with this, allowing the player to decide whether they want to use vsync or not, limit FPS or not. I have a 240hz monitor, and playing on ultra, some players may wish to lower the max FPS, just to keep the FPS stable, but I can't expect players to have to go into their computer settings to lower their monitor hz just to play. I really do wish there was a max FPS cap option.

I do not agree about Scirra being unaware or choosing to ignore the issues, and I don't agree with Construct Animate consuming Scirra's time, and I am someone that is currently not the target audience for CA - you have to imagine that since CA is literally C3 but with different things enabled/disabled, the development process must be very trivial rather than Scirra starting with an entirely new base for CA - not to mention that most updates get applied to C3 too, and only video exports have been the unique feature for CA so far. Also, if Scirra do work on a CA-only feature, they always seem to multitask and add a bunch of other fixes and changes within an update, so it's not like C3 gets abandoned whilst they work on CA. If Scirra turned a blind eye to issues so that they can work on CA, then yeah that would be a problem, but so far I have not observed this. Assuming those starred chrome bugs end up with a solution from Google, I'd bet that Scirra would be straight on this.

But! The thing is, yeah, some of those chrome bug reports haven't been updated for months now, so it does give a sense of "what now?", like are we relying on chrome devs to resolve this, which have no timeframe or deadline or anything, whilst C3 devs (particularly mobile devs) are patiently waiting and we are all at the mercy of Google? If they cannot resolve anything, is it up to Scirra to find a workaround or solution? I do not know.

I am unsure if this applies in Construct 3, but:

I find that, when testing gamepads, if I connect and disconnect controllers a lot, sometimes the controllers get assigned to random players at times (I.e the x box controller light is set to player 3, even when there are no other controllers connected).

If you test, try rebooting with only 1 DDR pad connected, and see if it works? Perhaps it is getting assigned to player 2 or 3 or something.

Thanks for the info R0j0 and WackyToaster!

I have now created a suggestion for collision filtering. Feel free to vote for it and write other examples you can think of:

https://construct23.ideas.aha.io/ideas/C23-I-128

I do think the LiquidFun library looks really cool - I have to wonder if it would be a tricky decision for Scirra to implement, I wonder if be compatible with the "Physics" behaviour, in the sense that, if someone threw in the "LiquidFun" behaviour/plugin into their project and expected their existing Physics objects to interact with LiquidFun, would that work, or does Box2D and LiquidFun exist as completely different methods of physics? No clue, but just a thought on the potential complexity of this. Regardless, I have voted because it is definitely something I'd use and assuming it's designed to be extremely performant compared to a bunch of Box2D objects simulating water, then heck yes!